Free ESG report : Seamless data management with Avere FXT

The virtualisation war is heating up. With Server 2012 Microsoft is at last bringing a viable platform to the table and Server 2012 R2 looks set to eclipse that.

You will get different numbers depending on who you talk to but the general consensus is that Microsoft has managed to grab about one quarter of all new installs.

It is easy to understand why greenfield deployment numbers are keeping VMware execs awake at night, but how difficult is it for Microsoft to crack committed VMware shops?

Peaceful coexistence

The key to breaking into brownfield virtualisation is ease of transition and coexistence. VMware has a powerful grip on the enterprise and the first rule of enterprise IT is that you do not introduce technologies that will disrupt running services.

Downtime is money – almost always far more money than the pricing delta between VMware and Microsoft.

Microsoft has begun to address some of these concerns by giving System Center 2012 the ability to manage multiple hypervisors from a single application. While moving virtual machines between VMware and Hyper-V infrastructures is still something of a pain, a single point of management helps mitigate that.

Running two environments has its upsides. If you embrace heterogeneity you can gain some measure of freedom from vendor lock-in but at the expense of increased complexity, requiring additional staff and training.

The costs can be offset at scale by the bargaining position a heterogeneous environment gives you. If vendors play hardball you can sweat them out without operational impact.

Whether your goal is to operate two environments in tandem or to transition from one to the other, you are going to run across the need to convert virtual machines.

Technically, it is best to reinstall and reconfigure each virtual machine for its new environment. However, that is impractical and unrealistic.

Does Microsoft have what it takes to tackle conversion?

Frequent the library

Microsoft's virtualisation management tool is System Center Virtual Machine Manager (SCVMM). This will deploy hypervisors to bare metal systems. It will also manage hypervisors, virtual machines and virtual networks, and to an increasing extent virtualised storage. It is also the tool that allows you to manage hypervisors from multiple vendors.

Assuming that you have added your VMware environment to SCVMM then converting a virtual machine residing on a VMware server to Hyper-V is reasonably straightforward.

One part of SCVMM's duties includes keeping a library of virtual machines and it is from here that handling virtual machines in bulk really takes place.

If you have a virtual machine that you want to convert, then you can simply copy the virtual machine files over to the SCVMM library server, place them in the appropriate directory and trigger a rescan. The virtual machines will then show up in the library's list and you can choose "convert virtual machine" at your leisure.

Another option for bulk conversions has been recently released: the Microsoft Virtual Machine Converter (MVMC).

This is available as a standalone application or as a plug-in for the VMware vSphere Client. It is completely scriptable and suitable for datacentre-scale work. A PowerShell Automation Toolkit is available for MVMC as well.

Entirely separate from the MVMC is the Virtual Machine Migration Toolkit (VMMT), also a large-scale conversion tool. Hyper-V.nu has a write-up that is worth a peek if you have a project coming up.

Of course you don't need either the MVMC or the VMMT to do scripted conversions if you have SCVMM. Like all modern Microsoft server technologies, SCVMM is entirely addressable via PowerShell. Microsoft has posted some basic examples.

That is three separate applications that you can use to convert virtual machines with Microsoft's blessing. SCVMM is probably the best for one-off virtual machines. The other two are not worth the time unless you want to start doing things in bulk.

Obstacles in the path

Microsoft has certainly provided a few different routes to get your virtual machines into Hyper-V but they all have the same basic limitations that are inherent to Hyper-V conversions.

In an ideal world I would be able to take a copy of a running virtual machine and convert it

One of the most annoying is the requirement to remove the VMware tools before conversion. This limits how useful the process can really be.

In an ideal world I would be able to take a copy of a running virtual machine and convert it from VMware over to Hyper-V. This would allow me to do testing of how that virtual machine survives the transition without taking it down to do so.

Even if I find the time to take the virtual machines down for conversion, the tools removal requirement means that if I am doing the conversion for testing purposes I will have to remove the tools, shut the virtual machine down, convert it, bring it back up, reinstall the tools and then reboot it again. That's a lot of reboots.

It also means that every virtual machine you have converted to Hyper-V will need to have the Hyper-V Integration Services installed after the conversion is complete to work properly on the Hyper-V infrastructure. The whole process is far from being as smooth as it should be.

The conversion process does not support VMware virtual machines with virtual hard disks connected to a virtual IDE bus. You must ensure that all disks in the virtual machine are SCSI before converting.

In reality this probably does not affect too many of us as VMware defaults to using SCSI disks for everything. Still, it is one more thing to check before attempting that conversion.

5 ways to reduce advertising network latency