Use case 1 - starting a monster VM
Currently, if there are not enough resources (RAM or CPU) to start a large VM on an individual node, the VM will not start, but remains unscheduled until enough resources become available on at least one node.

If there are enough resources in the cluster, but enough resources spread out on individual nodes across the cluster, we can live migrate workloads to other nodes, and free up enough CPU and memory to allows the large VM to start.

This VM rebalancing will still need to adhere to the principles of node selectors, affinity and anti-affinity rules, and any CPU pinning.

Use case 2 - upgrading a cluster with a monster VM

During an OpenShift upgrade, the process cordons and drains nodes in sequence, live migrating workloads to different hosts. In the case of a monster VM, where there is not enough free space on any one particular host, but there is across the cluster, drain the worker node with the monster VM will pend indefinitely, as there is not enough free resources on another host to live migrate to.

There may be a solution to live migrate other workload away from a single hosts to allow the monster VM to live migrate, so this worker node can be upgraded. Ideally, it would live migrated to a node already upgraded, so you don't have to move it twice. There is also the consideration that there may NOT be a solution to this, and we should notify the admin that there is no combination of moves that will allow us to free up enough space to live migrate this VM.

User Experience Considerations 
As described this feature seemingly does not require UXD support. If that is not the case, please update this section and add the 'UXD' component to this feature.