While we have not yet embraced Windows Server 2008 R2 as we are in a frozen state for the upcoming TechReady9 (TR9) event, we are investigating a future migration to Windows Server 2008 R2 and the new Hyper-V features. See Description of methods to upgrade to Windows Server 2008 R2 from Windows Server 2008 with Hyper-V for a list of upgrade options.
The VSTS Rangers have done extensive testing and adoption of Windows Server 2008 Hyper-V, in a number of different environments around the world. The vast distribution of the VSTS Rangers is the greatest challenge, but also the greatest value-add for the VSTS Rangers, because it combines experience from around the world :)
So far we are achieving all of our objectives, even a distant one to combine session VMs for TR9 in one common base image. However, we have also encountered a number of challenges which I have collected over time and which we can quickly mention:
- VPC --> H-V … H-V –| VPC (How can I Migrate from Hyper-V to VPC?)
Do not copy the VHD! (Which VHD is the right one to pick in a Hyper-V environment?)
- Issue: It is fairly easy to migrate a VPC image to Hyper-V, but moving from Hyper-V to VPC is not supported.
- Resolution: None … has anyone achieved a VPC –-> Hyper-V move?
Do not share Snapshots! (Sharing Snapshots shares the state and history of the Virtual Environment)
- Issue: Do not copy the VHD file when working with Hyper-V! When copying a VHD within the Hyper-V set of files, you may end up going back to the future by not including snapshots.
- Resolution: Export the virtual machine on the source and Import at the target, using the Hyper-V manager.
Where has drag-drop gone in Hyper-V?
- Issue: Sharing the Snapshots may appear to be the right thing to do, however, it introduced brittleness and more importantly bloats the size of the VM environment.
- Resolution: Before exporting a virtual machine to share with others, please delete and merge the snapshots where possible.
Loosing connection with host (Why can I not connect to shares on the host from the Hyper-V based server?)
- Issue: The drag and drop feature we loved in Virtual-PC does not work in Hyper-V.
- Resolution: Use Remote Desktop to connect to your virtual server. This will at least allow you to use the old and trusted copy-paste.
Use legacy network adapter (Why am I loosing network configuration when exporting a Hyper-V image?)
- Issue: Once you start applying hot fixes for the O/S, the virtual server “seems” to loose the ability to connect to shares on the host.
- Note: We have not investigated this issue, to determine when and why connectivity is lost yet.
- Resolution: Use Remote Desktop to connect to your virtual server. This will allow you to share local resources as part of the session:
Be prepared (time, plan, action)
- Issue: When exporting VM’s that use synthetic adapters, IP address information can often be lost.
- Resolution: Use the legacy network adapter to avoid the loss of IP address information during exports. Legacy adapters should not be used in production unless you need to take advantage of specific features they provide.
- Issue: Working with virtualised environments requires PATIENCE and TIME. The merging of snapshots takes time, RAR’ing images and copying takes time … plan accordingly.
- Resolution: Working with virtualised environments requires patience and time. I have been packaging endless variations of the VSTS Rangers base image for TFS|VSTS 2010 and at this stage the estimate to freeze an environment, export the image, re-import a copy of the image, delete all snapshots in the copy, export the copy and RAR’ing the image for sharing is a task that takes 4-5 hours on a standard workstation as I am using. While most of it can be done in parallel to other work, it is a brain numbing task for which you have to plan for elapsed time. Why are we creating and working with a copy to start with? It allows us to keep the working environment with all the snapshots :) Also remember that users have to copy the images from your share to their environment, which can take minutes on a LAN, hours on a WAN and days-weeks in certain parts of the world which are not as bandwidth spoilt as we are.
Perhaps you have other challenges we should be aware of and include in our virtualisation guidance, or you have smarter ways of resolving the listed challenges. Give us a shout!