If a host is overloaded, why won't VMware DRS load balancing migrate virtual machines?
Tools like VMware's Distributed Resource Scheduler (DRS) are designed to help ensure VM performance by recognizing and pooling the computing resources on available servers and then dynamically migrating VMs to balance workloads and optimize resource use. When a VM attempts to start on a server with inadequate resources, or the server's resources become overtaxed, DRS load balancing should ideally migrate the VM to another server where adequate resources are available. If migration does not occur, there are several issues for administrators to consider.
First, migration may fail if no acceptable destination servers are available. The VM must be compatible with the other host servers, which must have adequate resources available to host the VM. For example, if the troubled VM is running under VMware and other servers are running Hyper-V, migration might not be possible. Alternatively, if none of the destination servers have enough CPU or memory to support the VM -- including extra resources needed during the initial startup -- DRS simply won't migrate the VM. Try migrating the troubled VM to a spare or lightly loaded server and remember that DRS won't migrate a VM with fault tolerance enabled.
Next, consider the state of DRS. For example, make sure that DRS load balancing is enabled for the VM and verify that DRS automation is not set to "manual." If it is set to manual, be sure to approve the migration recommendation. Also, check the DRS rules for affinity -- DRS cannot migrate a VM to any server that violates affinity rules. For example, an affinity rule may prevent two mission-critical VMs from residing on the same physical host in order to prevent a potential hardware failure from disabling two critical applications at the same time. This may require rule changes or adjustments that will migrate the afflicted VM to an alternative host system.
Finally, examine the afflicted VM and make sure that there are no deliberate device dependencies. Although the premise of virtualization eliminates specific device dependencies, certain devices -- such as USB flash drives -- can still create dependencies that might prevent a VM from working on another host. For example, if a VM on one host relies on a USB dongle -- perhaps to unlock an enterprise application -- that VM cannot migrate to another host because the USB device does not exist at the destination.
Dig Deeper on VMware virtualization
Related Q&A from Stephen J. Bigelow
Not all hypervisors and OSes can play nice with others. The best method for avoiding complications down the road is to thoroughly test your nested ...continue reading
Theoretically, there is no limit on how 'deep' a nested VM can go. The best way to avoid any confusion is to appropriately label hypervisor nesting ...continue reading
Interested in giving nested virtualization a try in your data center? There are a few software and hardware requirements you'll have to meet first.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.