Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We currently run an SBS2008 DC/Exchange/AD on hardware that is getting dated. Before it falls all the way over we are trying to get it virtualized, as we do have a shiny new (and under utilized) VMWare host. I am doing network isolated test runs at the moment to figure out how long it will take and which bugbears to expect, etc etc. In case it matters, the process we are following is -

  1. Full backup via Acronis B&R 11.5
  2. Run up VM hardware (we use VMWare vSphere 5 Essentials)
  3. Connect VM CD Drives to Acronis Bootable media Image & VMWare-tools Windows image
  4. Run the universal restore sourcing drivers from the VMWare-tools disc.

At the very end of the restore we got two errors concerning missing drivers with generic long PCI device names names - I am almost sure that these are the same two devices I am having problems with but am unsure how to check this. (We tried re-searching the VMWare tools disc for these fut failed, so I crossed my fingers and clicked 'Ignore')

After it boots up I install VMWare tools (Complete installation) and restart. The whole thing seems to run fine in the very isolated environment I have it in, however the device manager shows issues (that is, yellow !'s) with 2 devices -

Virtual Machine Bus
Virtualization Infrastructure Driver

Trying to update these drivers (Either automatically or searching the VMWare tools disc) shows that they are apparently the latest. The Device status (for both) is:

Windows cannot load the device driver for this hardware. The driver may be corrupted or missing (Code 39).

My searches have revealed nothing VMWare related, however I did see a few articles like this one and this one related to Hyper-V and with different status codes, but the same devices. Nevertheless, I've tried the troubleshooting for them (enabling HAL in msconfig->Boot tab->Advanced Options; disabling and re-enabling the device) to no avail.

There is nothing in the event logs which seems related, as a matter of fact I can't see that anything is affected - but I'd rather not find out after hours on a Friday night at the end of the migration, when all I want to be thinking of is whether to watch GoT or Legend of the Seeker when I get home. Is there anyone who has either encountered this before or has the experience to say what the outcomes/cause might be?

share|improve this question
2  
TL;DR. Why not just P2V the server using the VMware Standalone Converter? –  joeqwerty May 1 '13 at 2:14
    
@joeqwerty there is a long explanation and a short explanation. The short explanation is - compatibility issues which I do not think are related. If you think it's warranted I can include the long explanation but I was worried already it was extraneously long. +1 for what is (in most/other cases) a good suggestion though –  Chris O'Kelly May 1 '13 at 2:35
    
These compatibility issues (super-condensed version - GPT Disks > 2 TB) are also the reason we didn't use Acronis's P2V solution. Now I have mentioned them let me point out that these disks are not on the virtual server - The backup we took to restore to this server did not include these disks. –  Chris O'Kelly May 1 '13 at 2:53
    
Ack - I am not sure if I should delete this question now. I had confused myself in my research, thinking that these were generic devices that I would see on a VM regardless of it's hypervisor, and that they were there for communications back up to the hypervisor. I now understand that these are specifically related to the hyper-v role which we didn't need on the DC in the first place. The "Solution" as it were, was to uninstall the Hyper-V role on the virtual DC. It seems like this would be a vanishingly rare mistake to make - so I am not sure if this staying here will help anyone or not. –  Chris O'Kelly May 1 '13 at 4:17
2  
Post it as an answer. I think it's certainly useful to someone who may be in the same boat and is overlooking or not quite seeing the problem and the solution. –  joeqwerty May 1 '13 at 4:31

1 Answer 1

OK, so the answer here is - Don't do what I did.

Those two devices are Hyper-V related - they exist on the Hyper-V hypervisor to communicate with the VM's running on it.

My misunderstanding was that I assumed they had appeared there when I virtualized the server, and, as such, that they were systemic of a VM. When I read online that they were for Host<->VM communications I assumed that they made up the VM side of that link.

What clued me onto the real issue here was when I noticed that the physical server also had these devices (although with working drivers). This brought me to the realization that the Hyper-V role was installed there (completely unnecessarily) and that I could resolve the issue simply by removing this role.

In hindsight, it makes a lot of sense - running one virtualization platform inside another seems like a recipe for disaster.

For the record - removing the role from the already virtualized machine seemed to destroy it - after a reboot it went 100% CPU and hung on "Installing Updates - Stage 3 of 3, 76%". A safe boot failed to get all the way back in. In this case it was a test VM anyway so no great loss, but the moral of the story is, to paraphrase a well known quote - Don't hypervise a hypervisor. Remove any virtualization software BEFORE a p2v.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.