Moving VMs to Hyper-v...

  • Article

There are 3 things I get asked regularly about Hyper-V. The first is "When can I get it ?". I've covered this before, the product group have committed to ship by August 2nd, and I've thought for a while that they're looking good to beat that. At MMS Bob Muglia said how pleased we were with performance and we're running the main Technet and MSDN sites on Hyper-V already. Question 2 is "Can you compare X with feature Y in VMware ?". And the third is "Will I be able to move my VMs from X to the release version of Hyper-V ?". Where X might be Virtual PC, Virtual Server, Pre-release Hyper-V, or VMWare. So let's go over the basic rules.

  1. In many cases Virtualization installs its own drivers and management components into the child OS. Sometimes it is possible to remove these under another Virtualization environment, sometimes it isn't (for example if you used the extensions from Virtual Server before R2 SP1 they won't uninstall under Hyper-V). So if you're changing products it's usually easiest to remove these first. As you move between builds of the same product, it's a good idea (and sometimes a requirement) to install the latest ones in the child VMs.  [With Linux VMs you should check if a update needs new integration components and since these are provided separately make sure they're available].  We're moving to one version of the Integration components disk for all supported Windows OS's, which streamlines the process. . Server 2008 core can't auto-run disks and depending on the OS auto run may be disabled, so simply selecting ‘Insert Integration Services Setup Disk’  may not get the job done. Some of the components look like new hardware, so make sure you cancel the Found New Hardware wizard before installing them
  2. We call OSes without Integration Components "unsupported".* This word tends to panic people. It doesn't mean you become an Outlaw in the eyes of PSS. Supported means if a flaw is exposed, it will get fixed. We have "Quick Fix Engineering" to provide patches to customers in this situation.  A VM running should look like a standard PC, so it should run OS/2, NT 3.x and 4, Novell NetWare 4 and 5, DOS 5 and 6. Some people might say in that case the Virtualization system "supports" those OSes , but if it exposes a latent flaw in an OS which is out of support, it won't get fixed; doesn't matter whose OS it was or whose Virtualization. If an out of support OS exposes a flaw in Hyper-V that doesn't show up any where else, it is only professional pride of the product group that drives a fix.
  3. A VHD is a VHD. You can take a VHD from any product which supports the format and mount it in Hyper-V. In itself that doesn't guarantee that the OS will boot and run properly, but you can mount the disk (as I showed here) and fix it off line. You wouldn't do that without making a copy of the VHD first would you ? Good.
  4. VMWare doesn't use VHD files. We've published our format and they've published theirs so there are conversion tools - we usually call this Virtual to Virtual migration, and we do it in SCVMM.
  5. Hyper-V's SCSI controller is what we call a synthetic one (VM-bus devices are "synthetic", non-VM bus ones are emulated). Synthetic devices are not available until the OS has booted, so Hyper-V must boot from IDE. (In the same way it can PXE boot from the Legacy NIC, but not the VM-bus one). When the OS is booted it also loads components which speed up IDE access substantially so there's no great speed advantage to using SCSI (there was in Virtual Server). If you were booting from SCSI before, using the same drive attached to an IDE controller is not normally a problem.
  6. Generally moving a VHD between Virtualization systems has the same effect as moving a hard disk between physical computers. You see a different BIOS, CPU, Mainboard, Network card etc. This may trigger re-activation. You can use the same product key - if activation tells you the key has been used, go through the telephone service. I've done this, so I know it is not onerous, although doing thousands of servers might be.
  7. Don't expect to move saved state files between builds. I know from personal experience you can't move saved states between Virtual Server 2005-R2 release and Service pack one builds, don't expect to do it between different builds of Hyper-V either, and if you had any thoughts of saving the state of a virtual server VM and bringing it back as a hyper-V one, I commend your optimism.  Online snapshots contain virtual machine saved-states: you can apply snapshots and shut the machine down and snap shot again to give an offline snapshot
  8. There is a KB article (949222) which explains updating from Beta to release candidate requires VM configurations to be recreated. The Beta-RC change was big enough to cause this but it shouldn't be repeated.

Those are all the bits I can think of, but if I've missed something I'll cover it in a later post

[Update Added this Footnote to point 2 * I'm told that in the future it may be possible to install ICs in a OS which is not supported - as I've described "supported" above, or an OS which lacks ICs may be supported.  ]