Streamlining VMware Physical-to-Virtual (P2V) Conversions

Chris Wahl · Posted on

Performing a Physical-to-Virtual (P2V) conversion of a source server to a VMware virtual machine is a fairly straight forward task that many companies require out of technical professionals. Often the driver behind it is to achieve a certain virtualization ratio (or consolidation ratio), get servers off hardware that is in need of a refresh, or to eliminate redundancy that is already baked into a VMware solution (such as non load balanced server farms vs HA).

The P2V process can be as easy as launching VMware Converter and answering a few questions. However, the resulting VM needs a fair bit of attention. Even when using some of the more fancy conversion software available, there are quite a few tasks that you’ll need to complete yourself. Since the VM is basically just a carbon copy of the physical server, with some adjustments made for the new SCSI disk controller, VMware BIOS, and other odds and ends, the freshly minted VM often screams pretty loudly when booted for drivers. I imagine it’s a little like buying a plant from the nursery store and taking it home to a new environment; a bit shocking, but ultimately some care will see it through.

Here are some common streamline processes I have used or suggest using when doing P2Vs …

Know the Local Administrative Password 

Make sure to have logged into the server at least once prior to conversion to cache your credentials, or, if you do not have a domain account with administrative powers, make sure to know the local administrative password. I often make it a habit to go ahead and reset the local administrative account password if there is any doubt, as even cached credentials will sometimes fail you (such as when a Group Policy is in place that denies cached credentials). When the P2V process is complete, often times the NIC drivers will need to be loaded and a network is not available (more common with vmxnet3 drivers as opposed to e1000 drivers). You could also pre-stage these drivers and have them available to the physical server before converting, but this seems like more effort than reseting a password.

To do this via a command line:

net user administrator <PASSWORD>

Install VMware Tools

VMware tools offers a wealth of drivers for the VM, along with being the vehicle that assist with scripting via PowerCLI directly into the guest. I’m not aware of any valid reasons to not load this on a VM.

I’m not a big fan of the “Install VMware Tools” option within the vSphere Client because it is so chatty when doing a fresh install (Note: I’m a big fan of it when doing Tools upgrades, especially via PowerCLI). Instead, I often pre-stage the tools folder directly to the C: drive of the server and launch the MSI using a local script.

Here is a very simple logic script to perform a silent, non-rebooting installation of tools

IF EXIST "C:Program Files (x86)" (GOTO WIN64) ELSE (GOTO WIN32)
:WIN32
ECHO Installing 32-bit VMware Tools ...
"C:VMToolsVMware Tools.msi" /qb REBOOT=ReallySuppress
GOTO EOF
:WIN64
ECHO Installing 64-bit VMware Tools ...
"C:VMToolsVMware Tools64.msi" /qb REBOOT=ReallySuppress
:EOF

Enable Video Hardware Acceleration

I’m not entirely sure why, but on Windows Server 2003 the Tools install does not set the Video Hardware Acceleration value to full. A little notepad document opens up that tells you how to do it. But that’s manual labor, and who likes that? So, let’s script it.

I found a really nice VBscript online that does the trick. Just fire it off and your video acceleration value will be set to full. However, a reboot will be required to read the registry value. I find this acceptable since the VM really should be rebooted after tools installed anyway.

Here is the script, including the author who created it:

'script to set the Video-Acceleration for Video-Cards to "FULL"
'[email protected], 31.03.2011
Const HKLM = &H80000002
Set reg=GetObject("winmgmts:\.rootdefault:StdRegProv")
regRoot="SYSTEMCurrentControlSetControlVideo"
regKey="Acceleration.Level"
reg.EnumKey HKLM, regRoot, GUIDs
For each GUID In GUIDs
	regPath = regRoot & "" & GUID & "000"
	if reg.GetDWORDValue(HKLM,regPath,regKey,regValue) = 0 then
		reg.SetDWORDValue HKLM,regPath,regKey,0
	end if
Next

It’s a fairly short and simple script and does the trick just fine. I’ve seen some others out there that are much more complicated.

Video Resolution 

While I’m sure 640 x 480 was a great resolution back in 1995, today’s monitors shed a tear when rendering desktops of this size. There are two relatively easy ways to get around this:

  1. Wait for Windows to open the resolution balloon pop-up in the system tray, complaining that your resolution is suitable only for 15″ CRTs made over a decade ago.
  2. Fire off something like nircmd to auto adjust the resolution.
I embed option 2 into my scripts to make life a little easier.
The script language to set the console size to 1024 x 768 @ 32bits is:
nircmd.exe setdisplay 1024 768 32

Stopping and Disabling Services

While Converter and others do support doing this, I often find the process tedious. Rather than select services one by one in a GUI, I often just script the stopping and disabling of commonly unwanted services. This includes things like the HP Support Pack services (of which there are many).

The easy script method is:

net stop <SERVICE>
sc config <SERVICE> start= disabled

You can use a shotgun approach with this and list all sorts of services. If the server doesn’t have the service, the script will just throw an error and keep going. Make sure to use the real service name, not the service display name.

Thoughts

I find it a fun challenge to streamline P2Vs, and I’m sure I’ll have some more tips as I continue to gain experience with doing them. I have begun using Double-Take Availability for Windows (v5.2) at my employer to assist with quicker cut-overs (and to automagically align disks on Windows 2003 servers) but the general process is pretty similar for both VMware Converter and Double-Take.