After cloning a Linux VM, you might find your network interface is no longer named eth0, taking on eth1 instead.  Fortunately, this doesn’t cause any functional problems with the guest and can be left as-is.  However, if you are not satisfied with this scenario, read on…

SLES for VMware, which is SLES 11 SP1, uses udev to provide persistency to various devices.  While this model is regarded by most as a big step forward from the semi-random device name assignments of the past, one side-effect is that a new MAC address — pertinent when cloning VMs — is regarded as an additional interface and not a replacement.  Thus, a newly-cloned SLES VM powers up with eth1 as the NIC name, not eth0.

Fortunately, this situation is easy to fix.  Simply log into the VM and edit:

/etc/udev/rules.d/70-persistent-net.rules

Which should look something like this:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:97:00:35", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
 
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:97:00:38", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

In the above example, the first line contains the MAC address of the original template VM and the second line is the new NIC/MAC found in the clone.

There are two ways to fix this issue:

• Completely delete the file — it will be created again on boot and the first NIC will be assigned eth0, OR
• Delete the line containing the old entry that references eth0 and change “eth1″ to “eth0″ in the remaining line.

Note: if a static IP has been configured, go to /etc/sysconfig/network/ and update the files ifcfg-eth0 and route accordingly.

Reboot the VM and verify that the NIC(s) are named to your liking.

No real breaking news here, but given the newly available SLES for VMware, some evaluators may run into this situation.

Related posts:

1. Installing VMware Tools OSPs in SLES for VMware
2. SLES for VMware Entitlement Expands Broadly
3. Start and Manage a VM Without Using vSphere Client
4. SLES for VMware – First Look

Virtualization management tasks such as cloning existing virtual machines or deploying new ones from templates often involve slinging around multi-gigabyte chunks of data.  It’s preferable to move or copy data on the SAN instead of the LAN because it can be faster, but more importantly, doing so reduces impact to other services that rely on the LAN.

Use the SAN, ESX!

VMware ESX will transfer VMs and templates over a SAN connection whenever possible but, if necessary, it also does a fine job of moving those bits over a standard LAN.  This goes for VMs as well as templates because with VMware vSphere, templates live on SAN datastores, too — shared among multiple ESX hosts — not on network file shares.  If templates were stored on a file server, there would be no choice other than to copy those multi-gigabyte files over the LAN and potentially impact other production traffic.

Nice design choice, VMware!  [Actually, if you go back to the early days of VirtualCenter 1.x, templates could also be stored directly on the VC server and deployed over the network.  That option was removed as of VC 2.0.]

So far, so good.  Let’s take a look at how Hyper-V stacks up.

Obfuscating the Inequalities

In the tradition of the recent storage hot add/remove claims, Microsoft has again gone the extra mile to give the appearance of feature parity.

Take a look at this excerpt from the System Center Virtual Machine Manager 2008 R2 What’s New page:

SAN migration into and out of clustered hosts: This allows virtual machines to migrate into and out of clusters using a SAN transfer, which saves the time required for copying the virtual machine file over the network.

And the features page is even more dramatic, proclaiming:

Virtual machine images can be large and difficult to move over the network. VMM auto-detects SAN infrastructure and enables copying of virtual machine images over fiber at fast speeds, thus leveraging SAN investments.

Sounds good, just like VMware — and at one-sixth the price!  But there is a small problem: it is not true.

Hyper-V uses the BITS service to transfer VMs over the LAN in almost all cases.  There is a scenario where SCVMM can orchestrate the disconnection and reconnection of a SAN LUN, “transferring” a VM to another host.  Enabling the feature requires additional configuration and some software from your SAN vendor.  Of course, it also means going back to one VM per LUN and foregoing the wonders of CSV.  Any takers?

The SCVMM Library Server

SCVMM 2008 R2 provides VM template functionality for Hyper-V.  Templates  and ISO images are stored in a Library, which uses standard Windows file services.  Obviously, that means no SAN copying for template deployments, either — kind of like VMware VirtualCenter 1.0.

Conclusion

“SAN LUN disconnect and reconnect” just doesn’t have the same ring to it as “SAN transfer” but I’m not sure that is sufficient justification for these misleading marketing claims.  And to use the word “copying” is simply dishonest.

Don’t make the mistake of assuming Hyper-V is just like VMware ESX.  Compare for yourself — seeing is believing.

Related posts:

1. IGT Part 2: SAN Misers
2. Storage vendors unanimously applaud SCVMM innovation
3. The Truth About Storage Hot Add and Remove
4. SCVMM to VMware: You will be assimilated

With template deployment comes VM (or “image”) customization — each instance of an OS needs to have a unique hostname and, in the case of Windows, a unique SID (security identifier).

Not surprisingly, each vendor has taken a different approach to image customization.  Let’s take a closer look.

VMware vCenter Server Image Customization

With VMware vSphere and vCenter Server, VM templates are simply virtual machines with a special flag that essentially prevents users from accidentally powering them on.  In fact, you can clone and customize a new VM from a standard VM if you prefer — converting to template first is not even required.  Sysprep is only run on the new VM after it is cloned — the original template/VM is never generalized by Sysprep.

The great thing about this design is that it gives you the ability to instantly convert a template back to a standard VM.  That makes it very easy to update templates and, for example, minimize the exposure of deploying virtual machines in dire need of numerous security patches.

Of course, vCenter also supports Linux guest customization, unlike competitors.

Virtual Machine Manager (SCVMM) Image Customization

Microsoft System Center Virtual Machine Manger also has VM templates, but the workflow is quite different from vCenter.

When you create a template in SCVMM, the guest OS is generalized with Sysprep before it is copied into the library.  That effectively destroys the original VM and, in fact, this is what the warning message states when you create a template.

Maintaining a clone of every VM template obviously introduces some management overhead.  Another option you might consider: when it is time to update a VM template, simply deploy a fresh VM from the previous template, make changes, and then re-create a new template from the VM.  That sounds like it will work, but there is actually a problem that prevents it from being a viable solution. For technical reasons, Sysprep can only be run on a particular OS image a total of three times.  You can read all about the details in this TechNet article. UPDATE: Activated systems in a KMS environment are not affected by this limit.

Here is what happens when you exceed the Sysprep limit when attempting to create a template in SCVMM:

Looks like SCVMM administrators will either be maintaining master clones of all templates, or reinstalling VMs from scratch when updated templates are needed.  Kind of makes you think about the whole “managing physical plus virtual” thing, doesn’t it?

Citrix XenCenter Image Customization

Curious to know how Citrix handles Windows VM cloning and customization?  They just don’t bother — the documentation simply explains how to manually run Sysprep on a Windows VM before converting to a template.  All the disadvantages of the SCVMM model — without the automation.  Nice.

Summary

VMware vCenter Server is the only virtualization management platform that offers fully functional, non-destructive VM templates for both Windows and Linux guest operating systems.

What interesting VM/template strategies have you adopted?

With apologies to the “Don’t Taze Me, Bro!” guy.

Related posts:

1. SCVMM to VMware: You will be assimilated
2. Which guest operating systems can be customized by SCVMM?
3. Getting eth0 back in a SLES for VMware clone
4. Even GPL can’t make Hyper-V Linux VMs well

From my perspective, Red Hat got exclusive rights to the downside of this deal while Microsoft benefits from media blitz and the increasing perception that they are becoming a cross-platform player.  Single pane of glass, and all that.

In order to see what Red Hat stands to gain from the Hyper-V deal, we can simply take a look at SUSE — the current “supported” Linux distribution on Hyper-V.  Critical aspects of supporting a guest OS are: integration components, customization, and P2V compatibility.  Here is where SUSE Linux Enterprise stands today:

Hyper-V Linux Integration Components

To get the most out of a virtual machine, administrators typically install an agent inside each guest operating system.  By the way, Microsoft has at least four terms for these: virtual machine additions, virtual guest services, integration components, and integration services.  VMware calls them Tools.

Part of supporting SUSE Linux Enterprise is providing applicable integration components (ICs).  Hyper-V, which shipped on June 26, 2008, did not include Linux ICs.  Where can users get them?  According to the Hyper-V FAQ:

Q. Will Microsoft continue to support Linux operating systems with Hyper-V?

A. Yes, Microsoft will provide integration components and technical support for customers running select Linux distributions as guest operating systems within Hyper-V. Beta Linux integration components are now available for SUSE Linux Enterprise Server 10 SP2 and SP1 x86 and x64 Editions. These integration components enable Xen-enabled Linux to take advantage of the VSP/VSC architecture and provide improved performance. Beta Linux Integration components are available for immediate download through http://connect.microsoft.com.

Well, guess what happens if you go to that Microsoft Connect site and search for Linux ICs?  Click on the first search result and you will get a “404″ page not found error — they have been recently removed.  Look a little further and you will find a bug report from an unhappy user that can’t find the SUSE Linux ICs — and several confirmations from other unhappy users.

UPDATE: James O’Neill sent me a tweet to let me know that I was not using Connect properly (and neither were those poor folks referenced in the above paragraph, hopefully someone will reach out to them soon).  You need to go to the Directory and look for the integration components section.  If you just search for them (like I did), they will show up in the results but not be available.  So the ICs are NOT MISSING.

I can offer three possible explanations for the missing Linux ICs:

1. They were pulled in order to resolve Open Source licensing issues.  This happened once already in July, so it is not unreasonable.
   
2. The production-quality version is finally ready for download from the main Microsoft Download Center, so the beta bits have been removed from Connect.
3. Linux support in Hyper-V is a very low priority.

A quick search of the Microsoft Download Center reveals the following, currently ruling out possibility #2:

That leaves options 1 and 3.  Select all that apply.

UPDATE:  The ICs were not pulled — they are available for download from the Connect beta site.  Supported by “newsgroup only” (code for “no support”) and lacking mouse, heartbeat, OS shutdown, and time sync functionality.

Do you really need the integration components?  That depends.  Do you want the maximum performance from your guest OS?  Do you want to use a mouse over a remote connection?

Frankly, I’m not even sure the mouse will work if you did find and install the Linux ICs — at least based on some quick observations. UPDATE: Confirmed.

Linux Guest Customization

The price of admission for virtual machine management is the ability to create templates in order to deploy customized instances of a master VM.  I wrote about this recently when I found that SUSE Enterprise Linux is not customizable by SCVMM.  I bet Red Hat hopes they get better treatment in this area.

Linux Physical to Virtual (P2V)

Finally, the old virtualization standby: consolidation.  Do you want to automatically convert your old physical Linux servers to virtual machines?  Don’t expect Hyper-V or SCVMM to come to your rescue here.  Nope, P2V in Microsoft parlance is strictly Windows-only.  If you need to convert Linux, look no further than VMware Converter 4.

Conclusion

It is not clear if Red Hat will get better support than SUSE on Hyper-V.  But that is not something you need to worry about — you can run your Red Hat Enterprise Linux workloads on VMware ESX today, not after some vague future milestone.  You also get full support for guest customization, P2V, and if you happen to need it — a mouse!

Related posts:

1. Hyper-V Linux integration components no longer Connected
2. Of Mice and Xen
3. Even GPL can’t make Hyper-V Linux VMs well
4. Which guest operating systems can be customized by SCVMM?

I was poking around with the System Center Virtual Machine Manager 2008 (SCVMM) PowerShell functionality and came across an interesting cmdlet that can be used to reveal which guest operating systems are customizable:

PS C:\Windows\System32> Get-OperatingSystem |
>> where { $_.IsCustomizationAllowed -eq $true } | sort | ft Name

Which yields the following list:

Name
----
64-bit edition of Windows Server 2008 Datacenter
64-bit edition of Windows Server 2008 Enterprise
64-bit edition of Windows Server 2008 Standard
64-bit edition of Windows Vista
Windows 2000 Advanced Server
Windows 2000 Server
Windows Server 2003 Datacenter Edition (32-bit x86)
Windows Server 2003 Datacenter x64 Edition
Windows Server 2003 Enterprise Edition (32-bit x86)
Windows Server 2003 Enterprise x64 Edition
Windows Server 2003 Standard Edition (32-bit x86)
Windows Server 2003 Standard x64 Edition
Windows Server 2003 Web Edition
Windows Server 2008 Datacenter 32-Bit
Windows Server 2008 Enterprise 32-Bit
Windows Server 2008 Standard 32-Bit
Windows Small Business Server 2003
Windows Vista
Windows Web Server 2008
Windows XP 64-Bit Edition
Windows XP Professional

Interesting.  No Linux?  I thought SCVMM and Hyper-V were embracing at least one Linux distribution.  Let’s try the converse of that command:

PS C:\Windows\System32> Get-OperatingSystem |
>> where { $_.IsCustomizationAllowed -eq $false } | sort | ft Name

Name
----
None
Novell NetWare 5.1
Novell NetWare 6.x
Open Enterprise Server
Other (32 bit)
Other (64 bit)
Other Linux (32 bit)
Other Linux (64 bit)
Red Hat Enterprise Linux 2
Red Hat Enterprise Linux 3
Red Hat Enterprise Linux 3 (64 bit)
Red Hat Enterprise Linux 4
Red Hat Enterprise Linux 4 (64 bit)
Red Hat Enterprise Linux 5
Red Hat Enterprise Linux 5 (64 bit)
Sun Solaris 10 (32 bit)
Sun Solaris 10 (64 bit)
Suse Linux Enterprise Server 10 (32 bit)
Suse Linux Enterprise Server 10 (64 bit)
Suse Linux Enterprise Server 9 (32 bit)
Suse Linux Enterprise Server 9 (64 bit)
Ubuntu Linux (32 bit)
Ubuntu Linux (64 bit)
Windows NT Server 4.0

Whoa! Why is SLES 10 is on that list?  That is a supported guest OS.

Sometimes supported doesn’t mean fully functional. For a virtualization platform that treats Linux workloads like first-class citizens, choose VMware ESX with vCenter Server:

Related posts:

1. Hyper-V Linux Smokescreen
2. What is Red Hat Enterprise Virtualization?
3. RHEV Manager — It’s not just a clever name
4. Dear Red Hat…

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