The usual IT babble
Posts tagged vCenter
Custom certificates in VMware vSphere
Jul 24th
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).
As noted in the Replacing VirtualCenter Server Certificates document for Virtual Infrastructure 3, as well as through our Customer support, you need to specify the password when exporting the signed crt/Private key into the pfx:
openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui \
-passout pass:testpassword -out rui.pfx
After successfully doing so, you just need to replace the original files (hopefully move them away beforehand) with the ones generated. And afterwards, you should be able to utilize your new certificates! When you now try to clone a template and customize it using an existing customization spec, you’re gonna see this:
After clicking on “OK“, you’re gonna get the normal customization specification edit frame, where you should be able to skip ahead to “Workgroup or Domain“, where you’re gonna have to reenter the domain administrator password.
VMware: New VirtualCenter 2.5 Update 4
Feb 25th
As many people on the VM-Planet already blogged about this, I ain’t gonna write just about it. Let’s turn the clock back a few months, to January 2008.
As the institution I work for, is part of the DFN we took the opportunity to be a part of the “I want you to run our RA“-gang. In January 2008 we thought about changing the vCenter certificate. Now, apparently there’s a slight difference between the DFN-PCA and what VMware considers common practice.
The DFN-PCA states, that only CSR’s with a key length of 2048 bits are allowed (as outlined in 6.1.5 of the DFN-PKI Certificate Policy). Now VMware apparently didn’t actually think customers would use this “feature” (that is changing the SSL certificates).
Customization Specifications Created in Previous Releases Can Be Used in VirtualCenter 2.5 Update 4 to Clone or Deploy Virtual Machine with Customized Guest Operating Systems
This release resolves an issue where, if you clone or deploy a virtual machine using a customization specification that was created prior to upgrading the VirtualCenter, the VirtualCenter Server might display the error message The VirtualCenter server is unable to decrypt the passwords stored in the customization specification in the following scenarios:
- VirtualCenter Server is uninstalled first, and then re-installed and/or upgraded afterwards.
- Custom SSL certificate are deployed, but the instruction in http://www.vmware.com/pdf/vi_vcserver_certificates.pdf are not followed in a verbatim manner.
Well, and apparently it ain’t fixed yet. At least not for us
VMware vCenter: <virtual machine> is not connected
Feb 4th
Well, today I once again had the case where a virtual machine (in my case a Virtual Machine Template) was kinda stuck. You couldn’t remove the template (as in the entries for “Remove from inventory” was grayed out) and you couldn’t re-add the Virtual Machine’s VMX from the datastore browser either.
Though, a simple putting the host into maintainance mode and rebooting helped that problem. Maybe there is a simpler solution for this, I just don’t know about it.
Thanks to Sven in #1, I now know that simple solution for my problem!
[root@esxi root]# /etc/init.d/mgmt-vmware restart
Stopping VMware ESX Server Management services:
VMware ESX Server Host Agent Watchdog [ OK ]
VMware ESX Server Host Agent [ OK ]
Starting VMware ESX Server Management services:
VMware ESX Server Host Agent (background) [ OK ]
Availability report startup (background) [ OK ]
Half a minute, and a heart-stopping moment later (all VM’s on that host turn grey after the first update) the VM’s are accessible again. Thanks again to Sven!
VI Client: Changing the language from the system default
Jan 14th
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.
Simply rename the folder in “%ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\2.5“, %ProgramFiles%\VMware\Infrastructure\VIUpdate” “%ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Plugins\Converter Enterprise 4.0.2” and “%ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Plugins\Update Manager 1.0 Update3” named “de” to something else. Tada, your VI Client is back in English.
More VirtualCenter troubles (fini)
Aug 7th
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:
<_type>vim.vm.customization.Password
true
Password01
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.

