Get a glimpse into Janique and Robert’s latest book – Windows Server 2008 Hyper-V Resource Kit. This chapter contains an overview of the Hyper-V features available in a full installation of Windows Server 2008, as a Server Core role and in Microsoft Hyper-V Server 2008.
Windows Server 2008 Hyper-V Resource Kit
Moving from Virtual Server 2005 R2 SP1 to Hyper-V involves migrating both the Virtual Server host and the virtual machines. Because of the change in architecture, it is not a simple process—you can’t perform an upgrade in place to make this move. Rather, the host and virtual machine migrations must be done separately. It is not a terribly difficult process, but the multiple steps involved in the migration must be performed in the correct order. This chapter will provide you with guidance about what should be moved, how to move it, when to move it, and other important considerations you need to be aware of during the process.
Considerations Before Migrating a Virtual Server 2005 R2 Host to Hyper-V
Virtual Server 2005 R2 SP1 is a hosted virtualization solution that runs on top of the operating system, and Hyper-V is a hypervisor that runs under the operating system. Because this is a significant change in architecture between Virtual Server 2005 R2 SP1 and Hyper-V, there is no option to perform an in-place upgrade of a Virtual Server 2005 R2 SP1 to Hyper-V.
The goal of the migration should be to get the Virtual Server host and virtual machines migrated with minimum impact and downtime. The best way to accomplish this is to migrate to new server hardware. This allows you to install Windows Server 2008 and the Hyper-V role or Microsoft Hyper-V Server 2008, configure the machine for the migration, and properly optimize the configuration following the guidelines provided in Chapter 7, “Hyper-V Best Practices and Optimization.” After you have optimized the installation, the virtual machines can be migrated from the Virtual Server 2005 R2 SP1 server to the new Hyper-V server.
Maintaining Virtual Server 2005 R2 Hosts
Although you might be tempted to migrate off all Virtual Server 2005 R2 SP1 hosts, it is a good idea to keep Virtual Server around for certain guest operating systems. Virtual Server 2005 R2 SP1 provides support for the following guest operating systems that Hyper-V does not support:
Windows NT Server 4.0 with Service Pack 6a
Windows XP SP2 (for Virtual Server 2005 R2 only)
Red Hat Enterprise Linux 2.1 (update 7)
Red Hat Enterprise Linux 3.0 (update 8)
Red Hat Enterprise Linux 4.0 (update 4)
Red Hat Enterprise Linux 5.0
Red Hat Linux 9.0
SuSE Linux 9.3
SuSE Linux 10.0
SuSE Linux 10.1
SuSE Linux 10.2
If you have virtual machines running any of these guest operating systems, we would recommend keeping them on Virtual Server instead of moving them to Hyper-V.
Wireless Networking Support
Virtual Server 2005 R2 SP1 provides support for wireless networks to be used for binding virtual networks. Hyper-V does not implement direct attachment of external virtual networks to wireless network adapters because Hyper-V adheres strictly to the 802.11 specifications, and those specifications do not allow wireless networks to modify the MAC address.
Server Hardware Support
You must evaluate your hardware before upgrading to Hyper-V to manage your virtual machines. The hardware you are planning to use for the Hyper-V server must be 64-bit and must provide hardware virtualization extensions enabled for the Hyper-V installation to be completed successfully. Since you cannot upgrade an existing Virtual Server 2005 R2 SP1 server directly to Hyper-V, either you must provide new server hardware, or the existing hardware must meet the recommended minimum Hyper-V hardware specifications to be reused.
When you migrate virtual machines from Virtual Server to Hyper-V, the virtual machines must be powered off for the migration. This will cause a period of downtime for the individual virtual machines. In addition, depending on the approach you take during the migration of the Virtual Server host, the host also could experience downtime that will result in downtime for all the virtual machines. Therefore, you should determine how much downtime is acceptable for the host and the virtual machines before you choose the host migration approach.
Migrating a Virtual Server 2005 R2 Host to Hyper-V
Migrating from Virtual Server 2005 R2 SP1 to Hyper-V is a multistep process, but the steps may vary based on the current configuration of your Virtual Server host. From previous chapters, you know that to run Hyper-V, you must have either Windows Server 2008 64-bit or Microsoft Hyper-V Server 2008. Unless the current Virtual Server 2005 R2 SP1 installation is running on the Windows Server 2008 64-bit operating system, you will first need to create a new installation of Windows Server 2008 x64 or Microsoft Hyper-V Server 2008.
If the Virtual Server host is currently running on Windows Server 2008 x64, it is possible to back up the host, uninstall Virtual Server, install the Hyper-V role, and then migrate the virtual machines. This method allows you to use the same hardware during the migration without having to copy virtual machine files to another computer, but it requires the existing Virtual Server and the virtual machines to be taken offline, so users will experience downtime. It also means that if something goes wrong, the recovery process will not be quick or painless. To minimize downtime on the host and the virtual machines, a better approach is to build a new Hyper-V server and migrate the virtual machines to the new server. You will gain several advantages by using this approach:
The flexibility to migrate virtual machines when needed
The ability to size the hardware to meet the requirements
No downtime for the existing Virtual Server host
The consolidation of multiple Virtual Server hosts to a single Hyper-V server or cluster of hosts
In addition, if something goes wrong during the migration process, the virtual machines still exist on the Virtual Server host and can be rebooted quickly.
The host migration process discussed in the following sections focuses on the side-by-side migration approach versus the migrate-in-place approach. The steps in the process include developing the specification for the Hyper-V server hardware, building the Hyper-V servers, and migrating the configuration. When you have completed the migration, you will be able to add any new features or capabilities available in Hyper-V.
Developing the Hyper-V Server Specification
The first step in the process is discovering and documenting the configuration of the Virtual Server 2005 R2 SP1 environment so that you can determine the minimum required Hyper-V hardware configuration. This involves determining the current hardware specification for memory, disk storage, networking, and processor. In addition, collect the number of virtual networks currently configured on the Virtual Server host. When you have collected this information, you can start developing the Hyper-V server specification. Use the following guidelines to determine the specification.
Hyper-V memory configuration should include memory reserved for the parent partition—typically a minimum of 1 gigabyte (GB) of RAM, virtual machine memory—the size of the memory of each virtual machine plus overhead calculated by adding 32 MB for the first gigabyte (GB) of RAM and then 8 MB for each additional gigabyte of RAM, and memory for the predicted number of concurrent VMConnect.exe sessions on the host at 20 MB each. It is always a good idea to add additional memory for expansion for temporary purposes (1 to 2 GB of RAM). At a minimum, you should make sure the Hyper-V server has as much memory as the current Virtual Server host.
Disk storage can involve many choices, including disk drive speed, disk drive size, RAID configuration, controller cards, and so on. Focusing on just the amount of storage you will need, the server requires space for the parent partition operating system; space for each virtual machine’s virtual hard disk (VHD), the maximum defined size of the VHD; space for saved-state files, which will vary based on the amount of RAM in the virtual machine; space for snapshots, which will vary based on the number of snapshots planned; and space for additional files such as CD or DVD images. At a minimum, you will need the amount of storage space that is currently used on the Virtual Server host, plus additional space for snapshots if you plan to use them.
Networking configuration involves the needs of the parent partition, interfaces for iSCSI communications, interfaces for clustering if the Hyper-V server is a member of a host cluster, and interfaces for the required number of virtual networks. The Hyper-V server should include a minimum of one 1-gigabit Ethernet card reserved for parent partition management purposes, one 1-gigabit Ethernet card for iSCSI communications (if iSCSI will be used), two 1-gigabit Ethernet cards for cluster communications (if a member of a host cluster), and one 1-gigabit Ethernet card for each required external virtual network.
Virtual Server allowed multiple virtual networks to be configured to a single network interface card, but Hyper-V allows only a single virtual network to be bound to a network interface card.
Processor configuration involves the needs of the parent partition, each virtual machine, and reserve for unexpected peaks in performance. The Hyper-V parent partition should have a minimum of one processor core reserved for its use to manage shared parent partition resources; each virtual machine should have a minimum of a single processor core; and a reserve amount of processing (one or more cores) should be included for peaks in performance and possible expansion. Virtual machines in Virtual Server 2005 R2 SP1 could have only a single processor. With Hyper-V, each virtual machine can have up to four virtual processors (depending on the operating system). If any virtual machines currently running under Virtual Server are utilizing high amounts of processing power, there is an opportunity to add virtual processors during the migration. Be sure to account for any additional processors you may need during the sizing process.
When you have identified the Hyper-V configuration you will require and have purchased and assembled the hardware, you are ready to install Hyper-V on the system. Chapter 4, “Hyper-V Installation and Configuration” goes into detail about how to install Hyper-V on the hardware and outlines the post-installation configuration changes that you should make.
Migrating Virtual Networks
After you have completed the default installation and optimization, you are ready to migrate the current configuration of the Virtual Server 2005 R2 SP1 virtual networks to the Hyper-V server. This is a manual process and involves recreating the required virtual networks that existed on the Virtual Server host on the Hyper-V server. In order to do this, you must determine the mapping of the existing virtual networks to physical adapters or loopback adapters (in the case of internal networks). When you have identified the mapping, collect the TCP/IP settings for the network adapter so that the subnet can be identified. This will allow you to determine which physical network adapter must be used in the Hyper-V server when the external virtual networks are recreated or how many internal or private virtual networks must be created.
The next step is recreating the external virtual networks on the new Hyper-V server to the correct physical network adapter using the mapping you identified. Although the virtual network name does not have to be the same as it was on the Virtual Server host, it is a good idea to use the same name to minimize any confusion. After the external virtual networks are completed, recreate any required internal or private virtual networks.
You no longer have to add a loopback adapter to get guest-to-parent partition communications internal to the Hyper-V server. An internal network provides this functionality. For each Virtual Server network that was created using a loopback adapter, create an internal virtual network in Hyper-V.
If the Hyper-V server was configured with additional physical network adapters to expand the number of available external virtual networks, now is the time to configure these. Remember to use the established naming convention for virtual networks.
Best Practice – Dedicate a network adapter for parent partition communications by not binding it to any external virtual network.
Best Practice – For any external virtual network you create, you must disable the parent partition virtual LAN adapter that was created so that the external virtual network is dedicated for virtual machine communications only.
Considerations Before Migrating Virtual Machines
Hyper-V does not provide the ability to import virtual machines that exist on a Virtual Server 2005 R2 SP1 host; you must migrate the virtual machines manually. The building blocks of a virtual machine in Virtual Server 2005 R2 SP1 and Hyper-V are basically the same, a virtual hard disk and a configuration file. The virtual hard disk has not changed and can be easily migrated from Virtual Server to Hyper-V. The configuration file has completely changed, however, and Microsoft does not provide a tool to migrate the settings from the old format to the new format.
Boot Disk Configuration
Virtual Server 2005 R2 SP1 virtual machines could be attached to the virtual SCSI adapter and the virtual machine would boot in this configuration (it was a recommended configuration for best performance). This was possible because the SCSI adapter was emulated and available at boot time. Hyper-V virtual machines cannot boot from the SCSI adapter, however, because it is synthetic, and synthetic devices are not available immediately at boot time. Therefore, virtual machines that are currently configured to boot from SCSI in Virtual Server must be converted to boot from IDE as part of the migration to Hyper-V.
Unlike Virtual Server IDE–attached virtual hard disks, IDE-attached virtual hard disks in Hyper-V perform almost on par with SCSI-attached virtual hard disks.
Virtual Machine Additions
Virtual Server 2005 R2 SP1 uses enhanced drivers to provide emulated devices and to improve performance in a virtual machine. Hyper-V uses something similar to provide synthetic devices and performance enhancements to virtual machines. The architecture and interfaces between these two technologies are not compatible; therefore, you must remove Virtual Machine Additions as part of the process of migration to Hyper-V. Although it is possible to remove the additions after you have migrated the virtual machines to Hyper-V, your ability to do this depends on the version of Virtual Machine Additions that is installed. The better approach, which will work regardless of the version installed, is to uninstall Virtual Machine Additions prior to migrating to Hyper-V.
The Undo disk feature in Virtual Server 2005 R2 has been removed in Hyper-V and replaced with a more powerful feature called snapshots. You cannot migrate Undo disks to Hyper-V; they must be discarded or committed prior to migrating the virtual machine hard disk to Hyper-V.
Virtual Server 2005 R2 SP1 and Hyper-V both have the ability to save the state of a running virtual machine to disk. The concept is similar to hibernation. In Virtual Server 2005 R2, the saved state file was a single file (.vsv) that contained the contents of memory and information on running processes, threads, and the processor stack. Hyper-V has split the save state file into two parts: the memory contents (.bin) and the stack and process information (.vsv). Because of this change, saved states cannot be migrated and must be merged or discarded before the migration can occur.
Hardware Abstraction Layer Differences
Virtual machines running in Virtual Server 2005 R2 can have only a single virtual processor. Hyper-V provides the ability for a virtual machine to be configured with up to four virtual processors. This presents an issue with hardware abstraction layer (HAL) compatibility. Hyper-V virtual machines require a multiprocessor Advanced Configuration and Power Interface (ACPI) HAL. Virtual Server 2005 R2 virtual machines can have APCI or non-ACPI HALs based on how they were created and what version of additions are loaded. Regardless of which HAL the existing virtual machine has, the HAL must be changed during the migration of the virtual machine to Hyper-V. For instructions on changing the HAL for Vista and Windows 2008 virtual machines, go to http://technet.microsoft.com/en-us/library/dd296684.aspx.
Both Hyper-V and Virtual Server 2005 R2 support differencing disks, and the technology has not changed. Differencing disks require that the parent and the child retain the same relative path when they are moved on the same machine or between machines. The relative path to the parent VHD is stored in the disk header of the child VHD. If a child VHD is copied and the parent is not, or if the relative path is not maintained between the two files, the child VHD will not have all the information it requires and the differencing disk will not be usable.
During migration, you may want to modify the directory structure of how the virtual machines are stored. If the directory structure change breaks the differencing disk relative path, you can repair the virtual hard disk using the Inspect Disk feature in the Hyper-V Manager MMC console.
Shared SCSI Virtual Machine Clusters
Virtual Server 2005 R2 virtual machine–emulated SCSI controllers provided a mode called shared SCSI (a parallel SCSI bus). Enabling shared SCSI on the controller allowed a Windows Server 2003 cluster to be built between virtual machines. Hyper-V has switched to a synthetic SCSI controller and removed the ability to put the SCSI controller into parallel SCSI bus mode. You can still create a cluster between virtual machines in Hyper-V, but you must use an iSCSI Initiator to attach remote iSCSI LUNs to the virtual machines. Virtual Server–based virtual machine clusters must be manually migrated to Hyper-V.
Migrating Virtual Machines
The following sections will guide you through a process that will enable you to migrate virtual machines from Virtual Server 2005 R2 SP1 to Hyper-V. Not all of the steps provided in the process will be required for your Virtual Server installation, depending on what features you are using from Virtual Server. The process includes the following tasks:
Determine compatibility with Hyper-V.
Convert SCSI boot to IDE boot.
Remove Virtual Server Additions.
Remove network interface cards.
Commit or discard all Undo drives.
Merge or discard saved states.
Merge all differential disks.
Check the hardware abstraction layer (HAL).
Copy the virtual hard disk to the new Hyper-V server.
Create a new virtual machine using existing VHD.
Install Integration Services.
Before you migrate a virtual machine, you should determine if it contains a supported operating system, and if the applications running in the virtual machine are supported by the independent software vendor (ISV) for production use on Hyper-V. Compare the operating system with the Hyper-V–supported guest operating systems and be sure to match product versions and service pack levels.
Convert SCSI Boot to IDE Boot
We have already discussed that Hyper-V does not support booting from the synthetic SCSI controller. So before you can migrate a Virtual Server 2005 R2 virtual machine that currently boots from a SCSI adapter to Hyper-V, you must convert it to boot from the IDE controller. Follow these steps to migrate the boot disk from a SCSI controller to an IDE controller:
Launch the Virtual Server Administrative Web console.
Select Configure from the Virtual Machines menu and then select the virtual machine name from the list.
From the Configuration menu options, select Hard Disks to display the Virtual Hard Disk Properties page, which shows the current configuration of all the hard disks for the virtual machine (see Figure 8-1).
Figure 8-1: Virtual Hard Disk Properties page
To convert the virtual hard disk so that it boots from the primary IDE controller (ID 0) instead of the SCSI controller (ID 0), select Primary Channel (0) from the Attachment drop-down list, as shown in Figure 8-2.
Figure 8-2: Virtual hard disk with Primary IDE channel (0) selected
To save the change, click OK.
Direct from the Source
Migrate VHD from SCSI to IDE Controller
Tony Soper, Senior Technical Writer
Windows Server Technical Writing Team
If you standardized attaching VHDs to SCSI controllers as most people did for performance reasons, manually migrating them to IDE controllers can be time-consuming. Following is a script that can help automate that process. Save this script as SCSI2IDE.vbs and run it with a command-line option to indicate the virtual machine for which you want to reconfigure the boot disk to use IDE instead of SCSI.
On the Companion Media – This script is included on this book’s companion media, in the \Scripts\Chapter 8 folder.
dim id, rtn
dim objVS, objVM, objHardDisk
dim colArgs, colVMs
Set objVS = CreateObject(“VirtualServer.Application”)
set colVMs = objVS.VirtualMachines
set colArgs = wscript.Arguments
id = 0
For Each objVM in colVMs
If objVM.Name = colArgs.item(0) then
set hdskConnections = objVM.HardDiskConnections
For Each objhdskConnection In hdskConnections
set objHardDisk = objhdskConnection.HardDisk
strFile = objHardDisk.File
wscript.echo “VM Disk File” & strFile
If objhdskConnection.BusType = 1 Then
rtn = objhdskConnection.SetBusLocation (0,0,id)
id = id+1
You should make sure all the virtual machines are powered off on the Virtual Server host prior to running the previous script.
Remove Virtual Machine Additions
Virtual Server 2005 R2 SP1 Virtual Machine Additions are not compatible with the Hyper-V architecture and will not work properly with it. Although it is possible to remove Virtual Machine Additions version 13.813 or newer from within a migrated virtual machine, a less risky approach is to remove the additions prior to migrating the virtual machine.
Follow these steps to remove Virtual Machine Additions:
Power on the virtual machine and log in with administrative privileges.
In the virtual machine, open Control Panel and then double-click Add Or Remove Programs or Programs And Features (depending on the operating system version).
Select Virtual Machine Additions and then select Remove, or right-click and select Uninstall (depending on the operating system version).
Click Yes in the confirmation dialog box that appears.
After you have successfully removed Virtual Machine Additions, restart the virtual machine.
Remove Emulated Network Interface Cards
Virtual Server 2005 R2 SP1 virtual machines have a single network interface card installed inside the virtual machine by default. The network interface card emulates an Intel 21140 adapter. In Hyper-V, the default networking interface card is not the legacy network adapter (which also emulates an Intel 21140 adapter), but instead is the synthetic network adapter. If you attempt to move a virtual machine with the emulated Intel 21140 adapter still installed, the network adapter will become a hidden device. You can install Hyper-V Integration Services and all will seem to be fine, but if the emulated Intel 21140 adapter had a static IP address assigned, any attempt you make to reassign that static IP address to the new synthetic network adapter will result in a warning box that says the IP address is already in use.
Follow these steps to remove the network adapter from the virtual machine:
Power on the virtual machine.
Log in with administrative permissions.
Open Control Panel and double-click Device Manager.
Expand the Network Adapters node.
Right-click the Intel 21140 adapter listed and select Uninstall.
Shut down the virtual machine.
When you migrate the virtual machine to Hyper-V, a synthetic adapter will be installed. The network adapter might not function until you install the Integration Services, however.
The synthetic network adapter in Hyper-V does not support boot from pre-execution environment (PXE). To enable PXE boot, you must use a legacy adapter.
Commit or Discard Undo Disks
Virtual Server 2005 R2 provided a disk mode that would write all changes to a separate file. This mode, called Undo, allowed you to perform what-if changes to the disk without fear that the changes had to be permanent. Undo disks were not very flexible if you needed to perform multiple what-if scenarios, however, so in Hyper-V the technology was replaced with snapshots. This means that any Undo disks in Virtual Server virtual machines must be discarded or committed to the virtual hard disk prior to migrating it to Hyper-V.
If a virtual machine is configured to use Undo disks but does not currently have an active Undo disk, then you do not need to perform any additional steps. If you do need to commit or discard an Undo disk, the procedures are slightly different depending on whether the virtual machine is currently powered on or not.
Follow these instructions for committing or discarding the Undo disks for a virtual machine that is currently powered on:
Shut down the virtual machine.
Select Turn Off Virtual Machine And Commit Undo Disks to commit the Undo disk if you want to merge the current changes into the virtual hard disk, or select Turn Off Virtual Machine And Discard Undo Disks to discard the changes to the Undo disk if you do not want to merge the changes.
Follow these instructions for committing or discarding the Undo disks for a virtual machine that is currently powered off:
Launch the Virtual Server 2005 Administration Web site.
On the Master Status page, find the appropriate virtual machine in the list of virtual machines and click the arrow to display the actions menu.
Figure 8-3 displays the menu options available. Select Merge Undo Disks or Discard Undo Disks from the menu.
Figure 8-3: Undo Disk actions menu for a virtual machine
Restore or Discard Saved States
Virtual Server 2005 R2 saved states are not compatible with Hyper-V saved states, so the virtual machine must be powered on and shut down properly, or the saved state must be discarded. If the virtual machine is currently powered on, perform a shutdown from within the virtual machine and do not select to save the state.
Follow these instructions for discarding the saved state for a virtual machine that is currently powered off:
Launch the Virtual Server 2005 Administration Web site.
On the Master Status page, find the appropriate virtual machine in the list of virtual machines and click the arrow to the display the actions menu.
Figure 8-4 displays the menu options available. Select Restore From Saved State or Discard Saved State from the menu.
Figure 8-4: Saved State actions menu for a virtual machine
If you select to restore the saved state, after the virtual machine is restored, perform a shutdown.
If you select to discard the saved state, then no further actions are required.
Merge Differential Disks
Differential disks allow you to save space by creating a dependent chain of virtual hard disks. This eliminates the need to duplicate copies of data. If you are migrating all virtual machines that contain differencing disks from a Virtual Server 2005 R2 host to the same Hyper-V server, then you do not have to merge the differencing disks. You will need to maintain the same relative path on both hosts, however, or you will need to repair the parent-child links.
If you are planning to migrate virtual machines that depend on the same differencing disk to different Hyper-V servers, then you must merge the differencing disks to break the dependency.
Follow these instructions for merging a virtual machine differencing disk:
Shut down the virtual machine with the differencing disk.
Launch the Virtual Server 2005 Administration Web site.
On the Master Status page, select Inspect Disk from the Virtual Disks menu.
Specify the virtual hard disk that has a parent that needs to be merged (as shown in Figure 8-5) and click Inspect.
Figure 8-5: Inspect Virtual Hard Disk page
The Properties and Actions will be displayed as shown in Figure 8-6. Select Merge Virtual Hard Disk from the Actions menu to merge the parent and child virtual hard disks.
Figure 8-6: Differencing disk Properties And Actions page
The Merge Virtual Hard Disk page is displayed (as shown in Figure 8-7). Select Merge To New Virtual Hard Disk and specify the full path to the new virtual hard disk that will be created as a result of the merge operation. Optionally, you can specify the type of virtual hard disk to be created—dynamic or fixed.
Figure 8-7: Merge Virtual Hard Disk options page
When you have selected all the appropriate options, click Merge.
The resulting merged virtual hard disk is the file that you will migrate to the Hyper-V server.
Check the Hardware Abstraction Layer
Hyper-V uses a multiprocessor APCI hardware abstraction layer (HAL). Although you would probably be prompted for the upgrade of HAL when you install Integration Services, it is best to prepare the machine for HAL detection prior to the migration so that it properly detects and updates the HAL.
Follow these steps to change the HAL prior to migrating the virtual machine:
Power on the virtual machine.
Log in with administrative permissions.
Run the System Configuration utility (MSConfig.exe) by clicking Start, clicking Run, typing msconfig, and then clicking OK.
Click the Boot tab and then select Advanced Options.
Select the Detect HAL check box, click OK, and then shut down the virtual machine.
Complete the Migration
After you have performed all the required pre-migration steps, the last tasks involve copying the virtual hard disk from the Virtual Server 2005 R2 server to the new Hyper-V server and creating a new virtual machine using that virtual hard disk.
Follow these steps to create a new virtual machine:
On the Hyper-V server, create a folder to hold the new virtual machine on a drive other than the system drive. Use the name of the virtual machine as the folder name (for example, D:\VMs\NEWVM).
Copy the virtual hard disk from the Virtual Server 2005 R2 host to the new directory.
Open the Hyper-V Manager MMC console.
Select New from the Actions menu and then select Virtual Machine. The New Virtual Machine Wizard will start. Click Next.
Specify the name of the virtual machine (use the same name as the directory you created) in the Name text box.
Select the check box that says Store The Virtual Machine In A Different Location and enter the path to the directory above the virtual machine folder you created (that is, enter D:\VMs for the example shown previously) in the Location text box, as shown in Figure 8-8. Click Next.
This will allow the wizard to use the directory you created for all the virtual machine files.
Figure 8-8: Specify name and location to store the new virtual machine
On the Assign Memory page, specify the amount of RAM the virtual machine requires and click Next.
On the Configure Networking page, select a virtual network to attach to the virtual machine and click Next.
On the Connect Virtual Hard Disk page (shown in Figure 8-9), select the Use An Existing Virtual Hard Disk option, and specify the path to the virtual hard disk (such as D:\VMs\NEWVM.VHD), and then click Next.
Figure 8-9: Connect Virtual Hard Disk page
On the Completing The New Virtual Machine Wizard page, click Start The Virtual Machine After It Is Created and then click Finish.
The virtual machine will power on.
At the login screen that will display after the virtual machine is booted, log in with administrative permissions.
On the VMConnect Actions menu, click Insert Integration Services Setup Disk. This should start the installation of Integration Services for the virtual machine. Complete the installation and reboot the virtual machine.
The virtual machine is now migrated to Hyper-V.
Direct from the Source
VMC to Hyper-V Migration Tool
Matthijs ten Seldam, Technology Specialist, Microsoft Sales
Migrating a virtual machine from Virtual Server to Hyper-V requires changes to the virtual machine prior to migration, migration of the virtual hard disk to the Hyper-V server, creation of a new virtual machine using the migrated virtual hard disk, and modification of the configuration of the virtual machine. Although you can perform the migration step manually, the VMC to Hyper-V tool, also called VMC2HV, is able to import the complete Virtual Server virtual machine configuration to Hyper-V, and it will allow you to modify the virtual machine configuration in one step.
VMC2HV can be used both locally and remotely. In the local scenario, the tool runs on the Hyper-V server, which limits its use to systems running Windows Server 2008 with graphical user interface, because it needs the .NET Framework to operate. For server core installations of Windows Server 2008 and Hyper-V Server 2008, it can be used from a remote installation of Windows Server 2008 or Windows Vista with the .NET Framework installed.
To use the tool with as little effort as possible, the recommendation is to copy the VMC and virtual hard disk file(s) to the Hyper-V server in a folder with the name of the new virtual machine. For example, you could copy the files Machine1.vmc and Machine1.vhd to a folder at D:\vm\machine1. When the tool imports the file Machine1 with a Virtual Machine Path to D:\vm, it will use the folder D:\vm\machine1 and will create the new virtual machine in that folder. This way, all the files belonging to Machine1 will be contained in the same folder.
Upon import, VMC2HV reads the configuration file and displays all properties. Properties that no longer exist in Hyper-V are ignored, and you can set new properties in Hyper-V manually. Figure 8-10 shows the tool with a remote connection after importing a VMC file.
Figure 8-10: VMC2HV opening page
The tool shows several tabs related to the Virtual Machine Properties. The Processor tab allows you to specify the number of logical CPUs, the Resource Control, and Processor Functionality. The Drives tab (shown in Figure 8-11) shows the virtual disk drives such as floppy drives, CD/DVD ROM drives, and virtual hard disks, as well as their locations (IDE/SCSI and device ID).
Figure 8-11: The Drives tab of Virtual Machine Properties in VMC2HV
In the case of a virtual machine that booted from SCSI under Virtual Server, the VMC2HV tool offers you the option to swap the SCSI disk at location 0 with IDE at location 0.
The Networking tab (shown in Figure 8-12) shows the number of network adapters and allows you to set them to Legacy; under Virtual Server, an adapter is always an emulated Dec/Intel adapter. By default, VMC2HV creates a synthetic adapter (which is also the default with Hyper-V). The tool also allows you to specify which virtual network and which VLAN you want the adapter to connect to.
Figure 8-12: The Networking tab of Virtual Machine Properties in VMC2HV
Special features include recognizing the guest operating system and limiting the number of logical processors, if applicable (according to support policy), and warning you if the virtual hard disks cannot be found at the current location. Any new paths for virtual hard disks can be edited using the VMC2HV tool, which is available as a download from http://blogs.technet.com/matthts/.
Migrating virtual machines from Virtual Server 2005 R2 to Hyper-V involves migrating both the configuration of the host and the virtual machines themselves. In this chapter, we discussed what you need to consider prior to migrating the host and the virtual machines. A key decision you must make before migrating the host involves determining if there are any virtual machines using operating systems that are not supported on Hyper-V, in which case you should maintain a Virtual Server host.
The chapter provided you with the important considerations and the steps for preparing the virtual machine hard disk for migration. These included dealing with hardware differences (SCSI controllers, network adapters, and HAL), cleaning up the virtual hard disk (Undo, saved state, and differencing disks), and removing Virtual Machine Additions. After the host is migrated, you learned that you can create a new virtual machine using the existing virtual hard disk, and then you must install Integration Services to provide support for synthetic devices and improve performance.
The following resources contain additional information related to the topics in this chapter.
Virtual Machine Migration Guide, a resource with information about how to migrate Virtual Server 205 R2 virtual machines to Hyper-V, available here.
VMC2HV Migration Tool, a resource for simplifying the migration process, available here.