Q

Four rules for virtual machine migration

In a physical-to-virtual migration, getting a handle on your server and storage requirements as well as disaster recovery needs can significantly reduce risks. An expert offers his four golden rules to avoid migration problems.

What are some of the risks of moving from client/server computing to virtual machines (VMs) and virtual servers? What do you recommend as a best practice to minimize the risks of a physical-to-virtual migration?

As with any operation, the best advice is be prepared. The more you know about a particular process, the better equipped you'll be to handle it. Here are my four rules to virtualization migration:

Rule #1: Don't shortcut capacity planning
Know peak server performance characteristics such as CPU and memory and not understanding storage requirements -- not only allocated vs. used storage, but also the I/O requirements of applications and servers. Will the application or server require a multi-CPU or memory-intensive operation? If performance tanks after moved to a VM, end-users and revenue generating applications will have difficulty recovering from a public relations perspective.

Rule #2: Consider how the recovery point objective (RPO) is influenced or changed
Backup and restore requirements or the changes to backup software should be understood. You can significantly reduce complexity and costs by changing the backup strategy by backup via the ESX host or the storage array rather than an individual VM. If you can restore the entire VM, back up from the ESX host or storage array. If you need to restore individual files from the VM, keep the agent on the VM just like you are backing up your current hosts, but consider the impact to the physical VM server. You don't want 10 VMs on a physical host getting backed up at the same time.

Rule #3: Define the disaster recovery (DR) requirements of each server and application and host appropriately
Understand the DR requirements of the application housed within the server and how these requirements dictate where it is stored, how it is accessed and what you would need to do in a recovery situation. Typically, moving VMs around or changing the storage/backup plan impacts your VM implementation strategy. Will your VM need to be replicated or is it a test/dev/qa app or a tertiary application?

Rule #4: Don't over-allocate
Plan for VM sprawl as you would have with server sprawl. What is where? Did you set up the correct policies and rules within DR or other VM movement software?

This was first published in April 2008

Dig deeper on Virtual machine performance management

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchVMware

SearchWindowsServer

SearchCloudComputing

SearchVirtualDesktop

SearchDataCenter

Close