P2V

Removing old hardware after a P2V conversion

A recent VMware KB article reminded me of a best practice I have been preaching for years that involves cleaning up old server hardware on a virtual machine (VM) after doing physical-to-virtual (P2V) conversions. When you perform a P2V conversion you are taking the operating system and encapsulating it inside a virtual machine. When you power it up on a virtual host afterwards the operating system wakes up and finds out it’s in a different home that has different server hardware and consequently proceeds to automatically load the correct drivers for all the new server hardware. Once that process is completed you typically need to reboot so all the new drivers can be loaded properly. If you go in to the device manager you will see all the new hardware devices, but you won’t see the old hardware devices. The reason for this is not because Windows deletes them — it simply hides them so you can’t see them. Continued »

Using vCenter Converter to create VMware ESXi virtual machines

Administrators considering VMware ESXi may wonder if vCenter Converter will workfor VMware ESXi conversions. The answer is yes, but there’s a gotcha.

Converting a physical machine into an ESXi virtual machine works best when you use the latest version of VMware Converter, version 3.0.3. While prior releases, such as 3.0.2 had support for ESXi, it has improved greatly with the updated 3.0.3 release. ESXi has a more updated version as well, version 3.5 Update 3. Likewise, if you are using PlateSpin’s PowerConvert or Vizioncore’s vConverter, you should make sure the version you are using supports ESXi as a target.

For most situations, converting machines to an ESXi host is not a big deal. The only practice issue that you may encounter would be the destination log-in selection of the converted virtual machine. Like many administrators, I have frequently used vCenter as the destination. If vCenter is not present in ESXi, ESXI will use the host as the destination log-in. The figure below shows the log-in:

Performing P2V conversions directly to ESX or ESXi hosts (no vCenter credentials) will use the local password to authenticate, and root is the default credential for ESXi. Beyond that, vCenter Converter converts machines to ESXi host nicely. Guest conversions can be placed in resource pools if set up on the host, as well as selected storage on VMFS volumes that are iSCSI, local,or fibre channel SAN. More information on vCenter Converter can be found on the VMware website.

P2V conversion success: Disable non-plug-and-play drivers

While performing a physical-to-virtual (P2V) conversion isn’t a new trick, there are always additional enhancements that can be performed to ensure a clean transition to a VMware platform. Recently when performing a P2V conversion, one particular system was not behaving as expected after the conversion was complete. While I have mentioned before that removing drivers from the new guest virtual machine is a good idea, this particular system required some more attention.

I found that some of the device drivers that were loaded in the Windows guest operating system even after all driver software was removed. Further, after the P2V conversion the hardware would not be enumerated in the hardware inventory because it was not present. This particular system had SAN connectivity before, and the drivers related to the fibre channel interface were causing me concern related to disk access, and a lot of errors in the local log. On the VMware virtual machine, the driver installed by VMware Tools provides all of the required disk access and I needed to stop this physical system hardware driver from filling up the error log.

The driver was listed in the Non-Plug and Play Drivers section of the Windows device manager. To view this section, be sure to view the hidden devices in the MMC snap-in for Windows Server 2003 systems. The figure below shows this area of Windows:

Once I identified the driver that was causing the issue, it was quite easy to disable the device. On subsequent boots, the offending process did not fill the Windows logs up with the errors related to the device not being present.