This tip is the second in a two-part series on virtual migrations. Read part one about management tips for planning...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Once a virtualization layer is in place, pre-existing workloads must make the transition from physical servers to virtual servers. Virtual workloads may also need to make a transition from one virtualization platform to another as platforms are upgraded or swapped out over time. And although the assumption might be that virtual machines (VMs) never go back, there are cases when a workload may make the transition back to a physical server. This tip takes a closer look at the considerations and caveats in virtual-to-virtual (V2V) and virtual-to-physical (V2P) workload transitions, as well as important factors to note for disaster recovery.
From virtual to virtual
Although migrating workloads from physical to virtual is quite common, the move from virtual to virtual is a bit more complicated. There are generally only three situations that require V2V migration:
- the current virtualization platform is upgraded or patched to a different version
- the organization is supporting multiple hypervisors—perhaps VMware in production or Hyper-V in QA
- the organization is switching hypervisors because of technological or budgetary reasons
Regardless of the reason, VM images must be converted between the incompatible virtual disk formats. Vendors that support the Open Virtual Machine Format generally do so only for virtual appliances, so typical hypervisors expect to handle proprietary formats such as VHD for Microsoft, VMDK for VMware, or qcow and qcow2 for QEMU, KVM and Xen.
Any V2V migration should start with an evaluation of the computing resource requirements of each original VM to ensure that those resources are available on the destination server. If not, the converted VM may need to be deployed on a different server, or other workloads may be redistributed to free the necessary resources.
“The planning is essentially the same as in a physical-to-virtual conversion,” said Chris Wolf, senior analyst with the Burton Group. “Look at how you’re structuring storage, the virtual networks, and how all that is mapping from one virtual infrastructure to another,” he said.
Planning also carries over to documentation and readme files so that the proper migration steps are followed. For example, Roberts said he upgraded from VMware 3.5 to 4.1 but had to patch in a specific order rather than moving directly between versions.
The actual conversion will use tools from virtualization vendors such as VMware vCenter Converter, Microsoft System Center Virtual Machine Manager or Citrix XenConvert. As with P2V conversions, the V2V process is largely wizard-driven and works well in many cases with little administrator intervention.
Because blocks must be transferred across the network, it may take several hours to convert a large disk image of 100 GB or so. Expect to take more time to convert larger disk images.
Remember several important issues when planning a V2V migration. Do not overlook the implications of cost—particularly VM management costs—when making the transition from one vendor’s hypervisor to another. The cost of a hypervisor is relatively small compared to the cost of associated management tools and other applications that are tied to the original vendor’s APIs, Wolf said, and those investments may all be negated with a move to another hypervisor.
Review the newly converted VM instance and take the time to remove any old agents, drivers, or tools associated with the old hypervisor platform. Finally, look for opportunities to optimize the converted VM for its new hypervisor. “We brought a certified VMware consultant to do a health check because there were some settings that didn’t optimize [during the upgrade],” Roberts said.
When virtual to physical is needed
It is rare that a VM would need to be converted back into physical workload, but it may be required in the event of performance problems, conflicts or vendor support limitations.
Consider performance problems. Most physical workloads will virtualize and run with no problems, but heavy or complex workloads must be sized and deployed with care. Although heavy applications like Oracle or Exchange 2010 are now virtualized successfully, comprehensive testing and tweaking lead to the best results.
Conflicts between virtual workloads might also require some or all of the conflicting workloads to be migrated back to a physical state. “We got those wonderful pink screens at one point due to our SAN having a problem with two hung ESX hosts,” said Roberts, adding that this cut off network access until one of the domain controllers was returned to a physical workload and the trouble resolved.
In most cases, the V2P process is a reverse of P2V, and administrators will use a wizard-driven tool like Novell’s PlateSpin Migrate or Quest Software’s vConverter to walk through the process. Computing resources aren’t usually a concern for physical servers running a single workload. But a V2P process removes the virtual abstraction layer between the application environment and the server hardware, so there can be serious problems locating and reinstalling device drivers and other hardware-specific files.
But perhaps the most common need for V2P comes from vendor support incidents. Many application vendors may require you to perform a V2P conversion on a troubled workload to eliminate virtualization as a possible cause of the underlying problems. This is changing slowly as more vendors develop and test their applications for virtualization—but be aware of this possibility.
Implications of backup and disaster recovery
The migration of workloads from physical-to-virtual (P2V), virtual-to-virtual (V2V) or virtual-to-physical (V2P) can serve specific and readily justifiable business needs. But administrators must adjust the backup, disaster recovery and other data protection processes related to each workload as they make the transition within the data center—it’s a step that should be included in every workload migration plan.
For example, migrating a physical workload to a virtual machine (VM) provides much simpler data protection through snapshots, but snapshots don’t work automatically. Snapshot software must be installed and configured. Adequate storage space must be available on the local or remote SAN to retain the snapshots. It is also possible to continue using more traditional backup technologies, but backup agents must be installed and set up in each VM.
The move from one hypervisor to another won’t change the data protection scheme as radically as a P2V transition. But it is important to ensure that current snapshot software or backup agents will operate on the newly converted VMs after a V2V migration. Alternative snapshot software or backup agents may be needed. And regardless of the tools, they may need to be redirected to a new location if the migration moves that newly converted VM to another physical host.
The return from VM to physical workload can be the most challenging to data protection because this typically requires a move back to more traditional backup schemes. It’s a bit easier for administrators to handle if the VM was using a backup agent because that agent will still typically work as a physical workload. But a VM relying on virtualization-only data protection tools might need to resurrect old backup schemes.