Well, it’s another day another fight. As we started migrating our VM’s from the old VMware ESX farms to the new environment, and upgraded the hardware suddenly the network devices were hot-plug-able, thus they did turn up in the “Safely Remove” dialog.
I myself don’t have any trouble with that. The trouble I do have is the people working with those VM’s and their possibly hazardous “uuuh, what’s this ? I don’t need this! <click-click, network-device unplugged>”
So I went googling (why isn’t that a dictionary term by now ?) and foundsomething. Simple solution is to disable the hot plugging of hardware in the VM’s settings.
I’ve been tinkering with VMware’s Data Recovery for the last two weeks (as in configured it some time before Christmas) and had it running all that time. I have to say the integration into the vCenter Client GUI is amazing, I’d love to see that for VCB also. The Changed Block Tracking is a neat way to minimize the amount backup data as well as your backup window (which is nearly zero anyhow due to vDR using snapshots).
What I don’t like about Data Recovery is the fact that you ain’t allowed supported to install any kind of backup agent inside. I was looking into Data Recovery because I wanted to replace VCB’s functionality with something tightly integrated, that even our, well lets say — not so vCenter centered workers — could use (restoring a VM with vDR is real easy, just three clicks and you got a previous version of your VM — even if it has been deleted).
I guess, we do have to stick to Consolidated Backup for now, until VMware redesigns vDR or polishes VCB.
I’ve been learning for my VCP-410 exam the last week or so, and what can I say ? It helped … 463 points of a total of 500 points ain’t that bad at all (considering I spend twenty minutes doing it).
Sure, I could have spent more time, and do better than 92,6%, but then again: why should I ?
The achieved points (nor the percentage) don’t appear on the certificate (or at least it didn’t on the old one), so why bother. Anyway, that was my christmas present to myself, it that light; happy christmas ya’ll.
Some of you may know, that VMware released vSphere 4.0 Update 1 yesterday. I took this as a reason, to finally wrap my head around booting the VMware ESXi installer from my PXE/TFTP box. Since VMware was kind enough to provide (a somewhat worthless) document, that explains how to extract the necessary files on Windows. But that quite doesn’t work with Linux — and VMware just states that you should be using mount and it’s option offset.
Luckily there are smart people around. Cameron shows exactly as to how you’d mount the dd-image. If the dd-image is mounted, you just need to copy over cim.vgz, license.tgz, oem.tgz, sys.vgz, vmk.gz and vmkboot.gz. After doing so, you should add a section to your pxelinux.cfg that kinda looks like this:
I’m just tracing some troubles I’m having with a backup server and two (independent) network adapter ports (as in two ports on two different dual-port nics). If I enable the port and set it to auto configuration, it’ll get 100MBit/Half-Duplex, but the Portgroup becomes unavailable.
In order to get the connection back, I need to logon on the console (thank god even the backup server got an iLO2), and manually (as in esxcfg-nics -s 1000 -d full vmnic1) configure the adapter to 1GBit/s and full-duplex.
Since I didn’t want to go downstairs and trace the damn cables, I figured I could use the CDPfeatures included in ESX. Turn the NICs on as 100MBit/Half-Duplex and run:
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:
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:
vCenter: Cannot decrypt password
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.
Well, if you’re gonna update a SLES10 (or even a SLES11) VM, you created with Virtual Infrastructure, you’re gonna run into a snag (like I do). Grub (or rather the kernel itself) is gonna barf.
Now, I searched for a while and didn’t find anything specific on the net, so I’m gonna write it down. Up till 3.5U4 the maximal resolution you’d be able to enter within a virtual machine was vga=0x32d (at least for my 19″ TFT’s at work). But now, after the upgrade to vSphere that isn’t working anymore.
Popped in a SLES10 install-cd selected the maximal resolution from the menu and switched to a terminal soon after it entered the graphical installer. A short cat /proc/cmdline revealed this: vga=0x334.
After switching these parameters in grub’s menu.lst, everything is back in working order and not waiting 30 seconds on boot …
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.
