I’ve prepared the L7TG virtual domain to evaluate 2 new “on-premise” Microsoft Server technologies: Microsoft Dynamics CRM 2011 and Microsoft SharePoint 2010. I’m running Windows Server 2008 R2 Enterprise Hyper-V in a Workgroup on a black box Intel E3400 3.0GHZ, dual core processor with 8GB of RAM and 3 SATA 500MB disk drives. Upon booting the host, I was strongly urged to install Service Pack 1, so I did. After rebooting a few times and installing new updates, I was finally ready to create virtual machines.
While I was deleting existing VMs from Hyper-V and creating a new VM, I managed to “break” Hyper-V. I received an error stating that Hyper-V was unable to create the VM because the file it was creating/deleting was in use by another process. That didn’t make any sense, so I cancelled it and deleted the files it creates. I tried again, this time Hyper-V reported that it didn’t have permissions to create a file, producing the ”General failure …” or the “Access denied … “ error messages. The virtual machine entry that was created in the Hyper-V Manager did not have a name. I give the entry a name and manually specified the location of the VHD file; however it wouldn’t start.
At one point, I thought it had to do with permissions relating to the “Virtual Machines” security group. The security group appears in in all of the existing virtual machine’s folders but not in the new one. Apparently, the Virtual Machines security group is one of those phantom groups that are created by an application but it doesn’t exist in as an object in Users and Groups, so you can’t manually add it to the folder’s permissions.
In this time frame was able to launch an existing virtual machine; however, I wasn’t able to take any snapshots. This was a major problem. Thinking Hyper-V was corrupted beyond repair; I deleted the role, rebooted, added the Hyper-V role, rebooted and finally added the new virtual machine from my VHD file. I noticed that after adding the Hyper-V role, the virtual machines that were previously in the Hyper-V Management console, were still there. When I created a new virtual machine from the VHD file, the process resulted in the same series of errors.
I decided to restore Windows from a backup. Unfortunately, the partition backup that I had was a few months old so I had to recover the partition, apply patches and then install Service Pack 1. Following this, I created a full partition backup.
At this point, I now have a current, updated Hyper-V host with all of my old virtual machines fully functional. I decide to add my new clone virtual machine and get the same series of errors and the same overall functionality loss. Any other machine I delete and re-create behaves the same way. I decide to restore my recent backup. Next, I decide to add a virtual machine using one of my old VHDs. It works! I add another of the old virtual machines and take snapshots. It still works. I reboot the host. All functionality seems to be restored. I add the clone VHD that I began this process with and Hyper-V goes bad. Apparently this one VHD I’ve been working with is able to corrupt the Hyper-V Virtual Machine Manager. Incredible!
Since the VHD in question was a clone, I decided to move on by once, again restoring the previous functioning OS partition. I deleted the VHD file that was causing the problem and then recreated the clone from a running virtual machine using SYSPREP to replace the corrupt file. I’m now back on the path to create the virtual machine infrastructure needed to install the free-trial applications.
This posting is provided “as is” with no warranties, guaranties or any rights whatsoever. All content is based on the author’s experiences and opinions and is not intended to influence the actions of the reader.