Moving the contents of a physical computer into a virtual machine is much more than simply copying files from one location to another. In fact, this is a complex technical operation that takes time and costs money.
In the previous article in this series, we discussed how to calculate ROI. Before that, we discussed how to recognize virtualization candidates and we discussed capacity planning. Now we will finally enter in the first operational phase: the physical-to-virtual (P2V) migration of the physical machines we recognized as being good candidates for virtualization.
The virtual hardware presented by a virtual machine is always different from the physical hardware on the original server.
Recognition of drivers is one area of concern. In any server, immediately after migration, at first reboot the operating system kernel recognizes new devices and looks for drivers to handle them. If the kernel fails to find appropriate drivers, the devices will not work.
Depending on the operating system, this adjustment can be complex. Microsoft Windows actually requires a P2V migration tool to pass the necessary drivers to the kernel and initialize them at the right moment and in the right order in order for Windows to boot correctly without the dreaded Blue Screen of Death (BSOD).
In Linux, experts would be able to adjust the drivers without commercial tools, but the process is annoying and time consuming. Plus, a manual operation wouldn't be able to automate the remaining part of the process, which involves interaction with the target virtualization platform.
P2V migration tools have the responsibility not only to move data from the source computer to the target virtual machine (and to accommodate the migration) but also to create a new virtual machine with opportune virtual hardware, to power it on and to install the required performance enhancement tools from the vendor.
Newcomers often balk at the price of P2V migration tools, but in so doing, the newcomers are failing to consider the costs of unexpected errors that tend to occur when the physical server has been rebuilt from scratch in a virtual machine.
Several virtualization experts and enthusiasts offer free P2V migration tools, but although they are good for converting a few servers, at the moment no one is really able to scale them for use in large conversion projects. Customers quickly discover that the amount of time spent to fix these tools when a technical issue appears is much more expensive than the cost per conversion in commercial solutions.
A needed add-on of modern P2V migrations tools is the capability to interact with products that recognize candidates for virtualization and products that aid in capacity planning. Integration of these tools allows speedup of virtual migrations, since every newly converted virtual machine can be immediately moved inside the most available host server.
At the moment of this writing, PlateSpin is the only company offering such a service. PlateSpin's P2V solution, PowerConvert, can integrate with its PowerRecon discovery tool.
A big plus when approaching P2V migration tools is considering their capability to perform the opposite process: a virtual-to-physical (V2P) migration.
Although the prevalent need is to consolidate machines, that's not the only use for virtualization. The huge administrative effort of deploying new workstations for employees, for example, could be greatly reduced if an IT manager would be able to configure an ideal virtual machine and then inject it into the brand new hardware each time a new employee started work.
Today this is partially mitigated with the help of disk cloning utilities like Symantec Save & Restore (formerly Ghost), but these solutions present a couple of severe limitations. They depend on hardware configuration, so the same image cannot be restored on a different server, and any modification to the desired configuration implies saving a new master image.
The first limitation is being addressed these days by disk image companies like Acronis, which have enhanced the traditional cloning tools to restore images on different hardware, also supporting virtual machines. But a P2V migration tool that can also do V2P operations could be an event better choice.
Virtual-to-Virtual migration capabilities could be another plus. A V2V migration moves operating systems and their data among virtual machines of different vendors, taking care of differences at the host level and handling dissimilar virtual hardware.
As soon as multiple hypervisors find their place in data centers, bigger companies will have to address multi-vendor management and find a simple way to move applications from a product to another.
Once again, PlateSpin is the leader here, already supporting V2V migrations back and forth between VMware, Microsoft and Virtual Iron virtualization products.
Even the most efficient P2V migration tool has a big limitation: it makes the physical machine unusable during the whole process.
The migration time is directly proportional to the size of the local storage and the network speed. On average, a physical machine with a 72GB disk can take up to 30 minutes to move through a standard Ethernet link. This could translate into a very expensive downtime. In the case of mission critical environments or where a Service Level Agreement (SLA) is in place, this may not even be an option.
Luckily, P2V technology is evolving, and PlateSpin is already able to offer a live migration feature that completely avoids the downtime. This much desirable process is possible thanks to a special technique that handled copying of all files, including open and locked ones.
At the moment, live migration is available only for Windows physical servers, but the company will add Linux support in the future.
A future of automation
In a near future, recognition of virtualization candidates, capacity planning and P2V/V2P/V2V migration tools will lose their original connotation and become an intelligent, automated and autonomous service that is dedicated to around the clock virtual data center optimization.
In perfect automation, the candidates' recognition component would scan the whole data center 24 hours a day, looking for underutilized physical server and overloaded virtual machines. Every time one appears, it would pass the report to the capacity planning component, which would suggest the best location where to migrate them. If a physical server were underutilized, it would be converted into a virtual machine; if a virtual machine were overloaded, it would be moved onto a less busy host or converted back into a physical machine. These orders would be passed to the migration component, which would perform seamless migrations without downtime.
The whole environment would be completely liquid, changing its shape by the minute based on the current workload. And end users would not be able to distinguish if our services were served by a virtual or physical machine.
In our next article, we'll look at the second, critical operational phase: the enterprise management. We'll have to face several challenges, including resources handling and monitoring, infrastructure automation and disaster recovery.
This was first published in October 2006