Vcenter

I’ve been meaning to post this, but never actually got around to doing that. When installing vCenter 5.0, an instance of ADAM is installed, which stores all the configration data for Linked Mode. It basically boils down to running this script and rebooting the box: 1 2 reg DELETE "HKLMSYSTEMCurrentControlSetservicesADAM_VMwareVCMSDSParameters" /v "Port SSL" /f reg ADD "HKLMSYSTEMCurrentControlSetservicesADAM_VMwareVCMSDSParameters" /v "Port SSL" /t REG_DWORD /d 0000027c /f This is no new invention of myself, just writing it down for myself from here or here.

I recently reinstalled the vCenter Server at work, and in my never ending wisdom cough, I decided to do that on new hardware. That entitled using the same host name plus the appendix _NEW. Now, I know this isn’t conforming with DNS naming schemes (iirc underscore isn’t a valid DNS char), however it worked … So once I had everything installed on the new hardware, I switched the ESX servers from the old vCenter to the freshly installed one. Once that was finished, I shut down the old vCenter server, changed IP address and host name of the new one and rebooted. That basically worked, even though suddenly every ESX in my inventory was disconnected. After reconnecting all ESX servers everything was back online. ...

We’re currently thinking about automating Windows Updates and the involved disaster snapshot-copy to a degree, where we don’t need to intervene anymore. Right now, we already have a rudimentary scheduler in place, which does the reboots for some (200 ..) systems already. Now, we’d like to extend it to also cover the bi-weekly Windows Update spree. Since PowerShell (and PowerCLI) work quite well with vSphere automation, I cooked up the below script to first shutdown a virtual machine (for snapshot consistency reasons), then take a snapshot and power on the virtual machine again afterwards. ...

Well, PowerCLI makes my life a little bit easier. Believe it or not, each of us vCenter infrastructure admins has one of these: a Windows admin, thinking a snapshot is also a backup. Thankfully, Alan Renouf over at virtu-al.net wrote the SnapReminder, which already helped me a lot! However, occasionally the script isn’t finding the snapshot author (for whatever reason). Since I want a notification in that case, I modified the script a little bit to suit my needs. ...

These last few weeks, I’ve been toying with PowerCLI (and PowerShell for that matter). One thing I do have to say, is that Microsoft finally did it right! It’s a useable, program-able command line interface for Windows after all! Thanks to Ivo Beerens and his post " Best practices for HP EVA, vSphere 4 and Round Robin multi-pathing", I was able to come up with the below: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 # LICENSE: GNU General Public License v2. (see LICENSE.txt) # COPYRIGHT: Copyright 2010 Christian Heim <christian.heim@barfoo.org> # Add the VI-Snapin if it isn't loaded already if ( (Get-PSSnapin -Name "VMware.VimAutomation.Core" -ErrorAction SilentlyContinue) -eq $null ) { Add-PSSnapin -Name "VMware.VimAutomation.Core" } if ($args.length -lt 2) { Write-Host Write-Host "fix_multipathing: " Write-Host " - Display-Name of the vCenter cluster, we should check all LUNs" Write-Host " on all available Hosts, and set the Path Selection Policy" Write-Host " to the selected one." Write-Host "" Write-Host " - Path Selection Policy" Write-Host " Possible:" Write-Host " - RoundRobin (VMW_PSP_RR, Round Robin)" Write-Host " - Fixed (VMW_PSP_FIXED, Fixed)" Write-Host " - MostRecentlyUsed (VMW_PSP_MRU , Most Recently Used)" Write-Host exit 1 } $vcserver = "vcenter.home.barfoo.org" $cluster = $args[0] $target_policy = $args[1] # Since I do have only SVC-Disks connected to my hosts, I limit the search to those $canonical_name = "naa.6005076801808021*" Write-Host "Target vCenter Cluster: " $cluster Write-Host "Target PSP: " $target_policy Write-Host switch ($target_policy) { RoundRobin { $display_policy = "VMW_PSP_RR"; } MostRecentlyUsed { $display_policy = "VMW_PSP_MRU"; } Fixed { $display_policy = "VMW_PSP_FIXED"; } default { Write-Warning "Unknown PSP selected! Please consult the help and try again."; exit } } Connect-VIServer $vcserver >/dev/null 2>&1 Write-Host "Found "@(Get-VMHost -location ( get-cluster $cluster ) | Get-ScsiLun -CanonicalName $canonical_name -LunType "disk" | where {$_.MultipathPolicy -ne $target_policy }).Count" LUNs in "$cluster" not using Path Selection Policy "$display_policy Get-VMHost -location ( get-cluster $cluster ) | Get-ScsiLun -CanonicalName $canonical_name -LunType "disk" | where {$_.MultipathPolicy -ne $target_policy } | Set-ScsiLun -MultipathPolicy $target_policy >/dev/null 2>&1 This works great, however you could make it work on the whole vCenter inventory, which I don’t want. We usually add LUNs to a single cluster at one time. Only thing you might need to change, is the canonical name. Mine simply says “find all SVC LUNs” and you might need to change it, if you’re using a different storage.

Finally, after about 6 months (I last talked about that on February 25th, when Virtual Center 2.5U4 was released) our troubles with our " custom" certificates seems to be resolved! As it turns out, it really was our fault and not VMware’s. When generating the pfx from the signed certificate and the key-file, you need to supply a password, otherwise the vCenter service is unable to utilize the private key of the pfx, since it’s unable to access the PFX with the default password ( testpassword is the default for Virtual Center as well as vSphere). ...

Well, as I am in fact running a german Windows XP, the VI Client started displaying all menus and operations in German when I updated to 2.5u2. Normally, I wouldn’t have much of a problem with that, but recently it started to annoy me, since the translation is a bit off from the real meaning of much of the operations. So today, in the morning I started looking for ways to revert the VI Client back to displaying everything in English. And guess what. There’s no way to switch the language from the VI Client itself. There’s just a workaround. ...

Well, today the support request came back. Seems one of the originally linked VMTN dicussions really is the only way: Export the customization specification Edit the XML file Import it again The related part inside the customization specification should then look like this: 1 2 3 4 <type>vim.vm.customization.Password</type> <plainText>true</plainText> <value>Password01</value> </password> So if you ever think about switching the default VirtualCenter certificate (for whatever reason), make sure you use the above workaround. Otherwise VirtualCenter is gonna fail miserably during the customization phase of the cloning process.