vSphere Snapshot Basics – Part 2

More about Snapshots

Snapshots are not backups, but backup software will leverage snapshots to take backups of the VM.

  • When you take snapshots the delta disks can potentially grow to the size of the original disk
  • When you take snapshots be careful because you can easily run out of storage space on the datastore

Snapshot Best Practices

If you plan to take snapshots

  • Do not over commit the datastore capacity
  • In fact you should be under commit by up to 30%
  • Do not create more than 1 snapshot
  • Do not keep snapshots for more that 1 day, in exceptional cases on production VMs (powered VMs) you may keep it up to 2 days

Difference between Clone and Snapshot

Clone is another copy of the virtual machine, where as a snapshot is a capture of point time state of the virtual machine. If you delete the virtual machine, the snapshot will also be deleted along with the it, however the clone will remain intact because its a separate copy.

vSphere Snapshot Basics – Part 1

What is a Snapshot?

  • It is a point in time state of the virtual machine
  • When you take a snapshot a delta disk gets created.
  • If you create another snasphot another delta disk will be created
  • The delta disk is mounted as ReadWrite (RW) whereas the original disk is mounted as ReadOnly (RO)
  • This delta disk is thin priovisioned disk, and grows in chunks of 16MB
  • After creation of Snapshot all disk writes within the VM go to the Snapshot-disk (delta disk) and not to the original disk (flat disk)

In vSphere, snapshots are based on “COW“

COW ==> Copy on Write Snapshots

In COW, all new writes always go to the delta disk.

Enumerating GuestId supported by VMware ESXi

Today when googling for various GuestId supported by VMware ESXi, I found a cool way that someone posted to “serverfault”. Here is a piece of PowerCLI code to do exactly that:


For reference, here is the original link where I found this:



Restore ESXi Connectivity when “Management Network” is deleted

Today one of my friends accidentally deleted the “Management Network” Port Group on a ESXi. Here’s what I did to restore the network connectivity to the ESXi host:


  1. Login to the DCUI of the ESXi host in question
  2. In the DCUI go to “Troubleshooting Options” and “Enable ESXi Shell”
  3. Press “Alt + F1” for logging in via the ESXi Shell
  4. After Logging in execute the following commands to restore the connectivity.

In our case the “Management Network” Port Group, was deleted so first we have to recreate the “Management Network” Port Group:

esxcfg-vswitch -A "Management Network" vSwitch0

After the “Management Network” is recreated, add a VMKernel Interface to the just created “Management Network” Port Group:

esxcfg-vmknic -a -i 10.20.30.x -n "Management Network"

Logout from the shell. Go back to DCUI [Alt + F2]. Logout from DCUI and Relogin and test “Management Network” connectivity.

That’s all.

vCenter Install Issues on Windows 2008

Last week, I was installing vCenter Server 5.5 on a Windows 2008 virtual machine and it used to fail. It seems that vCenter SSO would not install correctly on a machine which has multiple NICs. (Interestingly the vCenter 5.1b installed without any issues on the same setup.)

Here is the exact scenario. My (virtual) machine in question had 3 NICs.

NIC1 (NATed Network with internet access)
NIC2 (Internal Network)
NIC3 (Internal Network)

The issue was, I wanted the vCenter SSO (and vCenter and other components) to bind to NIC2 which connected to an internal network. My DNS server also resides on the same network, and the DNS forward lookups and reverse lookups were correctly configured.But still vCenter SSO installation would always fail. During the install of SSO, I used to select the “hostname” instead of IP Address, and the vCenter SSO would get bound to wrong IP/NIC combo. I changed the adapter priorities but with no success. Insetad of using the hostname, I also tried using the IP Address but with no luck.

Finally, I disabled both the adapters which I did not want to be selected by vCenter SSO, and then did the entire vCenter Server installation. After installation, I checked the access to the vCenter via the Webclient, added a couple of hosts and it all worked. After this, I then re-enabled the disabled NICs and the vCenter Server continued to play nicely.

Moral of the story, if you have a windows machine (physical/virtual) with multiple NICs to be used as a vCenter Server. During the vCenter installation disable the NICs that you do not want vCenter Server to bind to. Complete the install, reboot the machine, and re-enable the disabled NICs.

What really makes me think is during vCenter SSO install, why can’t the install wizard pop a dialog to the user to select the appropriate NIC card for network binding? The current installer behavior is not at all user friendly. This is a classic usability issue that you must avoid. Over engineering for auto-selection of a NIC during install, can be easily fixed by a simple dialog box. Less code to write and audit, gives you less bugs. Keep it simple.

This issue was observed on vCenter 5.5 build#1312299. I was using the vCenter installer ISO for setting up (VMware-VIMSetup-all-5.5.0-1312299.iso). I believe there were a few KB articles that talked about this. Unable to find those articles now.

And yes, I was not using a simple install, i was using a component based installed.

Well and I also want to thank my friend and colleague Atul Bothe, who actually identified a workaround to this issue. Thanks Atul! 🙂

Windows String Search (commandline)

In case, you are looking for a quick string search within files on a Windows machine, you can use the “findstr” tool:


findstr /i /s "my_string_abc"  <folder path>

In the abve example, we use the following modifiers:
/i indicates do a case insensitive search


/s search in sub directories

using * instead of <folder path>  would search for all files from the current folder and below.

You can also find additional information about findstr at  http://ss64.com/nt/findstr.html