2.4. Physical to Virtual Conversion (P2V)

Physical to Virtual Conversion (P2V) is the process by which an existing operating system on a physical server — its filesystem, configuration, etc. — is cast into a virtualized instance of the same operating system and filesystem, transferred, instantiated, and started as a VM on the XenServer Host.

For existing physical instances of Windows servers, a third-party tool is required. Windows P2V software and documentation is available for download from the XenSource website at http://www.xensource.com/partners/offers.

For existing physical instances of Linux servers, this is accomplished by booting from the XenServer installation CD and choosing the P2V option. The filesystem is copied across the network onto a XenServer Host, where it appears as a normal VM. We recommend that you perform P2V operations during off-peak hours since the process involves transferring a large amount of data, which could impact other Virtual Machines running on the XenServer Host.

The P2V tool requires a 64-bit capable CPU by default. If you have an existing Linux instance on an older machine that you want to transfer via P2V, you can boot the CD via the p2v-legacy option at the initial prompt. This does require at least a PAE-enabled machine, so for very old machines you can physically move the hard drive to a PAE-enabled machine and perform the operation from there.

To P2V an existing Linux server directly to a XenServer Host

Reboot the physical server that you want to convert and boot from the XenServer installation CD. If the boot fails, start again and use the p2v-legacy option.
After the initial boot messages, you will see the "Welcome to XenServer" screen. (In this and the screens that follow, use Tab or Alt+Tab to move between elements, Space to select, and F12 to move to the next screen.)
Select OK to proceed.
The installer does some hardware detection and initialization, then presents a screen with four choices.
Select Convert an existing OS on this machine to a VM (P2V) and choose OK to proceed.
A "Welcome to XenServer P2V" screen with a descriptive message is displayed next. Click OK to proceed and follow the on-screen prompts.

When the P2V process is complete and the new VM is created, you will need to create and attach a VIF for it to have external network connectivity. Similarly, extra disks may also be added to take advantage of additional storage capacity available to the XenServer host.

Since the VM has new virtual network hardware, the MAC addresses it sees will also be different. Follow the Linux cloning guidelines (see Section 4.5, “Preparing to clone a Linux VM”) for customizing the configuration files to make the VM re-run any hardware detection scripts at startup.

2.4.1. General Guidelines for Virtualizing Physical Servers

When considering how to best begin virtualizing a collection of physical servers, it is best to gain some comfort level and experience with virtualizing servers that are more simply configured, moving later to servers with more complex configurations.

Good candidates typically include servers that are used for test and development environments, and servers used for in-house IT infrastructure (intranet web servers, DNS, NIS, and other network services, etc.). Typically servers that are doing heavily CPU-intensive tasks (sophisticated mathematical modeling, video rendering) or are I/O-intensive (high-traffic commercial web sites, highly-used database servers, streaming audio/video servers) are not the best candidates for virtualization at the start.

Once you've identified some physical servers that seem reasonable to work on first, you should take a close look at how you are currently using them. What applications are they hosting? How I/O intensive are they? How CPU-intensive are they?

To make a reasonable assessment, you should gather a reasonable amount of data on the current physical servers that you are thinking about virtualizing. Look at system monitoring data for disk usage, CPU usage, memory usage, and network traffic, and consider both peak and average values.

Good candidates for virtualization are:

servers whose CPU and memory usage and NIC and disk throughput are low will be more likely to coexist as a VM on a XenServer Host with a few other VMs without unduly constraining its performance.
servers that are a few years old - so their performance as VMs hosted on a newer server would be comparable to their existing state.
servers that don't use any incompatible hardware which cannot be virtualized, such as dongles, serial or parallel ports, or other unsupported PCI cards (serial cards, crypto accelerators, etc.).

Once you have identified a set of machines that you want to virtualize, you should plan the process to accomplish the task. First, provision the physical servers that will serve as your XenServer Hosts. The chief constraint on the number of VMs you can run per XenServer Host is system memory.

Next, plan how you will create the VMs. Your choices are to P2V an existing server, install a fresh server from network-mounted vendor media, or install a base operating system using a pre-existing template.

If you P2V an existing server, it's best to P2V a test instance of the server, and run it in parallel with the existing physical server until you are satisfied that everything works properly in the virtual environment before re-purposing the existing physical machine.

Next, plan how to arrange the desired VMs on the XenServer Hosts. Don't "mix up" servers - assign VMs to specific XenServer Hosts, giving consideration to complementary resource consumption (mixing CPU-intensive and I/O-intensive workloads) and complementary peak usage patterns (for instance, assigning overnight batch processing and daytime interactive workloads to the same XenServer Host).

For configuring individual VMs themselves, keep these guidelines in mind:

create single-processor VMs unless you are serving a multi-threaded application that will perform demonstrably better with a second virtual CPU.
when you configure the memory settings for a VM, consult the documentation for the guest operating system you plan to run in that VM and for the applications you plan to run on them.