If you are a VMware ESX administrator, you know that a VMware virtual machine consists of several files,  normally contained in a single directory.  There is a configuration file, virtual disk files, and a few other supporting files.  Having all necessary VM files in one directory is the essence of encapsulation.

Let’s say that you have a development environment — not protected by VMware HA — that experiences a host failure.  You repair the host, reinstall ESX, and reattach the disk that contains your virtual machines.  In order to have ESX recognize a VM, it must be registered.  This is easily done with the Datastore Browser, just right-click on the .vmx file and select “Add to Inventory.”

This task can also be performed on the ESX service console (i.e., not ESXi) by using the vmware-cmd utility.  Here is an easy technique, just cd into the VM directory first:

vmware-cmd -s register $PWD/whatever.vmx

After that you are ready to power on your VMs and get back to work — snapshots and all.

Recovering Hyper-V VMs

Unfortunately, with Hyper-V you need to be more proactive — unless a VM is explicitly “exported” it cannot be “imported.”  There is no supported method of importing a VM from a failed host, especially if it has snapshots.  Or is that checkpoints?

Don’t believe me?

For the curious, there evidently is an unsupported technique to put Humpty Dumpty a Hyper-V VM back together again — for data recovery purposes only.  If making symlinks to XML files is your thing, go check it out.

When choosing a virtualization platform, don’t forget about the little things that can make a big difference.

Related posts:

1. Register a LUN full of VMs with PowerCLI
2. These are not the files you are looking for
3. Hyper-V snapshots: not for production
4. Snapshots that shoot back

The VI Client interface will not let administrators create new virtual machines with thin-provisioned disks.  Even so, it is entirely possible that your environment contains such disks.  Let’s take a look at a couple of ways to create these disks and then use a VI Toolkit (for Windows) PowerShell script to see if any exist.

Manual VMDK Creation

One way that thin disks may be introduced into an environment is by manually creating a VMDK file and then attaching that file to a virtual machine.  This can be accomplished by the vmkfstools command with the -d thin option.  This procedure is not for beginners, so if you have used it you presumably evaluated the risks of overcommitting your storage.  But what if one of your colleagues did this without telling you?

Compact Clones

Another source of thin disks requires a little background first:

There is a prominent option in the VI Client interface to convert a virtual machine to template (and vice versa).  But if you right-click a VM in the inventory, you are presented with a variation of that feature:  Clone to Template.

The wizard that launches in response to that option allows an administrator to optionally choose the Compact disk format — this is a thin-provisioned disk.  If your template has a 50GB virtual disk but only 8GB are actually used, this feature can provide significant storage savings.

So far so good.  Now, what do you suppose happens if you decide to convert that template to a VM?  Nothing happens — it just works.  You are free to use that VM just like any other in your inventory.  But this VM keeps its thin-provisioned disk, a fact that is not discernible through the user interface.

Find the Thin-Provisioned Disks

I wrote a small VI Toolkit (for Windows) PowerShell script that identifies latent thin disks in both VMs and templates.  I hope you find it useful:

# FindThinDisks.ps1
#
# Identifies VMs and templates that are using thin-provisioned
# virtual disks.
 
# Version 1.0  January 14, 2009
# Eric Gray
 
$vmtp = Get-VM
$vmtp += Get-Template
 
foreach($vm in $vmtp | Get-View){
  foreach($dev in $vm.Config.Hardware.Device){
    if(($dev.GetType()).Name -eq "VirtualDisk"){
      if($dev.Backing.ThinProvisioned -eq $true) {
        $vm.Name + "`t" + $dev.Backing.FileName
      }
    }
  }
}

Thin-provisioning is a great tool to have in your toolbox, when used properly.

Script inspired by this thread.

Related posts:

1. vSphere Thin-Provisioned Disk Performance
2. Responsible Thin Provisioning in VMware vSphere
3. Easy recovery from a full VMware ESX datastore
4. PowerShell Prevents Datastore Emergencies

VMware ESX virtual machine networking is pretty straightforward.  A virtual switch (vSwitch) is created on each host by default and is associated with one or more physical NICs.  When multiple physical NICs are used, virtual machines benefit from added redundancy and load balancing by simply connecting to such a vSwitch.

However, VMs don’t connect directly to vSwitches, they connect to port groups on a vSwitch. Port groups offer a means of configuring different settings, like VLAN and security, on a single vSwitch.  ESX virtual network administrators perform the infrequent task of creating port groups on hosts.  Later, virtual machine administrators simply select appropriate port groups when configuring VMs, seen as friendly names like this in the VI Client:

VM administrators do not necessarily know or care about VLAN or security settings, so this model abstracts some of the complexity that is a result of this network configuration flexibility.  Here is what a vSwitch with two port groups and two physical NICs looks like:

Unfortunately, if you use Microsoft System Center Virtual Machine Manager (SCVMM) to configure your VMware ESX virtual machines, you are only offered vSwitches in the configuration interfaces, not port groups:

When creating a new VM, or modifying an existing  one, SCVMM simply introduces new port groups on the fly into your environment.  Well, that’s one way to avoid having to figure out which existing port group to use, but it might have been better if the SCVMM interface actually presented the correct objects in the first place.

After making such a configuration change, the VM is then connected to a cryptically-named network like this:

And new port groups are added to the vSwitches on all ESX hosts, something the virtual network administrator might not appreciate:

Are you thinking about managing VMware ESX with SCVMM?  Are you also the virtual network administrator?  If not, you may have some explaining to do.

Related posts:

1. The Secret of Ephemeral Port Groups
2. Clean up vCenter with PowerShell after SCVMM leaves
3. NIC Teaming Update: Hyper-V Still Cloudy as Ever
4. Managing VI3 with SCVMM considered harmful