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?
Requires Free Membership to View
When you register, my team of editors will also send you the latest expert resources covering all areas of server virtualization, such as platforms, architectures and strategies, server hardware, managing virtual environments, application issues and more.
Cathleen A. Gagne, Senior Editorial Director
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