What are Virtual Appliances?

Virtual Appliances are portable virtual machines. One can export a virtual machine as a virtual appliance, and then you can also import the virtual appliance back as a virtual machine.

Virtual Appliances are available either as a folder of files – OVF (Open Virtualization format) or as a single (tarball) file – OVA (Open Virtualization archive).

Why use Virtual Appliances?

Since you already have a existing virtual Infrastructure, you can use the same for running virtual appliances. Virtual Appliances are essentially a VM which is pre-installed with a Operating System (OS) and an application. Virtual Appliances are built is such a way that you just import the appliance and start using it with a minimal network and application configuration.

Advantages of Virtual Appliances:

Both physical and virtual will require a approval from the finance team. However after the finance approval, implementing a virtual appliance will require no more approvals.

  1. No need for approval from the data-center team for rack space
  2. No need for approval from the networking team for free ports on network switches
  3. No need for approval for power requirement
  4. No need for approval for air conditioning or cooling needs

All these approvals basically increase your deployment time to anything about 4-6 weeks, whereas if using a virtual appliance that comes down to about 2 hours. Other advantages of virtual appliances include:

  1. Standard off-the-shelf server hardware used for running virtual appliances
  2. Reduces AMC costs as one less hardware vendor to manage
  3. Easy to standardize on a single hardware vendor
  4. Improves return on your investment in hardware infrastructure

You can find several free and paid appliances available from various vendors. VMware has something called as VMware Virtual Appliance Marketplace. Several free Linux based opensource virtual appliances are available from Turnkey Linux. You can also build your own virtual appliances using the SUSE Studio. You can also find a free Linux based L3 switch appliance at VyOS. You can also find the excellent Monowall Firewall as a virtual appliance for vSphere.

Overall I believe virtual appliances are here to stay and the easy of management and deployment is what makes them a very attractive form factor.




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! 🙂