WilliamLam.com

New Parameter in vim-cmd snapshot.remove for ESX(i) 4.1 Update 2

by // 2 Comments

While going through my ghettoVCB backlog this past weekend, I came across an issue reported by a user with snapshot removal using vim-cmd in ghettoVCB. It looks like with the recent release of ESX(i) 4.1 Update 2, the "snapshot.remove" required parameters have changed. Prior to 4.1 Update 2, the command would just require a virtual machine's vmid and if it only had a single snapshot, it would automatically consolidate the snapshot.

If a VM had more than one snapshot, users would then need to specify some additional parameters that identified the particular level of the snapshot tree and the snapshot index to be removed. This was pretty difficult to use, even for myself. It now looks like VMware has simplified this command and introduced a new required parameter called snapshotId in ESX(i) 4.1 Update 2.

Here's an example VM with several snapshots and let's say we would like to consolidate snapshot3

First we'll need to query the VM snapshots using vim-cmd vmsvc/snapshot.get [vmid]

As you can see from the screenshot, there is a new property called "Snapshot Id" which can now be passed into the snapshot.remove operation.

After the snapshot3 is consolidated, the snapshot tree is re-displayed again to verify the operation. We can also confirm by looking at the vSphere Client UI

This now makes snapshot manipulation using vim-cmd extremely easy to use.

There is a fix in ghettoVCB.next that will support the new snapshot.remove operation which hopefully I'll be able to release very soon.

VMware officially releases vibddi for vSphere 4.1

by // Leave a Comment

There were several product releases last week that got a lot of buzz on the inter-tube:

However, VMware actually released an additional product last week which snuck under the radar, vibddi.

I actually wrote about this unsupported and undocumented utility last year: How to inject custom drivers into an ESXi 4.1 image using vibddi? vibddi (pronounced vib d-d-i) stands for VIB (vSphere Installation Bundle) Disk Dump Image and it is a utility to help users easily customize ESXi images with custom drivers. This utility first appeared in the vSphere Auto Deploy appliance and it looks like VMware has finally released it as an official tool to support vSphere 4.1 image customization. You also may have heard about the new Image Builder tool with the release of vSphere 5, the origins of that utility actually came from vibddi.

If you are still using vSphere 4.1 and need to inject or modify drivers, I would highly recommend you take a look at the tool as it is extremely simple to use. For more details, please check out the new VMware KB article 2003316 documenting the details of the utility or my blog post. If you are using vSphere 5, you will need to use Image Builder as vSphere 4.1 is not supported and vice-a-versa with ESXi 5 with vibddi.

Note: There are some changes in the latest vibddi utility compared to the one found in the vSphere Auto Deploy such as injecting custom kickstart configuration file or license file. If you rely on these features, you may want to use the older version or manually update these after the system build.

How to Automate the Upgrade of Classic ESX 4.x to ESXi 5

by // 3 Comments

In prior releases of ESXi, there was not a supported method of upgrading from classic ESX to ESXi, you had to perform a clean installation. With the release vSphere 5, ESXi is the only available option and providing a supported and easy method for migrating to ESXi will be very helpful for users. There are currently three options of migrating/upgrading from ESX 4.x to ESXi 5. Going forward in the future, two additional methods will be available for upgrading ESXi 5.x to subsequent update/patch releases.

Here is a table of the supported ESXi 5 upgrade options:

Upgrade Method Upgrade from ESX or ESXi 4.x to ESXi 5.0 Upgrade or Patch from ESXi 5.0 to ESXi 5.n
vSphere Update Manager yes yes
Interactive upgrade from CD, DVD, or USB drive yes yes
Scripted upgrade yes yes
vSphere Auto Deploy no yes
esxcli no yes

The first two options should be pretty straight forward and I won't go into any details, but if you are interested, check out Ivo Beeren's post here. If you decide to use VUM to perform you upgrade, make sure you check out this post about lopsided bootbanks before doing so. The 3rd option is a new feature in a kickstart installation and you now can specify two additional types of installation:

  • upgrade - Tries to perform an upgrade from ESX(i) 4.x to ESXi 5.x
  • installorupgrade - Tries to perform an upgrade from ESX(i) 4.x to ESXi 5.x, if it fails, it will perform a clean installation

In addition to the new installation types, there are two new options that can be specified:

  • --deletecosvmdk - If the system is being upgraded from ESX, remove the directory that contains the old Service Console VMDK file, cos.vmdk, to reclaim unused space in the VMFS datastore
  • --forcemigrate - If the host contains customizations, such as third-party VIBS or drivers, that are not included in the installer .ISO, the installer exits with an error describing the problem. The forcemigrate option overrides the error and forces the upgrade

Here is an example of kickstart specifically for upgrading from ESX 4.x to ESXi 5:

Note: One thing I noticed from the upgrade is that even if you specify a new root password, the current password is still preserved. Virtual machines located on local VMFS volumes will also be preserved as long as you do not use the --overwritevmfs option

You will also know that an ESXi 5 host was upgraded from ESX 4.x when you login to ESXi Shell, a motd will display a message.

As you can see you have several options of upgrading both ESX(i) 4.x to ESXi 5, though if you have a choice between an upgrade and reinstall, my personal preference would still be a clean installation via kickstart or host profiles.