vSphere: SFCB configuration has changed

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.

vSphere: no coredump target has been configured (fix it w/ powershell)


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 = get-credential
#Echo "n" because I don't want or care for putty/plink to record the server ssh/rsa key.
$ClusterHosts = Get-Cluster myCluster | get-vmhost
Foreach ($ClusterHost in $ClusterHosts)
{
$ClusterHost| Get-VMHostService | Where { $_.Key -eq "TSM-SSH"} | Start-VMHostService
echo n | C:\someplace\plink.exe $ClusterHost.Name -l $creds.username -pw $creds.GetNetworkCredential().password "esxcli system coredump partition set -u; esxcli system coredump partition set --enabled true --smart"

$ClusterHost| Get-VMHostService | Where { $_.Key -eq "TSM-SSH"} | Stop-VMHostService -confirm:$false
}

Alan wrote a little snippet awhile back where you can insert it so that it'll download plink automatically for you.  It's also how I remember the little echo trick.

[Update: Just realized that this needs SSH service turned on and that I really didn't include loop statement.  Snippets inserted above]

Even better way:
$ClusterHosts = Get-Cluster myCluster | get-vmhost | get-esxcli
Foreach ($ClusterHost in $ClusterHosts)
{
$ClusterHost.system.coredump.partition.set($null,$null,$null,$true)
$ClusterHost.system.coredump.partition.set($true,$null,$true,$false)
}

VMware: Error 26002/26006 - Upgrading vCenter from 5.0 to 5.5 w/ CA signed certs

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:

  1. Shut down and disable services on original VM.
  2. Rename original VM.
  3. Rename new VM to original VM's name.
  4. Create the following directories on new VM:
    1. C:\ProgramData\VMware\Infrastructure\Inventory Service\SSL
      • ProgramData is typically always on C: drive, so this is a must.
    2. C:\ProgramData\VMware\VMware VirtualCenter\SSL
      • ProgramData is typically always on C: drive, so this is a must.
    3. C:\Program Files\VMware\Infrastructure\Inventory Service\SSL
      • C: drive can be replaced w/ drive that you plan to install inventory services.
  5. Copy your signed certs from your old VM to this new one in the above directories.
    1. rui.pfx
    2. rui.crt
    3. rui.key
      1. 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.truststore
        • sms.keystore
  6. End Result before installations begin, should look like this:
  7. Once you do this and backup the SQL server database, you should be ready to move forward.

Details:
Essentially, getting the error above was because I did not follow VMware's instructions on updating my signed cert.  If I did things properly, meaning updating both the Inventory Service and vCenter Service w/ the same signed cert, I would not have gotten the above error.

Meaning I generated a signed cert from my internal CA and only applied it to the vCenter service.  The Inventory Service was still using a self-signed cert, which when an upgrade is attempted causes it to blurt out the above error.

vSphere: Update Manager - Cannot run upgrade script on host

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)
or
cp /opt/vmware/uninstallers/VMware-fdm-uninstall.sh /tmp
chmod +x /tmp/VMware-fdm-uninstall.sh
/tmp/VMware-fdm-uninstall.sh

Reference Sources:

Powershell: Out-Gridview -passthru switch

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:
  1. Gathers a list of VMs
  2. Outputs that list into gridview
    1. 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.
  3. 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.

Basically, you can make use of it anytime you want prompt for a choice and just insert out-gridview in-between your source and destination.
So using the example above, lets say I want to stop a specific process, but I don't know the name of it.  Normally, I would get the list of processes by using get-process, record its name or PID, etc. then capture it a variable or just pipe it to stop-process.  Out-Gridview makes this a one step process:

Get-Process | Out-GridView -passthru | Stop-Process 

Now I just highlight the process I want to kill (granted you can do this in task manager, but hopefully you see the concept), and click OK.