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.
- 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.
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.
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!!!
- 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?