Birds have the right idea: Why not move to where the weather's better? Sure, it takes a lot of time, effort and energy to cross entire continents, but the trip is often worth it. The same can be said of platform migrations, as technical advantages may come with potential difficulties. Now that Microsoft's Hyper-V is finally available as an official, fully-supported platform on Windows Server 2008, many IT managers might be thinking about migration.
If you've been standing on the sidelines waiting for the official release of Hyper-V, you no longer have any excuses for waiting to at least deploy it in a test environment. If you've been working with the beta and release candidate versions, you're probably ready to deploy some production virtual machines (VMs) with Microsoft's latest virtualisation product. If your data center environment has an existing investment in Microsoft Virtual Server (MSVS) 2005, this article will help you decide why and how you might want to migrate.
Deciding to migrate to Hyper-V
It's important to first make a business and technical case for moving existing infrastructure to a new environment. If you have VMs that are running happily on MSVS, there's no immediate need to move them. MSVS is a supported platform, and it's free on machines that are running Windows Server 2003. With that said, don't expect any significant updates to MSVS. Hyper-V is Microsoft's platform for going-forward.
So what are good reasons to migrate? If you're planning to standardize on a platform, it can be helpful to migrate existing MSVS VMs to Hyper-V (especially if your MSVS environment is relatively small.) This will allow you to build expertise on Hyper-V and to simplify management. Note that some management tools, such as Microsoft System Center Virtual Machine Manager (MSCVMM) allow you to manage both MSVS and Hyper-V from within a single product.
Once you've decided to move workloads from MSVS to Hyper-V, the question turns to how you should perform the migration. One method is to completely rebuild new VMs for Hyper-V and then reinstall and reconfigure your applications. Sure, the process can be tedious and time-consuming, but if you're planning to build a Hyper-V VM Library anyway, it might not be all that difficult. Of course, there's often risk associated with moving complex applications, and you might not have the expertise (or patience) to do it manually. Fortunately, there are other options.
Manual VM migration
Both MSVS and Hyper-V use the same virtual hard disk (VHD) format, so this makes it fairly easy to migrate between the platforms. The main difference is that Hyper-V VMs can use a different set of drivers. So how do you accommodate this? The following steps outline the steps in the migration process:
- Start the VM in MSVS and choose to remove the "Virtual Machine Additions". For Windows OSs, this is done by accessing the Add/Remove Programs applet in Control Panel.
- Shut down the source virtual machine in MSVS. Note that you cannot migrate saved state information to Hyper-V, nor can you safely move or copy a VHD while it's in use (without the help of backup and recovery tools, that is). Make a note of the configuration settings for the VM (including CPU constraints, memory allocation, disk configuration and network adapter configurations).
- If you want to save the original VM for the purpose of rolling back, make a copy of all VHDs that are associated with the VM. Otherwise, you can use the current VHDs.
- Using the Hyper-V Management Console, create a new virtual machine using the settings you recorded in Step 2. You can safely make various changes, if necessary. For example, you can generally change the VM's memory allocation settings without causing any problems for future steps.
- Attach the VHD(s) from the source VM to the new VM. You can choose to attach the VHD when using the New Virtual Machine Wizard, or by using the appropriate commands in the Actions pane of the Hyper-V Management Console.
- Start the new Hyper-V VM. Log in to the guest OS and choose to install Integration Services. This will automatically install the most appropriate drivers for your guest OS. When prompted, reboot the VM.
When you're done, you should have a new Hyper-V VM ready for production use. This might sound like a lot of work, but rest assured: you can often complete these tasks in a matter of minutes (the majority of that time will likely be spent in rebooting the new VM.)
A word to the wise: Be sure to test your migrated VMs thoroughly before relying on the converted VMs in a production environment. There's always a chance that virtual network settings or VM configuration changes will cause unexpected issues to crop up.
Virtual-to-virtual (V2V) conversions
This approach might not get as much press as physical-to-virtual (P2V) conversions, however, organisations can use automated tools to move a VM between environments. While most of these tools incur some amount of cost, they can greatly reduce risk and effort required to move VMs. They can also perform certain types of conversions "hot" – that is, with little or no downtime. The conversion process can be attractive for environments that want to move large numbers of VMs between platforms, or that want to move between significantly different products. An example of the latter is moving a workload from VMware to Hyper-V (or vice-versa).
If you're currently supporting MSVS-based VMs, there's a good chance that you'll want to move them to Hyper-V at some point. Fortunately, there are several different ways to make the transition, depending on your requirements. Migration can be a painful and difficult process, but the benefits often make it worth it. Keep that in mind as you update your virtualisation infrastructure. Enjoy your flight!
About the author: Anil Desai is a Microsoft MVP and a Microsoft Certified Professional with numerous credentials including MCITP, MCSE, MCSD, and MCDBA. He is the author or coauthor of nearly 20 technical books, including several study guides for Microsoft Certifications.