DocsKnowledge BaseAPI Explorer
Documentation›ZCF›ZStack Cloud›Explore more›User GuideZCF

VM Instance

What is VM Instance?

A VM instance is a virtual machine instance running on a host. A VM instance has its own IP address and can access public networks and run application services. ZStack Cloud supports more than 60 VM instances per host.

Architecture

A VM instance consists of the following core components:
  • Instance: A virtual machine instance running on a host. An instance includes the basic resources such as CPU, memory, operating system, network configurations, and disks.
  • Image: An image is a template file used to create a VM instance. Images provide the operating system required by a VM instance.
  • Primary storage: A primary storage is one or more servers that store volume files of VM instances. These files include root volume snapshots, data volume snapshots, image caches, root volumes, and data volumes.
  • Snapshot: A snapshot is a point-in-time capture of data status in a volume. Before you perform a business-sensitive operation on a VM instance, you can schedule snapshot creation at specified time points to record the state of the VM data. This allows rollback in case of breakdowns.
  • Networks:
    • Flat network: A flat network is connected to the network where the host is located and has direct access to the Internet. VM instances in a flat network can access public networks by using elastic IP addresses.
    • VPC network: A VPC network is a private network where VM instances can be created. A VM instance in a VPC network can access the Internet through a VPC vRouter.
  • Security group: A security group provides security control services for VM NICs. It filters the ingress or egress TCP, UDP, and ICMP packets of VM NICs based on the specified security rules.
Figure 1. VM Architecture


Characteristics

VM instances have the following characteristics:
  • High availability (HA): You can set an HA mode for a VM instance. When the VM instance is stopped due to daily maintenance or exceptions, the HA policy can trigger the automatic restart of the VM instance to improve the VM availability.
  • Security:
    • The VM console allows you to conveniently monitor and manage VM instances. Note that you must have the corresponding permissions before you can log in to the VM console.
    • A VM instance supports IP/MAC/ARP anti-spoofing. Abnormal protocol access sent by the VM instance at the data link layer of a host is isolated to block MAC/ARP spoofing and achieve IP anti-spoofing at the network layer.
    • You can create an image for a VM instance. The image contains all of the information about the VM instance. You can quickly copy the corresponding resources through the image.
    • You can create a snapshot for a VM instance. Before you perform a business-sensitive operation on the VM instance, you can schedule snapshot creation at specified time points to record the state of the VM data. This allows rollback in case of breakdowns.
    • A VM instance supports encrypted storage of plain text passwords to protect sensitive data on the VM instance.
    • You can set a delete policy for a VM instance, including Direct, Delay, and Never. When you delete a VM instance in the UI, a dialog box is displayed to remind you of the consequences of the deletion. You must acknowledge the risks before you can delete it. This helps to reduce the risks caused by misoperations.
    • A VM instance supports role-based access control and permission management.
    • A VM instance supports operation logs and auditing, which can meet the needs of security analysis, intrusion detection, resource change tracking, and compliance auditing.
    • The Cloud is able to securely segregate the individual guest VM instance.
  • Scalability:
    • A VM instance allows you to modify its CPU and memory online and expand the attached root volumes and data volumes online. You can modify the VM configurations as needed.
    • A VM instance supports auto-scaling. The Cloud can automatically trigger VM auto-scaling or self-healing according to business changes.
    • A VM instance supports multiprocessing for virtual processors.
    • The Cloud is working on supporting fault tolerance with the capacity to provide zero downtime, zero data loss, and continuous availability for the applications running in VM instances in the event of a host failure and supporting up to at least 4 vCPUs per VM instance in fault tolerance.

Scenarios

VM instances can be used in the following scenarios:
  • Breaks down the traditional IT information silos.

    VM instances integrate the business of an enterprise on the cloud and migrate the information service system from traditional physical servers to VM instances. This helps to improve the resource utilization and reduce repeated investments. VM instances realize the rationalized scheduling of resources through intelligent load balancing services. In addition, the VM HA feature can deal with various exceptions to ensure business continuity of VM instances.

  • Improves the development and testing efficiencies of enterprises.

    For modern IT enterprises, the deployment and approval of a development and testing environment is time-consuming, which severely lengthens the business launch cycle. With VM instances, resources can be allocated online, which helps to establish or recover a development and testing environment in seconds. This accelerates the business launch. In the same resource pool, an enterprise can use the environment encapsulated in a VM instance for development at day time and for automated testing at night. After an application development is completed, resources occupied by the corresponding VM instance can be quickly released and assigned to other projects. You can plan resource configurations in advance, allowing projects to apply for needed resources which are assigned to them in time.

  • Deploys PaaS and SaaS services for enterprises.

    For enterprises that cannot migrate PaaS or SaaS services to the public cloud, they can use ZStack Cloud to build a private cloud environment and deploy the PaaS or SaaS services on VM instances. The flexibility, stability, and high concurrency characteristics of the VM instances help to ensure the security, stability, and high-efficiency of the enterprises.

  • Provides a safe rehearsal environment.

    In recent years, network attack defense is tilted towards attackers. Enterprises are facing severe cloud security challenges as various high-risk vulnerabilities, APT targeted attacks, and computer viruses emerged in an endless stream. By using VM instances, enterprises can build a completely isolated security rehearsal environment and ensure the business security through monitoring and alarming, log auditing, vulnerability management, anti-virus and other means.

  • 3D rendering, artificial intelligence (AI), and cloud desktop.
    VM instances with GPU passthrough have strong computing capabilities and can be used in thin terminal scenarios such as 3D rendering, AI, and cloud desktops.
    • 3D Rendering

      3D rendering is commonly used in the movie production and three-dimensional video games. In these scenarios, a GPU server cluster is often used to satisfy the high compute requirements. The VM GPU passthrough feature provided by ZStack Cloud enables both a low performance loss (within 5%) and a centralized and efficient cluster management. Coupled with intelligent monitoring and billing, it provides a complete set of convenient and efficient rendering farm solution.

    • Artificial Intelligence

      Enterprises can build a TensorFlow-based AI application by using VM instances with GPU passthrough. The powerful computing capabilities of GPU devices can fully meet the infrastructure requirements of large-scale model trainings.

    • Cloud Desktop

      GPU devices play a critical role in the field of cloud desktop applications, not only optimizing the desktop visual experience, but also providing main computing capabilities in special applications. Replacing traditional PC graphics stations, GPU devices allow users to implement their 3D work in a safer environment. By using VM instances with GPU passthrough and protocols such as RDP and PCoIP, users can fully enjoy the capabilities of graphics cards and obtain a near-physical machine experience.

View VM Instances

ZStack Cloud provides two method to display VM instance: List View and Directory View. A directory view can display VM instances by cluster or by group. You can specify how VM instances are displayed as needed to achieve a higher resource management efficiency.

Figure 2. List View


Figure 3. Directory View


Switch VM Instance View

By default, VM instances are displayed in a list view. You can flexibly switch the VM instance view as needed.

You can click the switch button in the upper right corner of the VM Instance page to switch the VM display view on the current page.

You can set VM Instance View in Global Setting. VM instances are displayed according to the global setting on all relevant pages.
  • Method: On the main menu of ZStack Cloud, choose Settings > Global Setting > Advanced > Resource Center > Resource Pool > VM Instance. Then, set VM Instance View as needed.
  • Figure 4. Set VM Instance View in Global Setting


List View | Introduction

Displays VM instance information in a list, such as the VM name, state, CPU, memory, and supported actions.

Directory View | Introduction

  • Displays VM instance in a directory tree form. You can click the switch button above the directory tree to make it display VM instances by clusters where VM instances locate or by groups that VM instances are affiliated to.
    Note:
    • Currently, ECS instances in Hybrid Cloud Management cannot be displayed in directory views.
    • Directory views are displayed to admin and platform managers. and sub-accounts cannot see a directory view.
      Figure 5. Switch Display Method in Directory View


  • When you create associated resources based on VM instances, you can filter needed VM instances by cluster or by group, such as alarms, backup jobs, CDP tasks, and scheduled jobs.
    Figure 6. Filter VM Instances When Creating Associated Resources


Directory View | Display By Cluster

  • Provides a cluster directory tree to display VM instances, helping you view the VM affiliations to clusters and hosts conveniently.
  • The cluster directory tree displays all clusters in the current zone and hosts in each cluster. You can specify a cluster to view VM instances in this cluster, or specify a host to view VM instances running on the host.
  • You can search a host in the directory tree quickly by the host name.
  • You can collapse or expand a whole cluster directory tree.

Directory View | Display By Group

  • Provides a group directory tree to display VM instances, helping you view groups that VM instances belong to conveniently.
  • The group directory tree displays all VM groups in the current zone and hierarchical relationships between the groups. You can specify a group to view VM instances in this group and its sub-groups.
  • You can search a group quickly in the directory tree quickly by the group name.
  • You can collapse or expand a whole group directory tree.
Note:
  • Groups are separated according to zones where they locate. The directory tree in the current zone does not include groups in other zones.
  • A directory tree on the VM Instance page does not include vCenter VM groups.

Directory View | Group Types

ZStack Cloud supports two types of VM groups: system groups and custom groups.
  • System Group: System groups are automatically provided by the system, including All and Default. All is the root directory in a group directory tree. Default is affiliated to All and is used to manage VM instances that are not allocated to any custom groups.
  • Custom Group: Custom groups are created manually as you need. All custom groups are affiliated to the root directory All.

Directory View | Manage Group

ZStack Cloud allows you to create and manage VM groups. The following lists the actions you can perform on a group.
Action Description
Create Group Create one-level or multiple-level groups.
Note:
  • To create a group, you need to set a group name that is 1 to 20 characters in length and contains only Chinese characters, English letters, digits, spaces, or the following characters: ()（）【】@._-+.
  • The name of the group you create cannot be used by an existing group on the same hierarchy.
  • You can create at most four levels of groups (including the root directory group).
  • You cannot create sub-groups for Default.
Create VM Instance Create VM instances in a specified group.
Note: Only custom groups support this action. You cannot perform this action on All and Default.
Rename Modify the name of a group.
Note: You can modify names only for custom groups. You cannot perform this action on All and Default.
Delete Group Delete a Group.
Note:
  • All and Default cannot be deleted.
  • Deleting a group also deletes all its sub-groups.
  • Deleting a group does not delete VM instances in it. After the group is deleted, VM instances in this group and its sub-groups are moved to Default.

Create a VM Instance (Fast Creation)

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. You can create a VM instance quickly through one of the following fast creation entrances:
  • Click the Fast Creation button on the right of Create VM Instance. Then, the Fast Creation page is displayed.
  • Click Create VM Instance. On the displayed page, click Fast Creation.
On the Fast Creation page, set the following parameters:
  • Name: Enter a name for the VM instance.

    The name must be 1 to 128 characters in length and can contain Chinese characters, letters, digits, spaces, hyphens (-), underscores (_), periods (.), parenthesis (), colons (:), and plus signs (+) and cannot begin or end with spaces.

  • Quantity: Enter the number of VM instances to be created. Valid values: 1 to 100. You can change the maximum number by modifying the value of Maximum VM Creation in Batch on UI in the global setting.
    Note: When you create VM instances in bulk, the names of these VM instances will be followed by -1, -2, -3 and so forth to distinguish these VM instances.
  • Tag: Optional. Bind one or more tags to the VM instance as needed.
  • Group: Optional. Choose a VM group for the VM instance. If you do not set this parameter, the VM instance goes to the default group.
  • Set the VM offering by using one of the following methods:
    Basic Offering: You can set the VM offering by selecting an existing instance offering and disk offering. If you select this method, set the following parameters:
    • Instance Offering: Select an existing instance offering. The instance offering defines the number of CPU cores, memory size, host allocation strategy, and other configurations of the VM instance.
      • Reserve Memory: The minimum memory that ensures the normal running of the VM instance. By default, this feature is disabled. If you enable this feature, make sure that the reserved memory is less than the memory defined in the instance offering.
    • Image: Select an existing image. The image is used to install an operating system for the VM instance.
      Note: If you select an Windows-based ISO image that has enabled Virtio, the Virtio drive will be attached to the VM operating system by default. You need to manually install the drive when you install the operating system. If you reboot the VM instance on the UI, the drive will be detached.
    • Root Disk Offering: Select an existing disk offering for the root volume of the VM instance. The root disk offering defines the root volume information such as the size and disk bandwidth.
      • If you select a raw or qcow2 image, this parameter is optional. If you do not select a disk offering, the root disk offering will be consistent with the size of the selected image.
      • If you select an ISO image, this parameter is required.
    • Data Volume: Optional. Choose whether to create data volumes and attach the volumes to the VM instance. You can attach a default maximum of 24 data volumes to a VM instance. The maximum number can be changed by modifying the global setting Maximum Data Volume. By default, no data volumes is created and attached to the VM instance.
      If you choose to attach a data volume, click Attach Data Volume and set the following parameters:
      • Data Disk Offering: Select an existing disk offering for the data volume of the VM instance. The data disk offering defines the data volume information such as the volume size and disk bandwidth.
      • Quantity: Enter the number of data volumes created from the selected data disk offering that you want to attach to the VM instance.
      • Enable VirtIOSCSI: Optional. Choose whether to use a VirtIOSCSI bus to create a SCSI data volume.
        Note:
        • By default, VirtioSCSI is enabled if a shared storage is used, indicating that you can create VirtIO SCSI volumes.
        • If a LocalStorage primary storage is used, you can enable VirtioSCSI on the volume details page.
        • VirtIOSCSI volumes support multiple I/O queues, which can be identified with IDs (WWN).
    Custom Offering: Set the VM offering by customizing the following VM configurations:
    • CPU: Set the number of CPU cores of the VM instance. Valid values: 1 to 1024, integer.
    • Memory: Set the memory size of the VM instance. Valid values: 16 MB to 1000 TB, integer. Unit: MB, GB, and TB.
    • Reserve Memory: The minimum memory that ensures the normal running of the VM instance. By default, this feature is disabled. If you enable this feature, make sure that the reserved memory is less than the memory defined in the instance offering.
    • Host Allocation Strategy: The strategy used to allocate a host to the VM instance. This strategy is consistent with the global setting Host Allocation Strategy. You can modify this global setting to specify a host allocation policy for the VM instance.
    • Image: Select an existing image. This image is used to install an operating system for the VM instance.
      Note: If you select an Windows-based ISO image that has enabled Virtio, the Virtio drive is attached to the image by default. You need to manually install the drive when you install the operating system. If you restart the VM instance on the UI, the drive will be detached.
    • Root Volume: Set the size of the root volume. Valid values: 1 MB to 1024 TB, integer. Unit: MB, GB, and TB.
      • If you select a raw or qcow2 image, this parameter is optional. If you do not select a disk offering, the size of the root disk offering is consistent with the size of the selected image. If you customize a size, make sure that the size is no smaller than the selected image size.
      • If you select an ISO image, this parameter is required. Make sure that the size is no smaller than the selected image size.
    • Data Volume: Optional. Choose whether to create data volumes and attach the volumes to the VM instance. You can attach a default maximum of 24 data volumes to a VM instance. The maximum number can be changed by modifying the global setting Maximum Data Volume. By default, no data volumes is created and attached to the VM instance.
      If you choose to attach a data volume, click Attach Data Volume and set the following parameters:
      • Data Disk Offering: Select an existing disk offering for the data volume of the VM instance. The data disk offering defines the data volume information such as the volume size and disk bandwidth.
      • Quantity: Enter the number of data volumes created from the selected data disk offering that you want to attach to the VM instance.
      • Enable VirtIOSCSI: Optional. Choose whether to use a VirtIOSCSI bus to create a SCSI data volume.
        Note:
        • By default, VirtioSCSI is enabled if a shared storage is used, indicating that you can create VirtIO SCSI volumes.
        • If a LocalStorage primary storage is used, you can enable VirtioSCSI on the volume details page.
        • VirtIOSCSI volumes support multiple I/O queues, which can be identified with IDs (WWN).
  • Network Configurations: Configure the network resources and network services for the VM instance. You can configure multiple networks for a VM instance as needed. One network corresponds to a NIC.
    • Network: Select an L3 network for the VM instance. Supported network types: VPC network, public network, and flat network.
      Note:
      • If the L3 network is enabled with the DHCP service, the NIC acquires an IP address in a DHCP mode. The network configurations are deployed by the DHCP service and take effect directly after the VM instance is created.
      • If the L3 network is disabled with the DHCP service, the NIC acquires an IP address in a Static mode. You need to install GuestTools for the VM instance after the creation and sync the configurations to the NIC to take effect. If the VM image has encapsulated GuestTools, the network configurations take effect directly after the VM instance is created.
    • Make Default: Choose whether to set the network as the default network of the VM instance.
    • Enable SR-IOV: Optional. Choose whether to use SR-IOV to generate a VF NIC and pass it through to the VM instance. By default, SR-IOV is disabled. You can enable it if you have hardware resources that satisfy related requirements.
      Note: To enable SR-IOV, note that:
      • Make sure that SR-IOV network acceleration mode is used for the L2 network from which the L3 network is created. Otherwise, SR-IOV cannot be enabled.
      • Enabling SR-IOV generates an NIC of the VF type and passes it through to the VM instance.
      • After SR-IOV is enabled, make sure that the physical NIC corresponded by the L3 network has an available VF NIC. Otherwise, the VM instance might fail to be created.
      • If you do not enable SR-IOV:
        • If the L2 network from which the VM L3 network is created uses Stndard or Smart NIC network acceleration mode, the VM instance is assigned an NIC of the vNIC type.
        • If the physical NIC in the L2 network from which the L3 network is created is a Smart NIC, and the L2 network uses Smart NIC network acceleration mode, the VM instance is assigned an NIC of the vDPA type.
    • Assign IP: Optional. Choose whether to manually assign an IP address to the VM NIC.
      • If the L3 network is enabled with IP Address Management, the checkbox is not selected by default and the system automatically allocates an IP address to the VM NIC according to the IP allocation policy of the L3 network. If you choose to manually assign an IP address, set the following parameters:
        • Assign IPv4/IPv6: Specify an IP address on the L3 network for the VM NIC.
          Note:
          • The IP address must be unique within the network segment of the selected network.
          • By default, the drop-down menu displays 5 recommended IP addresses. If the current network has less than 5 IP addresses, all available IP addresses will be displayed.
          • If you create VM instances in bulk and specify an IP address here, the Cloud will automatically assign a range of IP addresses to these VM instances with the IP address you specify as the start IP. If an IP address is occupied or if IP addresses are insufficient within the continuously assigned IP range, the corresponding VM instance will fail to be created.
        • If the L3 network is disabled with IP Address Management, the system does not automatically allocate an IP address. To configure a NIC IP address, you can either assign one on the Cloud or configure one in the VM instance.
          If you assign an IPv4 on the Cloud, set the following parameters:
          • Assign IPv4: Specify an IPv4 address for the VM NIC.
            Note:
            • Make sure that the IPv4 address has not been occupied on the Cloud.
            • If you create VM instances in bulk, the IPv4 address you enter is identified as the start IP and assigned to the first VM instance. The IPv4 addresses following it are continuously assigned to the rest VM instances. When an IPv4 has been occupied, the corresponding VM instance fails to be created.
            • After the creation, install VM GuestTools and sync NIC configurations to make the IPv4 take effect. If the VM image has encapsulated GuestTools, the IPv4 takes effect directly after the creation.
          • Netmask: Set the IPv4 netmask.
          • IPv4 Gateway: Optional. Set the IPv4 gateway.
          If you assign an IPv6 address on the Cloud, set the following parameters:
          • Assign IPv6: Specify an IPv6 address for the VM NIC.
            Note:
            • Make sure that the IPv6 address has not been occupied on the Cloud.
            • If you create VM instances in bulk, the IPv6 address you enter is identified as the start IP and assigned to the first VM instance. The IPv6 addresses following it are continuously assigned to the rest VM instances. When an IPv4 has been occupied, the corresponding VM instance fails to be created.
            • After the creation, install VM GuestTools and sync NIC configurations to make the IPv6 take effect. If the VM image has encapsulated GuestTools, the IPv6 takes effect directly after the creation.
          • Prefix Length: Set the IPv6 prefix length.
          • IPv6 Gateway: Optional. Set the IPv6 gateway.
          If you configure an IP address in the VM instance, the IP address can be read to the Cloud through GuestTools and then managed by the Cloud.
          Note:
          • If the IP address is conflict with IP addresses of other resources on the Cloud, this IP address will not be read.
          • The IP address assigned on the Cloud is prior to the IP address configured in the VM instance. If you have assigned an IP address to the NIC on the Cloud, the IP address of the same type you configure in the VM instance will not be read. For example, if you have assigned an IPv4 to the NIC on the Cloud, the IPv4 you configure for it in the VM instance will not be read.
    • MAC Address: Optional. Choose whether to customize a MAC address for the VM instance. By default, this option is not selected and the Cloud automatically assigns a MAC address to the VM instance.
      • Note:
        • If you use the custom configuration, the Cloud assigns a MAC address to the VM instance according to your configurations. In this case, pay attention to avoiding MAC address conflicts.
        • If you create VM instances in bulk and choose to assign a MAC address here, the Cloud automatically assigns MAC addresses to these VM instances with the first assigned MAC address as the start address. If a MAC address is occupied within the continuously assigned MAC range, the corresponding VM instance will fail to be created.
    • Security Group: Optional. Associate an existing security group with the VM instance. If the L3 network is disabled with IP Address Management, assign an IP on the Cloud before you can attach security groups.
    • EIP: Optional. Associate an existing elastic IP address (EIP) with the VM instance. If the L3 network is disabled with IP Address Management, you cannot associate an EIP.
  • HA Mode: Optional. Specifies whether to enable auto restart if VM instances are unexpectedly stopped or are errored because of errors occurred to compute, network, or storage resources associated with the VM instances. Valid values: None and NeverStop.
    • None: The VM instance does not reboot automatically after an unexpected stopping or error.
    • Neverstop:
      • The VM instance attempts to reboot automatically after it is unexpectedly stopped because of its own errors.
      • The VM instance attempts to migrate to another host automatically if errors occur to the compute, network, or storage resource it is residing on.
      • The VM instance does not reboot automatically if it is stopped manually or through a scheduled job.
    Note:
    • By default, a newly created VM uses VM HA Mode Default value in the platform setting. You can modify this value for a VM instance individually during or after the creation. After the modification, the VM instance is not affected by VM HA Mode Default Value in the platform setting.
    • If you choose NeverStop, make sure that you have enabled HA Policy in Platform Setting. Otherwise, the NeverStop mode does not take effect.
  • User Data: Optional. Inject user-defined parameters or scripts to customize configurations for the VM instance or to accomplish specific tasks.
    Note: To use user data, note that:
    • Before you import the user data, make sure that both the user data network service and DHCP network service work as expected.
    • Before you inject user data to Linux-based VM instances, make sure that cloud-init is installed on the images of the VM instances. We recommend that you install cloud-init 0.7.9, 17.1, 19.4, 19.4, or later.
    • Before you inject user data to Windows-based VM instances, make sure that Cloudbase-Init is installed on the images of the VM instances. You can install Cloudbase-Init of any version.
    • You cannot use User Data if the VM instance uses an SR-IOV VF NIC.
Figure 7. Create VM Instance (Fast Creation)


Create a VM Instance (Standard Creation)

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. Click Create VM Instance. On the displayed page, click Standard Creation.

To create a VM instance through the standard creation entrance, follow these four steps:
  1. Complete the basic configurations.
    Set the following parameters:
    • Name: Enter a name for the VM instance.

      The name must be 1 to 128 characters in length and can contain Chinese characters, letters, digits, spaces, hyphens (-), underscores (_), periods (.), parenthesis (), colons (:), and plus signs (+) and cannot begin or end with spaces.

    • Description: Optional. Enter a description for the VM instance.
    • Quantity: Enter the number of VM instances to be created. You can create VM instances in bulk.
      Note:
      • The quantity must be an integer ranging from 1 to 100.
      • You can change the maximum number of the VM instances that you can create at one time. Method:

        Go to Settings > Platform Setting > Global Setting > Advanced > Resource Center > Resource Pool > VM instance, locate Maximum VM Creation in Batch on UI, and change its value as needed. Default: 100.

    • Tag: Optional. Bind one or more tags to the VM instance.
      Note:
      • The Cloud supports 50 tags per resource and an unlimited number of resources per tag.
      • Multiple tags can be bound to multiple resources.
      • An administrator can unbind or delete tags created by a tenant.
      • An administrator can set the number of tags can be created by a tenant by using the following method:

        Go to Settings > Platform Setting > Global Setting > Advanced > Platform Policy > Quota Policy, locate Tag Default Quota, and change its value as needed. Default: 20.

    • Group: Optional. Choose a group for the VM instance. If you do not set this parameter, VM instance goes to the default group.
    • Set the VM offering by using one of the following methods:
      • Basic Offering: Set the VM offering by selecting an existing instance offering and disk offering.
        • Instance Offering: Select an existing instance offering.
          • Reserve Memory: The minimum memory that ensures the normal running of the VM instance. By default, this feature is disabled. If you enable this feature, make sure that the reserved memory is less than the memory defined in the instance offering.
        • Image: Select an existing image.
          Note: If you select an ISO image encapsulating a Windows operating system with Virtio enabled. The VM system will automatically load Virtio drivers. You need to manually in install the drivers when install the operating system. After you reboot the VM instance on UI, the drivers are automatically detached.
        • Root Disk Offering: Select an existing disk offering for the root volume of the VM instance. The root disk offering defines the root volume information such as the size and disk bandwidth.
          • If you select a raw or qcow2 image, this parameter is optional. If you do not select a disk offering, the size of the root disk offering is consistent with the size of the selected image.
          • If you select an ISO image, this parameter is required.
        • Data Volume: Optional. Choose whether to create data volumes and attach the volumes to the VM instance. You can attach a default maximum of 24 data volumes to a VM instance. The maximum number can be changed by modifying the global setting Maximum Data Volume.
          If you choose to attach a data volume, click Attach Data Volume and set the following parameters:
          • Data Disk Offering: Select an existing disk offering for the data volume of the VM instance. The data disk offering defines the data volume information such as the volume size and disk bandwidth.
          • Quantity: Enter the number of data volumes created from the selected data disk offering that you want to attach to the VM instance.
          • Enable VirtIOSCSI: Optional. Choose whether to use VirtioSCSI bus to create a SCSI data volume.
            Note:
            • By default, VirtioSCSI is enabled if a shared storage is used, indicating that you can create VirtIO SCSI volumes.
            • If a LocalStorage primary storage is used, you can enable VirtioSCSI on the volume details page.
            • VirtIO SCSI volumes support multiple I/O queues, which can be identified as IDs (WWN).
      • Custom Offering: Set the VM offering by customizing the following VM configurations:
        • CPU: Set the number of CPU cores of the VM instance. Valid values: 1 to 1024, integer.
        • Memory: Set the memory size of the VM instance. Valid values: 16 MB to 1000 TB, integer. Unit: MB, GB, and TB.
        • Reserve Memory: The minimum memory that ensures the normal running of the VM instance. By default, this feature is disabled. If you enable this feature, make sure that the reserved memory is less than the memory defined in the instance offering.
        • Host Allocation Strategy: The strategy used to allocate a host to a VM instance. This strategy is consistent with the global setting Host Allocation Strategy . You can modify this global setting to specify a host allocation policy for the VM instance.
        • Image: Select an existing image.
        • Root Volume: Set the size of the root volume. Valid values: 1 MB to 1024 TB, integer. Unit: MB, GB, and TB.
          • If you select a raw or qcow2 image, this parameter is optional. If you do not select a disk offering, the size of the root disk offering is consistent with the size of the selected image. If you customize a size, make sure that the size is no smaller than the selected image size.
          • If you select an ISO image, this parameter is required. Make sure that the size is no smaller than the selected image size.
        • Data Volume: Optional. Choose whether to create data volumes and attach the volumes to the VM instance. You can attach a default maximum of 24 data volumes to a VM instance. The maximum number can be changed by modifying the global setting Maximum Data Volume.
          If you choose to attach a data volume, click Attach Data Volume and set the following parameters:
          • Data Disk Offering: Select an existing disk offering for the data volume of the VM instance. The data disk offering defines the data volume information such as the volume size and disk bandwidth.
          • Quantity: Enter the number of data volumes created from the selected data disk offering that you want to attach to the VM instance.
          • Enable VirtIOSCSI: Optional. Choose whether to use VirtioSCSI bus to create a SCSI data volume.
            Note:
            • By default, VirtioSCSI is enabled if a shared storage is used, indicating that you can create VirtIO SCSI volumes.
            • If a LocalStorage primary storage is used, you can enable VirtioSCSI on the volume details page.
            • VirtIO SCSI volumes support multiple I/O queues, which can be identified as IDs (WWN).
    • Advanced:
      • HA Mode: Optional. Specifies whether to enable auto restart if VM instances are unexpectedly stopped or are errored because of errors occurred to compute, network, or storage resources associated with the VM instances. Valid values: None and NeverStop.
        • None: The VM instance does not reboot automatically after an unexpected stopping or error.
        • Neverstop:
          • The VM instance attempts to reboot automatically after it is unexpectedly stopped because of its own errors.
          • The VM instance attempts to migrate to another host automatically if errors occur to the compute, network, or storage resource it is residing on.
          • The VM instance does not reboot automatically if it is stopped manually or through a scheduled job.
        Note:
        • By default, a newly created VM uses VM HA Mode Default value in the platform setting. You can modify this value for a VM instance individually during or after the creation. After the modification, the VM instance is not affected by VM HA Mode Default Value in the platform setting.
        • If you choose NeverStop, make sure that you have enabled HA Policy in Platform Setting. Otherwise, the NeverStop mode does not take effect.
      • Sync with Host BIOS Time: Optional. Choose whether to sync Windows VM time with the host BIOS time. If enabled, Windows VM time is the same as that of the host. By default, the sync is enabled.
        Note:
        • If you enable time synchronization for a Windows VM instance, the VM time is synchronized with the host BIOS time automatically.
        • If you disable time synchronization for a Windows VM instance, the VM time is not synchronized with the host BIOS time.
        • If you modify the time synchronization setting for a Windows VM instance, the setting takes effect after the VM instance reboots.
        • The time synchronization setting does not take effect on Linux VM instances.
        • You can enable time sync in Global Setting for all Windows VM instances on the Cloud. To enable time sync in Global Setting, set Sync with Host BIOS Time to Sync. By default, the time sync global setting is enabled.
        • If you specifically set time sync for a Windows VM instance, the global setting does not take effect on the VM instance.
      • Resource Priority: Optional. Set a high resource priority for the VM instance so that VM instance can compete for more resources in case of resource contention.
        Note:
        • When resource contention occurs due to high host workloads, priority is given to allocating resources to VM instances with the high resource priority.
        • We recommend that you set a high resource priority for vital VM instances.
      • VM Scheduling Group: Optional. Add the VM instance to a VM scheduling group.
        • A VM instance can be added to only one VM scheduling group. After the addition, the VM instance will be scheduled based on the scheduling policy associated with group.
        • The scheduling policies associated with a VM scheduling group can be classified into the following four types: VM Exclusive from Each Other, VM Affinitive to Each Other, VMs Affinitive to Hosts, and VMs Exclusive from Hosts.
      • USB Redirection: Optional. Set USB redirection for the VM instance.
        Note:
        • The Cloud currently supports redirection of multiple USB devices. If you want to use the VDI feature, you can redirect the USB device on the VDI client to the VDI VM instance.
        • The setting takes effect after you restart the VM instance.
      • Anti-Spoofing Mode: Optional. Enable the anti-spoofing mode for the VM instance.
        Note:
        • This mode provides IP/MAC anti-spoofing and ARP anti-spoofing for the VM instance. If enabled, the VM instance can only communicate with outside networks by using the IP or MAC addresses allocated by the Cloud.
        • You can set whether to enable the anti-spoofing mode globally by using the following method:

          Go to Settings > Platform Setting > Global Setting > Basic > Resource Center > Resource Pool > VM Instance, locate Anti-Spoofing Mode, and enable or disable the switch as needed. Default: false.

        • By default, the anti-spoofing mode of a single VM instance is strictly controlled by that in the global setting.
        • If anti-spoofing is disabled in the global setting, you can enable it for a single VM instance on the VM details page.
        • Anti-Spoofing Mode is incompatible with IPv6 addresses. If you need to configure an IPv6 address for the VM instance, we recommend that you do not enable this mode because this will make the VM fail to communicate with others through the IPv6 address.
    Figure 8. Basic Configurations


  2. Complete the resource configurations.
    Set the following parameters:
    • Network Configurations: Configure the network resources and network services for the VM instance. You can configure multiple networks as needed. One network corresponds to a NIC.
      • Network: Select an L3 network for the VM instance. Supported network types: VPC network, public network, and flat network.
        Note:
        • If the L3 network is enabled with the DHCP service, the NIC acquires an IP address in a DHCP mode. The network configurations are deployed by the DHCP service and take effect directly.
        • If the L3 network is disabled with the DHCP service, the NIC acquires an IP address in a Static mode. You need to install GuestTools for the VM instance after the creation and sync the configurations to the NIC to take effect. If the VM image has encapsulated GuestTools, the network configurations take effect directly after the VM instance is created.
      • Make Default: Choose whether to set the network as the default network of the VM instance.
      • Enable SR-IOV: Optional. Choose whether to use SR-IOV to generate a VF NIC and pass it through to the VM instance. By default, SR-IOV is disabled. You can enable it if you have hardware resources that satisfy related requirements.
        Note: To enable SR-IOV, note that:
        • Make sure that SR-IOV network acceleration mode is used for the L2 network from which the L3 network is created. Otherwise, SR-IOV cannot be enabled.
        • Enabling SR-IOV generates an NIC of the VF type and passes it through to the VM instance.
        • After SR-IOV is enabled, make sure that the physical NIC corresponded by the L3 network has an available VF NIC. Otherwise, the VM instance might fail to be created.
        • If you do not enable SR-IOV:
          • If the L2 network from which the VM L3 network is created uses Normal or Smart NIC network acceleration mode, the VM instance is assigned an NIC of the vNIC type.
          • If the physical NIC in the L2 network from which the L3 network is created is a Smart NIC, and the L2 network uses Smart NIC network acceleration mode, the VM instance is assigned an NIC of the vDPA type.
      • Assign IP: Optional. Choose whether to manually assign an IP address to the VM NIC.
        • If the L3 network is enabled with IP Address Management, the checkbox is not selected by default and the system automatically allocates an IP address to the VM NIC according to the IP allocation policy of the L3 network. If you choose to manually assign an IP address, set the following parameters:
          • Assign IPv4/IPv6: Specify an IP address on the L3 network for the VM NIC.
            Note:
            • The IP address must be unique within the network segment of the selected network.
            • By default, the drop-down menu displays 5 recommended IP addresses. If the current network has less than 5 IP addresses, all available IP addresses will be displayed.
            • If you create VM instances in bulk and specify an IP address here, the Cloud will automatically assign a range of IP addresses to these VM instances with the IP address you specify as the start IP. If an IP address is occupied or if IP addresses are insufficient within the continuously assigned IP range, the corresponding VM instance will fail to be created.
        • If the L3 network is disabled with IP Address Management, the system does not automatically allocate an IP address. To configure a NIC IP address, you can either assign one on the Cloud or configure one in the VM instance.
          If you assign an IPv4 on the Cloud, set the following parameters:
          • Assign IPv4: Set an IPv4 Address for the VM NIC.
            Note:
            • Make sure that the IPv4 address has not been occupied on the Cloud.
            • If you create VM instances in bulk, the IPv4 address you enter is identified as the start IP and assigned to the first VM instance. The IPv4 addresses following it are continuously assigned to the rest VM instances. When an IPv4 has been occupied, the corresponding VM instance fails to be created.
            • After the creation, install a VM GuestTools and syn NIC configurations to make the IPv4 take effect. If the VM image has encapsulated GuestTools, the IPv4 takes effect directly after the creation.
          • Netmask: Set the IPv4 netmask.
          • IPv4 Gateway: Optional. Set the IPv4 gateway.
          If you assign an IPv6 address on the Cloud, set the following parameters:
          • Assign IPv6: Set an IPv6 for the VM NIC.
            Note:
            • Make sure that the IPv6 address has not been occupied on the Cloud.
            • If you create VM instances in bulk, the IPv6 address you enter is identified as the start IP and assigned to the first VM instance. The IPv6 addresses following it are continuously assigned to the rest VM instances. When an IPv4 has been occupied, the corresponding VM instance fails to be created.
            • After the creation, install a VM GuestTools and syn NIC configurations to make the IPv6 take effect. If the VM image has encapsulated GuestTools, the IPv6 takes effect directly after the creation.
          • Prefix Length: Set the IPv6 prefix length.
          • IPv6 Gateway: Optional. Set the IPv6 gateway.
          If you configure an IP address in the VM instance, the IP address can be read to the Cloud through GuestTools and then managed by the Cloud.
          Note:
          • If the IP address is conflict with IP addresses of other resources on the Cloud, this IP address will not be read.
          • The IP address assigned on the Cloud is prior to the IP address configured in the VM instance. If you have assigned an IP address to the NIC on the Cloud, the IP address of the same type you configured in the VM instance will not be read. For example, if you have assigned an IPv4 to the NIC on the Cloud, the IPv4 you configure for it in the VM instance will not be read.
      • MAC Address: Optional. Choose whether to customize a MAC address for the VM instance. By default, this option is not selected and the Cloud automatically assigns a MAC address to the VM instance. If you choose to configure a MAC address, set the following parameters:
        • MAC Address: Customize a MAC address for the VM instance.
        • Note:
          • If you use the custom configuration, the Cloud assigns a MAC address to the VM instance according to your configurations. In this case, pay attention to avoiding MAC address conflicts.
          • If you create VM instances in bulk and choose to assign a MAC address here, the Cloud automatically assigns MAC addresses to these VM instances with the first assigned MAC address as the start address. If a MAC address is occupied within the continuously assigned MAC range, the corresponding VM instance will fail to be created.
      • Security Group: Optional. Associate an existing security group with the VM instance. If the L3 network is disabled with IP Address Management, assign an IP on the Cloud before you can attach security groups.
      • EIP: Optional. Associate an existing elastic IP address (EIP) with the VM instance. If the L3 network is disabled with IP Address Management, you cannot attach an EIP.
    • Cluster: Optional. Specify a cluster of the host on which the VM instance is to be started.
    • Storage Allocation Policy: Specify how the Cloud allocates a primary storage. Supports two allocation policies: system allocation and manual allocation.
      • System allocation: The Cloud allocates a primary storage according to the preconfigured policy.
      • Manual allocation: Select a primary storage manually.
    • Host: Optional. Select the host on which the VM instance is to be started. If you specified a cluster, select a host from the cluster.
    • vDrive: Optional. Create a virtual drives (vDrive) for the VM instance.
      You can click Add vDrives to create more vDrives. Then, you can click Select ISO to attach an ISO to a vDrive.
        • If you select a qcow2 image or raw image, the Cloud creates an empty vDrive by default. To delete a vDrive, click the deletion icon next to the vDrive parameter.
        • If you select an ISO image, the Cloud creates a vDrive by default and attaches the ISO image to the vDrive. Note that this vDrive cannot be deleted here.
      • You can set the maximum number of vDrives for a VM instance after stopping the VM instance. The method is as follows:

        Go to Settings > Platform Setting > Global Setting > Basic > Resource Center > Resource Pool > VM Instance, locate Maximum Virtual Drive, and change its value as needed. Default: 3. Valid values: 1, 2, and 3.

    • GPU: Attach a GPU device to the VM instance by specifying a GPU specification or device. The GPU device can be either a physical GPU (pGPU) or a virtual GPU (vGPU).
      • Load GPU Specification: Allocate a CPU device according to the selected specification when you create a VM instance.
      • Auto Detach GPU Device: Choose whether to uninstall a GPU device automatically after the VM instance is stopped.
        • If a pGPU specification is used, this option is not selected by default. If a vGPU specification is used, this option is selected by default.
        • If selected, the GPU device will be automatically uninstalled after the VM instance is stopped. When the VM instance is restarted, a new GPU device will be allocated to the VM instance according to the GPU specification.
        • If not selected, the GPU device will be retained after the VM instance is stopped. When the VM instance is restarted, the existing GPU device will be used.
      • Load GPU Device: Attach the GPU device you selected when you create a VM instance.
      Note:
      • You can attach multiple pGPU devices or only one vGPU device to a VM instance at a time.
      • You cannot attach both pGPU and vGPU devices to a VM instance at the same time.
      • You can attach GPU devices to a VM instance from the host where the VM instance is located. Currently, you cannot attach GPU devices to a VM instance across hosts.
    • CPU Pinning: Optional. Assigns the virtual CPUs (vCPUs) of a VM instance to specific host pCPUs, which improves VM performance. Three CPU pinning methods are supported: Not Set, By NUMA Topology, and By Entry.
      • Not Set: The vCPUs of the VM instance are not pinned to specific pCPUs but are assigned to pCPUs by the operating system.
      • By NUMA Topology: Pins vCPUs to pCPUs based on the host pNUMA topology. You can implement Manual Pinning or Smart Pinning.
        • Manual Pinning allows you to customize vCPU-pCPU binding for all vCPUs.
        • Smart Pinning assigns a vCPU of a VM instance to a pCPU on a host pNUMA node by descending order of the pNUMA node ID. If all pCPUs on the pNUMA node are pinned, a pCPU on the next pNUMA node is to be pinned. If all pCPUs of the host are pinned but some vCPUs are not assigned to pCPUs, each vCPU is assigned to a pCPU starting again from the pNUMA node with the maximum node ID.
        • You can pin a vCPU to one or more pCPU or pin one or more vCPU to a pCPU.
        • The utilization of each pCPU in the past 15 minutes is displayed. You can pin a vCPU to the optimal pCPU based on the utilization.
        • Before you can select By NUMA Topology, you must select a host for the VM instance.
      • By Entry:
        • You can click Add CPU Pinning to specify more CPU pinning rules.
        • Enter the vCPU range in the left text box and the pCPU range in the right. Note that the - symbol indicates the value range, while the ^ symbol indicates that a value is not included. If you specify multiple entries in a rule, separate each entry by using a comma (,). The following are some examples:
          • 0-2 indicates CPU 0, CPU 1, and CPU 2.
          • ^2 indicates that CPU 2 is not included.
          • 0-2,^2 indicates CPU 0 and CPU 1.
          • 1-7,^2,^3,^4,10 indicates CPU 1, CPU 5, CPU 6, CPU 7, and CPU 10.
      Note:
      • The vCPU range depends on the selected instance offering of the VM instance, while the pCPU range depends on the selected cluster or the number of pCPUs of the selected host.
      • If a vCPU has multiple CPU pinning rules, the union of the rules is used.
      • ZStack Cloud supports CPU overcommitment. Therefore, the number of vCPUs can be greater than that of pCPUs. However, if the number of vCPUs specified in the CPU pinning rule is greater than that of pCPUs, the VM performance will be affected. Therefore, CPU overcommitment is not recommended.
      • You can modify the CPU pinning rules on the Overview tab page of a VM details page. The modification takes effect after you restart the VM instance.
      • Cloning or migrating a VM instance also copies the CPU pinging rules, while creating a VM image or performing VM backup does not.
      • When you create a VM instance, the Cloud firstly checks the VM scheduling policies and host allocation strategies, and then checks the CPU pinning rules.
      • When you power off a VM instance and modify its instance offering by reducing the number of the its vCPUs, the CPU pinning rules related to the reduced vCPUs no longer take effect. In this case, we recommend that you modify or delete these rules.
    Figure 9. Resource Configurations


  3. Complete the system configurations.
    Set the following parameters:
    • For Linux VM instances, you can log in to them when they are running by using an SSH key or a password.
      • SSH Key: If you select this method, set the following parameters:
        • SSH Key: Select an SSH key to enable the root user to SSH in to the VM instance without entering a password when the VM instance is running.
        Note:
        • Make sure that the Cloud-Init is installed in your VM image.
        • If your VM image does not have the Cloud-Init installed, the SSH key attached to the VM instance cannot work properly. In this scenario, you can try one of the following methods to make the SSH key work:
          • Install the Cloud-Init for the VM instance after the creation and reboot it to make the SSH key work.
          • Install the Guesttools (or the QGA of 2.5 or latter version) for the VM instance after the creation. Detach the SSH key from the VM instance first and re-attach it. Then, the SSH key can work properly.
      • Password: If you select this method, set the following parameters:
        • Username: The default username is root.
        • Password: After a root password is injected to your VM instance, you can SSH in to the VM instance by entering a password when the VM instance is running.
        Note:
        • Enter letters, digits, or special characters. Supported special characters include -`=[];',./~!@#$%^&*()_+|{}:"<>?.
        • Before you set a password, make sure that Cloud-Init is installed for the VM image.
        • If a VM instance runs CentOS, you can install Cloud-Init by running the yum install cloud-init command.
        • After you set the password, do not set it again via User Data to avoid conflicts of duplicated operations.
        • You can enable VM Password Strength in Global Setting to set password strength.
    • For Windows VM instances, you can log in to them by using a password only when they are running.
      • Username: The default username is administrator.
      • Password: After a password is injected to your VM instance, you can log in to the VM instance by using the password when the VM instance is running.
      Note:
      • Enter letters, digits, or special characters. Supported special characters include -`=[];',./~!@#$%^&*()_+|{}:"<>?.
      • Before you set a login password, make sure that Cloudbase-Init is installed for the VM image. Recommended Cloudbase-Init version: 0.9.11.
      • For more information about how to install Cloudbase-Init, see Cloudbase Documentation.
      • After you set the password, do not set the it again via User Data to avoid conflicts of duplicated operations.
      • You can enable VM Password Strength in Global Setting to set password strength.
    • Hostname: Set a hostname for the VM instance.
      • The rules for setting Linux hostname and Windows hostname are different.
        • Linux hostname: The hostname must be 2 to 60 characters in length, and can be uppercase, lowercase, digits, and hyphens (-). Note that a hostname cannot contain consecutive hyphens (-) and cannot start or end with hyphens (-).
        • Windows hostname: The hostname must be 2 to 15 characters in length, and can be uppercase, lowercase, digits, and hyphens (-). Note that a hostname cannot contain consecutive hyphens (-), cannot start or end with hyphens (-), and cannot contain only digits.
      • To set a hostname, make sure that the DHCP service of the corresponding L3 network is enabled.
      • After you set a hostname, do not set it again in User Data to avoid conflicts.
      • You cannot set a hostname for a Windows VM instance during the creation. If you need to set, install GuestTools for the VM instance after the creation, and then, click Modify Hostname on the VM action list.
    • User Data: Optional. Inject user-defined parameters or scripts to customize configurations for the VM instance or to accomplish specific tasks.
      • Before you import user data, make sure that both the user data network service and DHCP network service work as expected.
      • By default, the user data network service and DHCP network service in the flat network and VPC network environments are enabled.
      • For Linux VM instances:
        • Before you inject User Data, make sure that Cloud-Init is installed for the VM image. Recommended Cloud-Init versions: 0.7.9, 17.1, 19.4, 19.4, and later.
        • If you set a hostname and password by using User Data, do not set them again in SSH Login Method > Password to avoid conflicts.
        • If you create an Linux VM instance by using an image with Cloud-Init installed, you must import User Data. Otherwise, the Cloud-Init task will wait until timeout.
      • For Windows VM instances:
        • Before you import User Data, make sure that Cloudbase-Init is installed for the VM image. Recommended Cloudbase-Init version: 0.9.11.
        • For more information about how to install Cloudbase-Init, see the Cloudbase Documentation.
        • If you set the login password/hostname in User Data, do not set them again in the Login Password or Hostname input box. This helps avoid conflicts.
        • If you create a Windows VM instance by using an image with Cloudbase-Init installed, you must import User Data. Otherwise, the Cloudbase-Init task will wait until timeout.
      • When you use User Data, note that: If an L2 network has multiple L3 networks within the same CIDR, only the user data of the first L3 network works. This will make the internal monitoring of the VM instance fail to work properly.
      • Note: You cannot use User Data if the VM instance uses an SR-IOV VF NIC.
      • The following is an example of importing User Data to a Linux VM instance.
        #cloud-config
users:
 - name: test
   shell: /bin/bash
   groups: users
   sudo: ['ALL=(ALL) NOPASSWD:ALL']
   ssh-authorized-keys:
       - ssh-rsa AAAAB3NzaC1LXCJfjroD1lT root@10-0-0-18
bootcmd:
 - mkdir /tmp/temp
write_files:
 - path: /tmp/ZStack_config
   content: |
       Hello,world!
   permissions: '0755'
fqdn: Perf-test
disable_root: false
ssh_pwauth: yes
chpasswd:
  list: |
      root:word
  expire: False
runcmd:
 - echo ls -l / >/root/list.sh
        The preceding script can do the followings:
        1. Create a user named test and use ssh-key when a VM instance is created.
        2. Write the /etc/hosts file when the VM instance is started, create a directory named /tmp/temp, create a file, and write data to the file.
        3. Set a hostname, enable the root user, enable SSH login with password, and change the root password.
        4. Run the echo ls -l / command.
      • The following is an example of importing User Data to a Windows VM instance.
        #cloud-config
write_files:
   -   encoding: b64
       content: NDI=
       path: C:\b64
       permissions: '0644'
   -   encoding: base64
       content: NDI=
       path: C:\b64_1
       permissions: '0644'
   -   encoding: gzip
       content: !!binary |
           H4sIAGUfoFQC/zMxAgCIsCQyAgAAAA==
       path: C:\gzip
       permissions: '0644'
        The preceding script can do the following:
        • Create b64, b64_1, and gzip files under C drive when the VM instance is started.
    • Console Password: Set a console password for the VM instance. The password must be 6 to 8 characters long.
      • Enter letters, digits, and special characters. Supported special characters include -`=[];',./~!@#$%^&*()_+|{}:"<>?.
      • If you select the VNC mode, you can enable VNC Console Password Strength in Global Setting to set password strength.
      • If you set a console password, you need to enter the password when you launch the console.
    • Console Mode: Set the console mode. Options: VNC, SPICE, and VNC+SPICE. Default: VNC.
      Note:
      • If not set, the console mode specified in the global setting will be used by default.
      • If you set this parameter here, the VM instance will use the mode you select.
      • If you change the console mode of a VM instance, reboot the VM instance to take effect.
    Figure 10. System Configurations


  4. Confirm the information.

    View the information about the VM instance to be created. You can edit the information by clicking the Edit icon.

    Figure 11. Confirm Information


Considerations

When you create a VM instance, note the following:
    • Image BIOS modes include Legacy and UEFI. A VM instance inherits the BIOS mode from its image.
    • You need to get the corresponding image ready, and select a proper BIOS mode for it.
    • You can change the BIOS mode on the VM details page. Exercise with caution when you make any changes. The VM instance may fail to work properly because of an incompatible BIOS mode. After you change the BIOS mode, restart the VM instance to make the change take effect.
    • The Legacy mode is recommended when you create a VM instance. If you want to use the UEFI mode, we recommend that you select the corresponding image from the following list of operating system versions.
      OS BIOS Mode Supported Versions
      Windows UEFI
      • Windows 8 or later
      UEFI
      • Windows 7
      • Windows Server 2008 R2
      Linux UEFI
      • CentOS 7.2
      • CentOS 7.3
      • CentOS 7.4 or later
Note: SSH methods vary according to image types.
  • Operating System
    • Linux Image: Fixed user name: root. SSH method: with the SSH public key or password.
    • Windows Image: Fixed user name administrator. You can use a User Data to modify the password.
  • Image Format
    • ISO: SSH with the SSH public key.
    • Image: SSH with the SSH public key or password.

Import a VM Instance (Via Third-Party Template)

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. Select Import from the Create VM Instance drop-down list and you are redirected to the Import page.

To import a VM instance via a third-party template, follow these three steps:
  1. Select an OVF template file.
    Set the following parameters:
    • Backup Storage: Select an ImageStore or Ceph backup storage to temporarily store the template file. After the VM instance is created, the file will be auto-deleted.
    • Template Type: Only OVF template is supported.
    • OVF File: The OVF-formatted file in the uploaded OVF template. You can select only one file at a time.
    • VMDK File: The VMDK-formatted files in the uploaded OVF template. The number of files and the file configurations must be consistent with that defined in the OVF-formatted file.
    • MF File: The MF-formatted file in the uploaded OVF template. You can select only one file at a time.
    Figure 12. Upload OVF Template File


  2. Configure the VM instance.
    Set the following parameters:
    • Name: Enter a name for the VM instance.

      The name must be 1 to 128 characters in length and can contain Chinese characters, letters, digits, spaces, hyphens (-), underscores (_), periods (.), parenthesis (), colons (:), and plus signs (+) and cannot begin or end with spaces.

    • Description: Optional. Enter a description for the VM instance.
    • Tag: Optional. Bind one or more tags to the VM instance.
      Note:
      • The Cloud supports 50 tags per resource and an unlimited number of resources per tag.
      • Multiple tags can be bound to multiple resources.
      • An administrator can unbind or delete tags created by a tenant.
      • An administrator can set the number of tags a tenant can create by using the following method:

        Go to Settings > Platform Setting > Global Setting > Advanced > Platform Policy > Quota Policy, locate Tag Default Quota, and change its value as needed. Default: 20.

    • Instance Offering of Template: The instance offering of the imported VM instance is displayed.
    • Cluster: Optional. Specify a cluster of the host on which the VM instance is to be started.
      • Hosts that apply the KVM virtualization technology can be added only to KVM-based clusters.
      • You can enable network acceleration for a KVM-based cluster. If you add a host to a cluster for which network acceleration is enabled, note that:
        • If the L2 network associated with the cluster uses the Smart NIC network acceleration mode, the host must be attached with a smart NIC of the specified model.
      • Hosts of the X-Dragon architecture can be added only to X-Dragon-based clusters.
    • Network Configurations: Select an L3 network used by the VM instance and complete the network configurations.
      • Network: Select an L3 network used by the VM instance. Supported network types: public network, flat network, and VPC network.
        Note: When you select an L3 network, note that:
        • A VM instance can have multiple networks attached, and each L3 network corresponds to a NIC.
        • If the selected L3 network has both an IPv4 and IPv6 address, the VM instance would have a dual-stack NIC. That is, the VM NIC has both an IPv4 and IPv6 address.
        • Before you can create a VM instance by using an IPv6 or IPv4+IPv6 network, obtain the IP address by using dhclient -6 NIC_NAME.
        • We recommended that you use only one IPv6 address for VM instances to avoid potential risks.
      • Make Default: If you add multiple network configurations, set one of the networks as the default network.
      • Enable SR-IOV: Optional. Choose whether to use SR-IOV to generate a VF NIC and pass it through to the VM instance.
        • By default, SR-IOV is not enabled. In this case, the VM instance you create will have a vNIC attached.
        • If enabled, the VM instance you create will have a VF NIC attached.
        Note: To enable SR-IOV, note that:
        • Only IPv4 networks support SR-IOV, but IPv6 or IPv4+IPv6 networks do not.
        • Make sure that SR-IOV is enabled for the L2 network corresponding to the L3 network of the VM instance. Otherwise, SR-IOV cannot be enabled.
        • After SR-IOV is enabled, make sure that the physical NIC corresponded by the L3 network has an available VF NIC. Otherwise, the VM instance might fail to be created.
        • If SR-IOV is enabled, NICs of the VM instances created by using a public network or a flat network do not support the network services such as security group and EIP. If the VM instances is created by using a VPC network, their NICs do not support the security group network services.
      • Assign IP: Optional. Choose whether to assign an IP address to the VM NIC.
        • This option is not selected and the Cloud automatically assigns an IP address to the VM instance by default.
        • If you choose to assign an IP address to the VM instance, set the following parameters:
          • Assign IPv4: Assign an IPv4 address to the VM instance.
          • Assign IPv6: Assign an IPv4 address to the VM instance.
          Note:
          • If you use the custom configuration, the Cloud assigns an IP address to the VM instance according to your configurations. In this case, pay attention to avoiding IP address conflicts.
          • If you create VM instances in bulk and choose to assign an IP address here, the Cloud automatically assigns IP addresses to these VM instances with the IP address you specify as the start address. If an IP address is occupied or if IP addresses are insufficient within the continuously assigned IP range, the corresponding VM instance will fail to be created.
      • MAC Address: Optional. Choose whether to configure a MAC address for the VM instance.
        • By default, this option is not selected and the Cloud automatically assigns a MAC address to the VM instance.
        • If you choose to configure a MAC address, set the following parameters:
          • MAC Address: Customize a MAC address for the VM instance.
        • Note:
          • If you use the custom configuration, the Cloud assigns a MAC address to the VM instance according to your configurations. In this case, pay attention to avoid MAC address conflicts.
          • If you create VM instances in bulk and choose to assign a MAC address here, the Cloud automatically assigns MAC addresses to these VM instances with the MAC address you specify as the start address. If a MAC address is occupied within the continuously assigned MAC range, the corresponding VM instance will fail to be created.
      • Security Group: Optional. Associate a security group with the VM instance.

        The security group is used to better protect the VM instance by implementing access control in the group. You can customize access rules in the security group. These rules take effect immediately when the VM instance joins the security group. This protects the VM instance in real time.

      • EIP: Optional. Associate an elastic IP address (EIP) with the VM instance.
        Note: This parameter does not appear if you selected a public network.
    • Startup Now: Choose whether to startup the VM instance immediately after the import is completed. By default, the imported VM instance is not started up immediately
    • Advanced:
      • Storage Allocation Policy:
        • If you select System Allocation, the Cloud allocates a primary storage according to the preconfigured policy.
          • Host: Optional. Select the host on which the VM instance is to be started.
        • If you select Manual Allocation, you can select a primary storage as needed.
          • Primary Storage: Select a primary storage for the VM instance.
            • Host: Optional. Select the host on which the VM instance is to be started.
      • HA Mode: Optional. Specifies whether to enable auto restart if VM instances are unexpectedly stopped or are errored because of errors occurred to compute, network, or storage resources associated with the VM instances. Valid values: None and NeverStop.
        • None: The VM instance does not reboot automatically after an unexpected stopping or error.
        • Neverstop:
          • The VM instance attempts to reboot automatically after it is unexpectedly stopped because of its own errors.
          • The VM instance attempts to migrate to another host automatically if errors occur to the compute, network, or storage resource it is residing on.
          • The VM instance does not reboot automatically if it is stopped manually or through a scheduled job.
        Note:
        • By default, a newly created VM uses VM HA Mode Default value in the platform setting. You can modify this value for a VM instance individually during or after the creation. After the modification, the VM instance is not affected by VM HA Mode Default Value in the platform setting.
        • If you choose NeverStop, make sure that you have enabled HA Policy in Platform Setting. Otherwise, the NeverStop mode does not take effect.
      • Resource Priority: Optional. Set a high resource priority for the VM instance so that it can compete for more resources in case of resource contention.
        Note:
        • When resource contention occurs due to high host workloads, priority is given to allocating resources to VM instances with the high resource priority.
        • We recommend that you set a high resource priority for vital VM instances.
    Figure 13. Configure VM Instance


  3. Confirm the information.

    View the information about the VM instance. You can edit the information by clicking the Edit icon.

    Figure 14. Confirm Information


Considerations

After you import an VM instance to the Cloud via an OVF template, note that:
  • The root volume of the imported VM instance is of the IDE type and the data volumes of the VM instance is of the Virtio type. If the data volumes do not have the Virtio drive attached before the import, you need to install GuestTools on the imported VM instance and then start up the VM instance. Then the data volumes can be identified.
  • Imported VM instances go to the default group.

Manage a VM Instance

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. Then, the VM Instance page is displayed.

The following table lists the actions that you can perform on a VM instance.
Action Description VM State
Create VM Instance Create one or more VM instances. The Cloud provides two creation methods: standard creation and fast creation.
Note:
  • ZStack Cloud supports thin provisioning during creation of VM instances.
  • ZStack Cloud supports infrastructure automation platforms and provides self-service portal for requesting on-premise VM resources.
 /
Import VM Instance Import VM instances on a third-party cloud platform with an OVF template and customize the VM configurations.
Note: Imported VM instances go to the default group.
 /
Edit VM Instance Edit the name and description of a VM instance. Running/Stopped/Paused
Change Group Change the VM group a VM instance affiliated to. Running/Stopped/Paused
Start VM Instance Start a stopped VM instance. Stopped
Stop VM Instance Stop a running VM instance.
Note: A manually stopped VM instance does not auto reboot even if HA is enabled.
 Running
Reboot VM Instance Reboot a running VM instance. Running
Restore VM Instance Restore a paused VM instance. Paused
Pause VM Instance Pause a running VM instance.
Note: Pausing a VM instance does not really stop the VM instance. However, stopping the host on which the paused VM instance is located will affect the business running.
 Running
Force Stop VM Instance Forcibly change the VM state from Unknown to Stopped.
Note:
  • Stopping a VM instance forcibly might cause VM errors and crash. We recommend that you restore the host where the VM instance is located first.
  • Only admin and platform managers can perform this operation.
  • A manually stopped VM instance does not auto reboot even if HA is enabled.
 Unknown
Power Off VM Instance Power off a running VM instance.
Note:
  • We recommend that you do not power off a VM instance in general scenarios.
  • A manually powered-off VM instance does not auto reboot even if HA is enabled.
 Running
Launch Console Launch the console of a VM instance. ZStack Cloud includes command line scripting for managing hosts and VM instances.
Note:
  • You can set the boot options for a newly-started VM instance by pressing ESC in the VM console.
  • If you could not launch the VM console, go to the Console Proxy page and change the IP address of the console proxy to the IP address of the current management node.
 Running
Clone VM Instance Clone a VM instance that has the same system as the current VM instance based on the VM instance offering.
  • Full Clone: The cloned VM instance is independent of the source VM instance, and the performance is completely unaffected after cloning, but the VM instance starts slow.
  • Instant Full Clone: The cloned VM instance starts quickly, the VM instance is eventually independent of the source VM instance, and the performance is completely unaffected after cloning.
  • Linked Clone: The cloned VM instance starts quickly and saves storage space, but the linked clone VM instance/volumes have a dependency on source VM instances/volumes, and the performance is still affected after cloning.
Note:
  1. When you use Instant Full Clone to clone a VM instance, the Cloud automatically performs Flatten to eventually achieve data independence. During flattening, operations on VM instances/volumes will be conducted after the flattening is completed.
  2. You can unlink the dependency between linked clone VM instances/volumes and source VM instances/volumes by flattening.
  • If you clone the VM instance without attached volumes, note that:
    • Only the root volume of the VM instance will be cloned.
    • Supported backup storage types: ImageStore and Ceph.
      • If the backup storage is ImageStore, the primary storage can be LocalStorage, NFS, SMP, Ceph, or SharedBlock.
      • If the backup storage is Ceph, the primary storage can be Ceph.
      • If the backup storage is Ceph+ImageStore, the primary storage can be Ceph+SharedBlock.
    • If you use any primary storage mentioned above, you can clone the VM instance when it is running, paused, or powered off.
  • If you clone the VM instance with attached volumes, note that:
    • Both the root volume and data volumes of the VM instance will be cloned.
    • Supported backup storage types: ImageStore and Ceph.
      • If the backup storage is ImageStore, the primary storage can be LocalStorage, NFS, SMP, Ceph, or SharedBlock.
      • If the backup storage is Ceph, the primary storage can be Ceph.
      • If the backup storage is Ceph+ImageStore, the primary storage can be Ceph+SharedBlock.
    • If you use any primary storage mentioned above, you can clone the VM instance when it is running, paused, or powered off.
    • If the VM instance has a shared volume attached, the shared volume cannot be cloned.
  • When you clone a VM instance, you can set a storage allocation policy, including system allocation and manual allocation.
    • System allocation: The Cloud allocates a primary storage based on your selected clone method.
      • Full Clone:
        • Clone without attached volumes: The Cloud automatically allocates a primary storage.
        • Clone attached volumes: The Cloud allocates a primary storage consistent with that of the source VM instance/volume.
      • Instant Full Clone/Linked Clone: The Cloud allocates a primary storage consistent with that of the source VM instance/volume.
    • Manual allocation: You can select a primary storage as needed.
    Note: Instant full clone and linked clone support system allocation only.
  • When you clone a VM instance that uses a SharedBlock primary storage, select a provisioning method, including thick provisioning and thin provisioning.
    • Thick provisioning: Pre-allocates the required storage space and provides sufficient storage capacity to the VM instance to ensure the storage performance.
    • Thin provisioning: Allocates storage space to the VM instance according to the actual usage to achieve higher storage utilization.
  • When you clone a VM instance that uses a Ceph primary storage, you can specify a storage pool as needed.
    • When you clone a VM instance without the attached volumes, you can specify a Ceph pool (root volume pool).
    • For a VM instance that use an ImageStore or a Ceph backup storage, when you clone it with attached volumes, you can specify a data volume pool and a root volume pool.
  • You can specify whether to auto-start the newly cloned VM instances after cloning.
Note:
  • Cloning VM instances online clones only the data written to the disks at the beginning of the cloning jobs. The real-time cached data is not cloned.
  • To ensure data integrity, we recommend that you pause or power off high I/O VM instances before performing the cloning action.
  • The VM configuration, installation program, password, and other information, excluding the tags and scheduled jobs, will be copied to the newly cloned VM instance.
  • For the newly cloned VM instance, you need to reboot it to make the console password take effect.
  • If your environment has a LocalStorage and other types of primary storage, once the LocalStorage primary storage is unavailable, you could not successfully create VM instances by using the system allocation policy. In this case, for the instant full clone and linked clone, you cannot successfully clone a VM instance, and for the full clone, you can manually specify available primary storage for root volumes.
  • When you clone a VM instance, avoid setting a static IP address for the source VM instance. Otherwise, login errors might occur because multiple VM instances share the same IP address.
 Running/Stopped/Paused
Modify Hostname Modify the hostname of the VM instance.
  • If the VM instance is running and has GuestTools installed, the hostname is deployed and takes effect directly through the GuestTools.
  • If the VM instance is not running or does not has GuestTools installed, the hostname needs to be deployed by the DHCP service and take effect after you restart the VM instance.
  • The hostname of a Windows VM instance can only take effect through GuestTools. To modify the hostname of a Windows VM instance, make sure that the VM instance is running and has GuestTools installed.
Note: The VM hostname must comply with the following rules:
  • Linux hostname: The hostname must be 2-60 characters in length, and can be uppercase, lowercase, digits, and hyphens (-). Note that a hostname cannot contain consecutive hyphens (-) and cannot start or end with hyphens (-).
  • Windows hostname: The hostname must be 2-15 characters in length, and can be uppercase, lowercase, digits, and hyphens (-). Note that a hostname cannot contain consecutive hyphens (-), cannot start or end with hyphens (-), and cannot contain only digits.
 Running/Stopped/Paused
Flatten VM Instance Merges multiple snapshots of selected resources to improve resource performance and data security. By flattening, you can unlink the dependency between linked clone VM instances/volumes and source VM instances/volumes to achieve data independence.
Note:
  • Flatten may take a long time if the selected resources have relatively large data.
  • During flattening, operations on VM instances/volumes will be conducted after the flattening is completed.
  • After flattened, storage space occupied by cloned VM instances/volumes may increase.
  • Flattening a VM instance also flattens the data volumes attached to the VM instance. If you flatten a VM instance that has shared volumes attached, the shared volumes will not be flattened.
  • You can flatten a VM instance that is in the running/stopped/paused state.
  • You cannot flatten a VM instance that has a running CDP task and whose primary storage is not Ceph.
 Running/Stopped/Paused
Attach Tag to VM Instance Attach tags to a VM instance so that you can locate and query it quickly.
  • The Cloud provides two types of tags: admin tag and tenant tag.
    • Admin tags are created and owned by administrators (admin and platform managers).
    • Tenant tags are created and owned by tenants (sub-accounts and projects).
  • Tag owners cannot be changed.
  • A tenant can attach tenant tags to resources belonging to the tenant. An admin can attach any tags to any resources.
  • Relationship between tenants and tags:
    • A sub-account can see and perform operations on tags belonging to the sub-account.
    • Tags in a project belong to the project, and everyone in the project (project admin/project manager/project member) can perform operations on these tags.
    • Tenants cannot perform operations on admin tags.
  • Relationship between admins and tags:
    • Admins can see and perform operations on both admin tags and tenant tags.
    • For example, an admin can detach or delete tenant tags.
Note:
  • The Cloud now supports up to 50 tags per resource and an unlimited number of resources per tag.
  • You can attach multiple tags to multiple resources.
  • Tags can be sorted in order according to the creation time or tag name (priority: characters > numbers > Chinese characters > English characters). By default, tags are sorted in order by tag name. You can change the sort order in the global setting by changing the value of Tag Sort Method.
  • After the Cloud is seamlessly upgraded, existing tags are automatically updated and displayed in the latest way.
 Running/Stopped/Paused
Detach Tag from VM Instance Detach tags from the VM instance.
Note:
  • Changing a resource owner detaches the tenant tags on the resource. Admin tags are not affected.
  • You can detach tags from a resource in bulk or detach resources from a tag in bulk.
  • A tenant can only detach tags from the resources belonging to the tenant, and administrators can detach tags on all resources.
 Running/Stopped/Paused
Change Host Hot or cold migrate a VM instance to another host. This action changes only the host where the VM instance runs and does not change its primary storage. ZStack Cloud supports operating system clustering with shared-disk failover capability from one VM to another VM that is running on another host.
  • Hot Migration:
    • Migrate a running VM instance. This action mainly copies the CPU register status and memory information.
    • Supported primary storage types: LocalStorage, NFS, SMP, Ceph, and SharedBlock.
    • If the VM instance uses a LocalStorage primary storage, you could not hot migrate it with data volumes.
      In this scenario, perform the hot migration by following these steps:
      1. In the Global Setting, enable Change Host Online on Local Storage.
      2. Detach the data volumes from the VM instance.
      3. Migrate the VM instance and data volumes to the same host.
      4. Reattach the detached data volumes to the VM instance.
    • Windows VM instances on LocalStorage primary storage cannot be hot migrated.
    • Before you hot migrate the VM instance, detach the VF NIC (if any) from the VM instance first.
    • If a VM instance is on a LocalStorage primary storage or a shared storage, you can hot migrate the VM instance with vDPA NICs attached.
    • If a VM instance has a block device attached and is deployed as the master node of a Windows fail-over cluster, hot migrating the VM instance may make the fail-over cluster unavailable. Proceed with caution.
    • If the migration is blocked because the VM instance has high I/O operations for a long time, you can enable auto converge to ensure migration success.
      • You can go to the Global Setting and set Auto-converge to true to enable auto converge for all VM instances in the Cloud.
      • You can also enable auto converge for a single VM hot migration. By default, this setting complies with that in the Global Setting. If you set auto-converge for the migration specially, the global setting does not take effect on this migration process.
      • If your applications are performance sensitive, we recommend that you do not enable auto converge.
    • You can migrate VM instances to destination hosts according to the hosts' workloads.
      • In the list of recommended destination hosts, you can sort the destination hosts by the average CPU utilization or memory utilization. By default, the hosts are sorted by the average memory utilization in ascending order.
      • If the scale of hosts in the cluster is large, you can sort the top 20 or top 50 hosts as needed.
    • Before you hot migrate a VM instance, detach its volumes, ISOs, and peripheral devices (if any) first.
    • Before you hot migrate a VM instance with vNUMA enabled, make sure that the pNUMA architecture of the destination host is consistent with that of the source host.
    • The migration speed is affected by the network configuration of the source and destination hosts. Low network configuration might cause lower migration speed.
    • If a VM instance is associated with VM scheduling policies, hot migration may cause conflicts during the execution of the policies. Proceed based on your needs.
  • Cold Migration:
    • Migrate a stopped VM instance.
    • Supported primary storage type: LocalStorage.
    • If the VM instance uses a LocalStorage primary storage, you could not cold migrate the VM instance with data volumes.
      In this scenario, perform the cold migration by following these steps:
      1. Stop the VM instance.
      2. Detach the data volumes from the VM instance.
      3. Migrate the VM instance and data volumes to the same host.
      4. Reattach the detached data volumes to the VM instance again.
    • On a LocalStorage primary storage, you can cold migrate VM instances with vDPA NICs attached.
    • You can migrate VM instances to destination hosts according to the hosts' workloads.
      • In the list of recommended destination hosts, you can sort the destination hosts by the average CPU utilization or memory utilization. By default, the hosts are sorted by the average memory utilization in ascending order.
      • If the scale of hosts in the cluster is large, you can sort the top 20 or top 50 hosts as needed.
  • Before you cold migrate a VM instance, detach its data volumes, ISOs, and peripheral devices (if any) first.
  • The migration speed is affected by the network configuration of the source and destination hosts. Low network configuration might cause lower migration speed.
 Running/Stopped
Change Primary Storage Hot or cold migrate a VM instance to another primary storage. This action changes only the primary storage used by the VM instance and does not change the host. Changing primary storage only migrates valid data, and the migrated VM instance follows the provisioning type of the target primary storage. Currently, migration across SharedBlock primary storages and across SharedBlock and Ceph primary storages are supported.
  • Hot Migration Across SharedBlock Primary Storage:
    • You can implement an entire VM migration in this scenario.
    • If a shared volume is attached to the VM instance, the shared volume cannot be migrated.
    • Snapshots of the VM instance will not be saved after the hot migration.
    • Before you hot migrate a VM instance, detach its ISOs, block devices, and VF NICs (if any) first.
    • Make sure that the source and destination primary storage are in the same cluster.
  • Cold Migration Across SharedBlock Primary Storage:
    • Power off the VM instance before cold migration.
    • You can implement an entire VM migration in this scenario.
    • If a shared volume is attached to the VM instance, the shared volume cannot be migrated.
    • Before you cold migrate a VM instance, detach its ISOs, block devices, and VF NICs (if any) first.
    • Make sure that the source and destination primary storage are in the same cluster.
  • Hot Migration Across SharedBlock and Ceph Primary Storages:
    • You can migrate the VM instance with all attached volumes.
    • If a shared volume is attached to the VM instance, the shared volume cannot be migrated.
    • Before you hot migrate a VM instance, detach the ISOs, block devices, or VF NICs (if any) from the VM instance first.
    • Make sure that the source and destination primary storages are in the same cluster.
    • If you hot migrate a VM instance from a SharedBlock primary storage to a Ceph primary storage, you can specify a root volume pool or data volume pool for the volumes to be migrated.
  • You can specify the data transmission rate in the VM storage migration. Valid range: 1MB/s~100GB/s. Default value: 50MB/s.
    • The system limits the maximum I/O read rate of each volume in the source primary storage. If the VM instance has multiple volumes attached, the total migration rate does not exceed the rate limit.
    • When the total migration rate is less than the number of volumes, if the calculated average migration rate limit of volumes is less than 1MB/s, the default migration rate limit will be set to 1MB/s for each volumes.
    • Please set the migration rate limit reasonably according to the actual business requirements and network storage conditions to avoid affecting normal business operations.
    • The VM memory migration will also be affected by this migration rate. We recommend that you migrate VM instances during off-peak business hours to minimize dirty pages.
  • You can manually cancel the ongoing migration task.
 Running/Stopped
Change Host and Primary Storage Cold or hot migrate a VM instance to another host and primary storage. After you change the primary storage, the host where the VM instance resides is changed based on the system policy or your manual allocation choice. When cold migrate a VM instance, only system allocation is supported for target host.
  • Hot Migration:
    • Hot migration across primary storage of the same type:
      • You can hot migrate a VM instance across primary storage of the same type, including Ceph↔Ceph, NFS↔NFS, and SharedBlock↔SharedBlock.
        Note:
        • You can only implement an entire VM migration across primary storage.
        • If a shared volume is attached to the VM instance, the shared volume cannot be migrated.
        • Snapshots of the VM instance will not be saved after the hot migration.
        • The network configurations of the cluster to which the destination primary storage is attached need to satisfy the network requirements of the VM instance.
        • Before you hot migrate a VM instance across Ceph primary storage, make sure that the monitor nodes of these two Ceph primary storage can communicate with each other.
        • If you hot migrate a VM instance across Ceph primary storage, you can specify a root volume pool and data volume pool for the volumes to be migrated.
        • Before you hot migrate a VM instance across primary storage, make sure that the VF NICs, if any, are detached from the VM instance.
        • If vNUMA is enabled for the VM instance, the VM instance can be migrated only to a host that has the same pNUMA architecture of the source host.
        • If the VM instance has high I/O operations for a long time and your applications are not highly performance sensitive, we recommend that you enable auto converge to improve the success rate of the migration.
        • If a VM instance is associated with VM scheduling policies, hot migration may cause conflicts during the execution of the policies. Proceed based on your needs.
    • Hot migration across primary storage of different types:
      • You can hot migrate a VM instance across primary storage of different types, including Ceph↔SharedBlock, LocalStorage↔SharedBlock, LocalStorage↔Ceph, LocalStorage↔NFS, SharedBlock↔NFS, and Ceph↔NFS.
        Note:
        • You can only implement entire VM migration across primary storage.
        • If a shared volume is attached to the VM instance, the shared volume cannot be migrated.
        • Snapshots of the VM instance will not be saved after the hot migration.
        • The network configurations of the cluster to which the destination primary storage is attached need to satisfy the network requirements of the VM instance.
        • If you hot migrate a VM instance from a SharedBlock, Localstorage, or an NFS primary storage to a Ceph primary storage, you can specify a root volume pool and data volume pool for the volumes to be migrated.
        • Before you hot migrate a VM instance across primary storage, make sure that the VF NICs, if any, are detached from the VM instance.
        • If vNUMA is enabled for the VM instance, the VM instance will be migrated only to a host that has the same pNUMA architecture of the source host.
        • If a VM instance is associated with VM scheduling policies, hot migration may cause conflicts during the execution of the policies. Proceed based on your needs.
    • Hot migration across Ceph pools within the same Ceph primary storage:

      • You can migrate only the root volumes or implement entire VM migration.

      • If a shared volume is attached to the VM instance, the shared volume cannot be migrated.

      • Snapshots of the VM instance will not be saved after the hot migration.

      • If a VM instance is associated with VM scheduling policies, hot migration may cause conflicts during the execution of the policies. Proceed based on your needs.
  • Cold Migration:
    • Cold migration across primary storage of the same type:
      • You can cold migrate a VM instance across primary storage of the same type, including Ceph↔Ceph, and NFS↔NFS.
        Note:
        • Ceph↔Ceph: If you set a cold migration network for the target primary storage, the VM instance is migrated through the cold migration network. Otherwise, the VM instance is migrated through the management network. Before you cold migrate a VM instance across Ceph primary storages, you must power off the VM instance and detach all data volumes from the VM instance. You can specify a root volume pool for the destination primary storage.
        • NFS↔NFS: Before you cold migrate a VM instance across NFS primary storage, you must power off the VM instance and detach all data volumes from it. Make sure that the destination NFS primary storage can be attached to the cluster the VM instance in.
        • The network configurations of the cluster to which the destination primary storage is attached need to satisfy the network requirements of the VM instance.
    • Cold migration across Ceph pools within the same Ceph primary storage:
      • You must power off the VM instance and detach all data volumes from it.
      • You can only implement entire VM migration across Ceph pools.
      • If a shared volume is attached to the VM instance, the shared volume cannot be migrated
  • You can specify the data transmission rate in a VM storage migration. Valid range:1MB/s~100GB/s. Default value:50MB/s.
    • The system limits the maximum I/O read rate of each volume in the source primary storage. If the VM instance has multiple volume attached, the total migration rate does not exceed the rate limit.
    • When the total migration rate is less than the number of volumes, if the calculated average migration rate limit of volumes is less than 1MB/s, the default migration rate limit will be set to 1MB/s for each volume.
    • Please set the migration rate limit reasonably according to the actual business requirements and network storage conditions to avoid affecting normal business operations.
    • The VM memory migration will also be affected by this migration rate. We recommend that you migrate VM instances during off-peak business hours to minimize dirty pages.
  • You can manually cancel the ongoing migration task.
Note: Before you migrate a VM instance, detach the ISOs, block devices, and peripheral devices (if any) from the VM instance first.
 Running/Stopped
Modify Instance Offering Modify the instance offering of a VM instance.
Note: After the modification, only the CPU, memory, and host allocation policy in the new instance offering take effect for the VM instance.
  • You can modify the instance offering of Linux VM instances when they are running or powered off.
    • To modify the instance offering of a running VM instance, follow these steps:
      1. Enable Instance Offering Online Modification.
        • You can enable Instance Offering Online Modification for all VM instances in the Cloud. Method: In the Global Setting, enable Instance Offering Online Modification.
        • You can also enable Instance Offering Online Modification for a single VM instance. By default, this setting complies with that in the Global Setting.
      2. Restart the VM instance.
      3. Modify the instance offering of the VM instance.
    Note: When you modify the instance offering of a running VM instance, make sure that the new CPU core count and memory size are greater than the current one.
  • You can also modify the instance offering of Windows VM instances when they are running or powered off. The method is the same as that of Linux VM instances.
    Note: We recommend that you do not modify the number of CPU cores and memory size of a Windows VM instance in a production environment.
 Running/Stopped
Set GPU Specification Set the GPU specification for a VM instance.
  • Set pGPU specification: Attach a physical GPU (pGPU) specification to a VM instance, or modify its current pGPU specification.
    • You cannot set the pGPU specification for a running VM instance.
    • After you modify the pGPU specification of a VM instance, the VM instance attaches pGPU devices with the new pGPU specification when it starts the next time. Meanwhile, the pGPU devices related to the original pGPU specification will be detached.
    • When you set the pGPU specification, you can enable or disable the Auto Detach GPU Device mechanism as needed.
      • By default, Auto Detach GPU Device is disabled. That is, the attached pGPU devices are still on the VM instance after it is powered off.
      • If enabled, the VM instance automatically detaches the attached pGPU devices (if any) when it is powered off.
      Note: If you turn off the switch, NeverStop VM instances to which the GPU offering is attached will not restarted after being stopped.
  • Set vGPU specification: Attach a virtual GPU (vGPU) specification to a VM instance, or modify its current vGPU specification
    • You cannot set the vGPU specification for a running VM instance.
    • After you modify the vGPU specification of a VM instance, the VM instance attaches vGPU devices with the new vGPU specification when it starts the next time. Meanwhile, the vGPU devices related to the original vGPU specification will be detached.
    • When you set the vGPU specification, you can enable or disable the Auto Detach GPU Device mechanism as needed.
      • By default, Auto Detach GPU Device is enabled. That is, the VM instance automatically detaches the attached vGPU devices (if any) when it is powered off.
      • If disabled, the attached vGPU devices are still on the VM instance after it is powered off.
      Note: If disabled, NeverStop VM instances to which the GPU offering is attached will not restarted after being stopped.
  • No set: The VM instance does not attach GPU specifications.
    • In this case, VM instances without a GPU specification attached do not attach other GPU specifications, and VM instances with GPU specifications attached will detach these GPU specifications.
    • You cannot detach GPU specifications for a running VM instance.
 Stopped
Resize Root Volume Expand the root volume size of a VM instance.
  • You can expand the root volume size of a VM instance when the it is running or stopped. The new size takes effect immediately.
  • The new size must be larger than the current size. The increment must be equal to or larger than 4 MB. Unit: MB, GB, and TB.
  • The new size must be a multiple of 4 MB. For example, if you enter a size of 37 MB, the actual size is 40 MB.
  • You can specify whether to automatically create a snapshot of the VM root volume upon resizing for all VM instances in the Cloud. Method: in the Global Setting, set Snapshot Auto-Creation upon Volume Resizing as true. Default:false
  • The setting of a single VM instance complies with that in the Global Setting.
 Running/Stopped
Change Owner Change the owner of a VM instance.
Note: Changing a VM owner detaches all of the tenant tags on this VM instance. Admin tags are not affected.
 Running/Stopped
Change System Change the system of a VM instance.
  • Before you change the system, stop or power off the VM instance first. The new system takes effect after the VM instance reboots.
  • Make sure that the type of the destination image is Image.
Note:
  • Changing the operating system expunges the root volume. Please back up the root volume data to avoid data loss.
  • If the VM instance has a data volume attached, changing the operating system across platforms (for example, change a Linux OS to a Windows OS) may cause the partition format of the data volume unable to be correctly identified.
 Stopped
Reimage VM Instance Restore a VM instance to the initial state of the VM image and overwrite all the data in the root volume.
  • Before you reimage a VM instance, stop or power off the VM instance first. The change takes effect after the VM instance reboots.
  • VM instances created by using ISO cannot be reimaged.
Note: Please back up the original root volume data in advance to avoid data loss.
 Stopped
Set Boot Order Set a boot order for a VM instance.
  • This setting takes effect after the VM instance reboots.
  • If a VM instance is created from an ISO image, the VM CD ROM boots first after the VM instance is created.
  • If you attach an ISO to an existing VM instance, the default boot order is as follows:
    1. First boot order: Hard disk
    2. Second boot order: CD ROM
  • If you want the VM instance to boot from its network, set the first boot order to Network.
  • If you set the first boot order of a running VM instance to CD ROM or Network, the setting takes effect after you reboot the VM instance or start the VM instance after you stop it. If you reboot the VM instance by using the reboot command, the VM instance still boots from Hard Disk next time.
 Running/Stopped
Boot from Host Specify a host on which a VM instance boots.
  • After you stop a VM instance that uses a shared storage, you can specify a host on which the VM instance boots.
  • After you stop a VM instance that uses a LocalStorage primary storage, the VM instance can boot only from the host where the VM root volume is located.
Note: If a VM instance is associated with a VM scheduling policy, it is scheduled primarily based on the policy. You cannot specify a host for the VM instance to run.
 Stopped
Set VM HA Set the high availability (HA) mode for a VM instance.
  • VM HA modes:
    • None: Disables VM HA. The VM instance does not reboot automatically after either a scheduled or an unexpected stop.
    • NeverStop: Enables VM HA. The VM instance attempts to reboot automatically after it is stopped due to its own fault or the errors of the compute, storage, or network resources it is residing on.
  • When a VM instance is shut down due to exceptions, the VM HA can trigger automatic VM reboot to improve the VM availability.
  • If hosts are running properly, VM instances with HA enabled can reboot automatically in case of an abnormal shutdown.
  • If hosts are abnormal or enter the maintenance mode, VM instances using a LocalStorage primary storage and with HA enabled cannot reboot automatically after an abnormal shutdown.
  • If hosts are abnormal or enter the maintenance mode, VM instances using a shared storage and with HA enabled can reboot automatically in case of an abnormal shutdown.
    Note:
    • The VM instance does not HA reboot if it is stopped manually or through a scheduled job.
    • If you choose NeverStop, make sure that you have enabled HA Policy in Platform Setting. Otherwise, the NeverStop mode does not take effect.
 Running/Stopped
Sync with Host BIOS Time Set Windows VM time to sync with the host BIOS time. If enabled, Windows VM time is the same as that of the host. By default, the sync is enabled.
Note:
  • If you enable the sync for a Windows VM instance, the VM time is synchronized with the host BIOS time automatically.
  • If you disable the sync for a Windows VM instance, the VM time is not synchronized with the host BIOS time.
  • If you modify this setting for a Windows VM instance, the change takes effect after the VM instance reboots.
  • This setting does not take effect on Linux VM instances.
  • You can enable Sync Host BIOS Time in Global Setting for all Windows VM instances in the Cloud. Method: in Global Setting, set Sync with Host BIOS Time to Sync. By default, the time sync global setting is enabled.
  • If you specifically set time sync for a Windows VM instance, the global setting does not take effect on this VM instance.
 Running/Stopped/Paused
Set Hide KVM Hypervisor Signature Set whether to hide the KVM hypervisor signature for a single VM instance. If set to true, <hidden state='on'> is inserted under <kvm> in the XML definition of a newly started VM instance. If set to false, it is not inserted.
Note:
  • If this setting is configured for a VM instance, the global setting and cluster advanced setting do not take effect on the VM instance.
  • Restart the VM instance for the change to take effect.
  • Enable this setting for NVIDIA GPU scenarios as needed.
 Running/Stopped/Paused
Sync with Host System Time Set VM time to sync with the host system time. If enabled, the VM time is the same as that of the host system. By default, the sync is disabled.
Note:
  • Before you enable the sync, make sure that Qemu Guest Agent (QGA) is installed and running on the VM instance.
  • Before you enable the sync, we recommend that you disable other time servers configured for the VM instance.
  • If you enable the sync for a VM instance, the VM time is synchronized with the host system time automatically every 60 seconds.
  • If you disable the sync for a VM instance, the VM time is not synchronized with the host system time.
  • You can enable this time sync in Global Setting for all VM instances in the Cloud. To enable this time sync in Global Setting, turn on the Sync with Host System Time switch. By default, the time sync global setting is disabled.
  • If you specifically set this time sync for a VM instance, the global setting does not take effect on the VM instance.
Set Error Policy Set the error policy for a VM instance, including error inspection and error handling.
  • Error Inspection
    • You can enable error inspection for a running VM instance.
      • By default, error inspection is disabled. If enabled, reboot the VM instance to make the setting take effect. Note that you cannot reboot the VM instance through the VM console.
      • After you enable error inspection, if a VM instance crashes, the system automatically handles the error according to the specified error handling policy. In addition, the VM Crash alarm is triggered.
        • You can view the error alarms of the VM instance on the Alarm Message page.
        • You can also customize the VM Crashed alarm as needed.
    • You can enable error inspection for all VM instances in the Cloud. Method: In the Global Setting, set Error Inspection to true. Default: false.
    • You can also enable error inspection for a single VM instance. Then, the VM instance is not affected by the setting in the Global Setting.
    Note:
    • Before you enable error inspection for a VM instance, make sure that the VM instance has the latest version of GuestTools installed and the GuestTools is in the running state.
    • If you enable error inspection for a Linux VM instance, the kdump module is disabled after you reboot the instance.
  • Error Handling
    • After you enable error inspection, you can set an error handling policy for the VM instance. Supported policies:
      • Preserve (Default): Errors occurred on a VM instance, such as blue screen of a Windows-based VM instance or Linux VM instance crash, are not handled.
      • Reboot: After a VM error occurs, such as blue screen of a Windows VM instance or the crashed state of a Linux VM instance, the VM instance reboots automatically.
        • If the number of reboots reaches the threshold and the VM instance does not reboot successfully within the specified time, the VM instance does not reboot again.
        • You can set the Restart Policy Upon Error in the Global Setting. By default, the VM instance reboots up to five times within 30 minutes. If the VM instance is not rebooted after five attempts within 30 minutes, the VM instance remains crashed.
      • Shutdown: After a VM error occurs, such as blue screen of a Windows VM instance or the crashed state of a Linux VM instance, the VM instance shuts down automatically.
    • The error handling policy takes effect immediately without the need of rebooting the VM instance.
    • You can set the error handling policy for all VM instances in the Cloud. Method: In the Global Setting, enable Error Inspection and set an error handling policy as needed.
    • You can also set the error handling policy for a single VM instance. This setting is not affected by that in the Global Setting.
    Note:
    • If you pause or stop a VM instance, the GuestTools on the VM instance will be stopped. In this case, you cannot set the error handling policy for the VM instance.
    • If you restore a paused VM instance, start a stopped VM instance, or reboot a running VM instance, the GuestTools on the VM instance will be rebooted automatically. In this case, you can set the error handling policy for the VM instance. Note that a delay might occur during the starts or reboots.
 Running
Attach SSH Key Attach an SSH public key to a VM instance. Then, you can SSH into the VM instance with the corresponding private key.
Note:
  • Make sure that the VM instance satisfies the following requirements:
    • The VM instance runs a Linux operating system.
    • The VM instance is running.
    • The VM instance has a Qemu Guest Agent (QGA) installed and the QGA is running. You can install the QGA by installing the GuestTools for the VM instance. If you install through other methods, make sure that the QGA you use is of 2.5 or later versions.
  • Currently, you can access a VM instance with an SSH key only as a root user.
 Running
Detach SSH Key Detach the SSH key from the VM instance.
Note: Make sure that the VM instance satisfies the following requirements:
  • The VM instance is running.
  • The VM instance has a Qemu Guest Agent (QGA) installed and the QGA is running. You can install the QGA by installing the GuestTools for the VM instance. If you install through other methods, make sure that the QGA you use is of 2.5 or later versions.
 Running
Change VM Password Change the username/password of a VM instance.
  • You can change the VM username/password when the VM instance is running. The change takes effect immediately.
  • You can enter letters, digits, and special characters. Supported special characters include -`=[];',./~!@#$%^&*()_+|{}:"<>?.
  • Before you change the password of a VM instance, make sure that:
    • The VM instance is running.
    • The VM instance has a QEMU guest agent (QGA) installed, and the QGA is running properly. In addition, make sure that the QGA is enabled on the VM details page.
  • You can change the password of VM instances that are created from the following images:
    • CentOS 7.x/6.x (32 bit/64 bit)
    • Ubuntu 16.x/15.x/14.x/13.x/12.x (64 bit)
    • Windows 2003/2008/7/10/2012/2016 (64 bit)
Note:
  • If you fail to change the password of a VM instance, check whether the VM instance has a QGA installed, and then enter the terminal to manually check whether the QGA running status is normal.
  • If you can change the password of a VM instance, the password-change feature can be inherited by the image created and the VM cloned from this VM instance.
 Running
Set VM Console Password Set a console password or cancel the console password for a VM instance.
  • After you set or cancel a console password, reboot the VM instance to make the setting take effect.
  • The password is the VNC protocol password, not the password of the VM instance.
  • If you set a console password, you can enter letters, digits, and special characters. Supported special characters include -`=[];',./~!@#$%^&*()_+|{}:"<>?.
  • You can set the console password strength for all VM instances in the Cloud. Method: In the Global Setting, enable VNC Console Password Strength Policy, and set the password strength.
    • The default password length is 6 to 8 characters. A console password can contain at least 6 characters and at most 32 characters.
    • A console password can contain a combination of digits, letters, and special characters.
  • The console password strength policy of a single VM instance complies with that specified in the Global Setting.
 Running/Stopped
Toggle Console Mode Toggle the console mode for a VM instance. The console mode includes VNC, SPICE, and VNC+SPICE.
  • The toggle action takes effect after the VM instance reboots.
  • You can set the console mode for all VM instances in the Cloud. Method: In the Global Setting, edit Console Mode. Default: VNC.
  • You can also set the console mode for a single VM instance. This setting is not affected by that specified in the Global Setting.
 Running/Stopped/Paused
Resource Priority Set the resource priority for a VM instance.
  • Options: Normal and High. Default: Normal.
  • When resource contention occurs due to high host workloads, VM instances with High resource priority can compete for more resources than those with Normal resource priority.
Note:
  • We recommend that you set a High resource priority for only vital VM instances.
  • VPC vRouters have a higher resource priority than VM instances.
  • When resource contention occurs, the resource priority is as follows: VM instances with Normal priority < VM instances with High priority < VPC vRouters.
  • For example, when resource contention occurs due to high host workloads, VPC vRouters can compete for more CPU resources than VM instances.
  • If you use the performance-dedicated load balancing service, the corresponding load balancer instances have the same resource priority as the VPC vRouters.
 Running/Stopped/Paused
Bind with Cluster

Choose whether to make the VM instance bound to the cluster it is residing on.

  • If set to true, the VM cross-cluster migrations are restricted. You can further define which migration operations are restricted through the cluster setting Resource Binding Policy.
    • Soft Binding: this policy makes the VM instance be migrated only among the current cluster if the migration is triggered automatically by the VM HA or by a host maintenance mode. Migrations that are triggered manually are not limited by the cluster scope, such as manual VM migrations (Change Host).
    • Hard Binding: this policy makes the VM instance always run in the current cluster, and all cross-cluster migrations are denied, including the migrations triggered automatically and manually.
  • If set to false, the VM instance is not bound to the current cluster and allows cross-cluster migrations that are either triggered automatically, like triggered by the VM HA, or manually.
 Running/Stopped/Paused
USB Redirection Set USB redirection for a VM instance.
  • If you need the VDI feature, you can redirect the USB device on the VDI client to a VDI VM instance.
  • The redirection action supports multiple USB devices.
  • To make the redirection take effect, reboot your VM instance.
 Running/Stopped/Paused
Create Snapshot Create a snapshot for a VM instance.
  • Before you perform a business-sensitive operation, you can create a snapshot for a VM instance to record the state of its root volume, data volume, and VM memory. This allows rollback in case of breakdowns.
  • You can create a single snapshot or a snapshot group.
    • Single snapshot: A single snapshot is the snapshot of the VM root volume.
    • Snapshot Group: A snapshot group consists of the root volume snapshot, the snapshots of attached data volumes, and the snapshot of the VM memory. You can revert a snapshot group.
Note:
  • You cannot create snapshots of the shared volumes created on SharedBlock or Ceph primary storage.
  • In the production environment, we recommend that you create no more than five snapshots for a volume. Too many snapshots will lower the VM I/O performance, decrease data security, and occupy storage space of the primary storage. To back up data for the long term, you can use the backup service.
  • In the production environment, to ensure data integrity, we recommend that you do not create snapshots for high-I/O VM instances. If you create snapshots for a VM instance performing high-I/O operations, some data in the memory might fail to be saved to the hard disk and thus cannot be saved in the snapshot.
  • Currently, you could not create memory snapshots for VM instances that use Ceph primary storage.
  • Before you can create a memory snapshot, make sure that the VM instance is in the running state.
  • Before you can create a memory snapshot, detach the peripheral devices (if any) from the VM instance first.
  • When you create a memory snapshot, to ensure memory consistency, the VM instance will be in the paused state for seconds.
 Running/Stopped/Paused
Create Backup Create a backup for a VM instance.
  • If the authorized quota of the backup service is insufficient, no backup job can be created.
    Note: Resources that are already within the authorized quota of the backup service can normally create backups or associate backup jobs.
  • Before you create a backup for a VM instance, make sure that the VM instance is in the running state.
  • You can create a full backup or an incremental backup for a VM instance.
  • You can create a backup for a VM instance with its volumes.
  • You cannot create a backup for the shared volumes (if any) attached to the VM instance.
  • Before you create a backup, add a local backup service to the Cloud in advance.
  • You can synchronize the backup data to a remote backup server. Note that you need to add a remote backup server to the Cloud in advance.
 Running
Associate Backup Job Associate a backup job with a VM instance.
  • You can associate backup jobs with VM instances whose backup type is None only.
  • If the authorized quota of the backup service is insufficient, no backup job can be associated.
    Note: Resources that are already within the authorized quota of the backup service can normally create backups or associate backup jobs.
  • Before you associate a backup job, make sure that the VM instance is in the running or paused state.
 Running/Paused
Attach Volume Attach an available data volume to a VM instance.
Note:
  • You can attach up to 24 data volumes to a VM instance.
  • In the LocalStorage scenarios, the VM instance and the volume to be attached must be on the same host. If not, migrate the volume to the host where the VM instance is located and then attach the volume to the VM instance.
  • To attach a VirtIO volume to a VM instance, make sure that the VM instance has the VirtIO driver installed.
    • Mainstream Linux distributions such as CentOS 6 and CentOS 7 are integrated with VirtIO drivers. Therefore, you do not need to install them again.
    • For Windows VM instances, you need to install VirtIO drivers manually.
  • If the volume and instance belong to different owners, the newly added tenants might could not view the volumes and be restricted when perform relevant operations on the instance.
  • You cannot attach volumes to a VM instance with a memory snapshot. Perform this operation after you delete the memory snapshot.
 Running/Stopped
Detach Volume Detach a volume from a VM instance.
Note:
  • Detaching a volume interrupts the data reads/writes of the volume and might affect the business continuity. Please exercise caution.
  • If the VM instance has a memory snapshot and the volume to be detached is referenced by the memory snapshot, you could not detach the volume from the VM instance. You can try again after you delete the memory snapshot.
 Running/Stopped
Create Image Create a template image based on a custom VM instance so that you can use it to create VM instances with same configurations in bulk.
  • To ensure application integrity, we recommend that you power off the VM instance before you create a VM image.
  • You can create either a system image or a volume image.
    • System image is created from the VM root volume. It can be used to create only VM instances.
    • Volume image is created from the VM root volume. It can be used to create only volumes.
 Running/Stopped
Attach ISO Attach an ISO to a VM instance.
  • The ISO are attached in sequence of the VM virtual drive name.
  • By default, a VM instance can attach up to three ISOs. Bulk attachment is not supported.
  • You can set the maximum number of virtual drives a VM instance can attach for all VM instances in the Cloud. Method: In the Global Setting, set the value of Maximum Virtual Drive. Valid values: 1, 2, and 3.
  • The maximum number of virtual drives that can be attached to a single VM instance is controlled by the setting in the Global Setting.
Note: If the number of virtual drives attached by a VM instance has exceeded the setting in the Global Setting, the Global Setting does take effect for this VM instance.
 Running/Stopped
Detach ISO Detach an ISO from a VM instance.
Note: Detaching an ISO from a running VM instance might affect the business continuity. Please exercise caution.
 Running/Stopped
Add to VM Scheduling Group Add a VM instance to a VM scheduling group. After the addition, the scheduling policies associated with the group take effect on the VM instance immediately. Running/Stopped
Remove from VM Scheduling Group Remove a VM instance from a VM scheduling group. After the removal, the VM instance will no longer be scheduled based on scheduling policies associated with the group. Running/Stopped
Export VM Instance Export a VM instance to a backup storage. After the VM instance is exported, you can view and download the exported file on the Exported tab of this VM instance.
Note:
  • You can export the VM instance only to an ImageStore backup storage.
  • The OVA template of the exported VM instance does not include ISO drivers or GPU devices.
  • If the VM instance has been exported before, delete the export record before you can export it again.
 Stopped
Delete VM Instance Deleting a VM instance releases the associated CPU, memory, and IP address. The deleted VM instance is put into Recycle Bin.
  • Recycle Bin displays deleted VM instances in a list view.
  • By default, a VM instance in the recycle bin is expunged 7 days after the deletion.
  • You can set a deletion policy for all VM instances in the Cloud. Method: In the Global Setting, set Instance Deletion Policy. Options:
    • Direct: If you delete a VM instance, the VM instance is deleted at once.
    • Delay: If you delete a VM instance, the VM instance is marked as deleted and listed on the Recycle Bin tab. The default retention period of deleted VM instances is 7 days. When the retention period expires or if you expunge a deleted VM instance, the VM instance is completely deleted.
    • Never: If you delete a VM instance, the system does not automatically expunge the deleted VM instance.
Note: You can delete a VM instance with all attached volumes except for shared volumes.
  • If the VM Anti-Accidental-Deletion Mode is enabled in Global Setting, this action can be exercised on only VM instances in Unknown or Stopped States.
  • If the VM Anti-Accidental-Deletion Mode is disabled in Global Setting, this action can be exercise on VM instances in any states.
Expunge/Recover VM Instance You can completely delete or recover a VM instance in the recycle bin.
  • Expunging a VM instance also expunges resources associated with the VM instance. This operation is irreversible. Please exercise caution.
  • After a VM instance is expunged, its IP address will return to the IP address pool.
  • After a VM instance is recovered, the VM instance is displayed on the Available tab and is in the stopped state. You can choose whether to boot the VM instance after its recovery as needed.
  • After a VM instance is recovered, the Cloud allocates a new IP address to the VM instance.
  • After a VM instance is recovered, it goes to the group it affiliated to before it was deleted. If the original group has been deleted, the VM instance goes to the default group.
 Deleted
Copy URL Copy the URL of an exported VM instance. Running/Stopped/Paused
Download exported VM Instance Download an exported VM Instance to your local PC. Running/Stopped/Paused
Delete Export Record Delete the export record of a VM instance. Running/Stopped/Paused

VM Details

VM CPU Mode

The VM CPU mode specifies whether to select the same CPU model as the host for a VM instance.

VM CPU Architecture VM CPU Mode VM CPU Model for Cluster Description Note
x86_64 Inherit Cluster Setting (by default)
  • The CPU model of the VM instance is consistent with the VM CPU model of the cluster where the VM instance resides.
 none (by default) The CPU model of VM instances in the cluster is simulated via QEMU. In this mode, the VM instances inherit necessary host CPU features to a small degree. You can select this mode if you need to migrate your VM instances.
  • If you select host-passthrough, VM instances will allow for virtualization. However, if you migrate a VM instance to a host whose CPU model is different from the current host, the migration may fail. In addition, the CPU utilization of the VM instance measured within the instance may differ from the CPU utilization measured from the host.
  • Hygon_Customized is virtualized CPU model designed only for compating OS of eariler versions.
  • If you specifically set the CPU model of an individual VM instance, the VM CPU model configured for the cluster or in the global settings will not take effect on that VM instance.
  • If you modify the CPU model, you need to restart the VM instance to make the modification take effect.
host-model The CPU model of VM instances in the cluster is similar to or same as that of the host, such as Haswell Intel CPU. In this mode, VM instances inherit many host CPU features. You can select this mode if you need to migrate VM instances.
host-passthrough The CPU model and CPU features of VM instances in the cluster are all the same as the CPU model and CPU features of hosts in the cluster. For example, both VM instances and hosts support the extended page table extension, huge page, and virtualization features. Compared with the none, host-model, and Custom modes, VM instances in this mode have the most CPU features. You can select this mode if your business requires many features.
Custom (a specified CPU model) VM instances in the cluster share the specified CPU model. Different CPU models may have different CPU features. Note that if your host CPU is Hygon and the OS of your VM instance is an earlier version such as Windows Server 2012 R2 and Windows Server 2008 R2, you can select Hygon_Customized.
none N/A The CPU model of VM instance is simulated via QEMU. In this mode, the VM instance inherits necessary host CPU features to a small degree. We recommend you select this mode if you need to migrate your VM instance.
host-model N/A The CPU model of the VM instance is similar to or same as that of the host, such as Intel Haswell CPU. In this mode, the VM instance inherits many host CPU features. You can select this mode if you need to migrate your VM instance.
host-passthrough N/A The CPU model as well as CPU features of the VM instance are the same as the CPU model and CPU features of the host. For example, both the VM instance and host support the extended page table extension, huge page, and virtualization features. Compared with the none, host-model, and Custom modes, VM instance in this mode has the most CPU features. You can select this mode if your business requires many features.
Custom (a specified CPU model) N/A The CPU model of the VM instance is set to the specified model. Different CPU models may have different CPU features. Note that if your host CPU is Hygon and the OS of your VM instance is an earlier version such as Windows Server 2012 R2 or Windows Server 2008 R2, you can select Hygon_Customized.
aarch64 Inherit Cluster Setting (by default)
  • The CPU model of the VM instance is consistent with the VM CPU model of the cluster where the VM instance resides.
 none (by default) The CPU model of VM instances in the cluster is simulated via QEMU. In this mode, the VM instances inherit necessary host CPU features to a small degree. You can select this mode if you need to migrate your VM instances.
host-model The CPU model of VM instances in the cluster is the same as that of the host. In this mode, VM instances inherit many host CPU features. You can select this mode if you need to migrate VM instances.
host-passthrough The CPU model as well as CPU features of VM instances in the cluster are all the same as the CPU model and CPU features of hosts in the cluster. Compared with the host-model and Custom modes, VM instances in this mode have most CPU features. You can select this mode if your business requires many features.
Custom (a specified CPU model) VM instances in the cluster share the specified CPU model. Different CPU models may have different CPU features.
host-model N/A The CPU model of the VM instance is similar to or same as that of the host. In this mode, the VM instance inherits many host CPU features. You can select this mode if you need to migrate your VM instance.
host-passthrough N/A The CPU model as well as CPU features of the VM instance are the same as the CPU model and CPU features of the host. VM instance in this mode has the most CPU features. You can select this mode if your business requires many features.
Custom (a specified CPU model) N/A The CPU model of the VM instance is set to the specified model. Different CPU models may have different CPU features.
mips64el A specified CPU model N/A The CPU model of the VM instance is set to the specified model.
loongarch64 A specified CPU model N/A The CPU model of the VM instance is set to the specified model.

VM Configurations

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. On the VM Instance page, click on the name of a VM instance. Then, the details page of the VM instance is displayed. Click on the Configuration Info tab page. Then, the Configuration Info tab page is displayed.

The Configuration Info tab page displays the configuration information about the VM instance in the form of a list.

Volume

This section displays a list of root volumes and data volumes detached from and attached to the VM instance. You can perform operations on these volumes as needed. The following table lists some actions that you can perform on a volume.
Action Description VM State
Set Root Volume Set a data volume attached by the VM instance as a root volume.
Note:
  • Before you can perform this operation, stop the VM instance attached by the data volume.
  • After you perform this operation, the volume type will be changed to root volume.
  • After you perform this operation, the original root volume will be changed to data volume and is still attached to the VM instance.
  • If a data volume is created from the image used by the root volume of the VM instance, these two volumes will share a disk partition with the same UUID. In this case, the system might not boot from the newly-set root volume.
  • If the data volume is referenced by the memory snapshot of a VM instance, you could not set the data volume as the root volume. You can delete the memory snapshot and try again.
 Stopped
Attach to Current VM Instance Attach a detached data volume to the VM instance again. Running/Stopped

NIC

This section displays a list of NICs attached to the VM instance. You can perform operations on these NICs as needed. The following table lists the actions that you can perform on a NIC.
Action Description VM State
Enable NIC Enable a disabled NIC. All NIC configurations are kept same before and after the enablement.
Note: You can only enable NICs of the vNIC type.
Running/Paused/Stopped
Disable NIC Disable an NIC. After the disablement, the Cloud will keep all NIC configurations.
Note:
  • You can only enable NICs of the vNIC type.
  • Disabling an NIC will make related network disconnected and may interrupt your application workloads. Proceed with caution.
Running/Paused/Stopped
Attach NIC Attach an NIC to the VM instance.
  • You can set a default network for the VM instance.
  • You can enable SR-IOV for the VM instance. If enabled, the VM instance will have a VF NIC attached. If not enabled, the VM instance you create will have an NIC of the vNIC or vDPA attached based on your actual environment.
  • You can set an IPv4 or an IPv6 address for the NIC.
Note:
  • To enable SR-IOV, note the following:
    • Only IPv4 networks support SR-IOV. IPv6 and IPv4+IPv6 networks do not support SR-IOV.
    • Make sure that SR-IOV network acceleration mode is used for the L2 network from which the L3 network is created. Otherwise, SR-IOV cannot be enabled.
    • Make sure that the physical NICs on the corresponding L3 network have available VF NICs. Otherwise, you might fail to enable SR-IOV.
    • If the VM instance is using a public network or flat network, the VM NIC does not support security groups and elastic IP addresses after SR-IOV is enabled.
    • If the VM instance is using a VPC network, the VM NIC does not support security groups after SR-IOV is enabled.
  • If you attach an NIC of the vDPA type to a VM instance, note that:
    • Before you use vDPA NIC, make sure:
      • Network acceleration support is enabled for the associated cluster.
      • The L2 network attached to the cluster uses the Smart NIC network acceleration mode.
      • Hosts in the cluster have smart NICs of the specified model. Supported model includes Mellanox CX-5 and Mellanox CX-6.
      • SR-IOV is enabled in the BIOS.
    • You can attach vDPA NICs only to VM instances that are in IPv4 VPC networks.
    • vDPA NICs support all VPC network services excluding security group and port forwarding.
 Running/Stopped
Detach NIC Detach a NIC from the VM instance.
Note:
  • Detaching a NIC affects the network connectivity of the VM instance and disassociates other associated network services. Please exercise caution.
 Running/Stopped
Set NIC Type Change the NIC type from a VF NIC to a vNIC.
Note:
  • Before you can set the NIC type, stop the VM instance.
  • Only VF NICs can be changed to vNICs.
 Stopped
Set MAC Set a MAC address the VM NIC.
Note:
  • Before you set a MAC address, stop the VM instance.
  • If NIC information is contained in the memory snapshot of the VM instance, after you change the MAC address, the NIC information might be changed when you revert the memory snapshot. Please exercise caution.
 Stopped
Set the NIC Model Set the NIC model for the VM instance. supported VM NIC models: virtio, rtl8139, and e1000.
Note:
  • Before you can set the NIC model, stop the VM instance.
  • Before you set a NIC model, make sure that you installed a NIC driver that matches the NIC model. Otherwise, network exception may occur to the VM instance.
  • Creating VM images and V2V migrations do not inherit configurations associated with the NIC model.
  • Only Linux and Paravirtualization operating systems are supported.
 Stopped
Set NIC QoS Set the upstream bandwidth and downstream bandwidth of the VM NIC.
  • To set the NIC QoS, either the upstream bandwidth or downstream bandwidth is required. Bandwidth range: 8 Kbps – 60 Gbps. Unit: Kbps, Mbps, and Gbps.
  • If not set, both the upstream and downstream bandwidth is not limited.
 Running/Stopped
Set Network and IP Address Modify the network or IP address used by the VM NIC.
  • Allows you to modify the L3 network and IP address used by the NIC. You can make the modification when the VM instance is running or stopped. If the VM instance is running, the network type cannot be changed.
  • Different networks support different IP allocation methods:
    • A network enabled with IP Address Management supports two IP allocation methods: Assign IP and By IP Allocation Policy.
    • A network disabled with IP Address Management supports only Assign IP. Or, you can configure an IP address in the VM operating system. The IP address configured in the VM operating system can be read to the Cloud through the VM GuestTools.
  • After the modification, you can make it take effect through VM GuestTools or by restarting the DHCP service:
    • Through VM GuestTools:
      • If the VM instance has GuestTools installed, the network and IP address settings are automatically deployed to the NIC.
      • If the VM instance does not have GuestTools installed, you can install one after the modification and sync NIC configurations on the VM NIC action list.
    • By restarting DHCP service:
      • Linux VM instance:
        • If the network is not managed by NetworkManager, run the following command: dhclient -r ${ifname}; dhclient ${ifname}
        • If the network is managed by NetworkManager, run the following command: nmcli c up ${ifname}
      • Windows VM instance: Enter the command line tool and run the following command: ipconfig /release && ipconfig /renew
      • Restarting DHCP service interrupts the VM network temporarily. The network auto-resumes after the DHCP service is restarted successfully.
        • This method does not apply to L3 networks disabled with DHCP service.
 Running/Stopped
Set Security Group Attach/Detach security groups to/from the VM NIC. And set a default policy for flows that are not stipulated by the security groups.
Note:
  • If the NIC is in Disabled state, you need to enable the NIC to make the attachment take effect.
  • You can attach one or more security groups to a VM NIC and set priorities to them. The NIC matches the rules of the group with the highest priority first, and then the group of lower priorities. By default, all admin security groups must have priorities higher than those of user security groups.
  • After you attach security groups to a VM instance, all flows that access the VM NIC and are not stipulated by security groups are rejected, and all flows that are out of the VM NIC and not stipulated by security groups are allowed by default . You can manually modify this default policy here.
  • As an administrator, you can attach a security group either owned by administrators or by the owner of the current VM instance to the NIC. Note that
    • The priorities of an administrator security group must be higher than those of security groups owned by others.
    • The administrator security groups are invisible to tenants and sub-accounts.
  • As a tenant or sub-account, you can attach only security groups owned by yourself to the NIC.
 Running/Stopped
Set Default Network Set a default network for the VM instance if the VM instance has multiple NICs.
Note: Reboot the VM instance to take effect.
 Running/Stopped
Attach EIP Attach an EIP to the VM NIC.
Note: If the NIC is in Disabled state, you need to enable the NIC to make the association take effect.
 Running/Stopped
Detach EIP Detach an EIP from the VM NIC. Running/Stopped
Synchronize Configurations Deploys and updates NIC configurations according to the parameters you set on the Cloud, including IP address, netmask, gateway, DNS, and MTU.
Note:
  • If the L3 network the NIC resides on is disabled with IP Address Management, you need to manually specify an IP address and a gateway for the NIC before you can sync the DNS service.
  • To sync NIC configurations, install GuestTools of the latest version for the VM instance in advance.
  • This action overwrites the original NIC configurations. Proceed with caution.
 Running

vDrive

This section displays a list of virtual drives (vDrives) attached to the VM instance. You can perform operations on these vDrives as needed. The following table lists the actions that you can perform on a vDrive.
Action Description VM State
Create vDrive Create a vDrive for the VM instance.
Note:
  • Before you create vDrive, stop the VM instance first.
  • A VM instance can have up to three vDrives. You can change the maximum of vDrives that can be created for a VM instance globally. Method: In the Global Setting, modify Maximum Virtual Drive. Valid values: 1, 2, and 3.
 Stopped
Set as Default Drive Set a vDrive for the VM instance if the VM instance has multiple vDrives.
Note:
  • Before you perform this operation, stop the VM instance first.
  • If you change the default drive, note that:
    • The serial number of the vDrive will be changed, thus affecting the mapping between the device name and ISO.
    • For example, assume that you have three vDrives: CDROM-1, CDROM-2, and CDROM-3. If you make CDROM-2 default, CDROM-2 and the loaded ISO become CDROM-1, and the original CDROM-1 becomes CDROM-2.
 Stopped
Delete vDrive Delete a vDrive.
Note:
  • Before you can delete a vDrive, stop the VM instance.
  • After you delete a vDrive, the serial number of the remaining vDrives will be updated in order.
    • For example, assume that you have three vDrives: CDROM-1, CDROM-2, and CDROM-3. If you delete CDROM-2, CDROM-3 and the loaded ISO becomes CDROM-2.
 Stopped

LUN

This section displays a list of LUNs passed through from SAN storages to the VM instance. You can perform operations on these LUNs as needed. The following table lists the actions that you can perform on a LUN.
Action Description VM State
Attach LUN Pass through a LUN provided by an iSCSI or FC storage to the VM instance directly as a storage medium.
Note:
  • You cannot attach a LNU that has been used by a SharedBlock primary storage.
  • To attach a LUN provided by an iSCSI storage, attach the iSCSI storage to the cluster that the VM instance reside on in advance.
  • One VM instance can attach more than one LUNs, and a LUN can be attached to more than one VM instances.
 Running/Stopped
Detach LUN Detach a LUN from the VM instance.
Note: This operation interrupts the data reads/writes and may affect the business continuity. Please exercise caution.
 Running/Stopped

pGPU Device

This section displays a list of physical GPU (pGPU) devices passed through from hosts to the VM instance. You can perform operations on these pGPU devices as needed. The following table lists the actions that you can perform on a pGPU device.
Action Description VM State
Attach pGPU Device Pass through a pGPU device to a VM instance directly.
Note:
  • One VM instance can attach multiple pGPU devices.
  • Currently, you cannot attach pGPU devices and vGPU devices to the same VM instance at the same time.
 Running/Stopped
Detach pGPU Device Detach a pGPU device from the VM instance.
Note: This operation might affect the business continuity. Please exercise caution.
 Running/Stopped

vGPU Device

This section displays a list of vGPU devices passed through from hosts to the VM instance. You can perform operations on these vGPU devices as needed. The following table lists the actions that you can perform on a vGPU device.
Action Description VM State
Attach vGPU Device Pass through a vGPU device to a VM instance directly.
Note:
  • Before you can attach a vGPU device to a VM instance, stop the VM instance first.
  • A VM instance can only attach one vGPU device at a time.
  • Currently, you cannot attach pGPU devices and vGPU devices to the same VM instance at the same time.
 Stopped
Detach vGPU Device Detach a vGPU device from the VM instance.
Note: Before you detach a vGPU device from a VM instance, stop the VM instance first.
 Stopped

USB Device

This section displays a list of USB devices passed through from hosts to the VM instance. You can perform operations on these USB devices as needed. The following table lists the actions that you can perform on a USB device.
Action Description VM State
Attach USB Device Pass through a USB device to a VM instance directly. The following two attach modes are supported:
  • Passthrough: Attach a USB device from the host where the VM instance is located to the VM instance. If you want to migrate the VM instance, detach the USB device first.
  • Forward: Attach a USB device from the host that is in the same as the VM instance to the VM instance. If you want to migrate the VM instance, do not detach the USB device.
Note: To attach a USB device to a VM instance, note the following:
  • You can attach a USB device to only one VM instance.
  • A VM instance can have a maximum of 1 USB 1.x device, 6 USB 2.x devices, and 4 USB 3.x devices attached.
  • For VM instances in the running state or VM instances using LocalStorages and are in the stopped state, you can attach only available USB devices on the hosts where these VM instances are located. In this case, you cannot attach USB devices across hosts.
  • For VM instances using shared storages and are in the stopped state, you can attach multiple USB devices on a host in the same cluster with the VM instance.
 Running/Stopped
Detach USB Device Detach a USB device from the VM instance.
Note: This operation interrupts the data reads/writes on the USB device. Please exercise caution.
 Running/Stopped

Other Device

This section displays a list of other PCI devices, such as Ali-NPU cards, IB cards (PCI mode), and FPGA cards, passed through from hosts to the VM instance. You can perform operations on these PCI devices as needed. The following table lists the actions that you can perform on a PCI device.
Action Description VM State
Attach Other Device Pass through a PCI device to the VM instance.
Note: To attach a PCI device to a VM instance, note the following:
  • You need to edit the allowlist of PCI devices and then add the target device to the allowlist.
  • After you edit the allowlist, reconnect to the host to take effect.
  • For details about how to customize the allowlist for other devices and how to pass through them, consult the official technical support.
 Running/Stopped
Detach Other Device Detach a PCI device from the VM instance.
Note: This operation might affect the business continuity. Please exercise caution.
 Running/Stopped

Advanced Settings

ZStack Cloud allows you to set the advanced parameters of a VM instance. This setting takes effect only for the VM instance. If not set, the values set in the Global Setting will be used by default.

The following table lists the advanced parameters that you can set for a VM instance.
Parameter Description
Instance Offering Online Modification
  • Specifies whether to enable Instance Offering Online Modification. Enabling Instance Offering Online Modification for a VM instance allows you to modify the CPU and memory of the VM instance online. By default, Instance Offering Online Modification is disabled.
  • This setting is available for VM instances that run CentOS 7.2, CentOS 6.6, Ubuntu 14.04, and Ubuntu 16.04.
  • We recommend that you do not modify the CPU and memory of VM instances online in production environments.
  • For Windows-based VM instances, we recommend that you stop these VM instance before you set the NUMA.
Hyper-V Virtualization Specifies whether to enable Hyper-V of a VM instance. By default, Hyper-V is disabled. Note that you can set Hyper-V for Windows-based VM instances only.
NIC Queue Number Set the number of queues when VirtIO NIC traffics are allocated to multiple CPUs. By default, the number of queues is consistent with the number of vCPUs of the VM instance and is 12 at maximum. For example, if the number of vCPUs of the VM instance and is 16, the default value is 12. Valid values: 1 to 256, integer.
VM Instance Hypervisor Specifies whether to enable the hypervisor tag for the VM CPU. Default: true. If set to false, the VM CPU hypervisor tag is disabled, which is used to skip virtualization environment detections from applications on the VM instance.
Memory Reclaim Monitors in real time the memory usage of VM instances and the host. If the workloads running on a VM instance decrease, the host reclaims unused memory of the VM instance. If the workloads running on a VM instance increase, the host allocates necessary memory space to the VM instance. This dynamic reclaim and allocation mechanism makes sure the efficient use of host memory. Default:false.
Note:
  • Before you enable memory reclaim, make sure that Hugepages is disabled for the cluster where the VM instance resides and vNUMA is disabled for the VM instance. In addition, make sure that GuestTools is installed on the VM instance.
  • If HA is enabled for the VM instance or if the instance is running an important application, we recommend that you do not enable memory reclaim.

External Monitoring

The External Monitoring tab displays the VM performance data, such as the CPU utilization, memory usage, disk speed, disk IOPS, NIC data transfer rate, NIC packet rate, and NIC packet discard rate, obtained from a host by using libvirt. These data is displayed dynamically in real time through graphs.
Note: You cannot view External Monitoring Statistics if the VM instance uses an SR-IOV VF NIC.

CPU Utilization

You can select a time span to view the real-time CPU utilization of a VM instance.
  • Available time spans: 15 minutes, 1 hour, 6 hours, 1 day, 1 week, 1 month, 1 year, and custom.
  • Monitoring metrics:
    • Select All: Displays the utilization of all CPUs and the average CPU utilization. The average utilization and utilization of different CPUs are displayed in different colors.
    • Average: Displays the average of all CPUs of a VM instance.
    • Specified CPU: Displays the utilization of a specified CPU. You can specify one or more CPU. The utilization of different CPUs are displayed in different colors.
Figure 15. CPU Real-Time Monitoring


Memory Usage

You can select a time span to view the real-time memory utilization of a VM instance.
  • Available time spans: 15 minutes, 1 hour, 6 hours, 1 day, 1 week, 1 month, 1 year, and custom.
  • Monitoring metrics:
    • Select All: Displays the used memory and free memory. The used memory and free memory are displayed in different colors.
    • Used: Display the used memory of the VM instance.
    • Free: Display the free memory of the VM instance.
Figure 16. Memory Real-Time Monitoring


Note:
You can also monitor the real-time usage of the VM memory by using the virsh dommemstat command provided by libvirt.
# Obtain the ID of the VM instance.
[root@localhost ~]# virsh list
 Id    Name                         State
----------------------------------------------------
 1     fe3790c408204c9998ccd6b54272fab1 running

# Obtain the real-time memory utilization of the VM instance. Unit: KB.
[root@localhost ~]# virsh dommemstat 1
actual 2097152
swap_in 0
swap_out 16
major_fault 698
minor_fault 686260
unused 23876
available 2048544
rss 2147224
Note: The memory data obtained by using internal monitoring is more accurate than that obtained by external monitoring. Therefore, we recommend that you use internal monitoring to monitor the memory data..

Memory Reclaim

You can select a time span to view the real-time memory reclaim of a VM instance.
  • Available time spans: 15 minutes, 1 hour, 6 hours, 1 day, 1 week, 1 month, 1 year, and custom.
  • Memory reclaim mechanism: Monitors in real time the memory usage of VM instances and the host. Its dynamic reclaim and allocation mechanism makes sure the efficient use of host memory:
    • If the workloads running on a VM instance decrease, the host reclaims unused memory of the VM instance.
    • If the workloads running on a VM instance increase, the host allocates necessary memory space to the VM instance.
    • Memory reclaim is triggered only after the host memory usage exceeds 80%.
Figure 17. Memory Reclaim Real-Time Monitoring


Disk Speed

You can select a time span to view the real-time disk read/write speed of a VM instance.
  • Available time spans: 15 minutes, 1 hour, 6 hours, 1 day, 1 week, 1 month, 1 year, and custom.
  • Monitoring metrics:
    • Select All: Displays the read and write speed of a disk. The read and write speed are displayed in different colors.
    • Read: Displays the read speed of a disk.
    • Write: Displays the write speed of a disk.
  • Monitoring object:
    • Select All: Display the read/write speed of all disk partitions. Read/write speed of different disk partitions are displayed in different colors.
    • Specified Disk Partition: Display the read/write speed of a specified disk partition. You can specify one or more disk partition. Read/write speed of different disk partitions are displayed in different colors.
Figure 18. Disk Speed Real-Time Monitoring


Disk IOPS

You can select a time span to view the real-time disk read/write IOPS of a VM instance.
  • Available time spans: 15 minutes, 1 hour, 6 hours, 1 day, 1 week, 1 month, 1 year, and custom.
  • Monitoring metrics:
    • Select All: Displays the read and write IOPS of a disk. The read and write IOPS are displayed in different colors.
    • Read: Displays the read IOPS of a disk.
    • Write: Displays the write IOPS of a disk.
  • Monitoring object:
    • Select All: Display the read/write IOPS of all disk partitions. Read/write IOPS of different disk partitions are displayed in different colors.
    • Specified Disk Partition: Display the read/write IOPS of a specified disk partition. You can specify one or more disk partition. Read/write IOPS of different disk partitions are displayed in different colors.
Figure 19. Disk IOPS Real-Time Monitoring


NIC Data Transfer Rate

You can select a time span to view the real-time NIC data transfer rate of a VM instance.
  • Available time spans: 15 minutes, 1 hour, 6 hours, 1 day, 1 week, 1 month, 1 year, and custom.
  • Monitoring metrics:
    • Select All: Displays the transfer speed of data out/in a VM NIC. The out/in rate are displayed in different colors.
    • Out: Displays the transfer speed of data out of a VM NIC.
    • In: Displays the transfer speed of data accessing a VM NIC.
  • Monitoring objects:
    • Select All: Displays the data transfer rate of all VM NICs. Rate of different NICs are displayed in different colors.
    • Specify NIC: Displays the data transfer rate of specified VM NICs. You can specify one or more NIC. Rate of different NICs are displayed in different colors.
Figure 20. NIC Data Transfer Rate Monitoring


NIC Packet Rate

You can select a time span to view the real-time NIC data packet transfer rate of a VM instance.
  • Available time spans: 15 minutes, 1 hour, 6 hours, 1 day, 1 week, 1 month, 1 year, and custom.
  • Monitoring metrics:
    • Select All: Displays the speed of data packet out/in a VM NIC. The out/in rate are displayed in different colors.
    • Out: Displays the transfer speed of data packets out of a VM NIC.
    • In: Displays the transfer speed of data packets accessing a VM NIC.
  • Monitoring objects:
    • Select All: Displays the packet rate of all VM NICs. Rate of different NICs are displayed in different colors.
    • Specify NIC: Displays the packet rate of specified VM NICs. You can specify one or more NIC. Rate of different NICs are displayed in different colors.
Figure 21. NIC Packet Rate Monitoring


NIC Packet Discard Rate

You can select a time span to view the real-time NIC packet discard rate of a VM instance.
  • Available time spans: 15 minutes, 1 hour, 6 hours, 1 day, 1 week, 1 month, 1 year, and custom.
  • Monitoring metrics:
    • Select All: Displays the discard rate of packets out/in a VM NIC. The discard rates of out/in packets are displayed in different colors.
    • Out: Displays the discard rate of packets out of a VM NIC.
    • In: Displays the discard rate of packets accessing a VM NIC.
  • Monitoring objects:
    • Select All: Displays the packet discard rate of all VM NICs. Discard rate of different NICs are displayed in different colors.
    • Specify NIC: Displays the packet rate of specified VM NICs. You can specify one or more NIC. Discard rate of different NICs are displayed in different colors.
Figure 22. NIC Packet Discard Rate Monitoring


Internal Monitoring

The Internal Monitoring tab displays the VM performance data, such as the CPU, memory, and disk capacity, obtained by the internal monitoring agent from a host. These data is displayed dynamically in real time through graphs.

Monitoring Mechanism

  • The internal monitoring data is obtained by the internal monitoring agent. To view the data, install an agent in advance. You can install GuestTools to install the internal monitoring agent for a VM instance. For detailed installation method, see Installation.
  • The obtained data is pushed to the host through the DHCP service of the L3 network or through the QEMU Guest Agent (QGA) contained in the VM GuestTools.
    • If the default network of the VM instance has the DHCP service enabled, the monitoring data is pushed by the DHCP service.
    • If the default network of the VM instance has the DHCP service disabled or the DHCP services fails, the monitoring data is then pushed by the QGA. After the DHCP service of the default network is recovered, the monitoring data is switched to be pushed by the DHCP service again.
Figure 23. Internal Monitoring Mechanism


Note:
  • If you use ZStack Cloud of a version before 4.7.0, you cannot make the monitoring data pushed by the QGA.
  • GuestTools for VM instances of certain operating systems does not contain QGA. For detailed information of GuestTools components for different VM operating systems, see Table 1。

Monitoring Data | CPU

You can select a time span to view the real-time CPU utilization of a VM instance.
  • Available time spans: 15 minutes, 1 hour, 6 hours, 1 day, 1 week, 1 month, 1 year, and custom.
  • Monitoring metrics:
    • CPU Occupancy Rate (System Process): The percentage of CPUs occupied by the current kernel space of the VM instance.
    • CPU Occupancy Rate (User Process): The percentage of CPUs occupied by the current user process of the VM instance.
    • CPU Occupancy Rate (Waiting): The percentage of CPUs used for waiting for the I/O operations of the VM instance.
    • CPU Idle Rate: The percentage of idle CPUs of the VM instance.
    • CPU Utilization: The percentage of used CPUs of the VM instance.
  • Monitoring object:
    • Select All: Display the average, real-time utilization of all CPUs of a VM instance and the utilization of a single CPU.
    • Average: Display the average, real-time utilization of all CPUs of a VM instance.
    • Single CPU: Display the real-time utilization of a single CPU, such as CPU No. 1, No.2, and No. 3.
Figure 24. CPU Real-Time Monitoring


Monitoring Data | Memory

You can select a time span to view the real-time memory utilization of a VM instance.
  • Available time spans: 15 minutes, 1 hour, 6 hours, 1 day, 1 week, 1 month, 1 year, and custom.
  • Monitoring metrics:
    • used: The used memory of a VM instance.
    • available: The available memory of a VM instance.
    • free: The idle memory of a VM instance.
    • total: The total memory of a VM instance.
    • freeutilization: The percentage of idle memory of a VM instance.
    • usedutilization: The percentage of the used memory of a VM instance.
    Note: To a Windows 7 or Windows Server 2012 VM with Memory Reclaim enabled, the used memory and total memory displayed here contain the memory that has been reclaimed to the host.
Figure 25. Memory Real-Time Monitoring


Note: For memory data, internal monitoring is more accurate than external monitoring. We recommend that you use internal monitoring to monitor the memory data.

Monitoring Data | Disk Capacity

You can select a time span to view the real-time disk capacity of a VM instance.
  • Available time spans: 15 minutes, 1 hour, 6 hours, 1 day, 1 week, 1 month, 1 year, and custom.
  • Monitoring metrics:
    • Disk Utilization: The percentage of used disk of a VM instance.
    • Disk Used Capacity: The used capacity of the VM disk.
    • Disk Idle Rate: The percentage of idle disk capacity of a VM instance.
    • Disk Idle Capacity: The idle disk capacity of a VM instance.
  • Monitoring object:
    • Select All: Display the real-time status of all disk partitions.
    • Single disk partition: Display the real-time read/write status of a single disk partition, such as the vda partition.
Figure 26. Disk Capacity Real-Time Monitoring


Manage Internal Monitoring

You can manage the internal monitoring agent by using the following commands, so as to stop, start, restart, and querying the internal monitoring service:
  • Stop the agent service: service zwatch-vm-agent stop.
  • Start the agent service: service zwatch-vm-agent start.
  • Restart the agent service: service zwatch-vm-agent restart.
  • Query the agent service: service zwatch-vm-agent status.

Uninstall Internal Monitoring Agent

The uninstallation method varies according to the operating system of the VM instance.
  • Linux-based VM instances
    1. Stop the agent by running the service zwatch-vm-agent stop command.
    2. Delete the service configuration file by running the rm -f /etc/systemd/system/zwatch-vm-agent.service command.
    3. Delete the agent installation directory by running the rm -rf /usr/local/zstack/zwatch-vm-agent command.
  • Windows-based VM instances
    1. Delete registry related entries.
      Run the Windows command prompt as an administrator and run the following command to delete the relevant keys in the system:
      reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSDTC /f
reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC /f
reg delete HKEY_CLASSES_ROOT\CID /f
    2. Stop and reinstall msdtc service.
      Run the Windows command prompt as an administrator and run the following commands to stop and reinstall the msdtc service:
      net stop msdtc
msdtc -uninstall
msdtc -install
    3. Reboot the VM instance.
    4. Uninstall the agent.
      Run the Windows command prompt as an administrator and run the following command to delete the agent:
      msiexec /a "c:\Program Files\GuestTools\qemu-ga.msi" targetdir="c:\Program Files"
"c:\Program Files\QEMU Guest Agent\Qemu-ga\qemu-ga.exe" -s vss-uninstall

vNUMA Configuration

vNUMA Configuration: vNUMA uses CPU pinning to passthrough the topology of associated host physical NUMA (pNUMA) nodes to a VM instance, generating a topology of virtual NUMA (vNUMA) nodes for the VM instance. This topology enables a vCPU on a vNUMA node to primarily access the local memory and thus improves VM performance.

Concepts

  • NUMA: Non-uniform memory access (NUMA) is a computer memory design where the memory access time depends on the memory location relative to the CPU. Under NUMA, a processor can access its own local memory faster than non-local memory and thus improves VM performance.
  • pNUMA node: A pNUMA node (physical NUMA node) is a host NUMA node predefined based on the host NUMA architecture. It is used to manage the CPUs and memory of the host. A pNUMA node mainly consists of pCPUs and local memory.
  • pNUMA topology: A pNUMA topology (physical NUMA topology) is the topology of the host NUMA nodes predefined by the CPU vendor based on the host NUMA architecture.
  • vNUMA node: A vNUMA node (virtual NUMA node) is generated by passing-through associated pNUMA nodes via CPU pinning. It is used to manage the CPUs and memory of a VM instance. A vNUMA node mainly consists of vCPUs and local memory.
  • vNUMA topology: A vNUMA topology (virtual NUMA topology) is the topology of VM NUMA nodes generated by passing-through associated pNUMA nodes via CPU pinning.
  • Local memory: Local memory is the memory that a CPU (pCPU or vCPU) accesses through the Uncore iMC (Integrated Memory Controller) of the same NUMA (pNUMA or vNUMA) node. Compared with accessing non-local memory, accessing local memory has lower latencies.

Fundamentals

vNUMA configurations are achieved through CPU pinning, which assigns the vCPUs of a VM instance to specific pCPUs of the host. In vNUMA configurations, all vCPUs of the VM instance are pinned to pCPUs of the host. In addition, the pCPUs pinned by a vCPU belong to the same pNUMA node.

After the vNUMA configurations are completed, a vNUMA topology with one or more vNUMA nodes is generated by passing-through the topology of associated host pNUMA nodes. Then the vCPUs of the VM instance primarily access the local memory of the vNUMA node where the vCPUs reside.

Figure 27. vNUMA Configuration Basics


Configure vNUMA

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. Select the target VM instance, choose Overview > vNUMA, and go to the Configure vNUMA page.
Note: vNUMA groups vCPUs and memory based on the CPU pinning configurations. Before you can configure vNUMA, you need to disable the advanced setting Instance Offering Online Modification of the VM instance.
You can configure vNUMA by setting the following parameters:
  • vNUMA: Choose whether to enable vNUMA. By default, vNUMA is disabled.
  • CPU Pinning: CPU pinning assigns the vCPUs of a VM instance to specific host pCPUs. Two CPU pinning methods are supported: By NUMA Topology and By Entry.
    • By NUMA Topology: This method indicates that you pin vCPUs to pCPUs based on the host pNUMA topology. You can implement Manual Pinning or Smart Pinning.
      • Manual Pinning allows you to customize vCPU-pCPU binding for all vCPUs.
      • Smart Pinning assigns a vCPU of a VM instance to a pCPU on a host pNUMA node by descending order of the pNUMA node ID. If all pCPUs on the pNUMA node are pinned, a pCPU on the next pNUMA node is to be pinned. If all pCPUs of the host are pinned but some vCPUs are not assigned to pCPUs, each vCPU is assigned to a pCPU starting again from the pNUMA node with the maximum node ID.
      • You can pin a vCPU to one or more pCPUs or pin one or more vCPUs to a pCPU.
      • The utilization of each pCPU in the past 15 minutes is displayed. You can pin a vCPU to the optimal pCPU based on the utilization.
    • By Entry:
      • You can click Add CPU Pinning to specify more CPU pinning rules.
      • Enter the vCPU range in the left text box and the pCPU range in the right. Note that the - symbol indicates the value range, while the ^ symbol indicates that a value is not included. If you specify multiple entries in a rule, separate each entry by using a comma (,). The following are some examples:
        • 0-2 indicates CPU 0, CPU 1, and CPU 2.
        • ^2 indicates that CPU 2 is not included.
        • 0-2,^2 indicates CPU 0 and CPU 1.
        • 1-7,^2,^3,^4,10 indicates CPU 1, CPU 5, CPU 6, CPU 7, and CPU 10.
    Note:
    • ZStack Cloud supports fixed vCPU performance on VM instances.
    • All vCPUs of the VM instance must be pinned to pCPUs of the host.
    • The pCPUs pinned by a vCPU must belong to the same pNUMA node.
    • The vCPU range depends on the selected instance offering of the VM instance, while the pCPU range depends on the number of pCPUs of the host.
    • If a vCPU has multiple CPU pinning rules, the union of the rules is used.
    • ZStack Cloud supports CPU overcommitment. Therefore, the number of vCPUs can be greater than that of pCPUs. However, if the number of vCPUs specified in the CPU pinning rule is greater than that of pCPUs, the VM performance will be affected. Therefore, CPU overcommitment is not recommended.
  • Reboot VM Instance: Choose whether to restart the VM instance. By default, the VM instance is not restarted.
    Note:
    • You need to restart the VM instance to make the vNUMA configuration take effect.
    • Restarting the VM instance may temporarily interrupt the application workloads running on the VM instance. Proceed with caution.
Figure 28. Configure vNUMA


vNUMA Topology

After you complete the vNUMA configurations and restart the VM instance, a vNUMA topology is generated. The following describes the topology:
  • vNUMA:
    • The vCPUs that pin pCPUs residing on the same pNUMA node form a vNUMA node. Therefore, each vNUMA node is associated with a pNUMA node.
    • Total Memory: The total amount of local memory that a vCPU can access from the vNUMA node where it resides.
  • pNUMA:
    • All pNUMA nodes that associate with the VM instance are displayed.
    • Total Memory: The total amount of local memory that a pCPU can access from the pNUMA node where it resides.
    • Free Memory: The amount of free local memory that a pCPU can access from the pNUMA node where it resides.
    • Both the total memory and free memory are measured based on physical hardware resources.
Figure 29. vNUMA Topology


Benefits

  • Better System Performance: vNUMA uses CPU pinning to generate a topology of vNUMA nodes for VM instances, which enables a vCPU on a vNUMA node of VM instances to primarily access the local memory and thus improves VM performance.
  • Flexible Configuration Methods: Multiple CPU pinning methods make the vNUMA configuration more visualized, intelligent, and convenient. These characteristics allow you to efficiently configure vNUMA that suits your business needs.

Scenarios

vNUMA is designed for NUMA-aware applications. You can use this feature in the following scenarios:
  • Scenarios that require database and compiling services

    Database services such as Oracle and SQL Server and compiling services need to frequently access memory. This requires high performance and fast response of the system. vNUMA enables the services to primarily access local memory and thus greatly reduces latencies and improves computing performance of the system.

  • CPU-intensive application scenarios:

    CPU-intensive applications have high demand on CPU resources. If many small CPU-intensive applications are running on a VM instance, frequent context switching may occur. vNUMA resolves this issue by assigning vCPUs to specific pCPUs and thus improves system performance.

Limitations

If you enable vNUMA for a VM instance, note that:
  • CPU pinning is not supported for the VM instance (CPU pinning during vNUMA configuration is supported).
  • You cannot live modify the instance offering of the VM instance.
  • Before you hot migrate the VM instance across hosts, make sure that the pNUMA architecture of the destination host is consistent with that of the source host.
  • When you hot migrate the VM instance across hosts and primary storages, the VM instance will be migrated only to a host that has the same pNUMA architecture of the source host.

CPU Pinning

CPU Pinning: CPU pinning assigns the virtual CPUs (vCPUs) of a VM instance to specific physical CPUs (pCPUs) of the host, which improves VM performance.

Figure 30. CPU Pinning Basics


Configure CPU Pinning

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. Select the target VM instance, choose Overview > CPU Pinning, go to the CPU Pin page.
Note: Before you can configure CPU pinning for a VM instance, disable vNUMA for the VM instance.
You can configure CPU pinning by setting the following parameters:
  • CPU Pinning: CPU pinning assigns the vCPUs of a VM instance to specific host pCPUs. Two CPU pinning methods are supported: By NUMA Topology and By Entry.
      • By NUMA Topology: This method indicates that you pin vCPUs to pCPUs based on the host pNUMA topology. You can implement Manual Pinning or Smart Pinning.
        • Manual Pinning allows you to customize vCPU-pCPU binding for all vCPUs.
        • Smart Pinning assigns a vCPU of a VM instance to a pCPU on a host pNUMA node by descending order of the pNUMA node ID. If all pCPUs on the pNUMA node are pinned, a pCPU on the next pNUMA node is to be pinned. If all pCPUs of the host are pinned but some vCPUs are not assigned to pCPUs, each vCPU is assigned to a pCPU starting again from the pNUMA node with the maximum node ID.
        • You can pin a vCPU to one or more pCPUs or pin one or more vCPUs to a pCPU.
        • The utilization of each pCPU in the past 15 minutes is displayed. You can pin a vCPU to the optimal pCPU based on the utilization.
      • By Entry:
        • You can click Add CPU Pinning to specify more CPU pinning rules.
        • Enter the vCPU range in the left text box and the pCPU range in the right. Note that the - symbol indicates the value range, while the ^ symbol indicates that a value is not included. If you specify multiple entries in a rule, separate each entry by using a comma (,). The following are some examples:
          • 0-2 indicates CPU 0, CPU 1, and CPU 2.
          • ^2 indicates that CPU 2 is not included.
          • 0-2,^2 indicates CPU 0 and CPU 1.
          • 1-7,^2,^3,^4,10 indicates CPU 1, CPU 5, CPU 6, CPU 7, and CPU 10.
    Note:
    • The vCPU range depends on the selected instance offering of the VM instance, while the pCPU range depends on the number of pCPUs of the host.
    • If a vCPU has multiple CPU pinning rules, the union of the rules is used.
    • ZStack Cloud supports CPU overcommitment. Therefore, the number of vCPUs can be greater than that of pCPUs. However, if the number of vCPUs specified in the CPU pinning rule is greater than that of pCPUs, the VM performance will be affected. Therefore, CPU overcommitment is not recommended.
  • Reboot VM Instance: Choose whether to restart the VM instance. By default, the VM instance is not restarted.
    Note:
    • You need to restart the VM instance to make the CPU pinning configuration take effect.
    • Restarting the VM instance may temporarily interrupt the application workloads running on the VM instance. Proceed with caution.
Figure 31. CPU Pinning


Benefits

  • Better System Performance: CPU pinning assigns the vCPUs of a VM instance to specific host pCPUs, which makes full of CPU cache and thus improves VM performance and operating efficiencies.
  • Flexible Configuration Methods: Multiple CPU pinning methods make the configuration more visualized, intelligent, and convenient. These characteristics allow you to efficiently configure CPU pinning that suits your business needs.

Scenarios

CPU pinning is applicable to the following scenarios:
  • CPU-intensive application scenarios:

    CPU-intensive applications have high demand on CPU resources. If many small CPU-intensive applications are running on a VM instance, frequent context switching may occur. CPU pinning resolves this issue by assigning vCPUs to specific pCPUs and thus improves system performance.

  • Unbalanced CPU usage scenarios:

    If many applications are using one or more specific pCPUs, you can configure CPU pinning to adjust CPU usage in a more balanced way.

Limitations

  • Cloning or migrating a VM instance also copies the CPU pinging rule, while creating a VM image or performing VM backup does not.
  • When you power off a VM instance and modify its instance offering by reducing the number of its vCPUs, the CPU pinning rules that relate to the reduced vCPUs no longer take effect. In this case, we recommend that you modify or delete these rules.

EmulatorPin Configuration

EmulatorPin Configuration: EmulatorPin assigns all other threads than virtual CPU (vCPU) threads and IO threads of a VM instance to physical CPUs (pCPUs) of the host so that these threads run on assigned pCPUs.

Figure 32. EmulatorPin Basics


Configure EmulatorPin

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. Select the target VM instance, choose Overview > EmulatorPin, and go to the Configure EmulatorPin page.

You can configure EmulatorPin by setting the following parameters:

  • EmulatorPin: EmulatorPin assigns all other threads than vCPU threads and IO threads of a VM instance to pCPUs of the host. You can configure EmulatorPin by using the pNUMA node of the host.
Figure 33. Configure EmulatorPin


Scenarios

EmulatorPin is applicable to the following scenarios:
  • Concurrent Running of Multiple Applications:

    If many VM instances that run different applications are running on a host, context switching may occur. EmulatorPin assigns main QEMU threads of a VM instance to specific pCPUs. This isolates the main threads of VM instances and thus ensures relative stability of the system.

VM Instance GuestTools

VM instance GuestTools is a collection of drivers and tools that help improve the VM performance and realize more VM functions. This topic describes the component, installation, and application of VM instance GuestTools.

Introduction

GuestTools consists of the following drivers and tools, the actual component varying based on VM operating systems:
  • Internal monitoring agent: An agent responsible for obtain VM internal monitoring data, including CPU, memory, and disk capacity data.
  • QEMU Guest Agent (QGA): An application realizing mutual interactions between the VM instance and host. These interactions are independent from networks and realize the functions like deploying VM configurations, reading VM configurations, and pushing VM internal monitoring data.
  • VirtIO driver: A collection of drivers applied to Windows VM instances to improve the VM performance.
    • SCSI controller: used to improve the disk performance of a Windows VM instance in a virtualization environment.
    • PCI simple communications controller: used to realize the communications between a Windows VM instance and the underlying KVM virtualization.
    • PCI device: used to realize the balloon memory scaling.
    • Ethernet adapter: used to improve the network performance of a Windows VM instance in a virtualization environment.
  • Cloudbase-Init: A component helps realize the User Data import and other customized functions for Windows VM instances.
    The following table lists the matching relationship between the tools (or drivers) and VM operation systems:
    Operating System Version Supports Internal Monitoring Agent Supports QGA Supports VirtIO Driver Supports Cloudbase-Init
    CentOS CentOS 6.5 64 bit No Yes No No
    CentOS 6.8 64 bit Yes Yes No No
    CentOS 6.9 64 bit Yes Yes No No
    CentOS 6.10 64 bit Yes No No No
    CentOS 7.2 64 bit Yes Yes No No
    CentOS 7.3 64 bit Yes Yes No No
    CentOS 7.4 64 bit Yes Yes No No
    CentOS 7.5 64 bit Yes Yes No No
    CentOS 7.6 64 bit Yes Yes No No
    CentOS 7.9 64 bit Yes Yes No No
    CentOS 8.0 64 bit Yes Yes No No
    RHEL Redhat Enterprise Linux Server 6.9 64 bit Yes No No No
    Redhat Enterprise Linux Server 7.4 64 bit Yes Yes No No
    Redhat Enterprise Linux Server 7.5 64 bit Yes Yes No No
    Redhat Enterprise Linux Server 7.6 64 bit Yes Yes No No
    Fedora Fedora 30 64 bit Yes Yes No No
    Fedora 31 64 bit Yes Yes No No
    Debian Debian 9.9 64 bit Yes Yes No No
    Debian 10.0 64 bit Yes Yes No No
    Ubuntu Ubuntu 14.04 64 bit Yes Yes No No
    Ubuntu 16.04 64 bit Yes Yes No No
    Ubuntu 16.10 64 bit Yes Yes No No
    Ubuntu 18.04 64 bit Yes Yes No No
    Kylin Kylin 4.0.2 64 bit Yes No No No
    Kylin V10 SP1(0518) Yes Yes No No
    Kylin V10 SP2 Yes Yes No No
    NeoKylin NeoKylin V7.0 64 bit Yes Yes No No
    NeoKylin V7update 64 bit Yes Yes No No
    OpenSUSE OpenSUSE 12.0 64 bit Yes No No No
    OpenSUSE 15.0 64 bit Yes Yes No No
    SLES SUSE Linux Enterprise Server 15 64 bit Yes Yes No No
    SUSE Linux Enterprise Server 12 64 bit Yes Yes No No
    SUSE Linux Enterprise Desktop 12 64 bit Yes Yes No No
    SUSE Linux Enterprise Desktop 15 64 bit Yes Yes No No
    UOS UOS V20 1050e Yes Yes No No
    oracle linux oracle linux 7.9 Yes Yes No No
    FreeBSD FreeBSD 11 64 bit Yes No No No
    FreeBSD 12 64 bit Yes No No No
    FreeBSD 13 64 bit Yes No No No
    OpenEuler OpenEuler 20 64 bit Yes Yes No No
    OpenEuler 22 64 bit Yes Yes No No
    Windows Windows 10 64 bit Yes No Yes Yes
    Windows Server 2008 R2 64 bit Yes Yes Yes No
    Windows Server 2012 64 bit Yes Yes Yes Yes
    Windows Server 2016 64 bit Yes Yes Yes Yes
    Windows Server 2019 64 bit Yes Yes Yes Yes
    Windows Server 2022 64 bit Yes Yes Yes Yes

Installation

The methods to install VM GuestTools varies based on the VM operating systems.
  • Linux VM Instances
    1. Click Install GuestTools on the VM details page.
    2. Attach an ISO of VM GuestTools.
    3. Run the following installation commands on the VM instance console:
      # Create a mount point.
mkdir /mnt/cdrom
# Mount the CND-ROM image.
mount /dev/cdrom /mnt/cdrom
#
cd /mnt/cdrom/
bash ./zs-tools-install.sh
# Unmount the CD-ROM image.(Optional)
cd ~
umount /mnt/cdrom
      Note: You can copy the commands by one click from the VM details page to the VM instance console.
      Figure 34. Install GuestTools for Linux VM Instance




  • Windows VM Instance
    1. Click Install GuestTools on the VM details page.
    2. Attach an ISO of VM GuestTools.
    3. Launch the VM console and install GuestTools as prompted.
      Figure 35. Install GuestTools for


  • FreeBSD VM Instance
    1. Click Install GuestTools on the VM details page.
    2. Run the following installation commands on the VM instance console:
      curl http://169.254.169.254/vm-tools.sh -o vm-tools.sh && bash -x ./vm-tools.sh
      Note:
      • In the command above, 169.254.169.254 is the IP address of the User Data server.
      • Before you install GuestTools, make sure that you installed the bash, security/libgcrypt, and curl tools.
      Figure 36. Install GuestTools for FreeBSD VM Instance




Application

Installing GuestTools for a VM instance enables you to view the VM internal monitoring, deploy the VM configurations, and read the VM configurations.
  • Internal Monitoring: Internal monitoring shows monitoring data obtained by the internal monitoring agent from the VM instance. The data is pushed to the host by the DHCP service or the QGA at a fixed interval and displayed dynamically in real time through graphs, helping you to master the changing trends of VM performances, including CPU, memory, and disk capacity. For more information, see Internal Monitoring.
  • Configuration Deployment: Deploys the parameters you set on the Cloud to the VM instance through the QGA in the GuestTools to make these parameters take effect actually, including the network parameters and the VM hostname.
    • Hostname: After you install GuestTools for a VM instance, the modification you made on the hostname when the VM instance is running can be deployed by the QGA and take effect directly.
      Note: To use the QGA to deploy the hostname, install the GuestTools before you modify the hostname.
    • Network parameters: To a VM instance using an L3 network that has the DHCP service disabled, you can install a GuestTools to make the IP address, netmask, gateway, DNS, MTU, and other network parameters you set on the Cloud deployed by the QGA to the NIC and take effect actually.
      Note:
      • If you have installed the GuestTools before you modify the network parameters, the parameters take effect directly after your modification.
      • If you install the GuestTools after you set the network parameters, click Configuration Info > NIC > Actions > Sync Configuration on the VM details page to make the parameters take effect.
        Figure 37. Sync NIC Configuration


  • Configuration Read: Read the NIC IP address you configure in the VM instance to the Cloud through the QGA in the GuestTools. An IP address configured in the VM instance can be displayed on and managed by the Cloud after it is read successfully.
    Note:
    • To read an IP address, make sure the following points: the L3 network that the NIC resides on has the IP address management disabled; you have not assigned an IP address of the same type for the NIC on the Cloud (the IPv4 or IPv6 information of the NIC is displayed as None on the Cloud).
    • If the IP address to be read has been occupied on the Cloud, the QGA fails to read this IP address, and a conflict alarm is triggered.
    • By default, the QGA read each IPv4 or IPv6 address satisfying the above requirements only once. After reading an IP address successfully, the QGA does not make this IP address displayed anymore even though you change it in the VM instance. In addition, the change will trigger an alarm message.

NIC Monitoring

The NIC monitoring data of a VM instance is obtained from the host by using libvirt and is displayed through cards and curve charts.

View NIC Monitoring Data

On the details page of a VM instance, click the Configuration Info tab and select the NIC. On the NIC list, click on the name of a NIC. Then, the NIC details page appears. left side to access the NIC list. Click on the NIC name. Then, NIC details page appears. On the NIC details page, you can see the basic information and the monitoring data.

On the monitoring data area, you can select a time span to view the monitoring information as needed. Available time spans include 15 minutes, 1 hour, 6 hours, 1 day, 1 week, 1 month, 1 year, and custom.
  • The cards show the total traffic, average/maximum data rate, and the 95th percentile of data sent or received by a NIC in the selected time span.
    • Total traffic: The total amount of data sent or received by a NIC.
    • Average data rate: The average amount of data sent or received per second by a NIC.
    • Maximum data rate: The maximum value of the average data rate. The average data rate is calculated every 5 minutes.
    • 95th percentile: This value is calculated by arranging the average data rate samples collected every 5 minutes in the selected time range in descending order, and removing all values greater than the highest 5% of the data.
    Figure 38. Monitoring Data on Cards


  • The curve charts show the real-time NIC data rate and packet rate in the selected time span.
    • NIC data rate: The number of data bits sent or received by a NIC per second.
    • NIC packet rate: The number of data packets sent or received by a NIC per second.
    Figure 39. Monitoring Data on Curve Charts


Resize the Root Volume

ZStack Cloud allows you to resize the root volume of a VM instance when the VM instance is in the running or stopped state. Note that only increasing volume size is supported.

Resize the Root Volume

You can resize the root volume of a VM instance by using one of the following methods:
  1. On the VM Instance management page, select a VM instance that is in the running or stopped state and choose Actions > System Configurations > Resize Root Volume. Then, the Resize Root Volume dialog box is displayed.
    You can set a new size as needed. The new size takes effect immediately.
    Figure 40. Resize Root Volume


  2. Select a VM instance that is in the running or stopped state and go to the details page of the VM instance. On the Configuration Info tab page, select the root volume to be resized and choose Actions > Resize Volume. Then, the Resize Volume dialog box is displayed.
    You can set a new size as needed. The new size takes effect immediately.
    Figure 41. Resize Volume


  3. Select a VM instance that is in the running or stopped state and go to the details page of the VM instance. On the Configuration Info tab page, click on the name of the root volume to be resized and set a new size for the root volume. The new size takes effect immediately.

The steps above only increase the size of the root volume. To make the new size recognized by the VM instance, partition and resize the hard disk in the operating system of the VM instance.

Partition and Resize the Hard Disk

The resize method varies according to the VM type, partition, and file system.
Note:
  • Before you resize a root volume, create a snapshot for the VM instance to enhance the data security.
  • The resize operation has potential risks. For security reasons, we recommend that you plan a new partition for the new size.
  • The resize operation only increases the size, not reduce the size.
  • The increased size can be merged into the last partition for continuous use.
    • If the last partition is a system backup partition (Windows), you must plan a new partition for the increased size.
    • If the last partition is a swap partition, you can delete the swap partition first, add the increased size to the last partition, and then rebuild a swap partition.

The following are four different resize scenarios.

  1. Use the GParted open source tool to resize the ext4 root partition for an instance that has both the ext4 and swap partitions.
    Note:
    • In this scenario, you need to re-plan the current partition by using Live CD.
    • To prevent data loss, exercise caution when you adjust a partition.

    Assume that VM instance uses an ext4 root partition of 35 GB and a swap partition of 5 GB. The total size is 40 GB. After you resize the root volume from 40 GB to 50 GB, you want to add the increased size to the ext4 root partition.

    Procedure:
    1. Add a GParted ISO. You can download the ISO from the GParted official website https://gparted.org/download.php. We recommend that you download the amd64 iso, indicating that 64-bit operating systems are supported.
    2. After you add the ISO, set CD ROM as the first boot order and Hard Disk as the second. Then, the VM instance boots from CD ROM next time.
    3. Use GParted Live CD to boot the system and launch the console of the VM instance. After the GParted boot finished, follow the instructions and long-press the Enter key until you enter the graphical interface.
    4. In the GParted interface, right-click the original swap partition to delete it, resize ext4 from 35 GB to 46 GB, and create a new swap partition for the unallocated 4 GB.
      Figure 42. Delete Original swap Partition


      Figure 43. Resize ext4 from 35 GB 46 GB




      Figure 44. Create a 4 GB swap Partition




    5. Power off the VM instance, detach the ISO, and start the VM instance again.
    6. Launch the VM console and run the df -h command. Then, you can see that the size of the root partition is increased to 46 GB.
      [root@10-58-21-213 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 46G 1.2G 42G 3% /
    7. Enable the swap partition and modify the /etc/fstab disk partition table.
      [root@10-58-21-213 ~]# fdisk -l|grep vda
Disk /dev/vda: 53.7 GB, 53687091200 bytes, 104857600 sectors
/dev/vda1 * 2048 96468991 48233472 83 Linux
/dev/vda2 96468992 104857599 4194304 82 Linux swap / Solaris

[root@10-58-21-213 ~]# mkswap /dev/vda2
mkswap: /dev/vda2: warning: wiping old swap signature.
Setting up swapspace version 1, size = 4194300 KiB
no label, UUID=ed99f72b-aafb-43ad-be8f-fcd09794beb0
#You can see that the UUID of the swap partition is ed99f72b-aafb-43ad-be8f-fcd09794beb0.

[root@10-58-21-213 ~]# swapon /dev/vda2
#Enable the swap partition.

[root@10-58-21-213 ~]# free -m
 total used free shared buff/cache available
Mem: 911 106 671 6 133 657
Swap: 4095 0 4095

[root@10-58-21-213 ~]# sed -i '/swap/d' /etc/fstab
echo "UUID=ed99f72b-aafb-43ad-be8f-fcd09794beb0 swap swap defaults 0 0"
#Write the swap settings into the disk partition table so that it can be started automatically upon the VM boots.
    8. After you power off and reboot the VM instance, the ext4 partition of the root volume is resized successfully, and the swap partition reserves 4 GB.
  2. Use the LVM partition tool to resize the LVM partition for an instance that has both the xfs and swap partitions.
    Note: This method applies to the dynamic resizing of LVM partitions without the need of using other tools.

    Assume that the VM instance uses an LVM partition and formats the LVM partition as a boot partition, an xfs root partition, and a swap partition. In this scenario, the size of the xfs root partition and swap partition is 94 GB and 6 GB, respectively. Therefore, the total size is 100 GB. After you resize the root volume from 100 GB to 120 GB, you want to add the increased size to the xfs root partition.

    Procedure:
    1. View the current partition and the LVM partition. Here, the size of the boot partition, LVM partition, and swap partition is 500 MB, 94 GB, and 6 GB, respectively. The boot partition and LVM partition use /dev/vda1 and /dev/vda2, respectively. The path of the LVM partition and swap partition is /dev/vg/root and /dev/vg/swap, respectively.
      [root@10-0-44-221 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg-root 94G 6.5G 88G 7% /
/dev/vda1 477M 104M 344M 24% /boot
#The boot partition is 500 MB and uses /dev/vda1.
#The LVM partition is 94 GB and uses /dev/vda2. Path: /dev/vg/root.
#The swap partition is 6 GB. Path: /dev/vg/swap.

[root@10-0-44-221 ~]# fdisk -l |grep vda
Disk /dev/vda: 128.8 GB, 128849018880 bytes, 251658240 sectors
/dev/vda1 * 2048 1026047 512000 83 Linux
/dev/vda2 1026048 209715199 104344576 8e Linux LVM

[root@10-0-44-221 ~]# pvdisplay |egrep "Name|Size"
 PV Name /dev/vda2
 VG Name vg
 PV Size 99.51 GiB / not usable 3.00 MiB
 PE Size 4.00 MiB
#The physical volume uses /dev/vda2.

[root@10-0-44-221 ~]# vgdisplay |egrep "Name|Size"
 VG Name vg
 VG Size 99.51 GiB
 PE Size 4.00 MiB
 alloc PE / Size 25463 / 99.46 GiB
 Free PE / Size 11 / 44.00 MiB
#The volume group information. Name: vg. This volume group will be resized.

[root@10-0-44-221 ~]# lvdisplay |egrep "Name|Size"
 LV Name root
 VG Name vg
 LV Size 93.59 GiB
 LV Name swap
 VG Name vg
 LV Size 5.88 GiB
#The logical volume information.
    2. After the resizing, run the fdisk /dev/vda command to partition the increased size, create a new partition by using n, set the new partition to LVM format by using t, and make the setting take effect by using w. To make the setting take effect immediately, run the partprobe command.
      [root@10-0-44-221 ~]# fdisk /dev/vda
Welcome to fdisk (util-linux 2.23.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/vda: 128.8 GB, 128849018880 bytes, 251658240 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x0008168e
 Device Boot Start End Blocks Id System
/dev/vda1 * 2048 1026047 512000 83 Linux
/dev/vda2 1026048 209715199 104344576 8e Linux LVM
Command (m for help): n
Partition type:
 p primary (2 primary, 0 extended, 2 free)
 e extended
Select (default p):
Using default response p
Partition number (3,4, default 3):
First sector (209715200-251658239, default 209715200):
Using default value 209715200
Last sector, +sectors or +size{K,M,G} (209715200-251658239, default 251658239):
Using default value 251658239
Partition 3 of type Linux and of size 20 GiB is set
Command (m for help): t
Partition number (1-3, default 3):
Hex code (type L to list all codes): 8e
Changed type of partition 'Linux' to 'Linux LVM'
Command (m for help): p
Disk /dev/vda: 128.8 GB, 128849018880 bytes, 251658240 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x0008168e
 Device Boot Start End Blocks Id System
/dev/vda1 * 2048 1026047 512000 83 Linux
/dev/vda2 1026048 209715199 104344576 8e Linux LVM
/dev/vda3 209715200 251658239 20971520 83 Linux LVM
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.

[root@10-0-44-221 ~]# partprobe
    3. Create a physical volume for the newly formatted partition.
      [root@10-0-44-221 ~]# pvcreate /dev/vda3
 Physical volume "/dev/vda3" successfully created
#Create a physical volume.
    4. Extend the volume group.
      [root@10-0-44-221 ~]# vgextend vg /dev/vda3
 Volume group "vg" successfully extended
#Name of the volume group: vg. The new partition will be added to the volume group vg.
    5. Disable the swap partition and delete the original swap logical volume.
      [root@10-0-44-221 ~]# swapoff -a
[root@10-0-44-221 ~]# lvremove /dev/vg/swap
Do you really want to remove active logical volume swap? [y/n]: yes
 Logical volume "swap" successfully removed
    6. Add 20 GB to the logical volume /dev/vg/root.
      [root@10-0-44-221 ~]# lvextend -L +20G /dev/vg/root
 Size of logical volume vg/root changed from 93.59 GiB (23959 extents) to 113.59 GiB (29079 extents).
 Logical volume root successfully resized.
#Add 20 GB to /dev/vg/root.

[root@10-0-44-221 ~]# lvdisplay
 --- Logical volume ---
 LV Path /dev/vg/root
 LV Name root
 VG Name vg
 LV UUID UkyCVW-gd5E-Z4Q2-bVHv-T84e-c3GH-ZMiUdF
 LV Write Access read/write
 LV Creation host, time localhost, 2017-07-26 13:18:40 +0800
 LV Status available
 # open 1
 LV Size 113.59 GiB
 Current LE 29079
 Segments 2
 allocation inherit
 Read ahead sectors auto
 - currently set to 8192
 Block device 253:0
    7. Run the xfs_growfs command to resize the XFS file system, make the new size take effect, and check the new partition.
      [root@10-0-44-221 ~]# xfs_growfs /dev/vg/root
meta-data=/dev/mapper/vg-root isize=256 agcount=4, agsize=6133504 blks
 = sectsz=512 attr=2, projid32bit=1
 = crc=0 finobt=0
data = bsize=4096 blocks=24534016, imaxpct=25
 = sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal bsize=4096 blocks=11979, version=2
 = sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 24534016 to 29776896

[root@10-0-44-221 ~]# df -h|grep vg-root
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg-root 114G 6.5G 108G 6% /
#Resizing of the new partition takes effect.
    8. Divide a new size from the logical volume group to the swap partition, enable the swap partition, and write the disk configuration.
      [root@10-0-44-221 ~]# lvcreate -L 4G -n swap vg
 Logical volume "swap" created.
#Create a 4 GB partition named swap from the volume group vg.

[root@10-0-44-221 ~]# mkswap /dev/vg/swap
Setting up swapspace version 1, size = 4194300 KiB
no label, UUID=bfc8a843-c758-4665-adfe-e32752ceda44
#Create a swap partition. Here, you can see that the UUID of the swap partition is bfc8a843-c758-4665-adfe-e32752ceda44.

[root@10-0-44-221 ~]# swapon /dev/mapper/vg-swap
#Enable the swap partition.

[root@10-58-21-213 ~]# sed -i '/swap/d' /etc/fstab
echo "UUID=bfc8a843-c758-4665-adfe-e32752ceda44 swap swap defaults 0 0"
#Write the swap settings into the disk partition table so that the swap partition can be enabled automatically after the VM instance is started.
    9. After you power off and reboot the VM instance, the XFS system of the VM LVM partition is resized successfully, and the swap partition reserves 4 GB.
  3. Use the growpart tool to extend the xfs root partition instance.
    Note: This method applies to the dynamic resizing of xfs partitions without the need of attaching an ISO or using an LVM partition tool.

    Assume that the size of the xfs root partition is 6 GB and the total root volume size is 8 GB. After you resize the root volume from 8 GB to 40 GB, you want to add the increased size to the xfs root partition.

    Procedure:
    1. View the current partition. You can see that the root volume is resized to 40 GB, of which the xfs root partition is 6 GB. The extra disk space is unallocated and is not added to the disk partition.
      [root@10-0-44-210 ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0  400G  0 disk
└─sda1   8:1    0  400G  0 part /mnt/nfs-data
vda    253:0    0   40G  0 disk
├─vda1 253:1    0    2G  0 part [SWAP]
└─vda2 253:2    0    6G  0 part /
    2. Install the growpart tool.
      [root@10-0-44-210 ~]# yum install -y cloud-utils-growpart
    3. Resize the xfs root partition by using the growpart <DeviceName> <PartionNumber> command. Here, the DeviceName of the xfs root partition is /dev/vda and PartionNumber is 2.
      [root@10-0-44-210 ~]# growpart /dev/vda 2
CHANGED: partition=2 start=4196352 old: size=12580864 end=16777216 new: size=79689695 end=83886047
    4. View the partitions. Then, you can see that the xfs root partition is resized from 6 GB to 38 GB.
      [root@10-0-44-210 ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0  400G  0 disk
└─sda1   8:1    0  400G  0 part /mnt/nfs-data
vda    253:0    0   40G  0 disk
├─vda1 253:1    0    2G  0 part [SWAP]
└─vda2 253:2    0   38G  0 part /
    5. Extend the XFS file system.
      1. To extend the XFS file system, make sure that the xfsprogs tool is installed. The installation command is as follows:
        [root@10-0-44-210 ~]# yum install xfsprogs
      2. Extend the file system in /dev/vda2 by running the xfs_growfs command. Here, / is the mount point.
        [root@10-0-44-210 ~]# xfs_growfs /
meta-data=/dev/vda2              isize=256    agcount=26, agsize=393152 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0 spinodes=0
data     =                       bsize=4096   blocks=9961211, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 1572608 to 9961211
      3. Check whether the file system reflects the increased volume size.
        [root@10-0-44-210 ~]# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2        38G  3.3G   35G   9% /
    Note: We recommend that you install the expansion and formatting tools according to the actual operating system. For example,
    • For CentOS 7, install the following tool:
      yum install cloud-utils-growpart
yum install xfsprogs
    • For Ubuntu 14, Ubuntu 16, Ubuntu 18, and Debian 9, install the following tool:
      apt install cloud-guest-utils
apt install xfsprogs
    • For Debian 8, openSUSE 42.3, openSUSE 13.1, and SLES 12 SP2, use the growpart or xfsprogs tool of the upstream version.
  4. Resize the Windows partitions.
    You can resize disks of Windows partitions on the disk management page.
    Note: After you resize the disk of a Windows partition, scan the disk to take effect.
PreviousResource PoolNextVolume