Manage Learn to apply best practices and optimize your operations.

How to do better physical to virtual migrations

Physical to virtual migrations are largely wizard-driven these days, but there are some key prep tasks you can do to make them even better.

Besides the ability to virtualize servers, one of the greatest benefits of virtualization has been the ability to migrate existing physical servers into the virtual world without having to re-install them. The vMotion and HA migration techniques get all of the attention, but physical to virtual (P2V) migrations have been a cornerstone of virtualization, as very few organizations can afford to simply abandon existing servers and applications in favor of new servers. The physical to virtual migration is a tried-and-true method for taking what once was physical into this new virtual environment. Today, it is all wizard-driven, but there are several tips that can make you a P2V expert and help to ensure you are being a good steward to your virtual environment.

Clean up the server

This should probably go without mentioning, but clean up the servers you're going to import. Unhide system files and remove the 23 recycling bins that have collected from each user who has ever logged into the server. Of course, some of them will have left several GBs of data in the recycle bin -- and who wants to P2V that? Use a directory-sizing tool and look for excessive storage hotspots that will add both time and more drain on the expensive shared storage requirements of your P2V.

Some of the key areas to look at are the user directories where some folks may have copied service packs to the desktop before they deployed them. They may have also placed them in temporary folders on the local drive; a good directory-sizing tool will help you dig them out. Internet cache files can also contain large downloads that were typically a single-use item and never got removed from the server. While the traditional temp files and locations can collect some stale data, the desktop and profile areas tend to be the hotspots containing the large service packs and rollups that can account for tens of GBs of wasted storage.

Examine the resources used

Physical servers often have a lot of excessive hardware resources. This is very true if the server is currently targeted for virtualization. Oftentimes we virtualize servers that have been very lightly used, so directly copying hardware resources could be very wasteful in a virtual environment where resources are shared among multiple virtual servers.

The main categories to look at are CPU, memory, network adapters and storage. Monitor the server for a week and take note of the resources it's using. This gives you a benchmark when allocating the virtual resources. A key thing to keep in mind as you monitor the server is that an older server running at 50% CPU might take a lot less CPU on new hardware when it is virtualized.

Setting a standard on number of CPUs and memory per operating system and expanding upward from that standard is a more economical solution than over-allocating resources by matching what the physical server had and then trying to scale them back.

Ditch the installed software

With most physical servers the manufacturer will have preconfigured software and drivers that are used to support the specific hardware platform. This software needs to be removed from the new virtual server before it can be brought into production. It is very critical that all vendor-related software, including management homepages, is removed. Leaving even one application can cause CPU spikes, as that software may find itself in a loop looking for specific hardware. After you have uninstalled all of the software, you can check the services of the server to ensure nothing vendor-related still exists. Once this is done, you can install the hypervisor-specific tools to supply the new drivers to the virtual machine.

When uninstalling the vendor drivers, always configure your virtual machine with two virtual CPUs to start. Initially, use the dual CPU configuration even if you are planning on the server only having one. After the first reboot where the server has been virtualized, many of the vendor-specific drivers will be looking for hardware that no longer exists and will cause one CPU to spike to 100%. Having the dual CPUs will still allow you to uninstall the vendor software without having to fight for CPU cycles like if you only had a single CPU.

With some physical to virtual migration tools, it is now possible to disable specific services in the new virtual machines. This can be a bit hit-or-miss, as you are trying to catch all of the services and some of them might not be clearly labeled. Another possible gotcha with disabling them is that in some cases they may even prevent the server from booting unless they are uninstalled properly so the operating system can replace the vendor drivers with the native operating system components.

This was last published in October 2014

Dig Deeper on P2V, V2V and V2P migration

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.