IMPORTANT: In the process of writing this article, I discovered that VMware MHM 1.1 is incompatible with Windows Hyper-V R2 2012. The issue seems to originate from the fact that the namespace through which the management objects of Hyper-V are accessed is no longer supported – VMware MHM manages Hyper-V through WMI objects from the namespace root\virtualization. Microsoft introduced root\virtualization\v2 with its release of Hyper-V 2012 and kept root\virtualization for backward compatibility. However, it seems that Microsoft  also deprecated the root\virtualization namespace with R2. So I had two switch from my Windows Hyper-V 2012 R2 lab, to a Windows Hyper-V 2012 environment midway through the process.

As part of my wider journey into “da the cloud.” I’ve become more and more interested in how we might define “hybrid”.  Does hybrid merely mean a public and private cloud? Does it mean a cloud where those two domains are linked – as is the case with vCloud Connector’s “Stretched Deploy” feature or does it mean a multi-hypervisor environment, and being able to move workloads from one virtualization platform to another? Whilst we clearly want mobility of workloads in a ANY:ANY way, does that necessarily mean running more than one virtualization platform within our private environments is a good idea? Lets face it VMware vSphere pretty much dominates virtualization, with Windows Hyper-V bringing up the rear – leaving just KVM and bunch of also-rans.  As technologists we might prize the ideal of platform interoperability, but I don’t think there enough customers to make it of interest to the vendors. Those vendors are likely to put more effort in developing and improving their own management platforms and virtualization layers before they worry about the competition.

Having setup a Windows Hyper-V 2012/SCVMM 2012 environment. I decided to look at VMware managing Windows Hyper-V with VMware MHM, and also converting Microsoft VMs to being vSphere VMs – a process I’ve dubbed “M2V”. Then in an effort to remain balanced – I’ve also looked at SCVMM attempts to manage vSphere, and the quality of the tools to covert a VMware vSphere VM to a Microsoft Hyper-V VM, something I’ve dubbed “V2M”.

What follows is a full and unfiltered account of my experiences – things get a bit knotty after this point so looking back I thought a “summary” or “highlights” might help clarify the situation more.

Edited Highlights:

• The Microsoft Firewall is your enemy. It can cause things to stop working in all places where Windows is used – SCVMM, Windows Hyper-V and then source VM – whether that source VM is running in VMware vSphere and/or Windows Hyper-V
• VMware Convertor works with or without VMware Multi-Hypervisor Manager – and generally presents more options/features. However, if you want to have simple/quick method of converting from Windows Hyper-V to VMware vSphere then MHM is your man, if you want the fancy options then VMware Convertor is what you should focus on IMHO.
• VMware Convertor can convert both physical and virtual machines – on the fly without a power down of the source Windows Hyper-V VM. Remember VMware has been doing conversions like this ever since the P2V product which I first started using in 2003.
• The time to convert from M2V is considerably shorter than the time convert from V2M (5-6mins compared 30-40mins).
• VMware Convertor can do a “final sync” between the source (Windows Hyper-V) and the destination (VMware vSphere) which gives you an consistent copy of the VM.
  
• If you’re serious about (or forced against your will into) a multi-hypervisor strategy – I think neither VMware MHM or Microsoft SCVMM, where one vendor manages another, is a serious proposition. I think if your serious about this approach then you should be looking at a provisioning tool like VMware vCloud Automation Center.
• Adding VMware into SCVMM requires – adding vCenter, adding vSphere hosts AND retrieving/authentication to each and every host to get full functionality
• Neither SCVMM or MVMC (Microsoft Virtual Machine Convertor) allow you to convert a vSphere VM to a Windows Hyper-V without some sort of power down in the process, and as consequence a maintenance window
• Using SCVMM to convert V2M is fraught with authentication/communications problems, using “Convert Physical Machine” might work better and quicker (around 10mins compared to 30-40mins with MVMC/SCVMM V2M). I understand that SCVMM R2 removes “Convert Physical Machine” from SCVMM. This in the release notes for SCVMM R2 – http://technet.microsoft.com/en-us/library/dn303329.aspx
• After any successful conversion from vSphere to Hyper-V I’ve yet to see any method that successfully allowed for Microsoft Intregration Services to be installed – that means no mouse control, and in some case no network capabilities.

 

UPDATE:
Since the publication of this blogpost – Microsoft have indicated how their customers will be able to carry on doing P2V conversion. There recommendation is to run old instance of SCVMM 2012 containing a Windows 2012 Hyper-V host and carry out the conversions there. Then, (I kid you not!) export the VM out of the old SCVMM and import into the new SCVMM R2 2012 environment. Joined up management? I don’t think so.

http://blogs.technet.com/b/scvmm/archive/2013/10/03/how-to-perform-a-p2v-in-a-scvmm-2012-r2-environment.aspx

Although my post is about V2V and not P2V. I do take this as being symptomatic of Microsoft dropping the ball on the R2 release. It’s now 8 steps to covert a physical machine to a virtual – requiring two management layers!!!

This is a lengthy post – so I decided to split it up into sections to ease navigation.

• Installing VMware Convertor
• Installing VMware vCenter Multi-Hypervisor Manager
• Adding Windows Hyper-V Servers to VMware vCenter MHM
• Adding vCenter/vSphere hosts to Microsoft SCVMM
• Converting a Windows Hyper-V VM to a VMware vSphere VM with VMware vCenter MHM: (M2V)
• Converting a Windows Hyper-V VM to a VMware vSphere VM with VMware Convertor: (M2V)
• Converting a VMware vSphere VM to Windows Hyper-V VM with Microsoft SCVMM: (V2M)
• Converting a VMware vSphere VM to Windows Hyper-V VM with MVMC: (V2M)
• Conclusions: Time to stop kicking the tyres?

Installing VMware Convertor

Top of Page
I feel that one of the commonly misunderstood things about VMware MHM is that because it is based on Windows, people think you need the Windows version of vCenter to run it. You do need an instance of Windows running somewhere to install it, but it does work with the vCSA. The other recommendation I’d give is to start with an install of VMware Convertor – as the MHM installer will ask for it anyway. It’s an optional feature – so you don’t HAVE to install it, but I would… After all given choice between VMware vSphere and Window Hyper-V you surely pick VMware wouldn’t you? 😉

Personally, I think the installation of VMware Convertor & VMware Multi-Hypervisor Manager is quite prosaic. I’ve documented it below. If you’d rather cut the chase and see it in action, click here .

In the case of using VMware Convertor with MHM the “Client-Server” model is a requirement… which means I can manage the process from my normal workstation rather than having to log in to my Convertor/MHM box.

Installing VMware Multi-Hypervisor Manager

Top of Page

Note: Before you begin. Check that the service account you will use has the right to logon as service. Without it VMwareMHM will not install, and you cannot continue with the install before the user rights have been granted in the local policy of the Windows instance.

The current iteration of VMware MHM is 1.1 and it can support up to 50 Hyper-V Hosts, and 1,000 virtual machines. If you were installing this to the Windows version of vCenter you’d need to top up the RAM by 2GB, if your running it on separate instance you need 4GB – about 2GB for the OS and 2GB for the service.

When you come to install the VMware MHM you will be asked if you want to provide a certificate or have one auto-generated:

As with other plug-ins of this type there is a “registration process” to go through.

If you accept the auto-generated certificate – you then accept it in the following window:

Next you can set the port numbers and such like for the service itself

As the VMware MHM and Converter was the same Windows instance, I just re-typed the IP address/Hostnane.

Finally, you accept the certificate and then install proceeds.

The Client install is relatively straight forward, it merely needs downloading and installing  from the plug-ins menu in the vSphere Client (incidentally, there’s no support yet for the web-client UI)

This adds an icon to the “Inventory” section of the vSphere Client home page:

– your now ready to add Hyper-V Servers!

Adding Windows Hyper-V Servers to VMware MHM

Top of Page

The key point here is your adding Windows Hyper-V servers, not System Center Virtual Machine Manager (SCVMM). For this to work your Hyper-V hosts must be enabled for WinRM. There’s two ways to do this – non-securely with HTTP/80, or secure with HTTPS/443. This second configuration requires IIS be enabled on the Hyper-V host. Something I think most folks would struggle to justify in their environments. After all isn’t a hypervisor meant to be super-slim and skinny isn’t? I’m not sure installing a web-service fits into that model. I’m going with HTTP/80. My management network is private and nobody can snoop there (except the NSA, of course!)

You should get a pop-up message indicating the connection to Windows Hyper-V is non-secured.

The Windows Hyper-V Hosts together with their VMs, Storage & Network configuration appears in the console like so:

Adding vCenter/vSphere hosts to SCVMM

Top of Page

In contrast to VMware MHM the adding vCenter/vSphere hosts to SCVMM is two stage process. Firstly, the vCenter Server needs to be added into +Fabric part of SCVMM under the +vCenter Servers node. The wizard used to add vCenter acknowledges this under the Security pane.

Once that step has been completed, you can create a “Host Group” under “All Hosts” in the Fabric view in SCVMM to add VMware Clusters into the UI. To add in the vSphere hosts I created a “RunAs…” account for the root account on the vSphere hosts…

Comparing SCVMM support for vSphere, to VMware MHM support for Windows Hyper-V I’d have to say that by hairs-breathe there’s slightly more functionality in SCVMM than in vSphere. SCVMM does recognise VMware Clusters, whereas VMware VMware MHM just picks up on the Windows Hyper-V hosts. I think that largely reflects VMware MHM original “fling” status. Whilst SCVMM does support maintenance mode, the assumption is that DRS is turned on and fully-automated – so that kinda of rules out the use of Microsoft “Dynamic Optimization” feature – otherwise you would have two different systems trying to do load-management at the same time. But with all things weighed together I think these two approaches a pretty modest – as they limit themselves to basic VM management tasks only… But with that said SCVMM does nudge ahead of MHM as it supports features like Migration and Snapshots.

  

The VMware MHM doesn’t have a method for creating a remote console view on a VM, whereas SCVMM does. Sadly if your using vSphere 5.1, Microsoft have yet to update their SCVMM to reflect the fact that location of the VMRC has changed – so when it tries to open download it fails. The correct location of the VMRC on vSphere5.1 is:

https://<your vcenter server>/vsphere-client/vmrc/VMware-ClientIntegrationPlugin-5.1.0.exe

However, even with the plug-in installed, SCVMM doesn’t know how to call it (presumably because it’s expecting an older plug-in). That means your always confronted with message to install an ActiveX controller. I’m assuming that Microsoft will fix this problem in their R2 release, although there’s no indication of that yet.

Converting a Windows Hyper-V VM to a VMware vSphere VM with VMware MHM: (M2V)

Top of Page

So having compared the manageability/setup routine it was time to look at the issue of converting VMs. Remember your enemy the Microsoft Firewall can stop communications working. A converted VM is configured for the “VM Network” as it is being converted to different virtualization platform with different virtualization hardware – then the previous network adapter will disappear – and new network adapter generated. Converted Windows Hyper-V VMs are assigned the e1000 NIC type which presents an Intel Pro/1000 MT using a E1G6032E.sys driver in Windows 2008 R2. VMware Tools is not installed as part of the process.

In a Microsoft to VMware conversion you can use combination of VMware Convertor and MHM together convert a Windows Hyper-V VM to a VMware vSphere one. This is done as online process with the VM Powered on, and the VMware Convertor software must be able to communicate with the Windows Hyper-V VM, otherwise you will get an error message like so:

1. Start by right-clicking the VM in VMware MHM, and choosing Convert – and supply the credentials to the VM.

2. Next select a location in the Inventory for holding the converting the VM.

3. Select which VMware Cluster the VM will reside on – note you need to expand the cluster and select a vSphere host on which to place the VM.

4. Finally, select the datastore to hold the Converted VM.

5. You can monitor the conversion process by watching the “Recent Tasks” view in vCenter:

At the end of the process the VM located in vSphere is left in a powered off state, and the VM in Windows Hyper-V left powered on. By default VMware MHM patches the VM to the “VM Network” (assuming it exists) so before powered on you will need to change its portgroup assignment. The previous IP configuration settings will be lost – and new network adapter generated – so expect to see “Local Area Connection 2”  on Windows 2008 R2.

In short I found the conversion process as triggered with VMware MHM worked perfectly fine – and I did like the simplicity of the approach – but looking at VMware Convertor I think I prefer the additional options available there…

Converting a Windows Hyper-V VM to a VMware vSphere VM with VMware Convertor: (M2V)

Top of Page

As VMware MHM hides much of the VMware Convertor UI, I thought I would see what it would be like to do a M2V conversion with just it. Along side other conversion types, VMware Convertor provides an option specifically for Windows Hyper-V. The “server” field here is the name/IP of the Hyper-V server, not the VM you want to convert.

 So long as the credentials are correct this will trigger an install of the VMware Convertor Stand-alone Agent.

Sadly, I found that this method wasn’t up to date with Windows Hyper-V 2012. From what I can gather VMware Convertor supports only up to Windows 2008 Hyper-V.

That meant I had to use the failback option – of treating the Windows Hyper-V VM as if it was a physical machine. The process of triggering this is very similar to any other conversion – and there was nothing much to write home about here, except I quite liked the fact that VMware Convertor can control which Resource pool on a DRS cluster the VM resides… (something VMware MHM didn’t do…)

Additionally, the “options” allow you to edit settings on the VM, including the ability to set the portgroup assignment options – in contrast VMware MHM hides these options away from the administrator. These include options such as:

• Resize Disks
• Changing the memory/CPU assignment
• Services to start-up
• Power On/Off the source & destination after the conversion
• Install VMware Tools
• Perform a Sync between the Source & Destination (this means even if changes are taking place during the conversion they are captured too!)

The progress of the conversion has to be monitored via VMware Convertor – not from vCenter (although you will see a VM being created in vCenter). Personally, I found the predictions for how long the conversion would actually take varied massively. At one point VMware Convertor said the process would take 9hrs, then that came down quickly to 1hr/30mins. The actual time it took was around 6mins. I took advantage of the “synchronising process”. To test this I created files on the source whilst the conversion process was running at 20%, 60& and 99% of the process. I was pleased to see that I didn’t loose those files, and they were brought across with the sync happening between the VMs just before the shutdown of the source VM in Windows Hyper-V.

Personally, I felt the conversion process in VMware Convertor offered more options and did a better job of converting the Windows Hyper-V than simple options offered in VMware MHM.

Converting a VMware vSphere VM to Windows Hyper-V VM with SCVMM: (V2M)

Top of Page

As I’m comparing crossing functionality, its only seems right and proper – in the interests of being balanced to look at the process of converting a vSphere VM into a Windows Hyper-V VM. The conversion process comes built into SCVMM once you have configured it to access vCenter and the vSphere hosts. As with VMware Convertor the source VM needs to be powered on for the conversion to function.

 

From here, the browse options allow you to locate a vSphere VM in the inventory (in my case I have one – called vSphere-VM01 – so that was easy to find!)

The conversion process allows for changing the CPU/memory allocation to the VM.

As you might know Windows Hyper-V 2012 doesn’t support booting from iSCSI disk, and all boot processes are based on a IDE controller. So you will receive an alert indicating this… I’ve never really understood why Windows Hyper-V only permitted a boot from an IDE. I mean its not a like a big deal, it just seems redundant and unnecessary. I understand that Windows Hyper-V R2 GEN2 virtual machines will support boot from iSCSI disk, something that I’ve been doing with ESX ever since version 2.

As well as handling the storage locations, the convert in SCVMM handles the networking as well.

Sadly, this conversion process failed at the first hurdle with some obscure authentication issue to the vSphere Host.

A reboot of SCVMM ( which typically fixes all Windows problems) did not resolve this problem. So I abandoned this route entirely. It turns out this issue is associated with the method used to communicate to the vSphere host. If when adding in the vCenter, you use the secure method called “Communicate with VMware ESX hosts in secure mode”, then simply just adding the vSphere host afterwards isn’t the only step.

There’s more work to be done. Without these additional steps management of the vSphere hosts will be “Limited”.

To get full management over the VMware vSphere hosts you have to retrieve the VMware vSphere hosts certificate details – to do this you will also need a “RunAs” account in SCVMM to authenticate to the VMware vSphere host. This is done by right-clicking each VMware vSphere host in the SCVMM view, select properties – and selecting “Management” option.

Once completed, the status of the VMware vSphere hosts in SCVMM will change to “OK”

With that said – even when I resolved this authentication problem, I was confronted with another error. That’s pretty much been my typical experience of playing with Windows Hyper-V and SCVMM in the lab. You resolve one problem (which can take minutes, hours, days, weeks) only to expose another problem that it was hiding behind. In my case once the authentication problem was resolved this merely exposed another – this Error 2940 which indicates that SCVMM couldn’t speak to the vSphere host on port 80. I tried a telnet on port 22/80/443 and found them all to be open.

In the end I resolved to treating the vSphere VM as if it was a physical. Perhaps this is why folks on the forums recommend this – because getting V2M working in SCVMM is so chuffing difficult. When you do this repeated times you will see SCVMM create multiple VMs via these multiple failed jobs

One thing I would say about treating the source VM as if it was physical is that it requires DCOM permissions and rights which may need to be reconfigured, treating the vSphere VM as if it was physical exposes options not available when treating the VM as a VM. That includes options such as being able to re-size the destination .VHD (I would note that there’s no option to use the VHDX format which allows for disks >2TB). Also I thought the P2V process made a better job of identifying the details of the guest operating system…

Even with the P2V method of getting a vSphere VM into Windows Hyper-V I was left with the problem of being unable to install Microsoft Virtual Guest Services – or when I tried it failed miserably. Looking around on the forums many people suggested removing VMware Tools before attempting the conversion. That gave me two bits of work to do – firstly a snapshot of the VM in vSphere so I could revert to any changes, and then switching to generic ethernet driver (E1000) because a VMware VM without VMware Tools and using the VMXnet2/3 network interface will require a driver… This actually required the removal of the “old” VMXNET3 device and the adding of a “new” E1000 device (of course, that meant I lost the original controller, along with precious IP settings).

This method did successfully convert the vSphere VM to a Windows Hyper-V VM – however I was unable to install Microsoft “Integration Services” or get networking operable.

Converting a VMware vSphere VM to Windows Hyper-V VM with MVMC: (V2M)

Top of Page

Instead I opted for the newly released Microsoft Virtual Machine Converter Solution Accelerator (or MVMC for short). This is a plug-in to vCenter (Windows only) which extends the vSphere Client with the option to convert to Windows Hyper-V. This plug-in for vCenter is now out of date as it only works with the 4.0 or 5.0 client. If you have upgraded to vSphere5.1 then the plug-in does not work.

Fortunately, like VMware Convertor the Microsoft MVMC comes with its own UI. The first step is to crank-up the wizard to connect to the vCenter server.

Before you begin you should know MVMC has some specific requirements:

• You need temporary local storage on the system that is running the MVMC
• You need temporary shared (SMB/CIFS) storage that is accessible on the Windows Hyper-V server (Note: You cannot convert directly into a .CSV volume without the R2 release of Windows Hyper-V 2012)
• So the main thing to say is watch out for free space – you need space for export to OVF, space for the conversion from VMDK to VHD, and the space for the VHD at the final destination. Microsoft says its double the space requirements – but I think like others its more like triple the space requirements.

From there you can select the vSphere VM you wish to convert, and what account you will use to do conversion – and whether the source/destination VMs switch roles:

The next step involves setting the workspace location. This is local storage location which is used as temporary staging location for an export of the vSphere VM in an OVF format. Once that export has completed the disks that make up the OVF files are converted into the Microsoft .VHD format before being imported into the destination Windows Hyper-V host and destination .CSV. This means you need enough temporary free space for the export process and conversion process to complete. In my case I chose add a new disk to my SCVMM to act as this temporary storage location – as this was where I’d installed the MVMC. Incidentally, UNC paths are not supported in the MVMC for this purpose – to T: drive is a local partition.

Next we need to set the destination for the conversion process. It looks like MVMC doesn’t recognise Failover Clusters – as you specify the Windows Hyper-V host you want to be the destination. Additionally, I found I could not import the vSphere VM directly into a .CSV volume. The copy of the converted VM is carried out over SMB/CIFS shares. My theory was I could use a temporary share on one of my Windows Hyper-V hosts to get the VM across – then use Windows Hyper-V “Migrate Storage” to get the VM at the right location. That’s a bit of hop-skip-and-jump process I guess…

 

Once this part of the wizard is completed – there summary section does a verification over whether the settings are correct. In my case it flagged up the video RAM allocation on the source vSphere VM was higher than could be supported on the destination Windows Hyper-V host.

The MVMC Conversion Process in Detail:

First MVMC creates a vSphere Snapshot of the VM, before starting the export process. This means any changes that take place in the source VM after the snapshot is taken will be lost. Once this snapshot has completed – the VM is powered down in vSphere. This happens regardless enabling “Final state of source machine” to be “ON” under VM Connection in the MVMC wizard. So its not possible to do an online conversion of the vSphere VM – at some stage it will be powered off whether you like it or not. As I see it the primary reason for the snapshot is to allow the vSphere Admin to undo the changes taking place after the snapshot has been taken – this includes the forced removal of VMware Tools before the shutdown/export process…

 

Next the OVF export process is started, and temporary files are created on the MVMC system:

Once this export has completed, it is possible to then power on the source vSphere VM again, once the export process has completed, and the conversion process begins. Once the export has completed – the MVMC reverts the snapshot on the VM, and then removes it – leaving it in a powered off state. So it is up to you to power it back on if that’s is your intention.

For me this export process took nearly 22mins – a duration which I thought for the couple of GBs of data I had was quite a long time. So I decided to reinvestigate my setup – I run SCVMM inside a VM, so exporting “large” amounts of data to it across the network could be source of the bottleneck.

Despite requesting a dynamic disk be created it did seem to be the case that fixed disk is initially created during the conversion process – so although the status information said MVMC was converting 3.7GB, it was making a much larger temporary VHD file:

Sadly, after waiting all this time for the conversion to complete – it failed.

The log file indicated there was some problem accessing the VHD file as this was being “used by another process”. Quite what that process was – was never really clear. I decided to try installing the MVMC directly to the Windows Hyper-V host and see if I had a better outcome. However, that was not to be – the conversion process from VMDK to VHD took nearly as long (20mins+) and at the end the process wouldn’t complete. What I got was a cryptic “Sequence contains no matching element” error message… with some diligent googling I discovered is issue happens if there is CD/DVD connected to the vSphere VM. Once I addressed that issue on what I think what was my fourth or fifth attempt – I got successful conversion.

No matter what I did it was taking at least 20min to do first part of the process – and another 20mins or more to do the conversion from VMDK to VHD. It was only when the entire process had completed did I know whether it was successful or not.

You’ll want to install the Windows Hyper-V integration tools pretty quickly because not having access to the mouse in a predominantly graphical OS is restricting!

That initially had me foxed – because when I went to try an install the “Virtual Guest Services” the option wasn’t available. It was greyed out whether the converted VM was powered on or off. It turns out this is caused by a fault in the MVMC – as it doesn’t set the OS type correctly during the conversion process. It leaves it set as “Unknown”.

Despite my best endeavours I never did manage to get the guest services installed even after setting the OS correctly…

Finally, after the conversion using MVMC you will find the Network Adapter is not connected to the network:

Conclusions: Time to stop kicking the tyres?

Top of Page

Multi-Hypervisor Management:

I think it would be fair to say that quality of management at this level from Microsoft to VMware, and from VMware to Microsoft is pretty modest. I think that largely reflects a situation that’s been the case for a while. That heterogeneous management of systems from competing vendors always leaves something to be desired. That’s because historically companies like Microsoft’s ability to support “foreign” systems usually extends to offering just enough functionality to make the thing work, mainly to allow it to facilitate migrations from a competitor to Microsoft.

There have been attempts to make “uber” management systems for virtualization layers into a single windows such as BlueBear’s Kodiak project. [you could call it single pain of glass!]. Most of these attempts have failed miserably, and usually require the SysAdmin to make massive compromises in terms of the tasks they can or cannot do. 9 times out of 10 it means cranking up the vendors native tools to get full-functionality. This kind of takes me back to the days of when I was instructor. I used to do a bit of work with HP Education, and occasionally instructors would show the integration from HP. You could see HP servers, and the VMs on them – and do basic power management style activity. In the real-world I’ve never really seen these third party tools gain much traction. Pretty soon once you have virtualization the hardware begins to disappear and the host/server just becomes a block of CPU/Memory. For that reason products like vCenter have become the focus for most administrators – in fact there’s been more and more pressure to show to the virtualization admin what their hardware is up to – rather than other way round. A good example is the hardware information is now reported up from CIM providers into vCenter.

 

For me wonder if this sort of management from within the virtualization layer is DOA. Surely, the future if its going to contain hybrid or heterogeneous management is going to be from a management layer above, like VMware vCloud Automation Center? And with these thoughts in mind  you have to question the current fashion/vogue for so called “multi-hypervisor” strategies. I personally think the benefits have been wildly overstated. In one corner you have folks talking about avoiding “vendor lock-in”. But from where I’m standing a multi-hypervisor strategy locks you into to multiple vendors with different upgrade/roadmap timings. That leads to a “jive” between vendors and degrading of experience. After all, software vendors often struggle to get their own products compatible with each other – so expecting compatibility between vendors is double-ask… There’s been a couple of examples of that “jive” in this post already for example:

• VMware Convertor doesn’t natively recognise Windows Hyper-V 2012 (although you can do conversions as if the VM was physical)
• The plug-in for SCVMM getting a remote console on a vSphere5.1 is broken
• MCMV plug-in does not work with vSphere5.1 Client.

For me a so-called multi-hypervisor “strategy” is one that invariably means creating a “silo”, and curtailing one virtualization platform to one silo, and another virtualization platform to another silo. One of the first lessons I learned as SysAdmin in the ’90s is you do everything you can to reduce differences, rather than making decisions that increase them. We live in a period where we trying breakdown the silos of the past (between servers, network, storage) whilst at the same time some folks think its a good idea to create and generate new ones.

Virtual Machine Conversion:

As for convert from M2V or from V2M, I found the conversion from Microsoft to VMware using VMware Convertor was more robust and dependable. I particularly think the way VMware Convertor handles the syncing and switch over from Windows Hyper-V to VMware vSphere is better than using snapshots and the OVF export process. The other big advantage I think of VMware Converter is that it does a true online conversion of a Windows Hyper-V VM without a power down of the source. Both SCVMM and MVMC requires the vSphere VM to be powered off. SCVMM requires the VM to be powered before you even begin – and MVMC snapshots and powers off the VM before the export to OVF begins…

The MVMC method adds many additional steps (each could go wrong) and is dependent on lots of temporary storage to get the VM out of the domain of vSphere, and ready for Windows Hyper-V. The fact that VMware Convertor is so much better is a good thing for all those folks who thought that Windows Hyper-V was “good enough” and later discovered that “best of breeds” was the better approach. I feel sorry for those having to embark on lengthy conversion process because a less than excellent platform was selected in the first place. I know how those people feel. I worked in the ’90s for a company that seemed to be forever picking “good enough” products in effort to save money. What they burned instead was something more valuable – time. The amount of time wasted baby-sitting “good enough” technologies was never factored into the calculation. One of the good things about VMware vSphere is the fact that it pretty much takes care of itself leaving the SysAdmin free to baby-sit the software that doesn’t!

On a more practical level moving from one virtualization vendor to another (or even one cloud vendor to another) inevitably means a lengthy conversion process because there is no common standard for virtual disks. But on top of that it means changing processes and standards around virtualization management that might have taken many years of hard-won experience to develop. Making a switch means jumping into a time-machine a going back to that time. For some that process was quite painful, and personally don’t see much advantage in revisiting that period all over again. Even if a technology can convert a VM whilst its online from A-to-B and B-to-A, its still the case you will need to take a maintenance window, and do other configurations such as fixing the IP configuration of the VM. It’s for these reasons I think getting the choice of virtualization platform right first time is so important. Of course, at VMware we love to hear about “switch stories” where customers move from Microsoft to VMware. But personally, I’d prefer that customers didn’t haven’t to go through that wall of pain in the first place – by selecting VMware the first time! 🙂

Comparing the various conversion processes I used – I would recommend to Microsoft customers who are switching to VMware that they use the VMware Convertor (rather than VMware MHM) to do the conversion – as there are more options and controls available. For those going in the other direction MVMC seemed more dependable than the built-in functionality of SCVMM – but even with it I found my mileage varied considerably. Comparing the tools together – I rated VMware Convertor over MVMC by a country mile. That said they have totally opposite directions – after all VMware Convertor does not help customer move away from VMware. That’s something I’ve seen throughout my career where competing formats appear – conversion tools are created by vendors to help you move to them. They are nearly always unidirectional, and that means the vendor starts from weak position. By trying to convert a competing vendors format to their native format.

All this talk of “conversion” takes me back to my old P2V days – where I wrote extensively about the process of converting physical machines to virtual machines. Sure, the process now is much simpler and virtualization has helped generally to the portability of workloads – but were still a long, long way from it being a seamless process with no downtime, no operational changes and no maintenance window. And this is why I think the development of the VMware Cloud Hybrid Service is so important (as well as the plethora of Service Providers in the vCloud service providers program). It allows you to easily move your private vSphere VMs out a private virtualization/cloud environment into a public offering – without this conversion process getting in the way. You not locked-in to single supplier such as Amazon or Azure – and because the VM’s format stays the same – reclaiming the VM and bring it all back home to your private vSphere/vCloud environment is simple click using vCloud Connector.

As for Microsoft – my gut feeling is that since Windows Hyper-V 2012 has been released there’s been considerable “tyre kicking” by customers. I think that tyre kicking period is slowly coming to an end. Once again, folks having kicked the Microsoft tyres – they have found them wanting when compared to VMware vSphere. Some folks have to go through this tyre kicking process for their own peace of mind, or to be able to convince management that due diligence has been done. After all nothing beats first hand experience of a technologies deficiencies…..