Virtualization Features

As we have discussed in previous sections, cloud computing is a service delivery model, and virtualization is a technology. Virtualization is the main technology in the Cloud Computing 1.0 era. So, what features does virtualization provide?

Before introducing virtualization features, let's go over the characteristics of virtualization again.

Virtualization characteristics

Based on these characteristics, we introduce virtualization features from the aspects of clusters and VMs.

Virtualization Cluster Features

A cluster is a group of computers that collectively provide resources for users, including compute, storage, and network. A complete cluster must contain all these types of resources.

HA

Let's begin with a story about Kai-Fu Lee, a venture capitalist, technology executive, write, and an artificial intelligence (AI) expert currently based in Beijing, China. 

In the early years, Dr. Kai-Fu Lee worked in Apple, specializing in the development of new products.

At one time, Kai-Fu Lee and the CEO of the company, Mr. Sculley, were invited by America's most popular morning TV show, "Good Morning America." The TV station communicated with Apple in advance and hoped that they could demonstrate Apple's latest speech recognition system on live TV.

However, the success rate of the system was about 90%, and Mr. Sculley hoped to increase the success rate to 99%.

Kai-Fu Lee did not modify the program of the system, but prepared two identical computers. If one computer becomes faulty, the system will be immediately switched over to the other computer. This way, there is just a possibility of 1% (10% x 10%) that both the computers become faulty, and the success rate of the system reaches 99%.

This story shows us the basic principles of HA. The cluster technology is used to overcome the limitations of a single physical host, thereby preventing service interruption or reducing system downtime. HA in virtualization is actually the compute-layer HA, that is, VM HA. If a compute node becomes faulty, the other compute node in the cluster can be automatically started.

A virtualization cluster usually uses shared storage. A VM consists of configuration files and data disks. The data disks are stored on shared storage, and the configuration files are stored on the compute nodes. If a compute node becomes faulty, the virtualization management system (such as vCenter and VRM) rebuilds the fault VM on other nodes based on the recorded VM configuration information.

During HA, the following issues need to be addressed:

• Detecting host faults
• Handling VM startup failures

First, let's look at the first issue. To check whether a compute node is faulty, the administrator needs to periodically establish communication with all nodes in the cluster. If the communication with a node fails, the node may be faulty. Use Huawei FusionCompute as an example. The heartbeat mechanism between the CNA host and VRM enables VRM to check whether CNA is faulty. The detailed process is as follows:

1. The heartbeat mechanism runs in a process or service on the CNA host.
2. The host sends heartbeat messages to VRM at an interval of 3s. If the host does not send heartbeat messages to VRM within 30s for ten consecutive times, the host is set to the faulty state. In this case, the "Heartbeat Communication Between the Host and VRM Interrupted" alarm is generated on the FusionCompute portal.
3. A timeout mechanism is used when the host reports heartbeat messages to VRM. The timeout interval for socket connecting, receiving, and sending is 10s. If the VRM service or network is abnormal, timeout may occur. The timeout log is printed with a 13-second timestamp (Timeout detection interval 3s + Socket timeout period 10s = 13s).
4. After receiving a heartbeat message from a host, VRM sets the heartBeatFreq variable to 10 (the default value is 10, which can be changed by modifying the configuration file). The detection thread decreases the value by 1 every 3s and checks the current value of this parameter. If the value is less than or equal to 0, the system regards that the host is abnormal, reports an alarm on the FusionCompute portal, and sends a host exception message to VRM. VRM then determines whether to trigger VM HA.

Next, let's look at the second issue. When a VM is started on another host, services on the VM may fail to automatically start, and even the OS may fail to start. Service recovery on the VM may fail or take a long time. In this case, HA on the service plane is needed. If the active VM is faulty or cannot be restored, services will be recovered on the standby VM using HA technologies such as the floating IP address and Keepalived.

Therefore, VM HA is usually used together with application-layer HA to improve the service recovery success rate and efficiency.

In addition to the preceding issues, how to prevent split-brain needs to be considered. Split-brain may occur when the shared storage is written by two VMs at the same time. Before HA is implemented, the management system uses the heartbeat mechanism to detect whether the compute node is faulty. If only the heartbeat network is faulty, the management system may incorrectly determine that the compute node is faulty. In this case, split-brain may occur. Therefore, before starting a VM, the system checks whether data is written to the storage device. If data is written to the storage device, the host may not be faulty. In this case, the system does not start the VM. Instead, a message indicating that HA is successful is displayed on the management system page.

If a node in the cluster becomes faulty, VMs on this node are automatically migrated to an alternative host that is running properly

HA diagram

Load Balancing

Load balancing is a cluster technology that distributes loads (such as network services and traffic) to multiple network devices (such as servers and firewalls) or links. This improves service processing capabilities and ensures high service reliability.

Load balancing has the following advantages:

• High performance: Load balancing evenly distributes loads to multiple devices, improving the performance of the entire system.
• Scalability: Load balancing easily increases the number of devices or links in a cluster to meet the service growth requirements without degrading the service quality.
• High reliability: If one or more devices or links are faulty, services are not interrupted, improving system reliability.
• Easy management: Management work is concentrated on the devices that use the load balancing technology. The device group or link group only needs to be configured and maintained.
• Transparency: For users, a cluster is a device or link with high reliability and performance. Users do not need to care about the network structure. Adding or deleting devices or links does not affect services.

In a virtualization environment, load balancing is generally implemented on compute nodes based on the node CPU and memory usages. During VM creation and running, the management system detects the usage of all physical resources in the cluster, uses the intelligent scheduling algorithm to determine the optimal host for running VMs, and migrates VMs to the optimal host by means of live migration, thereby improving global service experience.

There are four compute nodes in the cluster and eight VMs with the same specifications are running. When the administrator creates a VM and does not specify the host for the VM, the system automatically creates the VM on the second or fourth node with light load. A large number of VMs are running on the third host. After a period of time, the system automatically detects that the load on the third host is heavy and migrates VMs on this host to other light-load hosts.

The load threshold can be specified by the system administrator or defined by the system. In Huawei FusionCompute, if the CPU and memory usage of a host exceeds 60%, VRM migrates VMs on the host to other hosts. Before the migration, the administrator can set an automatic migration task. Alternatively, the administrator can manually perform the migration after receiving a notification.

Load balancing diagram 

Scalability

In a traditional non-virtualization environment, all services are deployed on physical machines. In the initial phase of system construction, the service volume is not large. Therefore, the hardware resources configured for physical machines are limited. As the service volume increases, the original hardware cannot meet service requirements and needs to be upgraded continuously, for example, adding CPUs or expanding memory from 256 GB to 512 GB. This scaling mode is called vertical scaling, or scale-up. However, the hardware resources supported by a physical machine have an upper limit. If the service volume keeps increasing, the physical machine must be replaced, and the service migration requires machine shutdown.

In virtualization, all resources are pooled to carry service VMs. When the service volume increases, you only need to add resources to the resource pool, without having to add hardware resources. During the actual implementation, you only need to add servers. This scaling mode is called horizontal scaling or scale-out. 

Clusters support horizontal scaling, which is easier than the scaling in traditional non-virtualized IT systems. As shown in Figure 5-4, the original cluster contains only four servers and three storage devices. At the early stage of construction, the resources in the resource pool are sufficient. After some resources are consumed by VMs, the administrator finds that the existing resources are insufficient to support new services. The administrator can migrate all VMs to certain physical servers in a cluster during off-peak hours and power off and upgrade other hardware resources. The administrator can also add servers and storage devices to a cluster without affecting services. Scale-up or scale-out in virtualization systems is easier to implement than scaling in non-virtualization systems and has less impact on services.

Resource hot-add

Memory Overcommitment

Memory overcommitment allows VMs to use more memory than the total physical memory of the server by leveraging specific technologies to improve VM density.

Memory overcommitment technologies include memory ballooning, memory swapping, and memory sharing. Generally, the three technologies need to be applied together and take effect at the same time.

Memory sharing: Multiple VMs share the memory page on which the data content is the same. See Figure 5-5 for details. In this figure, the physical host provides 4 GB physical memory for the hypervisor and allocates the memory to three VMs. The three VMs read data from the same physical memory. According to the memory virtualization implementation principles, the hypervisor maps this memory segment to different VMs. To prevent any VM from modifying data in this memory segment, all VMs have only the read permission on this memory segment. If VMs need to write data to this memory segment, the hypervisor needs to create a memory segment for mapping. With the memory sharing technology, 6 GB of virtual memory can be allocated to VMs based on 4 GB of physical memory.

Memory overcommitment

Memory ballooning: The system automatically reclaims the unused memory from a VM and allocates it to other VMs to use. Applications on the VMs are not aware of memory reclamation and allocation. The total amount of the memory used by all VMs on a physical server cannot exceed the physical memory of the server. See Figure 5-6 for details.

Memory ballooning 

Each of the three VMs has 2 GB virtual memory. The memory usage of VM 1 is only 20%, and the memory usages of VM 2 and VM 3 are 70%. The system automatically maps physical memory allocated to VM 1 to VM 2 and VM 3 in the background to relieve the memory pressure.

Memory swapping: External storage is virtualized into memory for VMs to use. Data that is not used temporarily is stored to external storage. If the data needs to be used, it is exchanged with the data reserved on the memory. See Figure 5-7 for details. 

 

Memory swapping 

Memory swapping is similar to the functions of the virtual memory of Windows and the swap partition of Linux. They simulate storage as memory to store the data that has been called to the memory but is seldom used on disks. When the data is used, the data will be called back to the memory.

In some virtualization products, such as FusionCompute, memory overcommitment is configured based on clusters. After memory overcommitment is enabled, the memory overcommitment policy replaces the physical memory allocation policy. When the memory is sufficient, VMs can use all physical memory. If the memory is insufficient, the system schedules memory resources based on the memory overcommitment policies using memory overcommitment technologies to release free memory.

Memory overcommitment reduces customers' costs.

The feature helps increase VM density when the memory size of compute nodes is fixed.

The feature eliminates the need for storage devices when the VM density of compute nodes is fixed.

VM Features

Quick VM Deployment

When we purchase an Elastic Cloud Server (ECS) on the public cloud, a VM with an OS will be generated in the background. The time required for installing an OS on the VM is much shorter than that required for installing an OS on a PC. This is the quick VM deployment feature.

VMs can be quickly deployed by using templates or by cloning other VMs. A VM template is a copy of a VM. It contains VM disks and VM configuration files. Creating a VM using a VM template can greatly reduce the time for configuring a new VM and installing an OS. After a VM template is created, it cannot be started or modified. This ensures that the template will not be modified by other users and does not occupy compute resources of the cluster. A VM deployed using a template is independent of the template. To update or edit the template, you need to convert the template to a VM first. After the template is edited, you can convert the VM into a template.

VM templates are useful for deploying a large number of similar VMs because it can keep VM consistency and parameters can be modified automatically (such as the host name and SID) as required. For example, if a group of test personnel need to test the newly developed software, the administrator can use a VM with the software installed as a template, quickly deploy a batch of VMs with the same configuration, and assign the VMs to different test personnel for testing in different scenarios and with different requirements. If any problem occurs during the test, the administrator can delete the faulty VM and deploy a new VM for the test personnel. In addition, different VM templates may include different software. For example, a financial system may be pre-installed in a VM template used by financial personnel, and an ERP system may be pre-installed in a VM template used by sales personnel. VMs can be created for different departments using different templates.

In addition to deploying a VM using a template, you can also quickly deploy a VM using another VM. This function is called VM cloning. Different from template-based deployment, VM cloning is a process of completely copying the source VM at a specific time point. All settings of each cloned VM, including the host name and IP address, are the same as those of the source VM. The system reports an error if there are two identical IP addresses in a LAN. Therefore, the cloned VM and the source VM cannot be started at the same time.

Deploying a VM using a template

VM Resource Hot-Add

Hot-add is to add compute, storage, and network resources to a VM when the VM is started. 

VM resource hot-add

From the administrator's perspective, the CPU and memory parameters of a VM are part of the VM configuration file. The hardware configuration of the VM can be modified through modification of these parameters. As shown in Figure 5-9, when a user is using a VM, the CPU and memory usage reaches 75%, which may affect user experience or even affect the normal use of the VM. In this case, the VM resource hot-add feature can be used to add CPU and memory resources to the VM online. This feature allows the resource usage to be quickly reduced to the normal level.

In addition to CPU and memory resources, storage and network resources also support hot-add. For example, the disk capacity of a VM can be expanded or a NIC can be added to a VM.

The hot-add function needs to be supported by the VM and OS so that the added resources can take effect immediately. Otherwise, the VM must be restarted and can be used only after the OS identifies the hardware resources.

In most cases, resources support hot-add but do not support hot-delete. For example, the administrator can expand the capacity of a disk from 10 GB to 20 GB but cannot necessarily reduce the disk capacity from 20 GB to 10 GB.

In terms of storage resource addition, you can expand the capacity of existing disks and add disks to VMs.

VM Console

Physical machines can be operated using monitors but VMs cannot. Once the network is disconnected, VMs may be controllable. A real-time VM control technology is required. 

Most hardware devices that cannot be connected to the display system are configured with an independent management interface for users to perform management operations. For example, in addition to service interfaces, storage devices are configured with control interfaces, and network devices are configured with console interfaces. Can VMs be controlled in the same way? The answer is yes.

Remote control over VMs

Each VM vendor provides the console management function for VMs. For example, VMware uses Remote Console, and Huawei and KVM use VNC. The console is network-dependent. If you need to log in to a VM from the console, you do not need to configure an IP address for the VM but must configure an IP address for the compute node where the VM is located. In addition, the compute node functions as the server to provide services for users to log in to the VM. Therefore, the network between the client and the server must be normal.

VM Snapshot

In virtualization, VM snapshots are similar to pictures we take in our life. A snapshot records the VM status at a certain moment and contains complete data of the VM. You can use a snapshot to restore a VM to the state at a specific time point.

Generally, VM snapshots are used to quickly restore a VM if the VM is faulty before an upgrade, patch installation, or test is performed on the VM. The VM snapshot function is implemented by the storage system. Storage Networking Industry Association (SNIA) defines a snapshot as a fully usable copy of a defined collection of data that contains an image of the data as it appeared at the point in time at which the copy was initiated. A snapshot can be either a copy or a replication of the specified data. Figure 5-11 shows the diagram of the snapshot technology.

Snapshot

The snapshot technology has the following features:

Snapshots can be quickly generated and used as data sources for traditional backup and archiving, reducing or eliminating data backup windows.

Snapshots are stored on disks and can be quickly accessed, accelerating data restoration. Disk-based snapshots provide flexible and frequent restoration points for storage devices. Snapshots at different points in time can be used to restore data that is accidentally erased or damaged online.

In terms of specific technical details, a snapshot creates a pointer list that indicates an address for reading data. When data changes, the pointer list can provide real-time data in a very short time and perform replication.

Common snapshot modes are Copy-On-Write (COW) and Redirect-On-Write (ROW). Both COW and ROW are concepts in the storage domain. Most vendors use the ROW technology to create VM snapshots. No matter whether COW or ROW is used, physical copy operations will not be performed, and only the mapping is modified. The following describes the differences between COW and ROW.

• COW

Data is recorded in data blocks. When COW is used, the system generates a new space each time a snapshot is created. Once data in a data block changes, the system copies data in the original data block to a new space and then writes new data to the original data block. The copy operation is performed before data is written. For example, there is a parking lot, and cars are parked in parking spaces. A new car (car B) can be parked in only after a car (car A) in a parking space has been moved to another parking space. If you were the owner of car A, would you feel that there was a problem with the management of the parking lot when the parking lot administrator told you to make room for other cars? Why not let the new car park into another parking space? ROW is introduced to address this issue. 

COW diagram

• ROW

Similar to COW, data is recorded in data blocks and a new space is generated when a snapshot is created. The difference from COW is as follows: if new data is written into the system, the original data remains unchanged and new data is written to a new space. Let's go back to the previous example. If a new car is parked in, the administrator can direct the car to a new parking space.  

ROW diagram

COW writes data twice, whereas ROW writes data only once. Therefore, ROW is more advantageous than COW in terms of creating snapshots for VMs. 

Multiple snapshots can be created for a VM to form a snapshot chain. Operations on any snapshot do not affect other snapshots.

NUMA

Non Uniform Memory Access (NUMA) is a technology that can improve the data read/write speed.

In modern times, the computing speed of a single CPU has reached the bottleneck, so designers adopt multi-core CPUs to improve the computing speed of computers. The CPU and memory are connected through the northbridge. As the number of CPUs increases, the memory increases accordingly. As a result, the response speed on the northbridge becomes slower and slower. Therefore, designers evenly bind the memory to each CPU to avoid congestion caused by northbridge sharing. Figure 5-14 shows the comparison in multicore CPU ordering.

Comparison in multicore CPU ordering 

After the modification, memory is associated with CPUs. A CPU can access its own local memory faster than non-local memory. As the local access speed is high, it is more efficient for a program to only use a CPU and its associated local memory. This technology is called NUMA.

NUMA nodes are CPU/memory couples. Each node has CPUs, bus, and memory. Cross-node access requires NUMA interconnects between the CPUs. 

In virtualization scenarios, NUMA enables VMs to use hardware resources on the same NUMA node, improving the VM response speed.

Huawei Virtualization Product Features

As an advanced virtualization product, Huawei FusionCompute only supports the cluster and VM features aforementioned but also provides enhancements to general virtualization features. To use all features supported by FusionCompute, you need to install the Tools on VMs.

The Tools consists of the kernel-mode hardware driver and user-mode vm-agent process. The kernel-mode hardware driver allows administrators to perform VM operations such as snapshot creation, live migration, online VM flavor adjustment, and NIC QoS setting. The user-mode vm-agent process enables VRM to obtain the IP address and status of the VMs as well as soft power off and restart on VMs.

Tools installation methods vary depending on operating systems. For details about how to install Tools, see the product documentation. After Tools is installed, uninstall the Tools image. Otherwise, live VM migration and VM HA will be affected.

Cluster Features

Huawei FusionCompute supports memory overcommitment and NUMA. They are common virtualization technologies and therefore are not described in detail.

HA

In FusionCompute, clusters support multiple HA policies. Users can configure HA policies as required.

Host Fault Policy

• Restore VM on Original Host: When the host accommodating the VM is faulty, the system restarts the VM only after the host is restored.
• HA: When the host accommodating the VM is faulty, the system restarts the VM from another host based on the VM startup policy configured for the cluster.

Datastore Fault Policy

• Datastore Fault Handling by Host: You are advised to select No action. If this parameter is set to No action and the datastore fault duration exceeds the value of Policy Delay, the VM receives IO ERROR, causing the OS to become abnormal. Alternatively, you can select HA. If the datastore fault duration exceeds the value of Policy Delay, the system starts the VM from another host based on the VM startup policy configured for the cluster.
• Policy Delay (minutes): Indicates the delay for host handling policy upon datastore faults to take effect. Within this duration, the backend driver resends VM I/O requests. You are advised to set Policy Delay to a larger value that does not exceed 14400.

VM Fault Policy

• No action
• Restart VM
• HA

DPM

Distributed Power Management (DPM) enables the system to periodically check resource usage on hosts in a cluster. If resources in the cluster are sufficient but service load on each host is light, the system migrates VMs to other hosts and powers off these hosts to reduce power consumption. If the in-service hosts are overloaded, the system powers on offline hosts in the cluster to balance load among hosts.

When the automated power management function is enabled, automatic resource scheduling must also be enabled so that the system automatically balances VM load on hosts after the hosts are powered on.

The time-based power management settings allow the system to manage power in different time periods based on service requirements. When services are running stably, set automated power management to a low level to prevent adverse impact on services.

With the automated power management function enabled, the system checks resource usage in the cluster, and powers off some light loaded hosts only when the resource utilization drops below the light-load threshold over the specified time period (40 minutes by default). Similarly, the system powers on some hosts only when the resource utilization rises above the heavy-load threshold over the specified time period (5 minutes by default). You can customize the time period for evaluating the threshold of powering on or off hosts. 

DPM can be used to meet energy-saving and environmental protection requirements of enterprises. For example, if an enterprise uses the FusionCompute-based desktop cloud, all VMs used in the cloud can be migrated to certain physical hosts at 22:00 p.m. in the evening, and other physical hosts can be powered off. At 07:00 a.m. the next day, the system powers on all physical hosts and evenly distributes VMs to the physical hosts based on load balancing principles. When the physical hosts are powered off in the evening, auxiliary devices, such as the air conditioning and fresh air systems, can also be powered off to minimize energy consumption.

DRS Rules

Distributed Resource Scheduling (DRS) and DPM are part of load balancing. DRS provides a reference for system migration during load balancing.

• Keep VMs together: This rule keeps the selected VMs always running on the same host. One VM can be added to only one keep-VMs-together rule group.
• Keep VMs mutually exclusive: This rule keeps the selected VMs running on different hosts. One VM can be added to only one VM-mutually-exclusive rule group.
• VMs to hosts: This rule associates a VM group with a host group so that the VMs in the specified VM group can be configured to run only on the specified host in the host group.

If different rules conflict, the scheduling priorities of the rules are as follows:

• Highest priority: The rule type is VMs to hosts, and the rules are Must run on hosts in group and Must not run on hosts in group.
• Second priority: The rule types are Keep VMs together or Keep VMs mutually exclusive.
• Lowest priority: The rule type is VMs to hosts, and the rules are Should run on hostgroup and Should not run on hosts in group.

IMC

On FusionCompute, the incompatible migration cluster (IMC) feature can be configured for a cluster to enable VM migration across hosts that use CPUs of different performance baselines in the cluster.

Currently, IMC is available for the CPUs from Intel only.

IMC allows VMs running on the hosts in the cluster to present the same CPU features. This ensures successful VM migration across these hosts even if the hosts use physical CPUs of different performance baselines.

IMC can be enabled for a cluster that contains hosts and VMs only when the following conditions are met:

• The CPU generations of the hosts in the cluster are the same as or later than the target IMC mode.
• The CPU generations of the running or hibernated VMs in the cluster are the same as or earlier than the target IMC mode. If any VM in the cluster does not meet this requirement, the VM must be stopped or migrated to another cluster.

VM Features

VM Resource QoS

CPU QoS

The CPU QoS ensures optimal allocation of compute resources for VMs and prevents resource contention between VMs due to different service requirements. It effectively increases resource utilization and reduces costs.

During creation of VMs, the CPU QoS is specified based on the services to be deployed. The CPU QoS determines VM computing capabilities. The system ensures the CPU QoS of VMs by ensuring the minimum compute resources and resource allocation priority.

CPU QoS is determined by the following aspects:

• CPU Quota

CPU quota defines the proportion based on which CPU resources to be allocated to each VM when multiple VMs compete for the physical CPU resources.

For example, three VMs (A, B, and C) run on the host that uses a single-core physical CPU with 2.8 GHz frequency, and their quotas are set to 1000, 2000, and 4000, respectively. When the CPU workloads of the VMs are heavy, the system allocates CPU resources to the VMs based on the CPU quotas. Therefore, VM A with 1000 CPU quota can obtain a computing capability of 400 MHz. VM B with 2000 CPU quota can obtain a computing capability of 800 MHz. VM C with 4000 CPU quota can obtain a computing capability of 1600 MHz. (This example explains the concept of CPU quota and the

actual situations are more complex.)

The CPU quota takes effect only when resource contention occurs among VMs. If the CPU resources are sufficient, a VM can exclusively use physical CPU resources on the host if required. For example, if VMs B and C are idle, VM A can obtain all of the 2.8 GHz computing capability.

• CPU Reservation

CPU reservation defines the minimum CPU resources to be allocated to each VM when multiple VMs compete for physical CPU resources.

If the computing capability calculated based on the CPU quota of a VM is less than the CPU reservation value, the system allocates the computing capability to the VM according to the CPU reservation value. The offset between the computing capability calculated based on the CPU quota and the CPU reservation value is deducted from computing capabilities of other VMs based on their CPU quotas and is added to the VM.

If the computing capability calculated based on the CPU quota of a VM is greater than the CPU reservation value, the system allocates the computing capability to the VM according to the CPU quota.

For example, three VMs (A, B, and C) run on the host that uses a single-core physical CPU with 2.8 GHz frequency, their quotas are set to 1000, 2000, and 4000, respectively, and their CPU reservation values are set to 700 MHz, 0 MHz, and 0 MHz, respectively. When the CPU workloads of the three VMs are heavy:

• According to the VM A CPU quota, VM A should have obtained a computing capability of 400 MHz. However, its CPU reservation value is greater than 400 MHz. Therefore, VM A obtains a computing capability of 700 MHz according to its CPU reservation value.
• The system deducts the offset (700 MHz minus 400 MHz) from VMs B and C based on their CPU quotas.
• VM B obtains a computing capability of 700 (800 minus 100) MHz, and VM C obtains a computing capability of 1400 (1600 minus 200) MHz

The CPU reservation takes effect only when resource contention occurs among VMs. If the CPU resources are sufficient, a VM can exclusively use physical CPU resources on the host if required. For example, if VMs B and C are idle, VM A can obtain all the 2.8 GHz computing capability.

• CPU Limit

CPU limit defines the upper limit of physical CPUs that can be used by a VM. For example, if a VM with two virtual CPUs has a CPU limit of 3 GHz, each virtual CPU of the VM can obtain a maximum of 1.5 GHz compute resources.

Memory QoS

Memory QoS allows VM memory to be intelligently reused based on the preset percentage of reserved memory. Memory overcommitment technologies, such as memory ballooning, are used to provide more virtual memory resources for VMs. This function maximizes memory resource reuse, increases resource utilization, ensures that a VM can obtain the reserved memory at least, and guarantees reliable service operating.

System administrators can set the reserved memory percentage based on service requirements. The main principle of memory overcommitment is to first use the physical memory. Memory QoS is determined by the following aspects:

• Memory Quota

Memory quota defines the proportion based on which memory resources to be allocated to each VM when multiple VMs compete for physical memory resources.

The system allocates memory resources to VMs based on the proportion when VMs request memory resources or hosts release free memory resources (such as when VMs are migrated or stopped).

CPU resources can be scheduled in real time. Memory resources are scheduled subtly and continuously when VMs are running until the configured VM memory resources are allocated to VMs.

For example, three VMs each with 4 GB memory run on a host that has 6 GB memory, and their memory quotas are set to 20480, 20480, and 40960, respectively. In this case, the memory allocation ratio is 1:1:2. When the memory workloads on the three VMs gradually increase, the system subtly adjusts memory resources on the VMs based on the memory quotas until the VMs obtain 1.5 GB, 1.5 GB, and 3 GB memory, respectively.

The memory quota takes effect only when resource contention occurs among VMs. If the memory resources are sufficient, a VM can exclusively use memory resources on the host if required. For example, if the memory resources required by VMs B and C are less than the reserved memory values, and VM A has more memory workloads to handle, VM A can use memory resources from free memory resources and memory resources on VMs B and C, until the memory resources obtained by VM A reach the upper limit, or the free memory resources are used up and memory resources on VMs B and C drop to the reserved values. For example, if VM C is not under memory pressure and has 1 GB memory reserved, VMs A and B theoretically can obtain a maximum of 2.5 GB memory resources each.

• Memory Reservation

Memory reservation defines the minimum memory resources to be allocated to each VM when multiple VMs compete for memory resources.  

A VM exclusively uses its reserved memory, that is, if certain memory resources are reserved for a VM, other VMs cannot use the memory resources even if the memory resources are idle.

• Memory Limit

Memory limit specifies the maximum physical memory resources that can be used by a VM. When multiple VMs are started, they will complete for memory resources. To improve memory utilization and reduce idle memory, users can set the memory limit parameters in the configuration file when creating a VM to ensure that the memory allocated to the VM does not exceed the upper limit.

Network QoS

The network QoS policy controls the bandwidth configuration. Network QoS is determined by the following aspects:

• Bandwidth control based on the sending or receiving direction of port group members
• Traffic shaping and bandwidth priority configured for each member port in a port group  

Ref : https://e.huawei.com/en/talent/#/resources