Bookmark this page

Configuring Automated Migration and Scheduling Policies

Objectives

After completing this section, you should be able to configure virtual machines to automatically schedule and migrate VMs using cluster policies.

Describing Automated Migration

RHV-M checks the resources of the clustered hosts either when a virtual machine starts, or when migrating a virtual machine, to determine an appropriate host for the virtual machine in the cluster. RHV-M also checks the resources periodically to detect any noncompliance between the current load on the individual host and the cluster policies. If the current load on the individual host is not compliant with the cluster policies, RHV-M migrates virtual machines from one host to another host in the cluster without requiring manual administrative intervention. This method of having RHV-M automatically migrate a virtual machine from one host to another is called automated migration.

RHV environment requires the hosts to be offline for upgrades and maintenance. When you mark a host for maintenance, RHV-M automatically migrates virtual machines from the host in maintenance to another available host. The migration policy states the criteria for the live migration of the virtual machines.

Describing Load Balancing and Scheduling

In RHV, load balancing refers to the distribution of the virtual machines among the hosts in the cluster to ensure efficient utilization of the clustered resources. Each cluster uses a specific policy for load balancing that has tunable properties. RHV-M uses these properties to decide when to move the virtual machines from one host to another. Load balancing runs once every minute for a certain cluster to ensure that the load on the cluster is balanced.

RHV-M uses the process called scheduling to determine the host on which a virtual machine starts. RHV-M performs scheduling based on the scheduling policies of the cluster. A scheduling policy is a combination of filters, weights, and load balancing logic. The filters apply the hard constraints that a host must satisfy to run a virtual machine, such as the minimum RAM, or CPU. The weights apply the soft constraints that control the relative preference for a host to run a virtual machine. Lower weights are considered better for the scheduler preference. The load balancing logic determines whether a specific host is underutilized or overutilized. After identifying the underutilized and overutilized hosts, the load balancing logic calls the scheduler to migrate the virtual machine from the overutilized host to the underutilized host.

Figure 9.3: Virtual machine migrating off of overutilized host

Automated migration and scheduling are different actions that RHV-M performs to make sure that load in the cluster is balanced. Load balancing in RHV is unrelated to the high availability of the virtual machines. The high availability of a virtual machine is enabled separately on the virtual machine. A high availability virtual machine is automatically restarted in the event of an interruption, either on its original host or another appropriate host. The interruption could be due to host failure or due to host being put in maintenance mode. More details on the high availability virtual machine are given in a later chapter.

Configuring a Migration Policy

Virtual machine migration is a network-intensive operation. RHV-M copies the memory state of the virtual machine over the network to the new host. When a host contains ten or more virtual machines, migrating all of them can be a long and resource-consuming process. Therefore, administrators must be sure to select the migration policy that best suits their environment.

Important

For live migration to work, RHV-M copies the virtual machine state to the new host in real time. As the migration completes, the state change in place while the migration was running may need to be retransmitted. Eventually, the migration converges and allows RHV-M to pause the virtual machine for a fraction of a second to transmit the last few changes to the new host. Finally, the virtual machine is resumed on the new host.

A system that is very busy may take longer to converge. Migration policies also determine how RHV handles this situation.

RHV-M also automatically initiates live migration of virtual machines to maintain load balancing or power-saving levels, according to the current policy. RHV-M allows administrators to disable the automated migration of virtual machines. It is also possible to disable manual migration of virtual machines by setting the virtual machine to run only on a specific host. The configuration of a migration policy also includes the configuration of a resilience policy, which determines the virtual machine migration policy when a host fails.

In the Administration Portal of RHV-M, selecting ComputeClusters from the menu displays the Compute >> Clusters page. The Compute >> Clusters page lists the available clusters. To configure the migration policy for a specific cluster, select the cluster, and then click Edit to open the Edit Cluster window.

The Edit Cluster window contains the migration configuration for the cluster under the Migration Policy section. The Migration Policy section allows you to select the migration policy to apply in the Migration Policy menu. The following describes the available migration policies.

  • The Minimal downtime policy is the default migration policy. This migration policy optimizes for the shortest pause of the virtual machine during migration, but may abort the migration if it is taking an excessive time to converge.

  • The Post-copy migration policy also optimizes for the shortest pause, if possible. If the migration fails to converge after an extended time, then this policy is applied. Post-copy starts the virtual machine in the destination host as soon as possible. To achieve this, a subset of the virtual machine memory moves to the destination hosts. If the virtual machine tries to access a memory page that is not in the destination host, then it issues a page fault, and the source host transfers that page.

  • The Suspend workload if needed migration policy supports migration under most load conditions, but a longer pause of the virtual machine may occur if it has a heavy load.

Figure 9.4: Configuring migration policy

The Bandwidth menu allows you to limit maximum bandwidth in Mbps per host for migrations, both outgoing and incoming. The three available options for Bandwidth are described below.

  • The Auto mode uses the Rate Limit [Mbps] setting in the data center host network QoS. If there is no Rate Limit [Mbps] setting defined, then the minimum speed for the NICs of the source and destination hosts is applied.

  • The Hypervisor default mode uses the VDSM setting on the source host.

  • The Custom mode uses the bandwidth defined by the user in Mbps.

The Resilience Policy sets the virtual machine migration policy in the event of host failure. RHV-M migrates virtual machines to other hosts in the cluster if the host unexpectedly shuts down or moves into maintenance mode.

RHV supports the migration of all virtual machines using the Migrate Virtual Machines policy, migration of only the highly available virtual machines using the Migrate only Highly Available Virtual Machines policy, and disabling the virtual machine migration using the Do Not Migrate Virtual Machines option.

Figure 9.5: Configuring bandwidth and resilience policy

Configuring a Scheduling Policy

The Edit Cluster window allows you to configure the scheduling policy for a cluster. The Scheduling Policy section contains the current scheduling policy. The default configuration does not allow deployment of a virtual machine on an overutilized host. A host is overutilized when its CPU load is higher than 80% for more than 2 minutes.

The Select Policy drop-down menu allows you select the scheduling policy for the cluster. The following discusses the five scheduling policies that RHV supports by default.

  • The power_saving policy improves the efficiency of electrical power consumption on the hosts. The hosts that remain underutilized, in terms of CPU load, for longer than the defined time interval are marked to be powered down. Before powering down the underutilized host, all of its running virtual machines are migrated to other appropriate hosts.

  • The none policy disables load balancing in the cluster. This policy spreads the compute (memory and CPU) load evenly across all the hosts in the cluster. Hosts that reach the defined values of any of the policy properties, such as CpuOverCommitDurationMinutes, HighUtilization, or MaxFreeMemoryForOverUtilized, do not run additional attached virtual machines. These policy properties are described later in this section.

  • The cluster_maintenance policy disables starting new virtual machines during maintenance tasks. Only the highly available virtual machines are scheduled to start on appropriate hosts. In the event of a host failure, any of the highly available or regular virtual machines can migrate to a healthy host.

  • The evenly_distributed policy spreads the compute (memory and CPU) load evenly across all the hosts in the cluster. Hosts that reach the defined values of any of the policy properties, such as CpuOverCommitDurationMinutes, HighUtilization, or MaxFreeMemoryForOverUtilized, do not run additional attached virtual machines. These policy properties are described later in this section.

  • The vm_evenly_distributed policy schedules virtual machines evenly between the hosts in the cluster, based on a count of the virtual machines. To keep the cluster balanced, all the hosts should have a virtual machine count below the defined HighVmCount, and no host in the cluster should have a virtual machine count beyond the defined MigrationThreshold. These policy properties are described later in this section.

Describing Scheduling Policy Properties

Each scheduling policy has an associated set of properties to customize its behavior. The following are among the scheduling policy properties.

  • The HighVmCount property represents the minimum number of running virtual machines per host required to initiate load balancing. The default value is 10. An overutilized host runs more virtual machines than this number.

  • The MigrationThreshold property configures a buffer before virtual machines migrate from the host. This value is the maximum inclusive difference in virtual machine count between the highly utilized hosts and least utilized hosts. The default value is 5. To keep the cluster balanced, the virtual machine count of every host should be lower than the value of this property.

  • The SpmVmGrace property represents the number of slots reserved for virtual machines on SPM hosts. In a cluster, the SPM hosts have relatively lower loads. This property defines how many virtual machines run on the SPM host, in comparison to other hosts. The default value is 5.

  • The CpuOverCommitDurationMinutes property represents the time in minutes that the host can run a CPU load beyond the utilization values that are defined. After the specified time elapses, the scheduling policy takes action to implement the necessary virtual machine migration. The default value is 2. This value is limited to a maximum of two characters.

  • The HighUtilization property is the percentage of CPU usage on hosts that causes the virtual machine migration, if the CPU usage continues at this level for the defined time interval. The default value is 80.

Click the OK button in the Edit Cluster window to apply the selected policy with the defined properties.

Figure 9.6: Configuring scheduling policy

References

For more information, refer to the Migration Policy Settings Explained section of the Clusters chapter in the Red Hat Virtualization Administration Guide at https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html-single/administration_guide/sect-cluster_tasks#Cluster_Migration_Policy_Settings_Explained

For more information, refer to the Scheduling Policy Settings Explained section of the Clusters chapter in the Red Hat Virtualization Administration Guide at https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/administration_guide/sect-cluster_tasks#Cluster_Scheduling_Policy_Settings

Revision: rh318-4.3-c05018e