Your basic ITPro blog... What's going on at work, what I'm interested in.

Monday, March 31, 2008

Virtualizing Using VMM

I have been looking in to virtualizing XP machines using SCVMM. This tool has worked great for us on various W2003 servers. I wanted to try an XP box (namely, my laptop) for a couple of reasons. First, I wanted to see if it could be done. The docs say 'yes', but I wanted to test it. Second, I thought having a VM of my laptop standing by would be pretty nice in case my laptop HD dies. Third, I have Virtual PC running on my laptop and I wanted to see if it would run in a VM of my laptop... a VM hosting VMs.

While working through this process, I came up against various issues and errors that I had to resolve. I wanted to list them here, mainly so I could reference this list in the future when I forget this stuff!

The following services must be running on the source computer...

  • BITS
  • VMM Agent
  • WMI
  • WS-Management

Also, you need to make sure that nothing else is using port 443. It looks like BITS uses 443 to transfer data from the source machine to the VM host. I had IIS running on my laptop and it had 443 tied up. I just stopped my Default Website and everything was fine.

The last requirement I ran in to (and this may seem obvious) was that the VM Host I was deploying to had to have adequate resources available for the VM. This is true even if you don't plan on turning the VM on. Initially, my laptop would have put my Host over the top and my conversion failed. I pulled 2GB of RAM out of my laptop and run things again, with no problems.

A Recommendation! Try to have GB Ethernet all the way through for the data transfer. My laptop HD has around 70GB of data on it. Over a 100MG link... well... this was going to take longer than I wanted to wait.

As I have been working through this process, I have been considering how we might use this technology to our advantage. It would be nice to have a VM backup of my machine. I have read articles by people who do this for their servers. The make a VM weekly and keep it as a stop-gap DR solution. If their physical box blows up, they can turn up the VM and run on it while they get the physical server fixed up.

For workstations, this would be much more beneficial if there were also a V2P (virtual to physical) conversion process. A Google search for 'V2P' brings up numerous hits, so I don't think I am the first to want this! My initial thought would be to turn up the VM, Ghost it, and then blow the Ghost image on to a physical box. I will see if my research reveals a better option.

No comments:

Additional Info

My photo
email: support (AT) mangrumtech (DOT) com
mobile: 480-270-4332