WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud
  • Tanzu
    • Application Modernization
    • Tanzu services
    • Tanzu Community Edition
    • Tanzu Kubernetes Grid
    • vSphere with Tanzu
  • Home Lab
  • Nested Virtualization
  • Apple

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

11.22.2011 by William Lam // 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.

Categories // Uncategorized Tags // esxi4.1, snapshot, vim-cmd, vimsh

VMware officially releases vibddi for vSphere 4.1

09.18.2011 by William Lam // Leave a Comment

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

  • VMware Fusion 4
  • VMware Workstation 8
  • VMware vCloud Director 5
  • VMware Site Recovery Manager 5
  • VMware View 5
  • VMware vFabric 5
  • Microsoft Windows 8

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.

Categories // Uncategorized Tags // esxi4.1, vib, vibddi, vSphere 4.1

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

08.16.2011 by William Lam // 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.

Categories // Uncategorized Tags // esxi4.1, esxi5, kickstart, upgrade, vSphere 5.0

  • « Previous Page
  • 1
  • 2
  • 3
  • 4
  • 5
  • …
  • 12
  • Next Page »

Search

Author

William Lam is a Senior Staff Solution Architect working in the VMware Cloud team within the Cloud Infrastructure Business Group (CIBG) at VMware. He focuses on Cloud Native technologies, Automation, Integration and Operation for the VMware Cloud based Software Defined Datacenters (SDDC)

Connect

  • Email
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • Vimeo

Recent

  • Automated ESXi Installation with a USB Network Adapter using Kickstart 02/01/2023
  • How to bootstrap ESXi compute only node and connect to vSAN HCI Mesh? 01/31/2023
  • Quick Tip - Easily move or copy VMs between two Free ESXi hosts? 01/30/2023
  • vSphere with Tanzu using Intel Arc GPU 01/26/2023
  • Quick Tip - Automating allowed and not allowed Datastores for use with vSphere Cluster Services (vCLS) 01/25/2023

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2023