On 19th November, VMware released vSphere / ESX and ESXi 4 Update 1. It also comes along with the release of updates for VMware Data Recovery 1.1 and VMware CLI tools for vSphere / ESX 4.
VMware ESX 4 Update 1 Release Notes
VMware Data Recovery 1.1 (VDR) Release Notes
VMware vSphere PowerCLI 4 Update 1 Release Notes
Popularity: 2% [?]
Since VMware are allowing currently certified VCP3′s to do the VCP4 exam before December 31, 2009 without having to take the Install, Configure, Manage course AND are offering a free 2nd shot [link], I have booked in my exam. Giving myself about 2 weeks to study the new stuff in vSphere / vCenter Server and refresh everything VI3.
Study will be based around the following:
Beyond that I’ll get some practical time in running up ESX hosts, building vCenter, using Update Manager, trying to test as much as possible of the new features (vMware FT, Distributed vSwitches, DPM, etc).
Popularity: 8% [?]
As an update to this post, a snapshot chain could also become corrupt if for some reason the .vmsd file (snapshot definition file) does not get updated when a snapshot is taken. The result of this can be seen by running:
vmware-cmd <vm-name>.vmx hasnsapshot
and it returning blank, or by checking Snapshot Manager in Virtual Center and it being blank, however you know snapshots exist because when you check the VM’s .vmx file, it is referencing snapshot delta files not the parent vmdk.
The .vmsd file’s purpose is to maintain information about the snapshots on that VM. It is read by Virtual Center to get the snapshot name and chain details. It is also read by vmware-cmd in the above command.
The solution is is to first confirm that hte current snapshot CID / pCID chain and fix that if it is broken. Then remove the .vmsd file. Next, create a snapshot on the VM either through vmware-cmd or through Virtual Center (it’s best to do this logged into the ESX host directly rather than Virtual Center because we will also remove it from the host). Next, check the snapshot chain either in Virtual Center or using vmware-cmd, this time you should see hassnapshot = 1 and the fiull, correct chain in Virtual Center. Finally, if the chain is restored correctly, remove the snapshot chain as you would normally.
Popularity: 23% [?]
A VMware virtual disk is made up of two files, the disk descriptor (<name>.vmdk) and the disk content itself (<name>-flat.vmdk). Using Virtual Center, you can move virtual disk files around (i.e. folder to folder), but it will not let you rename them. To do this you have two options: mv or vmkfstools.
Using mv:
SSH to the ESX host, cd to the location of the virtual disk. Oh, if the disk was attached to a VM, that VM needs to be powered off. Type:
mv oldname.vdk newname.vmdk
mv oldname-flat.vmdk newname-flat.vmdk
Next, need to edit the descriptor file so it can locate the disk (you can use vi, pico, nano):
vi | pico | nano newname.vmdk – Locate the old name in the file and edit to match the new name. Write out the file.
Using vmkfstools:
vmkfstools can rename the files and update the descriptor all at once (command is all on one line):
vmkfstools -E /vmfs/volumes/path/to/oldname.vmdk
/vmfs/volumes/path/to/newname.vmdk
Finally, if the disk was attached to a VM, back in Virtual Center (or by editing the .vmx for the VM) edit settings for the VM and point it to the newly renamed virtual disk. You can then power on the VM.
Popularity: 18% [?]
Have recently had to deal with a virtual machine regularly failing to remove snapshots via VCB. The VM has 3 VMDK’s connected to it and I’ve seen as many as 11 delta files per disk (through VCB and troubleshooting efforts, etc) – that’s 33 snapshot deltas in the working directory!
Anyway, what can happen is the snapshot chain gets corrupted somehow and needs to be consistent before ESX can remove commit the snapshots back into the parent VMDK. You can see this happen when you run vmware-cmd .vmx removesnapshots and it returns quite quickly with an error.
What to look at:
You need to go back through the VMDK chain and ensure that the parentCID and CID for each vmdk is intact and effectively makes a linked list of hex values that ties each delta to the next, all the way back to the parent disk.
How to look at it:
Open an SSH session to the ESX host, cd to the snapshot working directory for the VM in question (likely going to be the location of the VM’s .vmx config file).
ls -lah to check out the contents of the directory. We are looking for the *-00000X.vmdk files
Starting with the original VMDK (you can cat the .vmx file to find out where that is located), cat the .vmdk file to check out the first CID field (the parentCID for the original VMDK will be all f’s).
Take note of the CID then cat the next VMDK in the chain (i.e. the first delta’s VMDK file). The parentCID field should match the CID value you noted.
Rinse and repeat all the way up the chain.
How to fix it:
A broken link in the chain will be a VMDK that has the same parentCID as CID. Either field needs to be changed to something else (just change one letter or number is fine) then the corresponding file either up the chain or down the chain (depending on if you chainged parentCID or CID) also needs to be updated to complete the chain.
Then, run vmware-cmd .vmx removesnapshots again and it should commit correctly.
I know the above isn’t all that clear – writing from memory rarely is. Will try to update when I have an example to refer to. Note there are a lot of good examples at http://communities.vmware.com
Popularity: 100% [?]
