The 2010 release of vSphere 4.1 improved VMware vMotion by allowing administrators to migrate more than one virtual machine (VM) at a time. (In contrast, Microsoft only debuted Hyper-V Live Migration in 2009, with the release of Windows Server 2008 R2.)
VMware vMotion enables the live migration of VMs from one host to another with continuous uptime. It allows admins to perform server maintenance without disrupting guest VMs, and it makes disaster recovery faster and more efficient. In addition, vMotion facilitates VM load balancing across physical hosts. That improves VM performance and optimizes resource usage.
There are a few VMware vMotion requirements to know before you begin installation. You might also encounter some roadblocks as you perform live migrations, but the following resources can help you overcome them. This guide also covers VMware Storage vMotion, which extends the vMotion concept from hosts to data stores.
VMware vMotion works with other VMware features -- VMware Distributed Resource Scheduler, Distributed Power Management and Update Manager -- to provide load balancing and make it easier to perform server maintenance. First, learn how the live migration process actually works and make sure you meet the VMware vMotion requirements. Then you can download and configure vMotion and, finally, perform a vMotion. (That’s actually the easiest part.)
Downloading, configuring and using vMotion in vSphere 4
VMware vMotion is a feature of the Advanced, Enterprise and Enterprise Plus versions of the vSphere suite. The vMotion requirements include rules about shared storage, VM affinity, CPU compatibility and cluster organization. You also need to add a vMotion-enabled VMkernel adapter if you use Fibre Channel storage. Once your configuration is all set, it’s easy to request a vMotion live migration with just a few clicks inside the vSphere client.
Understanding how VMware vMotion live migration works
VMware's Distributed Resource Scheduler uses VMware vMotion live migration technology to move VMs off overloaded hosts. Doing so provides resource balance, and of course, has zero downtime for end users. With Distributed Power Management, vMotion moves VMs from one host to another when the virtual infrastructure load is low. That way, your organization saves on power and cooling costs. Update Manager even uses VMware vMotion to apply patches.
VMware DRS and vMotion: Improve workload balance, prevent problems
Distributed Resource Scheduler (DRS) and VMware vMotion go hand in hand, but the features don’t always play nice together. DRS ensures that your resource requirements are enforced, and VMware vMotion performs a live migration when VMs and their resources need to be re-allocated. Still, using both VMware DRS and vMotion doesn’t guarantee perfect resource balancing. A vMotion live migration doesn’t always provide complete VM connectivity, and sometimes, a VM fails to migrate.
It may be easy to use, but VMware vMotion is not without some minor problems. There are a few cases in which you could encounter VM crashes when you attempt a vMotion live migration. But with these workarounds, you can circumvent those problems before they happen. Pay attention to VM snapshots, storage network connections and CPU types as you decide which machines to migrate. With the right tools, you can even migrate VMs across separate data centers.
VMware VMotion network and storage connectivity issues
When it comes time to migrate a VM from one host to another, you need to verify which other hosts have the right connections to accept that VM. VMware vMotion also requires access to shared storage, so in an infrastructure with lots of VMs and even more storage network connections, it can be difficult to manage those target hosts. Another caveat is that VMs that are being migrated must be able to access the same IP network. But there’s one solution to both network and storage problems with vMotion: dynamically allocating hosts.
Avoiding an Enhanced vMotion Compatibility gotcha
If you don’t perform live migrations between hosts with identical CPUs, you could experience a vMotion crash. But Enhanced vMotion Compatibility (EVC) can prevent these crashes through CPU masking, which tricks the guest OSes into not recognizing the extra features that might disrupt a live migration. Masking CPUs is not a perfect solution, so make sure you understand how VMware EVC works before you try live migrating VMs between hosts with different CPU types.
Live migration across data centers with Overlay Transport Virtualization
In the early days of VMware vMotion, a common complaint was that you couldn’t easily perform a live migration across physically separate data centers. In 2010, Cisco Systems developed a bridging method, known as Overlay Transport Virtualization (OTV), to facilitate vMotion between data centers. The setup is fairly simple and allows vMotion live migration across multiple data centers. As your virtual infrastructure grows and expands, the ability to migrate VMs to a remote location is invaluable for disaster recovery.
Troubleshooting VMware snapshots
VMware snapshots, or exact copies of a VM at a specific point in time, are vital for virtual machine backup. But snapshots can pose problems during a VMware vMotion live migration. If you try to migrate a VM that has snapshots running, you’ll get an error message explaining that the VM will crash once that migration completes. Changing the default location for VM files disrupts the snapshot process, often because the destination host cannot access the same storage that the files are located on as the source host. If the VM has all its files on shared storage, however, vMotion won’t encounter any problems.
Storage vMotion allows you to migrate guest OS virtual disks from one data store to another while the VM is running.
Storage vMotion: Application and performance
Instead of simply moving VMs from one host to another, Storage vMotion also moves the storage location of a VM to the same new host. (This process avoids VM downtime.) Storage vMotion also checks the target data store for adequate space before a migration begins. In addition; it’s handy for converting disk types; you can change the disk format of a VM during the copy process.
Using Storage vMotion to keep servers up when storage is down
Storage vMotion is especially useful if you want to keep VMs powered on while a SAN is down. The details behind the Storage vMotion process also reinforce the necessity of snapshots. But there are a few requirements for using Storage vMotion. Virtual machine disks must be in persistent mode or be a raw device mapping that’s in virtual compatibility mode. The host that the VM is running on must also follow several requirements.
This was first published in January 2011