Yet, MVS isn't entirely to blame for its intrinsic limitations. You see, MVS is exceptionally different from Microsoft's replacement platform, Hyper-V. As a type 2 hypervisor, MVS was installed as an application atop an existing operating system (OS). This is fundamentally different from Hyper-V R2's type 1 approach, which installs the hypervisor (for lack of a better word) "beneath" the OS. Being a type 2 hypervisor, MVS and its virtual machines (VMs) were not able to use the more direct communication paths that Hyper-V R2 enjoys. Because of its role as an application, MVS has the same processor scheduling priority as Windows Solitaire does on its host system.
The result is that virtually every business is looking to move off of MVS today. Completing this task isn't a trivial process, which means solutions providers can take advantage by offering migration services. The migration from Microsoft Virtual Server to Hyper-V R2 involves a set of manual steps that will incur downtime and require patience. To demonstrate the value of your services to your customers, you must make the transition as seamless as possible.
The first step in migrating Microsoft Virtual Server to Hyper-V R2 is identifying the server resources that will eventually host the new Hyper-V R2 VMs. Be aware that R2's requirements for processor virtualization extensions, hardware Data Execution Prevention and a 64-bit architecture may eliminate many existing MVS servers from the running. Also, be careful when spec'ing Hyper-V R2 clusters, because you must ensure that enough nodes are available for all VMs, that there is extra space for failover and even more extra space for VM expansion.
Once your customer's Hyper-V R2 infrastructure is laid out, purchased and in place, the complex process of migrating Microsoft Virtual Server VMs to Hyper-V R2 begins. This process requires multiple reboots, so plan for an extended outage during its completion. Prior to starting this process, it is always a good idea to power down any VMs and copy their .VHD files to archival storage as an emergency backup.
All VMs use special drivers that enable them to function within the hypervisor infrastructure. With some exception, these special drivers are very different when they move from one platform to another. The MVS to Hyper-V R2 migration is no different.
In step two, you have to uninstall the special drivers from each VM that is being migrated. Uninstall the MVS Virtual Machine Additions through Add/Remove programs and complete any necessary reboots to ensure their removal. It is also a best practice to uninstall network cards before migrating to Hyper-V R2, and that should be done during this step. Doing so will eliminate a known problem with hidden network cards that occurs once the VM begins its life atop Hyper-V.
Next, merge or remove all differencing disks and/or snapshots that are attached to the VM. Disks and snapshots can cause problems during the migration.
Once the preparatory activities are complete, copy the virtual machine's .VHD disk files to your customer's Hyper-V R2 storage location. On non-clustered servers, this will be in subfolders of the hidden folder C:\ProgramData\Microsoft\Windows\Hyper-V. After copying, create a new VM within the Hyper-V Manager console and point its configuration to the existing virtual disk.
The last step requires powering on the VM and installing Hyper-V R2's special drivers: the Integration Components. This is done in the Virtual Machine Connection window by clicking Action, then Insert Integration Services Setup Disk. A reboot may be required to complete this action.
As a solutions provider, ensuring that this process runs without causing problems is key to demonstrating the value of your services. The biggest area in which issues can occur with the MVS migration is in not planning enough time to complete the transfer. Because many VMs are exceptionally large in size, the raw transfer time to copy their .VHD files from one location to another can consume many hours of the project's total time. To prevent an accidental outage, ensure that enough planned downtime is available, or separate the project into multiple individual outages.
About the expert
Greg Shields is an independent author, instructor, Microsoft MVP and IT consultant based in Denver. He is a co-founder of Concentrated Technology LLC and has nearly 15 years of experience in IT architecture and enterprise administration. Shields specializes in Microsoft administration, systems management and monitoring, and virtualization. He is the author of several books, including Windows Server 2008: What's New/What's Changed, available from Sapien Press.
This was first published in December 2009