Zsoldier's Tech Blog

Was getting this error when applying a host profile.  It happened after I changed the DVS/vDS 'NAME'.  I updated it in the host profile too.  It's a nondescript error that I couldn't figure a way around.  So what did I do?  Deleted the profile and created a new host profile based on a host I knew was configured correctly.  Voila, SFCB configuration has changed error/noncompliant host profile state GONE! Resolve by simply deleting and recreating host profile.

Was able to fix the above error by following steps outlined here: http://blog.ukotic.net/2015/05/31/no-vmkcore-disk-partition-is-available/ So that inspired me to write how you can do this against multiple hosts via a scripted method.  I started by simply exporting a list of servers via PowerCLI: Get-Cluster myCluster | get-vmhost | select name | out-file -FilePath D:\scripts\Output\clusterlist.txt -Encoding ascii I opened the txt file, removed the 'name' header, then ran the following: for server in $(cat ~/Desktop/clusterlist.txt); do ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no root@$server 'esxcli system coredump partition set -u; esxcli system coredump partition set --enable true --smart' done A better way to do this would be to use plink, above was a quick and dirty way for me.  So here is a way to do it all from Powershell only that quite frankly would've saved me the trouble of pasting the password in 20 times: $Creds =...

There are troves of these articles online about this so I'll try to keep this concise. Steps for moving from one VM (assuming Windows and SSO/PSC already in place) to another: Shut down and disable services on original VM. Rename original VM. Rename new VM to original VM's name. Create the following directories on new VM: C:\ProgramData\VMware\Infrastructure\Inventory Service\SSL ProgramData is typically always on C: drive, so this is a must. C:\ProgramData\VMware\VMware VirtualCenter\SSL ProgramData is typically always on C: drive, so this is a must. C:\Program Files\VMware\Infrastructure\Inventory Service\SSL C: drive can be replaced w/ drive that you plan to install inventory services. Copy your signed certs from your old VM to this new one in the above directories. rui.pfx rui.crt rui.key In the case of the VirtualCenter SSL directory, you'll probably also need the following, I think they are used for the custom spec passwords: sms.trustst...

Ran into this problem on about 3 hosts when upgrading from 5.0 to 5.5. 2 of the hosts were resolved following this KB: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2007163 KB basically states to check /altbootbank or /bootbank and move the file located in stage.xxxxxxx the the directory above it. 1 of the hosts required the KB above in addition to uninstalling the FDM agent by doing the either of the following: Remove Host from HA (This removes the fdm agent, use command lines below if needed) o r cp /opt/vmware/uninstallers/VMware-fdm-uninstall.sh /tmp chmod +x /tmp/VMware-fdm-uninstall.sh /tmp/VMware-fdm-uninstall.sh Reference Sources: https://communities.vmware.com/thread/499255?start=0&tstart=0 http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2007163

My co-worker saw this on twitter and sent this to me: get-vm | out-gridview -passthru | open-vmconsolewindow Upon first glance, I was thinking: "Well, that'll kill my machine trying to open 10000 VM consoles". But upon closer inspection, it works a bit differently than I first thought. Basically what the above does is this: Gathers a list of VMs Outputs that list into gridview Clicking OK on the highlighted row, passes thru the highlighted 'object' to the next command. You can also select multiple rows and have them all pass to the next cmdlet.   I assume this will only work if the next cmdlet knows how to handle multiple objects. In the case of Open-VMConsoleWindow, it does work. Open-VMConsoleWindow takes in the highlighted object and runs. I didn't realize out-gridview had a passthru option, but now that I do, that can certainly make interactive scripts easier when I want someone to make a selection.  Obviously when I want to be lazy. ...

Found this snippet online. foreach ($loopnumber in 1..2147483647) {$result=1;foreach ($number in 1..2147483647) {$result = $result * $number};$result} Works great, but only seems to hit a single CPU.  In order for it fully load all CPU's, I decided to augment it by simply having it launch a powershell window per CPU/Core found w/ the same script running in a loop. Here is what I came up w/ below: #$NumberofProcs = (Get-WMIObject win32_processor | Measure-Object NumberofLogicalProcessors -sum).sum #Updated based on anonymous feedback. $NumberofProcs= [int]$env:Number_of_Processors While ($NumberofProcs -ne 0) { $NumberofProcs-- Start Powershell.exe -ArgumentList '"foreach ($loopnumber in 1..2147483647) {$result=1;foreach ($number in 1..2147483647) {$result = $result * $number};$result}"' } For some context, I was using this script to force vRealize Operations to send a notification for anomalous behavior on a typically low use VM. Thanks anonymous! I...

So my esteemed colleague, Andrew Harding , brought this to my attention and the idea has kind of blossomed.  I thought it was rather clever approach to implementing VSAN in a cost effective manner. The current line of thinking w/ VSAN is that you buy each host w/ the exact same disk configuration. In this way, with each host purchase, you not only get capacity, but you get additional I/O and CPU/Memory performance. Disclaimer: Mac Mini's are completely unsupported by VMware, this is for illustration purposes only. There are a couple problems w/ this model: Additional vSphere license cost Additional VSAN license cost Additional Hardware SSD/Disk cost Being that VSAN does NOT attempt to keep VM storage data local to a host, you can augment your VSAN cluster w/ simple compute hosts that have no storage.  Meaning, if you don't have storage capacity or I/O performance problems, you can simply add another host that does not participate in the VSAN for additional C...