A cautionary note for those of you performing an in-place upgrade of a machine running Windows Server 2008 with the Hyper-V role enabled, to Windows Server 2008 R2 Release Candidate.
During the installation, you will see the following compatibility report message stating that you should turn off the Hyper-V role:
This warning is incorrect, and you should not do this as the virtual machines will not be present, and virtual network configuration will be lost once the role is re-enabled.
You will see a similar message if you have virtual machines running at the time of upgrade, but it is a “hard block” (in other words, you cannot proceed further). In the case where you hit the hard block, running VMs should be cleanly shut down prior to upgrade. However, I re-iterate, you should not remove the role itself.
One other point to note is if you have online snapshots or virtual machines in a saved state. Saved states are not compatible between Hyper-V in Windows Server 2008 and Windows Server 2008 R2 RC build, so you should ensure you cleanly shut down VMs and delete online snapshots prior to upgrading to avoid the following message after the upgrade is complete:
PingBack from http://last-words.linkedz.info/2009/05/05/hyper-v-and-in-place-upgrade-to-windows-server-2008-r2-release-candidate/
Unfortunately, I appear to be bitten with the "hang on reboot" when Hyper-V is installed. Since I'm a developer and only using Hyper-V for testing / learning purposes, I decided to upgrade from the Server 2008 R2 Beta to the Server 2008 R2 RC. I saw no mention of the warning you speak of, but when nearly complete in the upgrade, my system hung. Thinking it was from the inability to reboot, I power cycled, and then got the rollback message. After that failure, I decided to uninstall the Hyper-V role, and was able to successfully upgrade to 2008 R2 RC. And I was able to easily re-enable the Hyper-V role and re-add my virtual machines.
Unfortunately the RC doesn't seem to have fixed a somewhat common problem with a machine not power cycling properly -at least not in my case.
Jason - can you provide hardware details and confirm you are running the latest BIOS available. We generally only see "hang on reboot" on desktop hardware (as opposed to "real"/aka 'supported' servers), and then 99%+ of the time it is solved by a BIOS update.
Thanks for the reply. Here's your requested info.
It's an HP Pavilion A6518F Desktop / Athlon 64 X2 (B) 5400+ 2.8 GHz with 8 GB of RAM - Definately desktop class hardware. BIOS is 5.17 which is showing as the latest version on HP's website.
It's not that troubling to me, I just wanted to share that I was able to uninstall the Hyper-V role and reinstall it without much issue. One caveat to that is that I run a very simple network setup, with a single NIC dedicated to Hyper-V and no serious VLAN configurations.
Jason - if you still have the cbs.log file, can you zip it up and email it to me (link at the top)? That may give some clues why the machine hung and rolled back.
Just thought I'd send you an update... after digging into my BIOS a little more, I noticed that HP has two BIOS updates labeled 5.17 for my machine, one released around March of 08 and one marked on December. So I booted into my BIOS, and saw that the date on my 5.17 was March.
I decided to try the December version, and after some work, updated. Now, I can reboot my computer with HyperV installed without issue.
Pretty silly of HP to have two releases of a BIOS at the same version number.
Thanks again for all your help, and your awesome blog.
Well John, I spoke too soon. It appears that my BIOS update reset my virtualization flag in my BIOS. After failing to start any VM's, I realized that my flag had been changed to disabled. I reset it, and still get the hang on shutdown. Oh well. ;)
Hi John, Last weekend I did an inplace upgrade from Windows 2008 RTM with Hyper-V enabled to RC. Except for the network configuration the upgrade went smooth. The 5 guests did startup properly after the upgrade. One virtual switch was set to internal where the original configuration was external. Besides that I know have my 5 guests in Hyper-V manager and also 5 GUIDS of VM-Guests which I cannot delete, the have a status of saved-critical ??? How to get rid of these GUIDS?
Hi Jack - Thanks for reporting this. Neither are issues that I've seen reported.For the network one, can you provide some more info about your network config: Number of physical NICs; How many virtual switches were created before upgrade; What sort of virtual switches they were; What physical hardware.
Can you confirm I have this correct for the VM issue itself: You have 5 VMs only, but after upgrade have your 5 VMs plus another 5 "Ghost" GUID VMs. Saved-critical generally means that the link to the configuration files of VMs cannot be located. Is it possible that your VMs were running at the time you performed the in-place upgrade? (BTW it's recommended not to have online snapshots, or running/saved VMs at upgrade as saved state files are not compatible between v1 and R2).
If you take a look in \programdata\Microsoft\Windows\Hyper-V\Virtual Machines, there will be a number of links. I suspect you have 5 XML files for the original VMs, plus another 5. It's a question of *very carefully* determining which ones are correct and which ones are invalid, and removing it. You many need to recycle the VMMS service (net stop vmms/net start vmms) for the change to take effect. Please be extra vigilant not to delete an XML file relating to a valid VM though.
I installed a W2k8R2 RC core sever with Hyper-V enabled and a W2k8 R2 RC full server. They were a pair of lab machines on the same domain, gateway, and dns. Firewalls have been enabled, and administrators have full permissions. However, I got "cannot connect to the rpc service on computer..." erorr when I was trying to use HyperV manager from full server to manage core server.
In W2k8SP1 and same machines and setting, KB950050 will fix the problem, but it is NOT for W2k8R2. Do you have any suggestions?
Sherry - Correct, 950050 is only applicable to Windows Server 2008 SP1 and updates the beta bits of Hyper-V which shipped with the gold media to RTM bits.
RPC errors are almost always due to DNS issues. Make sure that you can ping -4 by name in *both* directions and hit the right IP address. Not important if the ping fails, just that the IP being reached matches the output of ipconfig /all on the other box.
If that looks OK, please can you email me through hvremote /show on both boxes, plus the output of the ping attempts above for further analysis. (Email link is at the top)
The problem is actually resolved. There is no extra step has been added, but the server just can manager the client somehow after another power cycle. It looks it takes a while for the server to recognize the client. Thank you for your help.
I've just experienced the same upgrade rollback issue going from the R2 RC to the R2 RTM. Do you still want log files? I can send them to you, before trying to uninstall the Hyper-V role and then upgrading.
Jason - no logs needed. This is fully expected - we were not able to fix the issue in the RTM builds, so it affects the RC to RTM upgrade scenario as well. However, saved states and online snapshots will be compatible between R2 RC and R2 RTM.
Thanks for your awesome blog, John