John Howard - Senior Program Manager in the Hyper-V team at Microsoft

Senior Program Manager, Hyper-V team, Windows Core Operating System Division.

Hyper-V generation 2 virtual machines – part 10

Hyper-V generation 2 virtual machines – part 10

  • Comments 18
  • Likes

Part 1: Introduction to generation 2 virtual machines
Part 2: Networking and boot order
Part 3: Storage
Part 4: Keyboard for Windows 8 & Windows Server 2012
Part 5: Kernel debugging
Part 6: Secure Boot
Part 7: FAQ
Part 8: Manually migrating generation 1 virtual machines to generation 2
Part 9: Installing from ISO
Part 10: Utility for converting generation 1 virtual machines to generation 2 (Convert-VMGeneration)

The final part (at least for now, I’m hoping a guest author will write part 11) of this series on generation 2 virtual machines in Hyper-V re-visits conversion of a generation 1 virtual machine to a generation 2 virtual machine. Part 8 walked through the manual process, assuming it is possible. However, there is an easier way with a PowerShell script I wrote and recently released. Called Convert-VMGeneration.ps1, it can be downloaded from http://code.msdn.microsoft.com/ConvertVMGeneration. The script is intended to make life as simple as possible, reducing as many as reasonably possible manual post-migration fix-ups that may be required.

Convert-VMGeneration.ps1 is self-documenting – after downloading to a local drive, running get-help .\Convert-VMGeneration.ps1 –full will give you everything you need to know on how to use. I will assume that you have read part 8 of this series before use so you understand the three phases of conversion – capture, apply and clone.

A few tips worth mentioning:

  • Run reagentc /disable in the guest operating system prior to shutting down and converting (if reagentc /info indicates it is enabled). After conversion, in the generation 2 virtual machine, run reagentc /enable. This makes life a lot easier in terms of the Windows Recovery Environment and (lack of) manual intervention.
  • I strongly recommend you use the –Path parameter. Alternately, after a VM has been created, move the VM and its related storage to the right path using Hyper-V Manager. Note that if you subsequently perform a storage move, data-disks which were in use by the generation 1 virtual machine will no longer be valid from its perspective.
  • For the first few times of use, you might want to specify the name of the temporary .WIM file using the –WIM parameter, combined with –KeepWIM. That’ll save some time if a failure occurs during the apply or clone phases as you’ll not need to redo the potentially time-consuming capture phase. Using the -WIM parameter also makes it easier if you are running short of disk space and want to use an alternate location.
  • Be aware that you may not be able to start both the generation 1 and generation 2 virtual machines simultaneously (for example if they share a data VHDX). In reality, you really don’t want both machines on the network at the same time anyway. Be cautious of other implications too such as domain joined machine account passwords changing and so on.
  • Perform a move of the VM and all its data to another path after migration and you’ve verified the functionality of the converted generation 2 virtual machine. This will make it much cleaner to delete the old generation 1 virtual machine and clean up any old files which may be lingering.
  • The conversion performs a highly destructive step which completely wipes a disk. If everything is to plan, it’s the blank VHDX used as the boot disk for the generation 2 virtual machine. However, things could go wrong. For that reason, I strongly recommend you heed the warning (which cannot be suppressed) and make appropriate verifications. Should data loss occur for reasons such as coding error, no liability is assumed. If in doubt, export the generation 1 virtual machine, and import it onto a scratch box. Then do the conversion. That way, you are assured you will not lose anything important IF there is a bug.
  • Similar to HVRemote which some of you may have used, this script is not supported or endorsed by Microsoft Corporation.
  • Don’t close the PowerShell window while a conversion is in progress. Due to a bug in Windows, you may leave your system in a state whereby a drive letter is ‘leaked’ – it will be visible in Windows File Explorer, but unusable until the system is restarted. To cancel the script while it is progress, use Control-C and wait for it to clean-up instead.

Here’s an example of the conversion of a Windows Server 2012 virtual machine. The original virtual machine is highly available. The resulting generation 2 virtual machine will need to be made highly available after migration has completed.

clip_image002

Here’s an example where there are some (potential) issues to resolve. One is that there is an additional data partition on the boot disk for the source VM. Windows Recovery Environment was left enabled during the migration and will not operate correctly in the generation 2 virtual machine. Lastly, the original source boot disk was a differencing disk. Appropriate fix-ups may be required to mirror the configuration on the generation 2 virtual machine.

clip_image004

There are some VM configurations which aren’t handled, and the script will block the conversion:

  • The VM is running. The reason is simply that you cannot reasonably expect an operating system to continue running correctly if the firmware is fundamentally changed from under it.
  • Checkpoints (snapshots) are in use by the generation 1 virtual machine. The reasons partly relate to the above statement – an online checkpoint is equivalent to a running VM. While offline checkpoints could be converted in theory, there are further problems:
    • The mount-diskimage cmdlet that the script uses under the covers does not support .AVHDX files which are used by checkpoints. Further, the time to do the conversion would be prohibitive – each checkpoint would have to done individually.
    • Rebuilding the checkpoint tree with parent/child would be pretty much impossible – at best an individual offline checkpoint could be converted to a ‘standalone’ generation 2 virtual machine.
  • Hyper-V replica is enabled. The reason was simply my time to validate this scenario. In theory it should work. Obviously replica would need to be re-enabled after the conversion. The workaround is to disable replica prior to conversion, or use the “-IgnoreReplicaCheck” parameter.
  • When a guest cluster is configured in the generation 1 virtual machine using a shared VHDX. A highly available/clustered VM from the parent partition perspective works fine though. I am somewhat doubtful a guest cluster would come across cleanly, and have done no validation. The script hard blocks if any VHDX in the generation 1 virtual machine is shared.

I hope you find Convert-VMGeneration.ps1 useful. I’ll try to fix any bugs you report as time permits! A note for PowerShell aficionados reading the code – I make no apologies for my lack of PowerShell skills. This was the first time I’ve undertaken writing anything of reasonable complexity in PS. I’m sure there are many ways to make the code more powershellesque in efficiency.

So with that, I’ve reached the end of the planned parts of this series on generation 2 virtual machines in Hyper-V in Windows 8.1 and Windows Server 2012 R2. I hope you enjoyed them and found them and the conversion utility useful. As always, comments, questions and feedback are welcome.

Cheers,
John.

Comments
  • Nice effort, but too many precautions and in overall conversion procedure is too complex. We need MS to provide official, supported, in-place upgrade of generation 1 to generation 2 virtual machines. Anything less than this is not enough and will make so many great features provided by 2012 R2 completely useless. Generation 2 is really greast, but for so many years we have been creating virtual machines and now you simply made all of them old, legacy, crippled...providing us with no way to convert them to the new format. MS can (and must) do better than this.

  • srdjanm - I understand your frustration, but I want to pick up on a few points here. This isn't strictly a Hyper-V only issue. You won't be able to take a disk from a server running in BIOS mode, pop it into a server with Firmware in UEFI mode and expect it to boot. You would need to use third party tools which effectively do the transition for you. That's a fundamental difference between generation 1 and generation 2 as well - BIOS vs UEFI. This utility does the same as several (expensive) third party tools do in physical environments, some also for virtualized environments, but it's tailored for Hyper-V specifics, especially when it comes to cloning from a source VM.

    I also want to be really clear, generation 1 VMs are going to be around for a while to come yet. No-where will you find a statement of future deprecation of them in "X" years or "Y" releases time, or similar. Generation 1 VMs are required currently for pre-Windows 8, and 32-bit operating systems. So it's not absolutely necessary to move them to generation 2 virtual machines. It's certainly not the case that generation 1 virtual machines are (to use your terms) legacy, old or crippled. However, as I mentioned in part 1, moving forward in future releases, you can reasonably expect some features to only be present in generation 2 virtual machines - there are a finite number of resources available in any development project, so reducing the test matrix, for example, significantly helps. Of course, I am not stating any plan of record, just setting some reasonable expectations. But you can still expect generation 1 virtual machines to run just fine, fully supported, in a future release, alongside generation 2 virtual machines. The same as you can do today in Windows Server 2012 R2 and Windows 8.1.

    It would be nice to think that System Centre over time will introduce similar functionality to convert. But as it stands today, the choices are re-installation and app migration; manual migration; this utility; or third party tools.

    Thanks,

    John.

  • @John Howard

    Thanks and please don't get me wrong - I really admire your script, and I am very grateful for all your work. My point is that if generation 1 VMs cannot be easily upgraded to generation 2, then we need to have new functionalities like online resize, online export, hot add/remove scsi disks etc. enabled for generation 1 VMs as well. It seems that all cool features have been designed for generation 2 solely. Thanks again.

  • Actually..... online export and online resize work just fine for generation 1. Resize has the caveat that the feature only works on SCSI connected disks, but for data disks on generation 1, it works. It's more a limitation of the IDE controller than Hyper-V as to why you can't online resize an IDE connected disk. Hot add/remove SCSI disks has been around for some time and continues to work for generation 1 just as it has for previous releases. Really, outside of RemoteFX support which was unfortunate (see FAQ), there's very little differentiation from a feature capability only perspective between generation 1 and 2 in Windows Server 2012 R2. Obviously something like Secure Boot is intrinsically linked to UEFI (it's part of the UEFI spec), so it will never (well never say never) come to generation 1 PCAT/BIOS based VMs.

    Cheers,

    John.

  • Conversion worked on a DC (VM-2012R2), but unfortunately there is no Network Adapter at all installed now? Is it possible to get a "Microsoft Hyper-V Network Adapter" working manually? (I added such, but have "This device cannot start (Code 10)

  • Fridolin - thanks for reporting this. I assume the network adapter was working before the conversion. A question worth asking just in case. We can't think of any obvious reason this would be the case, and unfortunately code 10 is a very generic code. Can you try in device manager removing the device and letting it re-enumerate by right-clicking on the computer and scanning for changes to see if it comes back correctly.

    Also, \windows\inf\setupapi.dev.log would be an interesting file to get ahold of to see if there any errors (you can email it using the link at the top right) if the remove/reinstall doesn't work.

    And lastly, if there's anything interesting in the event logs. Select the device in device manager, properties and on the events tab.

    Thanks,

    John.

  • Working again. I had some problems, because on my Server2012R2 (the virtualization host) the physical network adapter was gone completely after the update to R2  (ASUS-Mini ITX.... board) I checked what NIC was in and found new drivers on the Intel page, which are working perfectly [PROWinx64.exe for 64-bit (x64) editions of Windows Server 2012 R2*.] Then (after conversion to Gen2 - which by the way was working perfectly, just could not map the previously mapped ISO / CD Drive) just Do not start the VM but first go to settings, add Network Adapter => Virtual Switch => Ext .... Then start the new VM Gen2... and everything was fine.

    Again thanks a lot for your great support!

  • John, Thanks for another great series of articles. Also enjoyed your SR-IOV insight emensly. A couple of small things: - Does a generation 2 conversion trigger a reactivation of the OS? (HAL being replaced?) - Having a problem with a 2012VM claiming integration comp. need upgrading. Doing so produces no change. VM has SR-IOV enabled.

  • I'm not the right person to comment on how Windows deals with reactivation triggers, although in the past it is true that hardware was a part of that. So on that basis, I would not be surprised if re-activation of non VL OS installations is triggered if a conversion is performed as generation 1 vs generation 2 hardware has significant differences. There is however a known bug you're hitting - there is a KB in the pipeline for publishing. When a 2012 VM runs on 2012 R2 and the VM is restarted with SR-IOV in use, we will incorrectly display that the Integration Services are out of date. This is display only. However, you should verify that they are indeed up to date by turning SR-IOV off temporarily.

  • Hello John,
    Thanks for the utility, is there a way to change the temp path to another drive because I am currently getting the error

    " There is not enough space on the disk. The DISM log file can be found at C:\Windows\Logs\DISM\dism.log error code 112

    Completed with error. Trace status code 830"

  • Mur - yes, use the "-WIM" parameter to specify the full file path for where the interim WIM is stored.

  • John...
    Thank you so much for your time and effort to create this script. I am currently in the process of testing it out. I am wondering if there is a way to tell how long a conversion will take to complete.
    I started the conversion on a VHD that is 30GB in size, and 4 hours later, it still says" Applying image. This will take some time..."
    Since I do not know how long the conversion will take, I am left wondering if the script has frozen or if it is still running.
    It would be helpful to know an average time per GB it will take to convert an image.

  • Allen - it's next to impossible to give you an indication. It's so highly dependent on the speed of your storage. Open Resource Monitor and go to the Disk Tab and sort by total (B/Sec). If the interim WIM and the new VHDX are still making a lot of reads/writes, it's still going. If they've stalled and the overall disk I/O is next to zero, then there's something else wrong. I guess you could take a comparative look at the size of the new VHDX to see how close it is to the source VHD(X) as well to determine progress, but it may not necessarily be a direct correlation in the case of the source being a dynamically expanding VHD(X)

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment