I am runnning CentOS 5.5 in a VM on Hyper-V. I created a fresh installation. I then installed Hyper-V Linux Integration Components. After Installing them I ran yum update.
After running a “yum update”, and rebooting I received this error.
Unable to access resume device (/dev/VolGroup00/LogVol01)
mount: could not find filesystem '/dev/root'
setuproot: moving /dev failed: No such file or directory
setuproot: error mounting /proc: No such file or directory
setuproot: error mounting /sys: No such file or directory
switchroot: mount failed: No such file or directory
Kernel panic - not syncing: Attempted to kill init!
During the yum update process, it updated my kernel. Kernels that are installed after Hyper-V Linux Integration Components don’t always mesh well together. Here is how I fixed my issue.
Here is how I ran a copy of my Rackspace cloud server locally on my Hyper-V 2008 R2 Server. Why would you want to do that you ask? Well, there are many reasons. For example, I want to run all my applications in a test/staging environment before I push them live. I want to test all updates to my servers before I push them out live, testing large processes out without wasting money on CPU/bandwidth before running them live, etc. It is very nice to have a near exact copy of what you are running on rackspace cloud servers locally.
Part of the problem was I didn’t have any spare servers laying around that I could install linux and Xen on but I already had a Hyper-V server. This would allow me to run a linux VM, but how do you get a Rackspace cloud server backup running in Hyper-V.
I have one Hyper-V R2 server that fights with me on occasion. The VMs are responsive and I can RDP into them. The server itself is sometimes responsive, and I can RDP into it, but it fails to connect to Hyper-V manager. A reboot usually clears up the problem, but I hate to reboot the host machine with VMs still running.
I have noticed, however, that I can still access Hyper-V through the PowerShell API. As the VMs on this machine aren’t critical, I can suspend the VMs using the API. Then I can reboot the host machine, and start the VMs back up again using Hyper-V manager.
The type of work I do relies heavily on passing Hyper-V VMs around. When I send a VM to someone, I usually export a copy onto an external Hard Drive. In a perfect world, the VM would get copied off of the external drive to the local machine before being imported, but that sometimes doesn’t always happen. One user imported the VM while it was still on the external drive. Granted the VM would still work, it would probably be considerably slower due to running off of USB. They ran into problems on their host machine, so they decided to swap it out for another host machine. They shutdown the VM, and deleted it from Hyper-V. Then they plugged in the external drive into a new machine, and tried to import the VM again. This time they received an error:
A server error occurred while attempting to import the virtual machine.
Import failed. Unable to find virtual machine import files under location ‘D:\vm-export\test-import\’. You can import a virtual machine only if you used Hyper-V to create and export it.
Hyper-V doesn’t allow you to import VMs multiple times. In order to import the VM again, they would have needed to export the VM beforehand in order to prepare it for being imported on the second machine. The export process basically, cleans up the file structure of the VM and creates a config.xml file similar to the following:
Upon importing the VM, Hyper-V looks for and then removes the config.xml file. If it can’t find that file, you will get an error message.
Now, if you have received this message, there is no need to panic. There are still ways to recover your VHD files. If your VM had 0 snapshots it is actually very easy to bring the VM back online. Dig around through the VM’s folder structure and locate its VHD file. That is the virtual hard disk that your VM uses to store all of its information.
Once you have a single VHD file, in Hyper-V, create a new Virtual Machine. Give it a name and location, and fill out all the other important information it asks. Then once you get to the “Connect Virtual Hard Disk” screen, select “Use an existing virtual hard disk” and then browse and select the VHD file you found from above. Finish creating the VM and turn it on. The VM should work just as it did before.
I was building out a new demonstration laptop. The laptop would be running VMs on Server 2008 R2 Hyper-V. Since the VMs we needed to run were rather large, we picked up a rather powerful laptop to support them.
Server 2008 R2 Enterprise
Intel i7-720 QM
640 GB HD
The build went fine. It was simple, enabling Virtualization in the BIOS, installing the OS, adding Hyper-V role, importing a few VMs. Everything went smoothly.
I started a Virtual Machine to make a few tweaks before going home for the weekend. When I came in on Monday morning. I found a wonderful screen telling me there was an unexpected shutdown. Awesome. Thanks Monday…
I checked the Event Viewer and found out that it had been restarting every few hours all weekend.
A client I was working with was having an issue with their Virtual Machine (VM) running on Hyper-V. It was an odd one that I have never seen before. The VM was running Server 2008 R2 and had a single synthetic Virtual NIC attached with a static IP. The problem was that when the VM was restored from a saved state, occasionally, the network would not work. This obviously caused issues for users that needed to connect to the VM via RDP. Luckily, this VM did not completely rely on the Internet, so minor downtime when the VM was restored from a saved state wasn’t a major issue. Disconnecting and reconnecting the NIC in Hyper-V did not fix the issue, and ipconfig /renew wouldn’t fix anything since the IP address was static. The only thing the admin was able to do to temporarily fix the issue (until the next saved state restore) was to log into the VM via Hyper-V console and disable and then enable the NIC that was having issues. Unfortunately, time was a factor in finding a solution, and I was unable to physically see the hardware or VM in action. This made it very difficult to figure out what was causing the issue in the first place. A workaround seemed to be a much better use of time than spending hours trying to deduce the problem via E-mail.
The restore action for the saved state was done by via script. So it would be very easy to tie in another script to essentially disable and enable the NIC after the VM was restored. From what I can tell, this can’t be done using the Hyper-V Powershell APIs from the host. Also, since the network was the problem, I couldn’t run a remote script from the host to fix the NIC. Anything that could be done would have to be done within the VM. Granted this is not a solution to the original problem, but a workaround, and given more time we would have looked into what the actual cause was. So, here is the workaround to the problem.
Windows 7 is a nice operating system and it has some pretty cool features. One of which, and one of my favorites, is that it comes with the newest version of Remote Desktop (RDP). This version is capable of letting you watch HD video through it (assuming your network connection is fast enough…). RDPing from one physical computer to another physical computer is easy and sound between the two works just fine. This is because both machines (most likely) have physical sound cards.
Sometime during my travels, I loaded Windows 7 onto a Virtual Machine (VM) running on Hyper-V Server 2008 R2. Virtual Machines in Hyper-V don’t have physical or even virtual sound cards like VPC. When RDPing to a Windows 7 VM the sound card is listed as Remote Audio. This is fine and will actually push through a decent amount of sound. While testing, it seemed to work fine for WMV files and a few other formats. For some reason, I was unable to get it to work with AVI files, and flash websites like youtube.com. I wanted full sound capabilities. So here is what I was able to get working.