The differences between MVS and Hyper-V
To explain the situation a bit, MVS is known as a "Type-2" virtualization architecture. This means that MVS runs as an application that is installed on top of an existing operating system (OS). As an application, virtual machine (VM) resource requests that run inside MVS must first pass through MVS and then make their way through the operating system before they can gain the attention of the physical resources. These extra hoops that VM requests are forced to jump through are why MVS is classified by many administrators as "slow".
Compare this process with Hyper-V, which is called a Microkernelized Type-1 architecture. "Type-1" in this case means that the virtualization layer actually sits directly on top of your physical hardware instead of above a regular OS. "Microkernelized" means that it's an extremely thin hypervisor that is made even thinner (read: thinner than what you see with products like VMware's ESX) because it contains no drivers. Unlike VMware ESX, Hyper-V stores its drivers in a special partition called the "primary partition". You can consider the primary partition as "the OS that used to be the full OS before you installed the Hyper-V role".
Hyper-V gives you a significant speed gain because virtual machines use pointers – called synthetic drivers – that direct virtual machine hardware requests to the actual driver in the primary partition. That driver then delivers the request on behalf of the virtual machine resulting in extremely high performance.
Moving your virtual workloads from MVS to Hyper-V will above all net you some significant speed improvements. But first you've got to get there. While the process to migrate MVS-hosted virtual machines to Hyper-V isn't hard, there are a few steps that you'll want to follow to ensure success. These extra steps are required because of the fundamental differences between the drivers used by the two virtualization solutions. Although both solutions leverage the same virtual hard disk (VHD) format for their disk files, the way in which they run their VMs requires a little massaging before you hit the button to power them on.
Migrating workloads from MVS to Hyper-V
Before making any moves, make sure that your Hyper-V installation is patched to the right levels. This means upgrading the native – and beta – Hyper-V code on your Windows Server 2008 box to the release to manufacturing (RTM) code. To do this, use the patch associated with knowledgebase article 950050. You'll also need the Hyper-V management console on your Vista SP1 desktop, which you can get from knowledgebase article 952627. If you're planning to use Hyper-V in a clustered environment, grab 951308. You'll also want to install 956589 and 956774 if you plan to manage Hyper-V with the RTM version of System Center Virtual Machine Manager (SCVMM).
Once you're patched and ready to go, migrate your MVS virtual machines over to Hyper-V, with following process:
- First, upgrade all of your virtual machines to their latest service pack if possible. This ensures that you're at the most recent software revision should any problems occur. This is an optional step, but ensuring the right patch level is a good idea when doing any migrations.
- Before starting any migrations, consider powering down all of the virtual machines you intend to migrate. Make a copy of their VHD files and store them elsewhere on the network to be used in the case of a migration failure.
- Once you have completed your emergency backups, while in MVS uninstall the MVS Virtual Machine Additions through Add/Remove Programs. Since the MVS additions don't function in Hyper-V, doing this before the migration saves you trouble down the road. Complete any necessary reboots to ensure the additions are removed.
- Next, check the VM's Hardware Abstraction Layer (HAL) to verify that you are running an ACPI HAL. If not, consider switching the HAL to an ACPI HAL prior to your migration. Also, consider uninstalling any network cards before moving to Hyper-V to prevent a known issue that involves static IP address conflicts with "hidden" network cards.
- If your virtual machine makes use of differencing disks, merge all differencing disks back into the main disk. The process to do this is explained here.
- Next, power down the virtual machine and copy its VHD file to your Hyper-V VHD storage location. By default, this location will be a subfolder of C:\ProgramData\Microsoft\Windows\Hyper-V, which is a hidden folder on your server with the name of the subfolder being equal to the name of the virtual machine. You only need to copy the VHD file as the other files are unusable in Hyper-V.
- Within Hyper-V, choose to create a new virtual machine. Create the VM with the settings you want. When prompted, choose to Use an existing virtual disk and point the wizard to the location where you have stored your VHD file.
- Finally, power on the virtual machine and install the Integration Components. This can be done in the Virtual Machine Connection window by clicking Action | Insert Integration Services Setup Disk. This process can take multiple reboots to complete. Once completed, make sure that any HAL updates and networking have completed upgrading successfully.
This process looks difficult on paper, but is easy in practice and is essentially risk-free if done properly. Should you experience any problems with the migration, reverting back to your untouched MVS VHD files is as easy as copying them, re-mounting them in MVS and then powering them back on. Be aware, though, that while the VHD file format is functionally compatible between MVS and Hyper-V, the Integration Components are not. Thus, once you've made the move towards Hyper-V, it can be complicated to revert back to MVS.
ABOUT THE AUTHOR:Greg Shields, MVP, is a co-founder and IT guru with Concentrated Technology (www.concentratedtechnology.com) with nearly 15 years of IT architecture and enterprise administration experience. He is an IT trainer and speaker on such IT topics as Microsoft administration, systems management and monitoring, and virtualization. His recent book Windows Server 2008: What's New/What's Changed is available from SAPIEN Press.
This was first published in November 2008