This tip is the first in a two-part series on virtual migrations. Read part two about considerations for V2V and V2P workload migrations.
Moving physical workloads to virtual
Hot cloning vs. cold cloning
There are basically two ways to convert a physical workload into a virtual workload: hot cloning and cold cloning. Both approaches work by encapsulating the physical server into a virtual disk image—converting the operating system, drivers, application files and user data into a single file format that is compatible with a particular virtualization platform such as Hyper-V or VMware.
The conversion process typically installs tools on the physical server such as VMware’s vCenter Converter Standalone or Novell’s PlateSpin Migrate. These tools create a virtual machine (VM), copy all of the disk blocks from the physical server then create and assign virtual hardware. Today, most virtualization vendors have refined the conversion process so that it has become a simple point-and-click wizard-driven interface.
The principal difference between hot cloning and cold cloning is that hot cloning executes this process while the physical server is still online, so the conversion takes place without disrupting users. Cold cloning requires that the physical server be quiesced and taken offline before the conversion.
This ensures that all of the physical workload’s files are closed and stable, so no files change during the conversion process, which might corrupt the resulting VM. Cold cloning usually offers fewer potential problems but can result in extended downtime for an application.
Any P2V workload conversions can be CPU-intensive and may require significant time to complete the block data transfers. This isn’t the case for cold cloning because the workload is offline anyway, but hot cloning may impair workload performance and user experience. Some experts compare the processing demands of hot cloning to a backup cycle and advise that administrators schedule all conversions for off-peak hours when user demand and server activity is lightest.
Planning P2V migrations does have some potential wrinkles. “Make sure your virtual environment has the necessary resources to run everything on that [consolidated server] box,” said Scott Roberts, director of information technology for the town of South Windsor, Conn. “And make sure your SAN can handle the IOPS.”
The challenge is to ensure enough CPU, RAM and network bandwidth to support the total number of VMs anticipated for host server—otherwise, the performance and stability of VMs may suffer. Tools like Novell’s PlateSpin Recon can help assess resource needs and availability.
One of the major benefits with virtualization, however, is that administrators can monitor the computing resources that each VM demands, adjust the resource allocation to increase resources for VMs that need it or reduce unused resources to make them available for other VMs.
Administrators also need to avoid accidentally cloning the physical server’s MAC address to the VM. When this happens, network traffic can easily become confused, causing serious application problems.
Even when the original physical server is taken out of service, the problem can surface if that server’s NIC is ever re-used on other hardware later on. One effective approach is to assign a MAC address with an Organization Unit Identifier, or OUI, prefix to the VM. This not only avoids the problem but also makes it easier for administrators to track VMs.
How workloads are managed
Migrating workloads between physical and virtual environments can have profound effects on the way workloads are managed. To avoid problems, administrators should consider some important caveats.
When converting physical workloads to virtual machines (VMs), experts say they see a distinct lack of management planning such as capacity planning, configuration management or lifecycle management. These oversights eventually lead to inefficiency, errors and unexpected capital expenses that can significantly raise the cost of server virtualization.
An enterprise may find that six months into the virtualization process, it realizes it doesn’t even know what it has anymore, said Chris Wolf, senior analyst with the Burton Group. “That often requires them to make another investment in management software.” Planning and budgeting for management is a critical element of successful virtualization.
The problem is similar with virtual-to-virtual (V2V) migrations, which may require new tools for different hypervisors. If the plan is to swap hypervisors outright, there will also be a new learning curve—and price tag—for the associated management tools. If an organization elects to host a number of hypervisors over the long term, it may be more cost-effective to bypass specific vendor management tools in favor of third-party management tools that provide heterogeneous support for multiple hypervisors.
The situation is probably most difficult for virtual-to-physical (V2P) transitions where virtualization management tools are rendered ineffective. In these cases, administrators may need to revisit older management tools used in original the physical environment.
This was first published in August 2011