SCVMM’s P2V functionality: nothin’ but net!
This weekend I did my first P2V (physical-to-virtual) conversion of a machine using SCVMM 2008 (System Center Virtual Machine Manager). I expected the worst. Instead, I got a really pleasant experience. It worked like a charm, so long as the right ports were opened and you knew the username/password of a user who is a local administrator on the destination machine. In my case, I simply plugged the secondary NIC on the machine (it was a machine in my DMZ, ironically enough, it was previously my VMWare Server box) into a switch on my LAN, started the conversion process, and an hour later, it was done. As expected, I needed to reconfigure the NIC (I always expect this, since it is considered a new NIC). One nice surprise is that it maintained the volume lettering, even though I did not convert all of the volumes. In this case, I had a D drive which I did not convert, but I did convert the F drive, and even though the converted F drive was the secondary drive on the virtual adapter, Windows was still calling it F. That ensured that I didn’t need to mess with anything after conversion. Overall, I can report that SCVMM did a P2V with flying colors, and should not be feared or avoided.
J.Ja
WOW. I hope you didn’t have to pay for that conversion utility.
Because, you could have done it for free with a Knoppix Linux CD.
Boot up the source PC into Knoppix, mount the partition and use ‘dd’ utility to copy the entire primary partition (/dev/hda, sda) straight into an existing VM with secure shell ssh. Simple once you know how, like with everything else.
Wah wah.
No, I didn’t have to pay for it (we’re certified Microsoft Partners). That being said, a straight copy like that a) is not the best plan with a Windows server in many situations and b) is more work than using a converter.
I’ve gone the dd route in the past (not to make VMs, but to clone a system from one drive to another, same principle). It works great for *Nix. On a Windows computer, it is usually a disaster, unless the destination machine has very similar hardware. It’s not the peripherals (NICs, video cards, etc.) that’s the issue, it’s the chipsets. Windows likes to use very specific chipset drivers, and cloning from one machine to another usually involving booting into the “rescue mode” afterwards, doing a “repair” of the system, and then needing to fix a million problems that come up as a result of the repair.
So, for our environment, the route you suggest is actually far, far worse, regardless of your familiarity with the various tools.
J.Ja
@Justin James
I’ve never had that problem with NTFS. Might need to run ntfsresize afterwards for a different target partition but that’s about it.
This has nothing to do with NTFS, and everything to do with Windows and how it handles the chipsets.
J.Ja