Resource Center – ZStack Indonesia

Table of Contents

Resource Pool

Resource Pool #

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.

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 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 IntelligenceEnterprises 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 DesktopGPU 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.

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 3. 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 4. 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 5. 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 or scheduled stopped or are errored because of errors occurred to compute, network, or storage resources associated with the VM instances. Valid values: None and NeverStop.
- If you set HA mode to None, VM instances scheduled or unexpectedly stopped are not auto restarted.
- If you set HA mode to Neverstop:
  - VM instances scheduled or unexpectedly stopped are auto restarted.
  - If errors occur to compute, network, or storage resources, associated VM instances are auto restarted on another host depending on the HA policy you configure for them.
Note:
- You can enable or disable VM HA globally by enabling or disabling the HA policy. By default, HA policy is enabled. If disabled, you cannot set HA for VM instances.
- You can set the HA mode globally by using the global setting VM HA Mode. Default: none. If you set the mode specifically for a VM instance, this global setting does not take effect on the VM instance.
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.
- If you set a root user password in user data for a VM instance, the password is displayed in the User Data option on the details page of the VM instance. Make sure that your password is well protected.
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).

Figure 1. 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:

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. By default, no data volumes is created and attached to a 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 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. By default, no data volumes is created and attached to a 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 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 or scheduled stopped or are errored because of errors occurred to compute, network, or storage resources associated with the VM instances. Valid values: None and NeverStop.
    - If you set HA mode to None, VM instances scheduled to be stopped or unexpectedly stopped are not auto restarted.If you set HA mode to Neverstop:
      - VM instances scheduled or unexpectedly stopped are auto restarted.If errors occur to compute, network, or storage resources, associated VM instances are auto restarted on another host depending on the HA policy you configure for them.
    Note:
    - You can enable or disable VM HA globally by enabling or disabling the HA policy. By default, HA policy is enabled. If disabled, you cannot set HA for VM instances.You can set the HA mode globally by using the global setting VM HA Mode. Default: none. If you set the mode specifically for a VM instance, this global setting does not take effect on the VM instance.
    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.
Figure 1. Basic Configurations
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:
    - 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 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: 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 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 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 2. Resource Configurations
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.
    - After you set the password, the password is displayed on User Data of the VM details page. Make sure that your password is well protected.
    - 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.
  - After you set the password, the password is displayed on User Data of the VM details page. Make sure that your password is well protected.
  - 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.
  - After you set the login password in User Data, a clear-text password is displayed on User Data of the VM details page. Remember to secure your password.
  - 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.
  - 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.shThe 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 3. System Configurations
Confirm the information.View the information about the VM instance to be created. You can edit the information by clicking the Edit icon.Figure 4. 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.OSBIOS ModeSupported VersionsWindowsUEFI
- Windows 8 or later
UEFI
- Windows 7
- Windows Server 2008 R2
LinuxUEFI
- 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:

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 1. Upload OVF Template File
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. Choose a high availability (HA) mode for the VM instance.Note:
    - You can enable or disable the VM HA feature in the Cloud by using the following method:Go to Settings > Platform Setting > Global Setting > Advanced > Platform Policy > HA Policy, locate Enable VM HA Globally, and turn on or off the switch as needed. Default: true.
    - The HA switch of a single VM instance is strictly controlled by that in the global setting.
    - If you turn off the switch in the global setting, you cannot set HA mode for a VM instance. In this case, the VM business may not be protected by HA. Please exercise with caution.
  - 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 2. Configure VM Instance
Confirm the information.View the information about the VM instance. You can edit the information by clicking the Edit icon.Figure 3. 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: If the VM instance has HA enabled, you can make the VM instance not automatically reboot this time after being stopped.	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.	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.	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: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.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 into one flat snapshot 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:In the Global Setting, enable Change Host Online on Local Storage.Detach the data volumes from the VM instance.Migrate the VM instance and data volumes to the same host.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:Stop the VM instance.Detach the data volumes from the VM instance.Migrate the VM instance and data volumes to the same host.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.	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 migratedNote: 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: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.Restart the VM instance.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 specificationYou 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:falseThe 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:First boot order: Hard diskSecond boot order: CD ROMIf 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) policy for a VM instance.VM HA policies:None: Disables VM HA.NeverStop: Enables VM HA.When a VM instance is shut down due to planned maintenance or exceptions, the VM HA policy 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.You can set whether to enable HA for all VM instances in the Cloud. Method: In the Global Setting, set VM HA to true. Default: true. If its is set to false, you cannot enable HA for VM instances in the Cloud.If a VM instance has HA enabled, you can make the VM instance not automatically reboot this time after being stopped.	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
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 InspectionYou 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 HandlingAfter 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
Set RDP Mode	Set the RDP mode for the VDI UI. Then, the VM console is opened in the RDP mode.	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
Cross-Cluster HA Policy	Set the cross-cluster HA policy for a VM instance.By default, this policy is enabled, indicating that the VM instance can be automatically migrated across clusters.If you disable this policy, the VM instance can only operate in the cluster where the VM instance resided when this policy was enabled.Background:In versions earlier than 3.8.0, when the VM HA policy is triggered or the host enters maintenance mode, the system automatically restores or migrates the VM instance on/to the other host. The destination hosts might be selected in the same cluster or from other clusters if these clusters shared the same L2 networks and primary storage.From 3.8.0, you can set the cross-cluster HA policy for a VM instance. If the policy is disabled, the VM instance can only operate in the cluster where the VM instance resided when this policy was enabled.Currently, this policy applies to host migration scenarios such as starting up a VM instance on another host to achieve HA, or migrating a VM instance to another host if the source host enters the maintenance mode.This policy takes effect only for VM auto-migrations. Other actions, such as manual hot migration, VM startups on specified hosts, and Dynamic Resource Scheduling (DRS),and policy-based migrations are not affected.If enabled, VM instances will not be stuck to a specified cluster.	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 /renewRestarting 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 thatThe 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.

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.

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.

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 3. 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 4. 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 5. 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 6. 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.

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 8. 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.

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.

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: 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 4. 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.

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.

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.

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 servicesDatabase 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.

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.

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.

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.

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:Table 1. Matching Relationships between GuestTools Components and VM OSOperating SystemVersionSupports Internal Monitoring AgentSupports QGASupports VirtIO DriverSupports Cloudbase-InitCentOSCentOS 6.5 64 bitNoYesNoNoCentOS 6.8 64 bitYesYesNoNoCentOS 6.9 64 bitYesYesNoNoCentOS 6.10 64 bitYesNoNoNoCentOS 7.2 64 bitYesYesNoNoCentOS 7.3 64 bitYesYesNoNoCentOS 7.4 64 bitYesYesNoNoCentOS 7.5 64 bitYesYesNoNoCentOS 7.6 64 bitYesYesNoNoCentOS 7.9 64 bitYesYesNoNoCentOS 8.0 64 bitYesYesNoNoRHELRedhat Enterprise Linux Server 6.9 64 bitYesNoNoNoRedhat Enterprise Linux Server 7.4 64 bitYesYesNoNoRedhat Enterprise Linux Server 7.5 64 bitYesYesNoNoRedhat Enterprise Linux Server 7.6 64 bitYesYesNoNoFedoraFedora 30 64 bitYesNote: This version does not support the service command, which results in an execution error in line 54 of systemctl start. You can successfully start the agent by changing the command to systemctl start.YesNoNoFedora 31 64 bitYesYesNoNoDebianDebian 9.9 64 bitYesYesNoNoDebian 10.0 64 bitYesYesNoNoUbuntuUbuntu 14.04 64 bitYesYesNoNoUbuntu 16.04 64 bitYesYesNoNoUbuntu 16.10 64 bitYesYesNoNoUbuntu 18.04 64 bitYesYesNoNoKylinKylin 4.0.2 64 bitYesNoNoNoKylin V10 SP1(0518)YesYesNoNoKylin V10 SP2YesYesNoNoOpenSUSEOpenSUSE 15.0 64 bitYesNoNoNoSLESSUSE Linux Enterprise Server 15 64 bitYesYesNoNoSUSE Linux Enterprise Server 12 64 bitYesYesNoNoUOSUOS V20 1050eYesYesNoNooracle linuxoracle linux 7.9YesYesNoNoFreeBSDFreeBSD 11 64 bitYesNoNoNoFreeBSD 12 64 bitYesNoNoNoFreeBSD 13 64 bitYesNoNoNoWindowsWindows Server 2003 R2 64 bitYesNoYesYesWindows Server 2008 R2 64 bitYesYesYesYesWindows Server 2012 64 bitYesYesYesYesWindows Server 2016 64 bitYesYesYesYesWindows Server 2019 64 bitYesYesYesYes

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/cdromNote: You can copy the commands by one click from the VM details page to the VM instance console.Figure 1. 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 2. 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.shNote:
  - 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 3. 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 4. 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 1. 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 2. 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:

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 1. Resize Root Volume
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 2. Resize Volume
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.

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 3. Delete Original swap Partition
  
  Figure 4. Resize ext4 from 35 GB 46 GBFigure 5. 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.
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.
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.
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.

Volume #

What is Volume? #

A volume provides storage space for a VM instance. Volumes are categorized into root volumes and data volumes.

Note: Volume management mainly involves data volumes.

Concepts #

Root volume: A root volume provides support for the system operations of a VM instance.
Data volume: A data volume provides extended storage space for a VM instance.

Considerations #

A volume attached to a VM instance cannot be attached to a VM instance of another hypervisor type. For example, a KVM VM volume cannot be attached to a VMware VM instance.
The storage space that a volume takes up is calculated based on the virtual size of the volume. When a volume is created, the virtual size of the volume is deducted. The actual storage space that the volume takes up is small upon creation while increases along with growing data writes.
A non-shared volume can be attached to only one VM instance. A shared volume can be created on a Ceph primary storage and SharedBlock primary storage and allows simultaneous access from multiple VM instances.
A root volume is an integral part of a VM instance. It cannot be detached from a VM instance.
A data volume attached to a VM instance can be detached from the VM instance and then attached to another VM instance of the same hypervisor type.
When multiple primary storage are available, you can specify a primary storage to create a volume. If you do not specify a primary storage when you create a volume, note that:
- For LocalStorage primary storage, the volume is created on the primary storage with the largest available space by default.
- For NFS primary storage, the volume is created on a random primary storage by default.
- For the combination of LocalStorage and NFS primary storage or the combination of LocalStorage and SharedMountPoint (SMP) primary storage, by default, the volume is created on a primary storage that does not store the root volume of the VM instance.
You can set the QoS for a data volume to limit its disk bandwidth. Note that an excessively low QoS may greatly lower I/O performance.

Create a Volume #

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > Volume. On the Volume page, click Create Volume. The Create Volume page appears.

The following lists the four volume creation scenarios:

Create a non-shared volume based on a disk offering.
Create a non-shared volume based on a volume image.
Create a shared volume based on a disk offering.
Create a shared volume based on a volume image.

Create Non-Shared Volume Based on a Disk Offering #

On the displayed page, set the following parameters:

Name: Enter a name for the volume.
Description: Optional. Enter a description for the volume.
Quantity: Enter the number of volumes that you want to create.Note: Enter an integer that ranges from 1 to 24.
Volume Type: Select Non-Shared Volume.
Creation Method: Select an existing disk offering or customize a disk offering.
Primary Storage: Optional. Select a primary storage.
Instance: Optional. Select a VM instance or elastic baremetal instance to which the volume is attached.
VirtioSCSI: Choose whether to use the Virtio-SCSI bus to create an SCSI data volume.Note:
1. Classic Volume: By default, VirtIO SCSI is disabled. If it is enabled, you can use it to create a VirtIO SCSI data volume.
2. Shared Volume: By default, VirtIO SCSI is enabled and cannot be disabled.
3. VirtIO SCSI data volumes allow multi-queue I/O operations and have worldwide names (WWNs) as their unique IDs.
4. We recommend that you do not create VirtIO SCSI data volumes on LocalStorage primary storage.

Figure 1. Create Non-Shared Volume Based on Disk Offering

Create Non-Shared Volume Based on a Volume Image #

On the displayed page, set the following parameters:

Name: Enter a name for the volume.
Description: Optional. Enter a description for the volume.
Quantity: Enter the number of volumes that you want to create.Note: You can only create one volume a time by using a volume image.
Volume Type: Select Non-Shared Volume.
Creation Method: Select Volume Image.
Instance: Optional. Select a VM instance or elastic baremetal instance to which the volume is attached.
Primary Storage: Optional. Select a primary storage on which the volume is created.Note: You can use a volume image stored on an ImageStore backup storage to create a volume on a Ceph primary storage.
VirtioSCSI: Choose whether to use the Virtio-SCSI bus to create an SCSI data volume.Note:
1. Classic Volume: By default, VirtIO SCSI is disabled. If it is enabled, you can use it to create a VirtIO SCSI data volume.
2. Shared Volume: By default, VirtIO SCSI is enabled and cannot be disabled.
3. VirtIO SCSI data volumes allow multi-queue I/O operations and have worldwide names (WWNs) as their unique IDs.
4. We recommend that you do not create VirtIO SCSI data volumes on LocalStorage primary storage.

Figure 2. Create Non-Shared Volume Based on Volume Image

Create Shared Volume Based on Disk Offering #

On the displayed page, set the following parameters:

Name: Enter a name for the volume.
Description: Optional. Enter a description for the volume.
Quantity: Enter the number of volumes that you want to create.Note: Enter an integer that ranges from 1 to 24.
Volume Type: Select Shared Volume.Note:
- You can create a shared volume on a Ceph primary storage or a Shared Block primary storage. Other types of primary storage do not support this operation.
- You cannot create a thin-provisioned shared volume on a Shared Block primary storage.
Creation Method: Select Disk Offering.
Primary Storage: Optional. Select a primary storage.
Instance: Optional. Select a VM instance or elastic baremetal instance to which the volume is attached.
VirtioSCSI: Choose whether to use the Virtio-SCSI bus to create an SCSI data volume.Note:
1. Classic Volume: By default, VirtIO SCSI is disabled. If enabled, you can use it to create a VirtIO SCSI data volume.
2. Shared Volume: By default, VirtIO SCSI is enabled and cannot be disabled.
3. VirtIO SCSI data volumes allow multi-queue I/O operations and have worldwide names (WWNs) as their unique IDs.
4. We recommend that you do not create VirtIO SCSI data volumes in LocalStorage primary storage.

Figure 3. Create Shared Volume Based on Disk Offering

Create Shared Volume Based on Volume Image #

On the displayed page, set the following parameters:

Name: Enter a name for the volume.
Description: Optional. Enter a description for the volume.
Quantity: Enter the number of volumes that you want to create.Note: You can only create one volume a time by using a volume image.
Volume Type: Select Shared Volume.Note:
- You can create a shared volume on a Ceph primary storage or a Shared Block primary storage. Other types of primary storage do not support this operation.
- You cannot create a thin-provisioned shared volume on a Shared Block primary storage.
Creation Method: Select Volume Image.
Instance: Optional. Select a VM instance or elastic baremetal instance to which the volume is attached.
Primary Storage: Optional. Select a primary storage on which the volume is created.Note: You can use a volume image stored on an ImageStore backup storage to create a volume on a Ceph primary storage.
VirtioSCSI: Choose whether to use the Virtio-SCSI bus to create an SCSI data volume.Note:
1. Classic Volume: By default, VirtIO SCSI is disabled. If enabled, you can use it to create a VirtIO SCSI data volume.
2. Shared Volume: By default, VirtIO SCSI is enabled and cannot be disabled.
3. VirtIO SCSI data volumes allow multi-queue I/O operations and have worldwide names (WWNs) as their unique IDs.
4. We recommend that you do not create VirtIO SCSI data volumes in LocalStorage primary storage.

Figure 4. Create Shared Volume Based on Volume Image

Notes #

You can batch create volumes only by using a disk offering.
If you create a volume by using a disk offering, you can select a primary storage and VM instance based on your business requirements:
- If you do not select a primary storage and VM instance, the created volume is in the uninstantiated state and is listed on the Uninstantiated tab.
- If you select a VM instance but do not select a primary storage:
  - When only one primary storage is available, the volume is created on the primary storage.
  - When multiple primary storage are available:
    - If all these primary storage are of the Local Storage type, the volume is created on the primary storage with the largest available space by default.
    - If all these primary storage are of the NFS or Shared Block type, the volume is created on a random primary storage by default.
    - If these primary storage are combinations of Local Storage and NFS primary storage, combinations of Local Storage and Shared Mount Point (SMP) primary storage, or combinations of Local Storage and Shared Block primary storage, by default, the volume is created on the primary storage that does not store the root volume of the VM instance the created volume you want to attach to.
    - If these primary storage are a combinations of Ceph and Shared Block primary storage, the volume is created on the primary storage with the largest available space by default.
- If you only select a primary storage and do not select a VM instance, the created volume is in the available state and takes up the storage space of the primary storage.Note:
  - If you select a Local Storage primary storage, you must select a host.
  - If you select a Ceph primary storage, you can select a Ceph storage pool.
  - If you select a Shared Block primary storage, you must select a provisioning method, including thin provisioning and thick provisioning.
    - Thin provisioning: allocates storage space to a volume according to its data amount. This method improves usage efficiency of storage space.
    - Thick provisioning: preallocates storage space that a volume needs. This method ensures sufficient storage space for a volume and thus ensures high storage performance.
If you create a volume based on a volume image and do not select a primary storage:
- If the volume image is stored on a Ceph backup storage, the volume is created on a Ceph primary storage.
- If the volume image is not stored on a Ceph backup storage:
  - When multiple primary storage are available:
    - If all these primary storage are of the Local Storage type, the volume is created on the primary storage with the largest available space by default.
    - If all these primary storage are of the NFS or Shared Block type, the volume is created on a random primary storage by default.
    - If these primary storage are combinations of Local Storage and NFS primary storage, combinations of Local Storage and Shared Mount Point (SMP) primary storage, or combinations of Local Storage and Shared Block primary storage, by default, the volume is created on the primary storage that does not store the root volume of the VM instance the created volume you want to attach to.
    - If these primary storage are a combinations of Ceph and Shared Block primary storage, the volume is created on the primary storage with the largest available space by default.

Manage a Volume #

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

The following table lists the actions that you can perform on a volume.

Action	Description
Create Volume	Create a new volume based on a disk offering or from a volume image.You can use a disk offering or volume image to create a classic volume or a shared volume.A shared volume must be created on a Ceph primary storage or a thick-provisioning Shared Block primary storage.A new volume is displayed on the Uninstantiated tab page if you do not specify a primary storage or VM instance for it.
Edit Volume	Edit the name and description of a volume.
Enable Volume	Enable a disabled volume.
Disable Volume	Disable an enabled volume.
Attach Instance	Attach a volume to an instance as its data volume.On a LocalStorage primary storage, make sure that the volume (if it is once instantiated) and the VM instance to be attached to are on the same host. Otherwise, migrate the volume and the VM instance to a same host.
Detach Instance	Detach a volume from the instance it attached to.Note: This action interrupts the data reads/writes of the volume and may affect the business continuity. Please exercise caution.
Change Host	Migrate a volume to another compute note.Allows you to choose target compute nodes according to their loads.On the Recommended list, you can make compute nodes ranked on their CPU allocation rate or memory allocation rate. By default, the compute nodes are ranked on their memory allocation rate from low to high.You can filter the top20 or top50 compute nodes according to their CPU allocation rate or memory allocation rate.You can only migrate a volume on a LocalStorage primary storage.
Change Primary Storage	Allows you to migrate a volume across primary storage of same type, including Ceph↔Ceph, NFS↔NFS, and Shared Block↔Shared Block. Changing primary storage only migrates valid data, and the migrated volume follows the provisioning type of the target primary storage.Ceph↔Ceph：Make sure that the volume is not attached to any VM instance.Make sure that the Mon notes of the original primary storage and the target primary storage can intercommunicate with each other.NFS↔NFS:Make sure that the volume is not attached to any VM instance.Make sure that the target NFS primary storage can be attach to the cluster of the volume.Shared Block↔Shared BlockYou can migrate a volume attached to a stopped VM instance across Shared Block primary storage.A shared volume to be migrated across Shared Block primary storage cannot be attached to any VM instance.Make sure that the target Shared Block primary storage can be attached to the cluster of the volume.Note:The original data of the volume is maintained on the original primary storage and displayed on the Data Cleanup tab page after the migration.You can manually cleanup the original data if you ensure that the volume data is integrity and undamaged after the migration. The cleaned data cannot be recovered. Please exercise caution.
Change Owner	Change the owner of the volume.The tenant tags are detached from the volume after you change its owner. Admin tags are not affected.
Resize Volume	Allows you to resize a root volume or data volume when the VM instance its attched to is running or stopped.The new size must greater than the original size and the increment must no smaller than 4 MB. The new size takes effect immediately.The new size must be a multiple of 4 MB. For example, if you enter a size of 37 MB, the actual volume size is 40 MB after the resize.You cannot resize a shared volume on a Shared Block primary storage.To resize a volume on a Ceph primary storage, make sure that the volume is not attached to any VM instance, or stop the VM instance it attached to in advance.We recommend that you manually create a snapshot before you resize the volume. This allows fast rollback when needed.
Attach Tag	Attach tags to a volume.You can make the tags sorted according to their attachment time or names. By default, the tags are sorted according to names. You can change the Tag Sort Method in Global Setting.Note:The priority of name sort: symbol > digit > Chinese character > English letter. English letters are case insensitive.After you upgrade a 3.4.0 or earlier version to the latest version, the resource tags are sorted by tag names by default.
Detach Tag	Detach tags from a volume.Note:Admin tags are created and owned by administrators (admin and platform managers). Tenant tags are created and owned by tenants (normal accounts and projects).Tenant tags can be attached to the resources belong to the tenant. Admin tags can be attached to any resources.Administrators can detach or delete tenant tags.Tags in a project are owned by the projects. All project members (project admin, project managers, and normal members) can perform on these tags.All tenant tags are detached from the volume after you change its owners. Admin tags are not affected.All old versions are displayed in the latest way after the seamless Cloud upgrade. You can refresh your browser or recreate the tags if exceptions occur.You can detach tags from a resource or detach resources from a tag in bulk.A tenant can detach tags only from the resources belong to the tenant. An administrator can detach tags from all resources.
Create Backup	Create a backup for a volume.Before you create a backup, make sure that the volume is attached to a VM instance and that the VM instance is in the running or paused state.If the VM instance attached by the volume has a CDP task, no backup can be created.If the authorized quota of the backup service is insufficient, no backup can be created.Note: Resources that are already within the authorized quota of the backup service can normally create backups or associate backup jobs.You cannot create a backup for shared volumes.You can create a full backup or an incremental backup for a volume.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.
Associate Backup Job	Associate a backup job with a volume.Volumes that already have backup jobs associated do not support this operation.Before you associate a backup job, make sure that the volume is attached to a VM instance and that the VM instance is in the running or paused state.Before you associate a backup job, make sure that the VM instance attached by the volume does not have a CDP task.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.
Create Volume Image	Create an image based on a volume. The image can be used to create new volumes.You can create a image for a volume on a Ceph primary storage and store the image in a ImageStore Backup storage.To create an image for a shared volume on a Shared Block primary storage, stop all VM instance that the shared volume is attached to in advance.
Create Volume Snapshot	Create a volume snapshot to record the volume state at a specified time point before important actions. This allows a quick rollback in case of breakdowns.A snapshot contains all volume data at one time point. You can use the snapshot to recover the volume to the stats at this time point. This is a temporal backup manual. For a long-term backup, we recommend that you use Backup Management.It may cost you a relatively long time to store the snapshot if you are creating a snapshot for the first time.You cannot create a snapshot for a shared volume.
Set Volume QoS	You can set a upper limit for a volume bandwidth by either setting its total speed or read/write speed.A normal account or project member can set QoS for any volume that is created from a disk offering without bandwidth limit. By default, a disk offering is not set with a bandwidth.If the disk offering is set with disk bandwidth, a normal account or project member can set QoS for volumes created from it, but the bandwidth of volumes cannot exceed the bandwidth of the disk offeringThe method a normal account or project member used to set a volume QoS should be the same as that used to set the disk bandwidth of the disk offering.
Flatten Volume	Merges multiple snapshots of selected resources into one flat snapshot 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.You cannot flatten a shared volume.You cannot flatten a disabled volume. Enable the volume and try again.You cannot flatten a volume if the VM instance attached by the volume has a running CDP task and primary storage of the volume is not Ceph.
Delete Volume	A deleted volume is displayed on the Recycle Bin tab page.Note:Deleting a volume detaches the volume from the VM instance it attached to and interrupts the volume reads/writes. Please exercise caution.Deleting a volume detaches the volume from the elastic baremetal instance it attached to and interrupts the volume reads/writes. Please exercise caution.
Expunge/Recover Volume	You can expunge or recover a deleted volume. A recovered volume is displayed on the Available tab page.

Volume Details #

Volume Snapshot #

Snapshot: A snapshot is a point-in-time capture of data status in a volume. Create a snapshot to store the volume state before you perform important actions. The snapshot helps you recover the volume data when exceptions occur during the action. However, this is only a temporal solution. For a long-term backup, we recommend that you use Backup Management.

Volume Snapshot Type #

Volume snapshots are categorized into the following two types:

Manual snapshot: Data volume snapshots that you manually create at any time points.
Automatic snapshot: Snapshots automatically created by scheduled jobs or by the system in specific scenarios.
- To use a scheduled job to create snapshots, configure a scheduled snapshot policy in advance. The system automatically creates snapshots on corresponding resources at specified time points.
- The system automatically create volume snapshots in the following scenarios:
  - Resizing a data volume.
  - Making a data rollback with a volume snapshot.Note:
    - By default, the system does not create volume snapshots automatically when you make a data rollback with a snapshot.
    - To make the system automatically create volume snapshots whenever a snapshot rollback occurs, follow this method:On the main menu of ZStack Cloud, choose Settings > Platform Setting > Global Setting > Advanced > Resource Center > Resource Pool > Snapshot. Enable Volume Snapshot Auto Creation.
  - Creating a data volume image on a Ceph primary storage.

Scenarios #

Snapshots apply to following scenarios:

Quick recovery from breakdowns: You can use a snapshot to recover the volume to a normal state when exceptions occur in a production environment. This is a temporal solution. For a long-term and more completed data protection, we recommend that you use Backup Management.
Data exploration: You can create snapshots based on production data, so as to provide a nearly real-time production data for exploration, report query, development, and testing.
Fault tolerance improvement: We recommend that you create on or more snapshots befire you perform important actions on resources, such as the system upgrading and data migration. You can quickly recover the data with the snapshots if exceptions occur during the upgrading or migration.

Create a Volume Snapshot #

You can create a snapshot on the details page of the volume. Follow these steps:

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > Volume. On the Volumepage, click a volume to enter its details page. On the volume details page, click Snapshot > Create Snapshot. Then the Create Volume Snapshot page is displayed.

If the volume is attached to a VM instance. You can create a snapshot for it on the VM instance details page. On the VM details page, choose Configuration Info > Resource Configurations > Volume. Click a volume to enter its details page. On the volume details page, click Snapshot > Create Snapshot. The the Create Volume Snapshot page is displayed.

Resize a Volume #

ZStack Cloud allows you to increasing the size of a volume. The resize procedure consists of resizing the volume on the Cloud and resizing the hard disk in the VM operating system.

Resize Volume on Cloud #

On the Volume page, locate the volume you want to resize. Click Actions > Resize Volume. Then, the Resize Volume dialog box is displayed.

Note:

The new size must greater than the original size and the increment must no smaller than 4 MB.
The new size must be a multiple of 4 MB. For example, if you enter a size of 37 MB, the actual volume size is 40 MB after the resize.
We recommend that you manually create a snapshot before you resize the volume. This allows fast rollback when needed.

Resize Hard Disk in VM Operating System #

The resize method varies according to the VM type, partition, and file system.

Note:

The risize operation has potential risks. For security reasons, we recommend that you plan a new partition for the new size.
Only increasing the volume size is supported
The increased size can be merged into the last partition for continuous use.

The following are three different resize scenarios:

Use the resize2fs command to resize the ext4 partition.Note: Resize partition is a risky operation. Please exercise caution. We recommend that you back up important data before the resize in case of data loss.Assume that the VM instance uses a CentOS7 operating system. The original size of the ext4 partition and the volume are both 60 GB. After the resize, the volume size is increased to 100 GB, and the new size is planned to be added to the ext4 partition.Procedure:
1. Run lsblk to query the current partition. You can see that the new size is not allocated to the disk partition.[root@10-0-18-185 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 8:0 0 60G 0 disk └─vda1 8:1 0 60G 0 part / sr0 11:0 1 1024M 0 rom sda 253:0 0 100G 0 disk └─sda1 253:1 0 60G 0 part /data
2. Run fdisk /dev/sda to recreate the partition.Note: The start sector of the new partition should be consistent with that of the original disk. Otherwise, the data may be lost.[root@10-0-18-185 ~]# fdisk /dev/sda 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): d # Delete the current partition Selected partition 1 Partition 1 is deleted Command (m for help): n # Create a new partition Partition type: # Set the partition type as primary p primary (0 primary, 0 extended, 4 free) e extended Select (default p): Using default response p Partition number (1-4, default 1): # Set the partition number as 1 First sector (2048-209715199, default 2048): # Set a start sector consistent with that of the original disk in case of data loss Using default value 2048 Last sector, +sectors or +size{K,M,G} (2048-209715199, default 209715199): # Set the end sector as the default value to allocate all disk space to the new partition Using default value 209715199 Partition 1 of type Linux and of size 100 GiB is set Command (m for help): w # Write these configurations into the disk 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.
3. Run partprobe to query the partition list.[root@10-0-18-185 ~]# partprobe
4. Run e2fsck -f /dev/sda1 to check whether the file system partition works as expected.[root@10-0-18-185 ~]# e2fsck -f /dev/sda1 e2fsck 1.42.9 (28-Dec-2013) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sda1: 12/2621440 files (0.0% non-contiguous), 209591/10485504 blocks
5. Run resize2fs to make the new size recognized by the xfs file system.[root@10-0-18-185 ~]# resize2fs /dev/sda1 resize2fs 1.42.9 (28-Dec-2013) Resizing the filesystem on /dev/sda1 to 26214144 (4k) blocks. The filesystem on /dev/sda1 is now 26214144 blocks long.
6. Run lsblk to query the current partition size.[root@10-0-18-185 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 100G 0 disk └─sda1 8:1 0 100G 0 part /data sr0 11:0 1 1024M 0 rom vda 253:0 0 60G 0 disk └─vda1 253:1 0 60G 0 part /
Use the xfs_growfs command to resize the xfs partition.Note:
- This solution applies to the dynamic xfs resize. You do not need to attach an ISO or use a LVM partition tool to manage the disk.
- The partition resize is a risky operation. We recommend that you back up important data before you exercise the resize.
Assume that the VM instance uses a CentOS 7 operating system. The original size of the xfs partition and the volume are both 60 GB. The xfs partition is mounted to /data. After the size, the volume size is increased to 100 GB, and the new size is planned to be added to the xfs partition.Procedure:
1. Run lsblk to query the current partition. You can see that the new size is not allocated to the disk partition.[root@10-0-44-210 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 8:0 0 50G 0 disk └─vda1 8:1 0 50G 0 part / sr0 11:0 1 1024M 0 rom sdb 253:0 0 100G 0 disk └─sdb1 253:1 0 60G 0 part /data
2. Detach the mount point.The changed partition cannot be occupied before you running partprobe. Run umount /data to detach the mount point of /dev/sdb1.[root@10-0-44-210 ~]# umount /data
3. Run fdisk /dev/sdb to recreate the partition.Note: The start sector of the new partition should be consistent with that of the original disk. Otherwise, the data may be lost.[root@10-0-44-210 ~]# fdisk /dev/sdb 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): d # Delete the current partition Selected partition 1 Partition 1 is deleted Command (m for help): n # Create a new partition Partition type: # Set the partition type as primary p primary (0 primary, 0 extended, 4 free) e extended Select (default p): Using default response p Partition number (1-4, default 1): # Set the partition number as 1 First sector (2048-209715199, default 2048): # Set a start sector consistent with that of the original disk incase of data loss Using default value 2048 Last sector, +sectors or +size{K,M,G} (2048-209715199, default 209715199): # Set the end sector as the default value to allocate all disk space to the new partition Using default value 209715199 Partition 1 of type Linux and of size 100 GiB is set Command (m for help): w # Write these configurations into the disk 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.
4. Run partprobe to query the partition list.[root@10-0-44-210 ~]# partprobe
5. Run mount /dev/sdb1 /data to attach the new partition to the mount point /data.[root@10-0-44-210 ~]# mount /dev/sdb1 /data
6. Run xfs_growfs /dev/sdb1 to make the new size recognized by the xfs file system.[root@10-0-44-210 ~]# xfs_growfs /dev/sdb1 meta-data=/dev/sdb1 isize=512 agcount=7, agsize=3932096 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0 spinodes=0 data = bsize=4096 blocks=26214144, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal bsize=4096 blocks=7679, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 data blocks changed from 16214144 to 28835584
7. Run lsblk to query the current partition size.[root@10-0-44-210 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 100G 0 disk └─sdb1 8:17 0 100G 0 part /data sr0 11:0 1 1024M 0 rom vda 253:0 0 50G 0 disk └─vda1 253:1 0 50G 0 part /
Resize the Windows partition.You can directly resize the Windows partition on the Disk Management page.Note: Rescan the disk after the resize.

Image #

What is Image? #

An image is a template file used to create a VM instance or volume. Images are categorized into system images and volume images.

A system image is used to create VM instances. A system image can be of the ISO or Image type.
A volume image is used to create volumes. A volume image can only be of the Image type.
Image-type images can be in the raw, qcow2, or vmdk format.
Images are stored on backup storage. When an image is used to create a VM instance or volume, the image is downloaded to a primary storage and cached there.

Add an Image #

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Compute Configuration > Image. On the Image page, click Add Image. The Add Image page appears.

The following lists the two image addition scenarios:

Add a system image.
Add a volume image.

Add System Image #

On the displayed page, set the following parameters:

Name: Enter a name for the image.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 image.
Image Type: System Image.
Image Format: Select an image format. You can select qcow2, iso, raw, or vmdk.Note: vmdk-formatted image files will be auto-converted to qcow2-formatted files if uploaded to an ImageStore backup storage, and to raw-formatted files if uploaded to a Ceph backup storage.
CPU Architecture: Select a CPU architecture for the image. VM instances created from the image use this CPU architecture.Note: If you select aarch64 or mips64, set the BIOS mode to UEFI.
Platform: Select an image platform type.The platform type of an image decides whether the VM instances created based on the image use KVM VirtIO drivers, including VirtIO disk drivers and VirtIO NIC drivers. The following lists the available platform types of an image:
- Linux: If VirtIO is enabled, the image operating system will attach VirtIO drivers, including a VirtIO disk driver and VirtIO NIC driver. If it is disabled, the image operating system will not attach VirtIO drivers, such as RHEL 5.8, and will use a QEMU device instead.
- Windows: If VirtIO is enabled, the image operating system will attach VirtIO drivers, including a VirtIO disk driver and VirtIO NIC driver. If it is disabled, the image operating system will not attach VirtIO drivers and use a QEMU device instaed.
- Other: If VirtIO us enabled, the image operating system will attach VirtIO drivers, including a VirtIO disk driver and VirtIO NIC driver. If it is disabled, the image operating system will use a QWMU device. Platforms of this type allows compatibility with earlier-version operationg systems that do not support VirtIO drivers.
OS: Select an operating system that is consistent with the image.
VirtIO: Choose whether to enable VirtIO according to your operating system and platform.
Backup Storage: Select a backup storage.
Image Path: Specify an image URL or upload a local file:
- URL: Enter a specified URL to add an image. You can enter a URL by using either of the following syntax:
  - A URL that starts with http or https:
    - Syntax: http://host[:port]/path/file or https://host[:port]/path/file.
  - A URL that starts with ftp:
    - Syntax that does not specifies the user: ftp://hostname[:port]/path/file.
    - Syntax that specifies the user: ftp://user:password@hostname[:port]/path/file.
  - A URL that starts with sftp:
    - Syntax that specifies the user identity: sftp://user:password@hostname[:port]/path/file
    - User-identity-free syntax: sftp://user@hostname[:port]/path/file.
  - The absolute path of an image file that is stored on a backup storage. The backup storage that stores the image file can be an ImageStore backup storage.Syntax: file:///path/file
  Note:
  - The image file to be added to the destination backup storage must exist and the backup storage needs to have access to the URL of the image file.
  - If you enter a URL that starts with sftp and does not specify user identity, make sure that you enable password-free SSH login to the server that stores the image file.
  - For the progress bar and resumption from breakpoint features:
    - If you use an ImageStore backup storage, a progress bar will appear to display the upload progress. In addition, upload resumption from breakpoints is also supported.
    - If you use a Ceph backup storage, a progress bar will appear to display the upload progress. However, upload resumption from breakpoints is not supported.
  - If you specify a URL with the file:/// syntax to add an image:
    - Ceph backup storage does not support the file:/// syntax.
    - The three forward slashes (/) in file:/// represents the absolute path of a file on a backup storage. For example, if you specify the URL file:///opt/dvd/image-1.4.qcow2, you add the image file named image-1.4.qcow2 in the /opt/dvd path of a backup storage to the Cloud.
- Local File: Select a local image file that the current browser can access and upload the image file to the specified backup storage. The backup storage that stores the image file can be an ImageStore or Ceph backup storage.Note: If you upload a local image file, the local browser serves as a transfer station. Do not refresh or close the browser or stop management node services. Otherwise, the image addition may fail.
BIOS Mode: Select a BIOS mode. You can select the Legacy or UEFI mode.
- Legacy: This mode supports all operating systems (OSs) and ensures stable operation. We recommend you select this mode.
- UEFI: If the CPU architecture is AArch64 or MIPS64EL, you must select UEFI. This mode supports Windows and CentOS. Note if you use Windows 7 or Windows Server 2008, make sure that the operating system uses CSM.
Note: Mode mismatch may make VM instances unable to work as expected. Select a mode according to your business needs:
- If you add an image in the qcow2 or raw format, select the mode used when the image was created.
- If you add an image in the iso format, you can select either of the two modes. OS will be boot based on the selected mode.
- If you want to boot the OS of a VM instance in UEFI mode, we recommend that you select a VM image that is created from one of the OS listed in the following table.OSBIOS ModeSupported VersionsWindowsUEFI
  - Windows 8 or later
  UEFI
  - Windows 7
  - Windows Server 2008 R2
  LinuxUEFI
  - CentOS 7.2
  - CentOS 7.3
  - CentOS 7.4 or later
- If you use a Window-based VM instance such as Windows Server 2012 R2, Windows Server 2016, or Windows 10 that has its OS boot in UEFI mode, the following figure will be displayed after you start the VM instance. In this case, press any key to continue the installation of the OS. Otherwise, the system will enter the UEFI Shell.Figure 1. Press Any Key to Continue
  
  If you have entered the UEFI Shell, run the following commands to exit the UEFI Shell:Shell> fs0: FS0:\> dir FS0:\> cd EFI FS0:\EFI\> cd BOOT FS0:\EFI\BOOT\> BOOTX64.EFIThen press any key in a timely manner. Otherwise, the system will reenter the UEFI Shell.
Enable CSM: Optional. Choose whether to use the CSM.The CSM can only be used for OSs that do not support or partially support the UEFI mode.Note: For Windows 7 and Windows Server 2008 R2, CSM must be enabled.
Support Elastic Baremetal Instance: Optional. Choose whether the image can be used to create an elastic baremetal instance. If enabled, the image can be used to create an elastic baremetal instance.Note: When you add an image of an elastic baremetal instance, make sure:
- The image has installed the agent. Otherwise, after you use the image to create an elastic baremetal instance, you cannot open the console or modify the password of the elastic baremetal instance. In addition, you cannot attach a volume or network to the instance or detach a volume or network from it.
- The BIOS mode of the image is the same the system configuration. Default: UEFI. If you want to use Legacy, contact the technical support.

Add Volume Image #

On the displayed page, set the following parameters:

Name: Enter a name for the image.
Description: Optional. Enter a description for the image.
Image Type: Select System Image.
Image Format: Select an image format. You can select qcow2, raw or vmdk.Note: vmdk-formatted image files will be auto-converted to qcow2-formatted files if uploaded to an ImageStore backup storage, and to raw-formatted files if uploaded to a Ceph backup storage.
Backup Storage: Select a backup storage.
Image Path: Specify an image URL or upload a local file.

Manage an Image #

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Compute Configuration > Image. Then, the Image page appears.

The following table lists the actions that you can perform on an image.

Action	Description
Add Image	Add an image to a backup storage.
Edit Image	Edit the name and description of an image.
Enable Image	Enable a disabled image.
Disable Image	Disable an enabled image. If you disable an image, you cannot use the image to create a VM instance. VM instances created by using the image before the disablement are not affected.
Export Image	Export one or more images. ImageStore and Ceph backup storage support image export. Exported images are displayed on the Exported tab.Note:Image exports from ImageStore backup storage may take a long time if the image size is great.You can also run the rbd command on a Ceph backup storage to export an image from the Ceph backup storage.An exported image cannot be exported again.
Change Backup Storage	Migrate data between shared storage across networks. Currently, this action is supported across Ceph backup storage.Note:To migrate data between Ceph backup storage, make sure that the MON nodes of these two backup storage are interconnected.If you migrate an ISO image to a backup storage of another zone, the VM instances using the image cannot be started. You need to detach the ISO image from the VM instances and then you can start them as expected.After the storage migration, the raw data is reserved in the source backup storage. You can go to the details page of the source Ceph backup storage and view the data on the Data Cleanup tab.You can Cleanup the raw data. Before you perform this operation, make sure that the storage-migrated data is intact. Cleaning up raw data will make the data unrecoverable. Proceed with caution.
Sync Image	Synchronize images that are stored in one or more backup storage to a specified backup storage that shares the same monitoring node with the source backup storage. Image synchronization is supported only by ImageStore backup storage.Note: To ease the pressure on the management network, you can set a network dedicated to image synchronizations by using either of the two methods:Set an image synchronization network when you add a backup storage to the platform.Set an image synchronization network on the details page of a backup storage. The setting takes effect immediately.
Set Sharing Mode	Set the sharing mode of a resource. The platform provides the following sharing modes:Share Globally: Shares the resource to all projects and accounts.Share to Specified Projects/Accounts: Shares the resource with specified projects and accounts.Not Share: Revokes the resource from projects and accounts to which the resource is shared. If you set Sharing Mode to Not Share for a resource, other projects and accounts cannot use the resource.Note:If you change the Sharing Mode setting of a resource from Share Globally to Share to Specified Projects/Accounts, the resource is visible only to the specified projects or accounts the resource is shared to.If the resource that you share to projects orthe specified accounts has been used by these projects or accounts and then you change the Sharing Mode of the resource, the change does not take effect on the projects or accounts. They can reverse and use the resource until it is released.
Delete Image	Delete an image. A deleted image is displayed on the Recycle Bin tab.
Recover Image	Recover a deleted image. If you recover a deleted image, the image is displayed on the Available tab.
Expunge Image	Expunge a deleted image. You can only expunge an image that is in the recycle bin.
Download Exported Image	Download an exported image. ImageStore and Ceph backup storages support this action. The download is implemented by the browser.Note: ImageStore backup storage allow you to view the MD5 value of the downloaded image to check whether the downloaded image is the same as the exported image.
Delete Exported Image	Delete an exported image.Note:In an ImageStore backup storage, image files are stored in the format of chips. Only when you export an image, or use an image, for example, to create a VM instance will a complete image file be produced. When you delete an exported image, only the complete image file is deleted. The image chips in the backup storage remain intact.In a Ceph backup storage, image files are stored in the format of blocks. When you delete an exported image, only the exported image file is deleted. The image in the Ceph backup storage remain intact.

Instance Offering #

What is Instance Offering? #

An instance offering defines the number of vCPU cores, memory size, network bandwidth, and other configuration settings of VM instances.

Create an Instance Offering #

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Compute Configuration > Instance Offering. On the Instance Offering page, click Create Instance Offering. Then, the Create Instance Offering page is displayed.

On the displayed page, set the following parameters:

Name: Enter a name for the instance offering.The instance offering name must be 1 to 128 characters in length and can contain Chinese characters, letters, digits, hyphens (-), underscores (_), periods (.), parenthesis (), colons (:), and plus signs (+).
Description: Optional. Enter a description for the instance offering.
CPU: Set the CPU cores of the VM instances to be created by the instance offering. Note that this value must be an integer. Unit: core. Valid values: 1 to 1024.
Memory: Set the memory size of the VM instances to be created by the instance offering. Note that this value must be an integer. Unit: MB, GB, and TB. Valid values: 16 MB to 100 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: Specify how the Cloud allocates a host for you to create a new VM instance. Default strategy: Host with min. running VMs.
- Host with min. running VMs: Allocates the host with the least running VM instances to the new VM instance.
- Host with min. CPU utilization: Allocates the host with the minimum CPU utilization to the new VM instance.Note:
  - The Cloud collects the host CPU loads over a period of time, calculates the average CPU utilization, and selects the host with the lowest CPU utilization to create the new VM instance.
  - By default, the Cloud collects data at an interval of 10 minutes. You can change the collection cycle through the following method:Choose Settings > Platform Setting > Global Setting > Advanced > Host, and edit Host CPU Utilization Collection Interval.
- Host with min. memory utilization: Allocates the host with the minimum memory utilization to the new VM instance.Note:
  - The Cloud collects the host memory loads over a period of time, calculates the memory average utilization, and selects the host with the lowest memory utilization to create the new VM instance.
  - By default, the Cloud collects data at an interval of 10 minutes. You can change the collection cycle by using the following method:Choose Settings > Platform Setting > Global Setting > Advanced > Host, and edit Host Memory Utilization Collection Interval.
- Host with max. running VMs: Allocates the host with the most running VM instances to the new VM instance. Before you can use this option, set the maximum number of VM instances that can run on a host. Then, the Cloud selects a host that meets the requirements to create the new VM instance. If no host is available, you will fail to create it.
- Host where the VM located last time: When you restart a stopped VM instance, the Cloud allocates it with the host where it was running last time.Note: If you start a VM instance for the first time, the Cloud allocates a host randomly.
- Random allocation: Randomly allocates a host to create the new VM instance.
Set Disk Bandwidth: Optional. Set an upper limit for the I/O bandwidth of a volume.If not set, the I/O bandwidth of the volume is not limited. Unit: MB/s, GB/s, and TB/s. You can set the I/O bandwidth by using either of the following methods:
- Total Speed: Set an upper limit for the total read and write speed of the volume.
- Read/Write Speed: Set an upper limit for the read or write speed of the volume.
  - Read Speed: Optional. Set an upper limit for the read speed of the volume.
  - Write Speed: Optional. Set an upper limit for the write speed of the volume.
Set Disk IOPS: Optional. Set an upper limit for reads/writes per second (IOPS) of a volume.If not set, the IOPS of the volume is not limited. You can set the IOPS by using either of the following methods:
- Total IOPS: Set an upper limit for the total IOPS of the volume.
- Read/Write IOPS: Set an upper limit for the read or write IOPS of the volume.
  - Read IOPS: Optional. Set an upper limit for the read IOPS of the volume.
  - Write IOPS: Optional. Set an upper limit for the write IOPS of the volume.
Set Network Bandwidth: Optional. Set an upper limit for the network bandwidth of a VM instance created by the instance offering.If not set, the network bandwidth of the VM instance is not limited. Unit: Kbps, Mbps, and Gbps. You can set the network bandwidth by using either of the following methods:
- Upstream Bandwidth: Optional. Set an upper limit for the network bandwidth used by the VM instance to upload data.
- Downstream Bandwidth: Optional. Set an upper limit for the network bandwidth used to download data from the VM instance.
Note: Before you make any settings, make sure that you fully understand the configurations of the disk bandwidth and network bandwidth. Otherwise, you might fail to upload files to or download files from a VM instance.
Advanced Parameter: Optional. Configure a JSON file to customize disk performance.Sample:{ "allocate": { "primaryStorage": { "type": "Enter a primary storage type. Valid values: Ceph, LocalStorage, NFS, and SharedBlock.", "uuid": "Enter the UUID of the primary storage.", "poolNames": [ "Enter a name for the Ceph pool. Delete this parameter if you do not specify a Ceph primary storage." ] } "clusterUuid":"Enter the cluster UUID." }, "priceUserConfig": { "rootVolume": { "priceKeyName": "Set the billing name for the root volume. Make sure that the advanced parameter setting in the pricing list is consistent with the setting here. Otherwise, the corresponding billing entries cannot be generated." } }, "displayAttribute": { "rootVolume": { "diskType": "Set the display type of the root volume. You can view this parameter setting on the VM details page." } } }The preceding configuration settings can be divided into the following three parts:
1. Set a primary storage and cluster for the root volume."allocate": { "primaryStorage": { "type": "Enter a primary storage type. Valid values: Ceph, LocalStorage, NFS, and SharedBlock.", "uuid": "Enter a primary storage UUID.", "poolNames": [ "Enter the name of a Ceph pool. Delete this parameter if you do not specify a Ceph primary storage." ] } "clusterUuid":"Enter a cluster UUID." }
  - type: Enter a primary storage type. Valid values: Ceph, LocalStorage, NFS, and SharedBlock. If you specify a Ceph primary storage, you can specify a Ceph pool.
  - uuid: Enter a primary storage UUID.
  - poolNames: Enter the name of a Ceph pool. Delete this parameter if you do not specify a Ceph primary storage.
  Note: If you do not need to specify a primary storage or a cluster, delete the corresponding codes.
2. Set a billing type for the root volume."priceUserConfig": { "rootVolume": { "priceKeyName": "Set a billing name for the root volume. Make sure that advanced parameter setting in the pricing list is consistent with this setting. Otherwise, the corresponding billing entries cannot be generated." } }
  - priceKeyName: Set a billing name for the root volume. Make sure that advanced parameter setting in the pricing list is consistent with this setting. Otherwise, the corresponding billing entries cannot be generated.
  Note: If you do not need billing settings, delete the preceding parameter settings.
3. Set the display attribute of the root volume."displayAttribute": { "rootVolume": { "diskType": "Set the display type for the root volume. You can view this parameter setting on the VM details page." } }
  - rootVolume: Set the display type for the root volume. You can view this parameter setting on the VM details page. You can also set multiple attributes in key-value pair format.
  Note: If you do not need special display, delete the corresponding codes.

Manage an Instance Offering #

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Compute Configuration > Instance Offering. Then, the Instance Offering page is displayed.

The following table lists the actions that you can perform on an instance offering.

Action	Description
Create Instance Offering	Create an instance offering.
Edit Instance Offering	Edit the name and description of the instance offering.
Enable Instance Offering	Enable the instance offering when it is disabled.
Disable Instance Offering	Disable an enabled instance offering.
Set Sharing Mode	Set the sharing mode of a resource. The platform provides the following sharing modes:Share Globally: Shares the resource to all projects and accounts.Share to Specified Projects/Accounts: Shares the resource with specified projects and accounts.Not Share: Revokes the resource from projects and accounts to which the resource is shared. If you set Sharing Mode to Not Share for a resource, other projects and accounts cannot use the resource.Note:If you change the Sharing Mode setting of a resource from Share Globally to Share to Specified Projects/Accounts, the resource is visible only to the specified projects or accounts the resource is shared to.If the resource that you share to projects orthe specified accounts has been used by these projects or accounts and then you change the Sharing Mode of the resource, the change does not take effect on the projects or accounts. They can reverse and use the resource until it is released.
Delete Instance Offering	Delete the instance offering. In this case, a dialog box will be displayed, asking you to confirm the deletion action.

Disk Offering #

What is Disk Offering? #

A disk offering defines the capacity and other configuration settings of volumes.

A disk offering can be used to create root volumes and data volumes.

Create a Disk Offering #

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > Disk Offering. On the Disk Offering page, click Create Disk Offering. Then, the Create Disk Offering page is displayed.

On the displayed page, set the following parameters:

Name: Enter a name for the disk offering.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 disk offering.
Disk Size: Set the capacity of a volume.
Set Disk Bandwidth: Optional. Set an upper limit for the I/O bandwidth of a volume.If you do not set this parameter, the I/O bandwidth of a volume is not limited. Unit: MB/s, GB/s, and TB/s. You can set the I/O bandwidth by using either of the following methods:
- Total Speed: Set an upper limit for the total read and write speed of a volume.
- Read/Write Speed: Set an upper limit for the read or write speed of a volume.
  - Read Speed: Optional. Set an upper limit for the read speed of a volume.
  - Write Speed: Optional. Set an upper limit for the write speed of a volume.
Set Disk IOPS: Optional. Set an upper limit for reads/writes per second (IOPS) of a volume.If not set, the IOPS of a volume is not limited. You can set the IOPS by using either of the following methods:
- Total IOPS: Set an upper limit for the total IOPS of a volume.
- Read/Write IOPS: Set an upper limit for the read or write IOPS of a volume.
  - Read IOPS: Optional. Set an upper limit for the read IOPS of a volume.
  - Write IOPS: Optional. Set an upper limit for the write IOPS of a volume.
Advanced Parameter: Optional. Configure a JSON file to customize the disk performance.The following is a sample JSON configuration file:{ "allocate": { "primaryStorage": { "type": "Enter a primary storage type. Valid values: Ceph, LocalStorage, NFS, and SharedBlock.", "uuid": "Enter the UUID of a primary storage.", "poolNames": [ "Enter the name of a Ceph pool. Delete this parameter if you do not specify a Ceph primary storage." ] } }, "priceUserConfig": { "volume": { "priceKeyName": "Set a billing name for a data volume. The advanced parameter setting of the billing type in the pricing list must be consistent with this setting. Otherwise, this billing entries cannot be generated." } }, "displayAttribute": { "volume": { "diskType": "Set the display type of a data volume. You can view this parameter setting on the volume details page." } } }The preceding configuration settings can be divided into the following three parts:
1. Configure the primary storage for a data volume:"allocate": { "primaryStorage": { "type": "Enter a primary storage type. Valid values: Ceph, LocalStorage, NFS, and SharedBlock.", "uuid": "Enter the UUID of a primary storage.", "poolNames": [ "Enter the name of a Ceph pool. Delete this parameter if you do not specify a Ceph primary storage." ] } }
  - type: Enter a primary storage type. Valid values: Ceph, LocalStorage, NFS, and SharedBlock. If you specify a Ceph primary storage, you can specify a Ceph pool.
  - uuid: Enter the UUID of a primary storage.
  - poolNames: Enter the name of a Ceph pool. Delete this parameter if you do not specify a Ceph primary storage.
  Note: If you do not specify a primary storage, delete the corresponding codes.
2. Configure the billing type for a data volume:"priceUserConfig": { "volume": { "priceKeyName": "Set a display name of the billing type for the data volume. The advanced parameter setting in the pricing list must be consistent with this setting. Otherwise, this billing type cannot be generated." } }
  - priceKeyName: Set a billing name for the data volume. The advanced parameter setting in the pricing list must be consistent with this setting. Otherwise, this billing entries cannot be generated.
  Note: If you do not need billing, delete the corresponding codes.
3. Configure the display attributes of a data volume:"displayAttribute": { "volume": { "diskType": "Set the display name of the data volume. You can view this parameter setting on the volume details page." } }
  - volume: Set the display name of the data volume. You can view this parameter setting on the volume details page. You can set multiple attributes in the key-value pair format.
  Note: If you do not need special display, delete the corresponding codes.

Manage a Disk Offering #

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Compute Configuration > Disk Offering. Then, the Disk Offering page appears.

The following table lists the actions that you can perform on a disk offering.

Action	Description
Create Disk Offering	Create a disk offering.
Edit Disk Offering	Modify the name and description of a disk offering.
Enable Disk Offering	Enable a disabled disk offering.
Disable Disk Offering	Disable an enabled disk offering. A disabled disk offering cannot be used to create volumes. However, the volumes created from the disk offering before the disablement are not affected.
Set Sharing Mode	Set the sharing mode of a resource. The platform provides the following sharing modes:Share Globally: Shares the resource to all projects and accounts.Share to Specified Projects/Accounts: Shares the resource with specified projects and accounts.Not Share: Revokes the resource from projects and accounts to which the resource is shared. If you set Sharing Mode to Not Share for a resource, other projects and accounts cannot use the resource.Note:If you change the Sharing Mode setting of a resource from Share Globally to Share to Specified Projects/Accounts, the resource is visible only to the specified projects or accounts the resource is shared to.If the resource that you share to projects orthe specified accounts has been used by these projects or accounts and then you change the Sharing Mode of the resource, the change does not take effect on the projects or accounts. They can reverse and use the resource until it is released.
Delete Disk Offering	Delete a disk offering.

GPU Specification #

What is GPU Specification? #

A GPU specification defines the frame per second (FPS), video memory, resolution, and other configuration settings of a physical or virtual GPU. GPU specifications are categorized into physical GPU specifications and virtual GPU specifications. ZStack Cloud supports GPUs installed on hosts. In ZStack Cloud, you can directly assign a single physical GPU to a VM instance, or share it among multiple VM instances running on the same host.

Physical GPU specification: defines the FPS, video memory, resolution, and other configuration settings of a physical GPU.
vGPU specification: defines the FPS, video memory, resolution, and other configuration settings of a virtual GPU virtualized from a physical GPU.

Auto-Scaling Group #

What is Auto-Scaling Group? #

An auto-scaling group is a group of VM instances that are used for the same scenarios. An auto-scaling group can automatically scale out or in based on application workloads or health status of VM instances in the group.

Characteristics #

Auto-Scaling
- Auto-Scaling consists of both scaling-out and scaling-in. When workloads increase, auto-scaling groups automatically scale-out by increasing VM instances in groups. When workloads decrease, auto-scaling groups automatically scale-in by reducing VM instances in groups.
- You can set an alarm notification for an auto-scaling group and specify an endpoint, such as system endpoint, Email, SMS, HTTP Application, DingTalk, and Microsoft Teams, to receive alarm messages.
Figure 1. Auto-Scaling
Auto-Healing
- An auto-scaling group automatically removes unhealthy VM instances and creates new VM instances based on VM health checks. Therefore, the healthy VM in the auto-scaling group are always no less than the minimum VM number you set.
- ZStack Cloud supports two health check method: load balancer-based health check and VM health check. We recommend that you use the load balancer-based health check if you configure a load balancer for the auto-scaling group.
Figure 2. Auto-Healing

Scenarios #

Followings are three scenarios that auto-scaling groups apply to:

Auto-Scaling-Out：During Double 11 festival, Spring festival, and other large holidays, some e-commerce companies launch activities to promote sales. This results in a workload surge. In this scenario, auto-scaling-out helps employ more VM instances to lower latency and avoid resource restraints.
Auto-Scaling-In：After the holidays, the business workloads of e-commerce companies decrease. In this scenario, auto-scaling-in helps reduce VM instances to avoid resource wastes.
Auto-Healing：To ensure a normal operation of companies’ core business, the number of running VM instance cannot be less than a certain threshold. In this scenario, auto-healing helps maintain the healthy VM number.

Supplements #

Auto-Scaling-Out Triggering Conditions

An auto-scaling group automatically scales-out when the VM utilization in the group exceeds the specified threshold.
- An auto-scaling group does not scale-out when it is cooling down.
- The VM instances in an auto-scaling group are always less than the maximum VM number you set.
- When the VM instances in an auto-scaling group achieve the maximum VM number, the auto-scaling group no longer scales out.
An auto-scaling group automatically scales out when the VM instances in the group are less than the minimum VM number.
- The VM instances in an auto-scaling group are always less than the maximum VM number you set.
- When the VM instances in an auto-scaling group achieve the maximum VM number, the auto-scaling group no longer scales out.

Auto-Scaling-In Triggering Conditions

An auto-scaling group automatically scales-in when the VM utilization in the group is lower than the specified threshold.
- An auto-scaling group does not scale-in when it is cooling down.
- The VM instances in an auto-scaling group are always greater than the minimum VM number you set.
- When the VM instance number in an auto-scaling group is equal to the minimum VM number, the auto-scaling group no longer scales in.
An auto-scaling group automatically scales-in when the VM instances in the group exceed the maximum VM number.
- The VM instances in an auto-scaling group are always greater than the minimum VM number you set.
- When the VM instance number in an auto-scaling group is equal to the minimum VM number, the auto-scaling group no longer scales in.

Auto-healing Triggering Conditions

An auto-scaling group exercise ab auto-healing when an unhealthy VM instance is in the group.

The unhealthy VM instance is automatically deleted. If the VM instances in the group are less than the minimum VM number after the deletion, the auto-scaling group scales out by creating a new VM instance.

ZStack Cloud provides global settings for auto-scaling groups.

For auto-scaling groups using load balancer-based health check, you can set the health check interval.Method: On the main menu of ZStack Cloud, choose Settings > Global Setting > Advanced > Network > Load Balance. Then, you can set Load Balanced Auto-Scaling Group Health Check Interval. Default: 10. Unit: second. Valid values: 10 to 1000.
For auto-scaling groups using load balancer-based health check, you can set health check concurrency.Method: On the main menu of ZStack Cloud, choose Settings > Global Setting > Advanced > Network > Load Balance. Then, set Load Balanced Auto-Scaling Group Health Check Concurrency. Default: 10. Valid values: 10 to 1000.
For auto-scaling groups using VM health check, you can set the interval to delete unhealthy VM instances.Method: On the main menu of ZStack Cloud, set Settings > Global Setting > Advanced > Resource Pool > Auto-Scaling. Then, set Unhealthy Instance Deletion Interval. Default: 30. Unit: Second. Valid values: 10 to 1000.
For auto-scaling groups using VM health check, you can set the unhealthy instance deletion concurrency.Method: On the main menu of ZStack Cloud, choose Settings > Global Setting > Advanced > Resource Pool > Auto-Scaling. Then, set Unhealthy Instance Deletion Concurrency. Default: 10. Valid values: 10 to 1000.
You can set the interval to check the instance number in auto-scaling groups.Method: On the main menu of ZStack Cloud, choose Settings > Global Setting > Advanced > Resource Pool > Auto-Scaling. Then, set Instance Number Check Interval. Default: 20. Unit: second. Valid values: 10 to 1000.

Considerations #

Following reasons may result in repeated auto-scaling actions, such as keeping creating or deleting VM instances:
- New VM instances cannot achieve a healthy status within a certain time after they are created. Then, the auto-healing policy deletes these unhealthy VM instances and creates new VM instances again. This forms a creating-deleting circulation. We recommend that you check the VM health check policy or change a check mechanism in this scenario.
- You set an unreasonable scaling-in or out threshold. For example, you set an auto-scaling group to scale in when the VM CPU utilization average is lower than 40%, and to scale out when the VM CPU utilization average is higher than 45%. Assume that there is one VM instance in the group and its CPU utilization is 60%. This triggers an auto-scaling out. And after the auto-scaling, the group contains two VM instances whose CPU utilization average is 30%, which then triggers an auto-scaling-in. This forms a scaling-out-and-in circulation. We recommend that you reasonable threshold for the scale-out and scale-in policies.
Following reasons may make an auto-scaling group keep triggering alarms but do not exercise a scaling-out action:
- You set an unreasonable maximum VM number or scaling-out trigger metric for the auto-scaling group. In this scenario, the VM utilization average is still higher than the scaling-out threshold even the VM instances in the group have achieved the maximum VM number. We recommend reset a reasonable maximum VM number or a scaling-out trigger metric for the group.
The business application running on the VM instances in an auto-scaling group must be stateless and scalable horizontally.
We recommend thay you do not manually attach volumes, NICs, or security groups to VM instances in an auto-scaling group for the group may automatically release VM instances.Note: The VM state information saved (if any) may loss.
Auto-scaling groups are not scalable vertically. This means that the instance offering, network bandwidths, and other configurations of the VM instance in the auto-scaling group are not automatically changed.
If you want to replace the external monitoring with internal monitoring for the trigger metric, you need to delete the auto-scaling group and recreate one.

Create an Auto-Scaling Group #

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Resource Service > Auto-Scaling Group. On the Auto-Scaling Group page, click Create Auto-Scaling Group. Then, the Create Auto-Scaling Group page is displayed.

To create an auto-scaling group, follow these steps:

Complete the basic configuration.To complete this step, set the following parameters:
- Zone: By default, the current zone is displayed.
- Group Name: Enter a name for the auto-scaling group.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 auto-scaling group.
- Initial VM Count: Enter the initial number of VM instances in the group.
  - If you create an auto-scaling group for the first time, the number of VM instances in the group is equal to the initial VM count you set.
  - The initial VM count must be an integer ranging from 1 to 1000. Make sure that the initial VM count is greater than the minimum VM count and smaller than the maximum VM count. Make your configurations as needed.
- Minimum VM Count: Enter the minimum number of VM instances in the auto-scaling group.
  - When a scale-in policy is configured, the number of VM instances in the auto-scaling group must not be smaller than that of the specified minimum VM count.
  - The minimum VM count must be an integer ranging from 1 to 1000. Make your configurations as needed.
- Maximum VM Count: Enter the maximum number of VM instances in the auto-scaling group.
  - When a scale-out policy is configured, the number of VM instances in the group must not be greater than that of the specified maximum VM count.
  - The maximum VM count must be an integer ranging from 1 to 1000. Make your configurations as needed.
- If you choose to configure the load balancing service (recommended), set the following parameters:
  - Load Balancer: Select a load balancer.
    - Before you can select a load balancer, create it first and then associate one or more listeners with it.
  - Listener: Select a listener that is associated with the load balancer.
    - The listener list displays all listeners associated with the load balancer.
    - If you select multiple listeners, they listen on their respectively configured ports of VM instances in the auto-scaling group.
  - Network: Select an L3 network used for creating VM instances.
    - If you do not use the load balancing service, you can select a VPC network or flat network. Specifically, the VPC network must be attached to a VPC vRouter.
    - If you use the load balancing service, the network you select must be included in the backend network of the load balancer.
  - Health Check Method: Select a health check method. We recommend that you choose Load Balancer.
    - VM-based health check: This method checks the health status of VM instances in real time. If a VM instance is detected in stopped, unknown, or deleted state, it is considered to be unhealthy. Then, the VM instance is automatically removed from the auto-scaling group and a new one is created. This ensures the number of healthy VM instances in an auto-scaling group is no less than the specified minimum VM count.
    - Load balancer-based health check: This method use the built-in mechanism of the load balancer.
  - Health Check Grace Period: Set the health check grace period after you select the load balancer-based health check method.
    - The health check grace period is a period of time after VM instances in the auto-scaling group are created and booted. During this period, application services related to these VM instances are probably still booting, and the auto-scaling group will not perform load balancer-based health checks. After this period, the health status of the VM instances are monitored based on the health check mechanism of the load balancer.
    - The grace period must be longer than 10 seconds. Enter an integer. Unit: second, minute, and hour.
- If you do not configure the load balancing service, set the following parameters:
  - Load Balancer: Leave this field blank.
  - Network: Select a private L3 network.Note: Currently, our auto-scaling service offers auto-scaling capabilities that let you automatically add or delete VM instances in the scenarios such as VPC networks and flat networks.
  - Health Check Method:
    - VM-based health check: This method checks the health status of VM instances in real time. If a VM instance is detected in stopped, unknown, or deleted state,it is considered to be unhealthy. Then, the VM instance is automatically removed from the auto-scaling group and a new one is created. This ensures the number of healthy VM instances in an auto-scaling group is not less than the specified minimum VM count.
- Enable Immediately After Creation: Choose whether to enable the auto-scaling group immediately after creation. By default, the group is not enabled immediately.
Figure 1. Basic Configuration
Complete the VM configuration.To complete this step, set the following parameters:
- VM Name: Enter a name for the VM instance.
  - VM instances in an auto-scaling group are named in the format of asg-Auto-Scaling Group Name-VM Name-First Five Digits of VM UUID. “asg” is an abbreviation of “autoscaling group”.
- Description: Optional. Enter a description for the VM instance.
- Instance Offering : Select an instance offering for the VM instance.
- Image: Select an image for the VM instance.Note:
  - The image of a VM instance in an auto-scaling group can be in qcow2 or raw format.
  - If you want to use the internal monitoring metrics, select an image with the agent installed, or install the agent manually by using the User Data script.
  - If you modify the image after you create a VM instance, the new image will only be effective for the subsequently created VM instances, and VM instances created before still remain the original image.
- Root Disk Offering: Optional. 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 do not select a disk offering, the size of the root disk offering is consistent with the size of the selected image.
- L3 Network: The L3 network you selected in the previous step is displayed.
- Advanced:
  - Data Disk Offering: Select a data disk offering. The data disk offering can be used to directly create data volumes and attach them to the VM instance.
  - 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.
  - Security Group: Select a security group. VM instances in the group share the same security group rules.
  - Console Password: Enter a password (VNC password) for the VM console. Password length: 6 to 18 characters.
  - SSH Public Key: Inject an SSH public key into the VM instance. By doing so, you can SSH in to the VM instance without a password.
    - Before you can inject an SSH public key into the VM instance, install cloud-init for the VM image first. Recommended cloud-init version: 0.7.9, 17.1, 19.4, 19.4, and later.
  - User Data: Import User Data. You can upload user-defined parameters or scripts to customize configurations for VM instances or to accomplish specific tasks.
    - Before you can import User Data to Linux-based VM instances, install cloud-init for the VM image first.The following is a sample script of importing User Data to a Linux-based 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.shThe sample script above implements the following functions:
      1. Creates a user with the name test for the VM instance and inject it with an ssh-key.
      2. Writes the /etc/hosts file when the VM instance starts. Meanwhile, creates a /tmp/temp directory, and write in the file under the directory.
      3. Sets a hostname, enable the user root, allow the user to SSH to the VM instance, and change the root password.
      4. Runs the echo ls -l / command.
    - Before you can import User Data to Windows-based VM instances, install Cloudbase-Init for the VM image first. For detailed information about the installation method, see Cloudbase-Init Documentation.The following is a sample script of importing User Data to a Windows-based 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 sample script above creates the b64, b64_1, and gzip files in the C drives when the VM instance starts.
    Note: When you use user data, note the following: If an L2 network has multiple L3 networks within the same CIDR, only the user data of the first L3 network takes effect. This will make the internal monitoring of the VM instance fail to work properly.
Figure 2. VM Configuration

Note: Exercise caution. If you delete resources, such as the instance offering, image, and network from the template configurations, you might fail to create the auto-scaling group.
Complete the scaling policy configuration.The Cloud provides two types of scaling policy: resource-based policy and periodic policy.
- Resource-based Policy: Configure the scale-out and scale-in policies based on the resource utilization. This policy type applies to the scenarios with unpredictable business changes to increase or decrease VM instances accordingly.
  - Trigger Metric: Select a trigger metric. Available trigger metrics are as follows:
    - VM Memory Utilization Average: The sum of the memory utilization of a single VM instance in the auto-scaling group/The total number of VM instances in the auto-scaling group
    - VM CPU Utilization Average: The sum of the CPU utilization of a single VM instance in the auto-scaling group/The total number of VM instances in the auto-scaling group
    - VM Memory Utilization Average (Agent Required): The sum of the memory utilization of a single VM instance in the auto-scaling group/The total number of VM instances in the auto-scaling group
    - VM CPU Utilization Average (Agent Required): The sum of the CPU utilization of a single VM instance in the auto scaling group/The total number of VM instances in the auto scaling group
    Note:
    - We recommend that you use an agent to monitor the average memory utilization of VM instances. The data monitored through this method is more accurate.
    - If you select trigger metrics that require an agent, make sure that you select an image with an installed agent when you create VM instances.
    - You can install agents by using the User Data script for Linux-based VM instances. For more information, see the User Data part in this topic.
    - If you did not install an agent for internal monitoring but select trigger metrics that require an agent, the auto-scaling group would fail to take effect.
  - Scale-out policy:
    - Trigger Rule: Set a trigger condition and the threshold duration.
      - The utilization must be an integer ranging from 1 to 100. Unit: %.
      - The threshold duration must be an integer that is greater than 0. Unit: second, minute, and hour.
    - Addition Policy: Enter the number of VM instances to be added each time when a scale-out action is triggered.Note: A minimum number of 1 VM instance can be added each time during the scale-out activity. If the value is too large, the scale-out activity might fail.
    - Cooldown Time: Set the cooldown time.
      - Cooldown time refers to a specified period after a successful scaling activity. During this period, the auto-scaling group is in the locked state and rejects to perform another scaling action.
      - The cooldown time must be an integer that is greater than 0. Unit: second and minute.
  - Scale-in policy:
    - When workloads decrease, auto-scaling groups automatically scale in to avoid resource waste.
    - Auto-scaling groups scale in based on the alarm rules that you set for the groups.For example, if the average memory utilization of all VM instances in an auto-scaling group keeps lower than 20% for a period of time, a reasonable number of VM instances are removed. This way, the workloads are well balanced at a reasonable level among the VM instances.
    To configure the scale-in policy, set the following parameters:
    - Trigger Rule: Set a trigger condition and the threshold duration. You can set to trigger the policy when the utilization greater than, less than, or equal to a specified value.
      - The utilization must be an integer ranging from 1 to 100. Unit: %. Note that the trigger rule set for the scale-out policy cannot conflict with that for the scale-in policy.
      - The threshold duration must be an integer that is greater than 0. Unit: second, minute, and hour.
    - Removal Policy: Select a removal policy and enter the number of VM instances to be removed each time when a scale-in action is triggered. Available removal policies are as follows:
      - Most Recent Created VM Instance (default): When the auto-scaling group starts scale-in activities, the latest created VM instances are removed successively at first.
      - Earliest Created VM Instance: When the auto-scaling group starts scale-in activities, the earliest created VM instances are removed successively at first.
      - VM with Minimum CPU Usage: When the auto-scaling group starts scale-in activities, VM instances with the minimum CPU usage are removed successively at first.
      - VM with Minimum Memory Usage: When the auto-scaling group starts scale-in activities, VM instances with the minimum memory usage are removed successively at first.
      Note: A minimum number of 1 VM instance can be removed each time during the scale-in activity. If the value is too large, the scale-in activity might fail.
    - Cooldown Time: Set the cooldown time.
      - Cooldown time refers to a specified period after a successful scaling activity. During this period, the auto-scaling group is in the locked state and rejects to perform another scaling action.
      - The cooldown time must be an integer that is greater than 0. Unit: second and minute.
  - Alarm Notification: Choose whether to enable alarm notification. You can configure a monitoring and alarm mechanism to trigger auto-scaling. By default, alarm notification is not enabled.
    - If enabled, you must specify one or more endpoints.Endpoint: Specify one or more endpoints.
      - You can either select the system endpoint (default) or select a custom endpoint such as email, DingTalk, HTTP application, short message service, and Microsoft Teams.
- Periodic Policy: Perform scale-out or scale-in policies periodically. This policy type applies to the scenarios with predictable business changes to increase or decrease VM instances periodically.
  - Scale-out policy:
    - Scale-out Period: Select a scale-out period. Options: scale-out by month, scale-out by week, scale-out by day, scale-out by hour, and scale-out by minute.
    - Execution Time: If you set the scale-out period as scale-out by month, scale-out by week, or scale-out by day, select an execution time for the scale-out activities.
    - Addition Policy: Enter the number of VM instances to be added each time when the auto-scaling group performs a scale-out activity.Note: A minimum number of 1 VM instance can be added each time during the scale-out activity. If the value is too large, the scale-out activity might fail.
    - Cooldown Time: Set the cooldown time.
      - Cooldown time refers to a specified period after a successful scaling activity. During this period, the auto-scaling group is in the locked state and rejects to perform another scaling action.
      - The cooldown time must be an integer that is greater than 0. Unit: second and minute.
    - Schedule Effective Time: Specify the time when the scale-out activities starts. The auto-scaling group executes scale-out actions according to the scale-in period since this time point.Note: You can set the effective time if you choose to scale-out by month, scale-out by week, or scale-out by day.
  - Scale-in policy:
    - Scale-in Period: Select a scale-in period. Options: scale-in by month, scale-in by week, scale-in by day, scale-in by hour, and scale-in by minute.
    - Execution Time: If you set the scale-in period as scale-in by month, scale-in by week, or scale-in by day, select an execution time for the scale-in activities.
    - Removal Policy: Select a removal policy and enter the number of VM instances to be removed each time when the auto-scaling group performs a scale-in activity. Available removal policies are as follows:
      - Most Recent Created VM Instance (default): When the auto-scaling group starts performing scale-in activities, the latest created VM instances are removed successively at first.
      - Earliest Created VM Instance: When the auto-scaling group starts performing scale-in activities, the earliest created VM instances are removed successively at first.
      - VM with Minimum CPU Usage: When the auto-scaling group starts performing scale-in activities, VM instances with the minimum CPU usage are removed successively at first.
      - VM with Minimum Memory Usage: When the auto-scaling group starts performing scale-in activities, VM instances with the minimum memory usage are removed successively at first.
      Note: A minimum number of 1 VM instance can be removed each time during the scale-in activity. If the value is too large, the scale-in activity might fail.
    - Cooldown Time: Set the cooldown time.
      - Cooldown time refers to a specified period after a successful scaling activity. During this period, the auto-scaling group is in the locked state and rejects to perform another scaling action.
      - The cooldown time must be an integer that is greater than 0. Unit: second and minute.
    - Schedule Effective Time: Specify the time when the scale-in activities starts. The auto-scaling group executes scale-in actions according to the scale-in period since this time point.Note: You can set the effective time when you choose to scale-in by month, scale-in by week, or scale-in by day.
Figure 3. Scaling Policy Configuration
Preview the configurations.Preview the configuration information about the auto-scaling group. You can modify the configurations by clicking the “Edit” icon.

Figure 4. Preview Configurations

Manage an Auto-Scaling Group #

On the main menu of ZStack Cloud, Choose Resource Center > Resource Pool > Resource Service > Auto-Scaling Group. Then, the Auto-Scaling Group is displayed.

You can perform following actions on an auto-scaling group.

Action	Description
Create Auto-Scaling Group	Create an auto-scaling group.
Edit	Edit the name and description of an auto-scaling group.
Enable Auto-Scaling Group	Enable a disabled auto-scaling group.
Disable Auto-Sacling Group	Disable an enabled auto-scaling group.
Add to VM Scheduling Group	Add all VM instances in the auto-scaling group to a VM scheduling group. After the addition, the scheduling policies associated with the group take effect on the VM instances immediately.
Remove from VM Scheduling Group	Remove all VM instances in the auto-scaling group from a VM scheduling group. After the removal, the VM instance will no longer be scheduled based on scheduling policies associated with the group.
Change Image	Change the image used to create the auto-scaling group.Note: The new image is only used to create new VM instances after the change and does not affect the existing VM instances.
Delete Auto-Scaling Group	Delete an auto-scaling group.

Snapshot #

What is Snapshot? #

A snapshot is a point-in-time capture of data status in a volume. Before you perform a business-sensitive operation, you can schedule snapshot creation at specified time points to record the state of the root volume, data volume, or memory of a VM instance. This allows rollback in case of breakdowns. If you want to backup data for a long term, you can use the Backup Service.

Snapshot Category #

Snapshots can be classified into the following two categories:

Manual snapshot: snapshots that are manually created for root volumes or data volumes.
Auto snapshot: snapshots that are automatically created at a scheduled time interval or in specific scenarios.
- To create auto snapshots for a resource at a scheduled time interval, you need to create a scheduled snapshotting policy for the resource. This way, the system creates snapshots at scheduled time points for the resource.
- The system may create an auto snapshot in the following scenarios:
  - Root volume capacity expansion
  - Data volume capacity expansion
  - VM reset
  - Snapshot rollbackNote:
    - By default, the system does not create a snapshot in the snapshot rollback scenarios.
    - You can enable or disable one-time snapshot-creation in snapshot rollback scenarios on the Global Setting page.Choose Setting > Platform Setting > Global Setting > Advanced > Resource Center > Resource Pool > Snapshot. Turn on or off the Auto Create Volume Snapshot switch according to your business needs.
  - Image creation of root volume or data volume on Ceph primary storage

Snapshot View #

ZStack Cloud provides the following two views of snapshots:

List view: In this view, snapshot information are displayed in a list, including their name, type, size, creation time, and supported operations.
Topology view: In this view, snapshots are displayed in a hierarchical tree with snapshot chains and snapshot nodes. You can locate the current snapshot, reset canvas, zoom in or out the canvas, and enter the full screen of the view.

Scenarios #

Snapshots can be used for the following scenarios:

Fast recovery from breakdowns: If the production environment breaks down, you can rollback snapshots to return to the normal state. Snapshot rollback is a temporary use for unexpected breakdowns. To backup data for a long term, we recommend that you use Backup Service.
Data exploration: You can create snapshots for production data and use the snapshots to do data mining, query, and development and test.
Fault tolerance improvement: Before you perform a business-sensitive operation such as upgrading your system or migrating data, we recommend that you create one or more snapshots. This allows fast recovery to the normal state in case of any errors or exceptions during the operation.

Snapshot Fundamentals #

Non-Ceph Storage QCOW2 External Snapshot Mechanism #

For non-Ceph storage, including LocalStorage, NFS, Shared Mount Point, and Shared Block, ZStack Cloud uses QCOW2 (QEMU Copy On Write, Version 2) external snapshot mechanism.

Snapshot Tree and Snapshot ChainA volume corresponds to a snapshot chain. ZStack Cloud allows you to create a snapshot tree for a volume. Each branch of the snapshot tree is a snapshot chain.Figure 1. Snapshot Tree
A snapshot tree includes the following information:
- Snapshot chain: a chain of snapshots of a volume that are associated with each other. Each branch of a snapshot tree is a snapshot chain.
- Snapshot node: a node in a snapshot chain that represents a snapshot of a volume.
- Snapshot size: the storage space that a snapshot occupies. You can view the total size of all snapshots in a snapshot tree and the size of an individual snapshot node.
Note:
- For non-Ceph storage, a snapshot node can have a maximum of 128 nodes by default. You can customize the maximum length of a snapshot chain Global Setting by setting Maximum Incremental Volume Snapshot. For Ceph storage, a snapshot node can have a maximum of 32 nodes, including the auto-created and manually-created nodes.
- When the length of a snapshot chain reaches the threshold:
  - If an auto-snapshot is created, the system automatically deletes the snapshot that was created at the earliest time.
  - If you manually create a snapshot, you need to manually delete the snapshot that you do not need.
- In the production environment, we recommend that you limit the number of snapshots created for a volume to 5. Too many snapshots will lower VM and volume performance, increase data security risks, and occupy storage space of primary storage. To back up data for the long term, you can use Backup Service.
Create SnapshotWhen an external snapshot is created, an empty qcow2 file is created. The backing file of the empty file points to the previous qcow2 file. This qcow2 file is set to read-only and become a snapshot. Data is written to the empty qcow2 file.
- Create single-chain snapshots based on the backing file.Figure 2. Create Single-Chain Snapshots
  
  Suppose you have a raw image. You use the image to create a VM instance named VM 1 and then create snapshot 1A and 1B for VM 1.
  - Raw image: a disk image file that includes a complete operating system and boot process. The image is a read-only file used as the base file.
  - VM 1: creates an empty file named Overlay-1. The backing file of the empty file points to the base file. The base file is kept read-only and becomes a snapshot. Data is written to Overlay-1.
  - Snapshot 1A: creates an empty file named Overlay-1A. The backing file of the empty file points to Overlay-1. Overlay-1 is set to read-only and becomes a snapshot. Data is written to Overlay-1A.
  - Snapshot 1B: creates an empty file named Overlay-1B. The backing file of the empty file points to Overlay-1A. Overlay-1A is set to read-only and becomes a snapshot. Data is written to Overlay-1B. Overlay-1B is the last snapshot in the snapshot chain and is in Active state. VM 1 uses the disk file that corresponds to the snapshot Overlay-1B.
- Create a multi-chain snapshot chain based on the backing file.Figure 3. Create Multi-Chain Snapshots
  
  Suppose you have a raw image. You use the image to create VM instances named VM 1, VM 2, and VM 3 and then create snapshot 1A and 1B for VM 1, snapshot 2A for VM 2, and snapshot 3A for VM 3.
  - Raw image: a disk image file that includes a complete operating system and boot process. The image is a read-only file used as the base file.
  - Snapshot chain 1:
    - VM 1: creates an empty file named Overlay-1. The backing file of the empty file points to the base file. The base file is kept read-only and becomes a snapshot. Data is written to Overlay-1.
    - Snapshot 1A: creates an empty file named Overlay-1A. The backing file of the empty file points to Overlay-1. Overlay-1 is set to read-only and becomes a snapshot. Data is written to Overlay-1A.
    - Snapshot 1B: creates an empty file named Overlay-1B. The backing file of the empty file points to Overlay-1A. Overlay-1A is set to read-only and becomes a snapshot. Data is written to Overlay-1B. Overlay-1B is the last snapshot in the snapshot chain and is in Active state. VM 1 uses the disk file that corresponds to the snapshot Overlay-1B.
  - Snapshot chain 2:
    - VM 2: creates an empty file named Overlay-2. The backing file of the empty file points to the base file. The base file is kept read-only and becomes a snapshot. Data is written to Overlay-2.
    - Snapshot 2A: creates an empty file named Overlay-2A. The backing file of the empty file points to Overlay-2. Overlay-2 is set to read-only and becomes a snapshot. Data is written to Overlay-2A. Overlay-2A is the last snapshot in the snapshot chain and is in Active state. VM 1 uses the disk file that corresponds to the snapshot Overlay-2A.
  - Snapshot chain 3:
    - VM 3: creates an empty file named Overlay-3. The backing file of the empty file points to the base file. The base file is kept read-only and becomes a snapshot. Data is written to Overlay-3.
    - Snapshot 3A: creates an empty file named Overlay-3A. The backing file of the empty file points to Overlay-3. Overlay-3 is set to read-only and becomes a snapshot. Data is written to Overlay-3A. Overlay-3A is the last snapshot in the snapshot chain and is in Active state. VM 1 uses the disk file that corresponds to the snapshot Overlay-3A.
Consolidate SnapshotsExternal snapshots are interdependent with each overlay snapshot depending on its backing file. Each snapshot captures certain amounts of data. You cannot directly delete a snapshot to shorten a snapshot chain. To shorten a snapshot chain, you can blockcommit or blockpull external snapshots.
- BlockcommitConsolidate overlay snapshots of a snapshot chain into backing files.Figure 4. Blockcommit
  
  Suppose you have a raw image. You use the image to create VM instance named VM 1 then create three dependent snapshots named 1A, 1B, and 1C for VM 1. Then you blockcommit snapshot 1A and 1B to VM 1. This makes the backing file of snapshot 1C which is in Active state points to VM 1 and shortens the snapshot chain. Snapshot 1A and 1B are no longer useful and you can delete the two snapshots.
- BlockpullConsolidate backing files of a snapshot chain into overlay snapshots.Figure 5. Blockpull
  
  Suppose you have a raw image. You use the image to create VM instance named VM 1 then create three dependent snapshots named 1A, 1B, and 1C for VM 1. Then you blockpull snapshot 1A and 1B to snapshot 1C of VM 1. This makes the backing file of snapshot 1C which is in Active state points to VM 1 and shortens the snapshot chain. Snapshot 1A and 1B are no longer useful and you can delete the two snapshots.

Ceph Storage Snapshot Mechanism #

For Ceph storage, ZStack Cloud uses the mainstream ROW (Redirect-On-Write) snapshot mechanism of Ceph.

Create a Snapshot #

The following lists the two snapshot creation scenarios:

Create VM snapshots:
- Single volume snapshot: creates a snapshot for the root volume of a VM instance.
- Snapshot group: creates snapshots for the root volume, data volumes, and memory of a VM instance.
Create volume snapshots: creates snapshots for data volumes.

Create VM Snapshot #

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > VM Instance. On the VM Instance page, select a running, stopped, or paused VM instance, and then choose Actions > Snapshot and Backup > Create Snapshot. Then, the Create Snapshot for VM Instance dialog box appears.

On the dialog box, set the following parameters:

Name: Enter a name for the volume.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 snapshot.
Snapshot Type: Select either of the following type of snapshots that you want to create:
- Single Volume Snapshot: creates a snapshot for the root volume of the VM instance.
- Snapshot Group: creates a group of snapshots for the volumes of the VM instance, including the root volume and data volumes.Note:
  - You cannot create snapshot groups for a VM instance to which shared volumes are attached.
  - 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.
  - Ceph primary storage does not support memory snapshots.

You can also create snapshots for a VM instance on its details page. On the details page, click the Snapshot tab. On the tab, click Create Snapshot. Then, the Create Snapshot for VM Instance dialog box appears. On the dialog box, set the required parameters and create a snapshot for the VM instance.

Create Volume Snapshot #

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Virtual Resource > Volume. On the Volume page, select a volume, and then choose Actions > Create Volume Snapshot. Then, the Create Volume Snapshot dialog box appears.

On the dialog box, set the following parameters:

Name: Enter a name for the volume.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 snapshot.

You can also create snapshots for a volume on its details page. On the details page, click the Snapshot tab. On the tab, click Create Snapshot. Then, the Create Volume Snapshot dialog box appears. On the dialog box, set the required parameters and create a snapshot for the volume.

Create Elastic Baremetal Instance Snapshot #

On the main menu of ZStack Cloud, choose Resource Center > Elastic Baremetal Management > Elastic Baremetal Instance. On the Elastic Baremetal Management page, locate an elastic baremetal instance. Click Actions > Create Snapshot. Then, the Create Elastic Baremetal Instance Snapshot page is displayed.

On the displayed page, set the following parameters:

Name: Enter a name for the snapshot. 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 snapshot.
Type: You can only create a snapshot for the elastic baremetal instance root volume.

You can also enter the details page of an elastic baremetal instance. On the details page, choose Snapshot tab and click Create Snapshot. Then, the Create Elastic Baremetal Snapshot is displayed.

Notes #

You can create a snapshot for a running or stopped instances.
You cannot create a snapshot group for an elastic baremetal instance.
You cannot create a snapshot group for a VM instance attached with shared volumes.
In the production environment, we recommend that you create a maximum of five snapshots for a volume. Excessive number of snapshots lowers I/O performance of volumes or VM instances, increases data security risks, and occupies storage space of primary storage. To back up data for the long term, you can use Backup Service.
In the production environment, we do not recommend that you create snapshots for VM instances with high I/O operations. This is because if a VM instance has high I/O operations, some data may be still in the memory and is not stored on the volume when you create a snapshot for the VM instance. This part of data is not reserved in the snapshot, thus affecting data integrity.
You cannot create a snapshot for a shared volume that is created on a Shared Block or Ceph primary storage.

Manage a Snapshot #

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Resource Service > Snapshot. Then, the Snapshot page is displayed.

Action	Description
Create VM Snapshot	Create a snapshot for a running or a stopped VM instance.VM snapshots are categorized into single snapshots and snapshot groups:Single snapshot: a snapshot based on the VM root volume.Snapshot group: snapshots created for both the VM root volume and the data volumes attached to the VM instance. You can revert snapshots in a snapshot group uniformly.Note: You cannot create a snapshot group for a VM instance attached with shared volumes.
Edit VM Snapshot	Edit the name and description of a VM snapshot.
Delete VM Snapshot	Delete a VM snapshot no longer required.Note:Snapshots created on a LocalStorage, NFS, NFS, or Shared Block primary storage are stored as a tree structure. Deleting a root snapshot also deletes snapshots and unbinds snapshot groups on its sub branches. Please exercise caution.Snapshots created on a Ceph primary storage are stored respectively instead of as a tree structure. Deleting a snapshot does not affect other snapshots.When you delete a snapshot in the tree structure, the system automatically figures out and deletes its associated snapshots.Deleting a snapshot group also deletes data volume snapshots in the group and snapshots on its sub branches. Please exercise caution.Deleting snapshots in bulk also deletes the snapshots and unbinds the snapshot groups on their sub branches. Please exercise caution.Before a snapshot on a LocalStorage, NFS, NFS, or Shared Block primary storage is deleted, the system merges the snapshot data to corresponding volumes first. This action occupies a certain capacity of the primary storage. If the primary storage capacity is insufficient, you might fail to delete the snapshot.Deleting a snapshot occupies I/O. Do not restart the management node service during this process.You cannot delete snapshot groups in bulk.You cannot delete snapshots and snapshot groups at the same time.You cannot delete a snapshot if it is used by linked clone VM instances. To delete the snapshot, flatten relevant resources and try again.
Revert VM Snapshot	Recover the VM instance to the state at the time point when you created the snapshot.Note:With a snapshot, you can recover the VM root volume to the state at the time point when you created the snapshot.With a snapshot group, you can recover both the VM root volume and data volumes to states at the time point when you created the snapshot group.Make sure that the VM instance is stopped before you revert the snapshot.You can set whether to make the VM instance start automatically after the snapshot reversion.If a VM snapshot cannot be reverted, check the following points:One or more data volumes snapshots in a snapshot group is deleted. Then, you cannot revert the snapshot group, but can only revert snapshots in it respectively.One or more data volumes attached to the VM instance are deleted. Then, you cannot revert the snapshot group, but can only revert snapshots in it respectively.One or more data volumes are detached from the VM instance. Then, you cannot revert the snapshot group, but can only revert snapshots in it respectively.The VM instance is attached with a new data volume. Then, you cannot revert the snapshot group, but can only revert snapshots in it respectively.
Unbind Snapshot Group	Restore the VM snapshot to a single snapshot and disassociated the VM instance from the data volume snapshots. This action is irreversible. Please exercise caution.

Action	Description
Create Volume Snapshot	Create a snapshot for a volume.Note: You cannot create a snapshot for a shared volume on a Shared Block primary storage.
Edit Volume Snapshot	Edit the name and description of a volume snapshot.
Delete Volume Snapshot	Delete a volume snapshot no longer required. You can delete volume snapshots in bulk.Note:Snapshots created on a LocalStorage, NFS, NFS, or Shared Block primary storage are stored as a tree structure. Deleting a root snapshot also deletes snapshots on its sub branches. Please exercise caution.Snapshots created on a Ceph primary storage are stored respectively instead of as a tree structure. Deleting a snapshot does not affect other snapshots.When you delete a snapshot in the tree structure, the system automatically figures out and deletes its associated snapshots.If the snapshot to be deleted is in a snapshot, deleting this snapshot also deletes snapshots on its sub branches. The action is irreversible. Please exercise caution.If you delete a root volume snapshot in a snapshot group, the group is unbound and other snapshots in the group become single snapshots.If you delete a data volume snapshot in a snapshot group, the group is not unbound but other snapshots in the group can be reverted only as single snapshots.Before a snapshot on a LocalStorage, NFS, NFS, or Shared Block primary storage is deleted, the system merges the snapshot data to corresponding volumes first. This action occupies a certain capacity of the primary storage. If the primary storage capacity is insufficient, you might fail to delete the snapshot.You cannot delete snapshot groups in bulk.You cannot delete snapshots and snapshot groups at the same time.You cannot delete a snapshot if it is used by linked clone volumes. To delete the snapshot, flatten relevant resources and try again.
Revert Volume Snapshot	Recover the volume data to the state at the time point when you create the snapshot.Note: Stop the VM instance the volume attached to or detach it from the VM instance before you revert the volume snapshot.

Action	Description
Create Elastic Baremetal Instance Snapshot	Create a snapshot for a running or stopped elastic baremetal instance.
Edit Elastic Baremetal Instance Snapshot	Edit the name and description of an elastic baremetal instance snapshot.
Revert Elastic Baremetal Instance Snapshot	Recover the elastic baremetal instance data to the state at the time point when you create the snapshot.Note:You can only recover the root volume data of the elastic baremetal instance to the state at the time point when you create the snapshot.You can revert the snapshot only for a stopped elastic baremetal instance. Before you revert a snapshot, stop the corresponding elastic baremetal instance.You can choose whether to make the elastic baremetal instance start automatically after the snapshot is reverted.
Delete Elastic Baremetal Instance Snapshot	Delete an elastic baremetal instance snapshot.Note:Snapshots created on a LocalStorage, NFS, NFS, or Shared Block primary storage are stored as a tree structure. Deleting a root snapshot also deletes snapshots on its sub branches. Please exercise caution.Snapshots created on a Ceph primary storage are stored respectively instead of as a tree structure. Deleting a snapshot does not affect other snapshots.When you delete a snapshot in the tree structure, the system automatically figures out and deletes its associated snapshots.Before a snapshot on a LocalStorage, NFS, NFS, or Shared Block primary storage is deleted, the system merges the snapshot data to corresponding volumes first. This action occupies a certain capacity of the primary storage. If the primary storage capacity is insufficient, you might fail to delete the snapshot.Deleting a snapshot occupies I/O. Do not restart the management node service during this process.

Snapshot Usage Suggestion #

This topic provides some suggestions for you to better use snapshots.

We recommend that you create less than 5 snapshots in a production environment. Too many snapshots negatively affect the VM/volume I/O performance, reduce the data security level, and occupy the primary storage space. For a long-term backup, we recommend that you use Backup Management.
We recommend that you do not schedule automatic snapshot creations frequently in a production environment. Frequent scheduled snapshots negatively affect the I/O performance, storage space, and business stability of a production environment.
- The snapshots created by frequent scheduled jobs affect VM business. For example, a VM instance on a Ceph primary storage reduces its write performance, and a VM instance on a LocalStorage or shared primary storage reduces its read performance if you create too many snapshots for it.
- The snapshots created by frequent scheduled jobs affects the I/O output of a primary storage.
- The snapshots created by frequent scheduled jobs occupy a large space on a primary storage.
For the data integrity, we recommend that you do not create a snapshot for a high-I/O VM instance. If you create a snapshot for the VM instance when it is exercising a high-I/O operation, you may fail to record the data that has not been stored by volumes to the snapshot.
The system capacity occupied by snapshots is as follow:
- In a LocalStorage or shared storage scenario, an incremental snapshot occupies only a small space, while a full snapshot occupies twice as much space.
- In a Ceph primary storage scenario, creating a snapshot does not occupy a storage space, but the Copy-On-Write triggered when you write in the disk may consume a space as much as the disk size.
The system automatically create snapshots in the following scenarios:
- Resizing a VM root volume.
- Resizing a data volume.
- Reimaging a VM instance.
- Using a snapshot to make a data rollback.Note:
  - By default, the system does not automatically create snapshots when you exercise snapshot rollbacks.
  - To make the system automatically create snapshots when you exercise snapshot rollbacks, follow these method:On the main menu of ZStack Cloud, choose Settings > Platform Setting > Global Setting > Advanced > Resource Center > Resource Pool > Snapshot. Enable Volume Snapshot Auto Creation.
  - We recommend that you create a snapshot for the volume to record its current data state before you make the snapshot rollback.
- Creating a root volume or data volume image on a Ceph primary storage.
The influence of snapshot creations on the business is as follow:In normal scenarios, creating a snapshot does not affect the business. If you create a full snapshot, it brings an excess storage network I/O. In a LocalStorage or shared storage scenarios, it occupies a certain disk I/O bandwidth, but brings little influence the disk IOPS.
The influence of snapshot deletion on the business is as follow:In normal conditions, deleting a snapshot also deletes the snapshots on its sub branches and merges the data to the disk. This brings an excess disk I/O, and slightly slows down the business I/O.

VM Scheduling Policy #

What is VM Scheduling Policy? #

A VM scheduling policy is a resource orchestration policy based on which VM instances are assigned hosts to achieve the high performance and high availability of businesses.

Create a VM Scheduling Policy #

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Resource Service > VM Scheduling Policy. On the VM Scheduling Policy page, click Create VM Scheduling Policy. Then, the Create VM Scheduling Policy page is displayed.

The following lists the four VM scheduling policy creation scenarios:

Create a VM scheduling policy of the VM Exclusive from Each Other type.
Create a VM scheduling policy of the VM Affinitive to Each Other type.
Create a VM scheduling policy of the VMs Exclusive from Hosts type.
Create a VM scheduling policy of the VMs Affinitive to Hosts type.

Create VM Exclusive from Each Other Scheduling Policy #

On the displayed page, set the following parameters:

Name: Enter a name for the VM scheduling policy.
Description: Optional. Enter a description for the VM scheduling policy.
Type: Select VM Exclusive from Each Other.
Execution Mechanism: The following two mechanisms are provided:
- Hard: VM instances are forcibly assigned hosts based on the VM Exclusive from Each Other policy. VM instances in the same VM scheduling group must not run on the same host. If no host is available to be scheduled based on the policy for a VM instance, the VM instance will end up failure upon startup.
- Soft: VM instances are primarily assigned hosts based on the VM Exclusive from Each Other policy. If possible, VM instances in the same VM scheduling group should not run on the same host. If no host is available to be scheduled based on the policy for a VM instance, the VM instance will attempt to run on a host that does not satisfy the policy while has sufficient resources.
Associate VM Scheduling Group: You can associate a VM scheduling policy with a new or existing VM scheduling group. After the association, the policy takes effect on all VM instances in the scheduling group:
- Existing: Associate the VM scheduling policy with an existing VM scheduling group.
  - VM Scheduling Group: Select an existing VM scheduling group.
- Create: Create a new VM scheduling group.
  - VM Scheduling Group Name: Enter a name for the VM scheduling group.
  - VM Instance: Select one or more VM instances to add to the scheduling group.

Create VM Affinitive to Each Other Scheduling Policy #

On the displayed page, set the following parameters:

Name: Enter a name for the VM scheduling policy.
Description: Optional. Enter a description for the VM scheduling policy.
Type: Select VM Affinitive to Each Other.
Execution Mechanism: The following two mechanisms are provided:
- Hard: VM instances are forcibly assigned hosts based on the VM Affinitive to Each Other policy. VM instances in the same VM scheduling group must run on the same host. If no host is available to be scheduled based on the policy for a VM instance, the VM instance will end up failure upon startup.
- Soft: VM instances are primarily assigned hosts based on the VM Affinitive to Each Other policy. If possible, VM instances in the same VM scheduling group should run on the same host. If no host is available to be scheduled based on the policy for a VM instance, the VM instance will attempt to run on a host that does not satisfy the policy while has sufficient resources.
Associate VM Scheduling Group: You can associate a VM scheduling policy with a new or existing VM scheduling group. After the association, the policy takes effect on all VM instances in the scheduling group:
- Existing: Associate the VM scheduling policy with an existing VM scheduling group.
  - VM Scheduling Group: Select an existing VM scheduling group.
- Create: Create a new VM scheduling group.
  - VM Scheduling Group Name: Enter a name for the VM scheduling group.
  - VM Instance: Select one or more VM instances to add to the scheduling group.

Create VMs Exclusive from Hosts Scheduling Policy #

On the displayed page, set the following parameters:

Name: Enter a name for the VM scheduling policy.
Description: Optional. Enter a description for the VM scheduling policy.
Type: Select VMs Exclusive from Hosts.
Execution Mechanism: The following two mechanisms are provided:
- Hard: VM instances are forcibly assigned hosts based on the VMs Exclusive from Hosts policy. Given any one of the VM instances in a VM scheduling group and any one of the hosts in a host scheduling group, the VM instance must not run the host. If no host is available to be scheduled based on the policy for a VM instance, the VM instance will end up failure upon startup.
- Soft: VM instances are primarily assigned hosts based on the VMs Exclusive from Hosts policy. Given any one of the VM instances in a VM scheduling group and any one of the hosts in a host scheduling group, the VM instance should not run the host if possible. If no host is available to be scheduled based on the policy for a VM instance, the VM instance will attempt to run on a host that does not satisfy the policy while has sufficient resources.
Associate VM Scheduling Group: You can associate a VM scheduling policy with a new or existing VM scheduling group. After the association, the policy takes effect on all VM instances in the scheduling group:
- Existing: Associate the VM scheduling policy with an existing VM scheduling group.
  - VM Scheduling Group: Select an existing VM scheduling group.
- Create: Create a new VM scheduling group.
  - VM Scheduling Group Name: Enter a name for the VM scheduling group.
  - VM Instance: Select one or more VM instances to add to the scheduling group.
Associate Host Scheduling Group: You can associate a VM scheduling policy with a new or existing host scheduling group. After the association, the policy takes effect on all hosts in the scheduling group:
- Existing: Associate the VM scheduling policy with an existing host scheduling group.
  - Host Scheduling Group: Select an existing host scheduling group.
- Create: Create a new host scheduling group.
  - Host Scheduling Group Name: Enter a name for the host scheduling group.
  - Host: Select one or more hosts to add to the scheduling group.

Create VMs Affinitive to Hosts Scheduling Policy #

On the displayed page, set the following parameters:

Name: Enter a name for the VM scheduling policy.
Description: Optional. Enter a description for the VM scheduling policy.
Type: Select VMs Affinitive to Hosts.
Execution Mechanism: The following two mechanisms are provided:
- Hard: VM instances are forcibly assigned hosts based on the VMs Affinitive to Hosts policy. A VM instance in a VM scheduling group must run on a host in a host scheduling group. If no host is available to be scheduled based on the policy for a VM instance, the VM instance will end up failure upon startup.
- Soft: VM instances are primarily assigned hosts based on the VMs Affinitive to Hosts policy. A VM instance in a VM scheduling group should run on a host in a host scheduling group if possible. If no host is available to be scheduled based on the policy for a VM instance, the VM instance will attempt to run on a host that does not satisfy the policy while has sufficient resources.
Associate VM Scheduling Group: You can associate a VM scheduling policy with a new or existing VM scheduling group. After the association, the policy takes effect on all VM instances in the scheduling group:
- Existing: Associate the VM scheduling policy with an existing VM scheduling group.
  - VM Scheduling Group: Select an existing VM scheduling group.
- Create: Create a new VM scheduling group.
  - VM Scheduling Group Name: Enter a name for the VM scheduling group.
  - VM Instance: Select one or more VM instances to add to the scheduling group.
Associate Host Scheduling Group: You can associate a VM scheduling policy with a new or existing host scheduling group. After the association, the policy takes effect on all hosts in the scheduling group:
- Existing: Associate the VM scheduling policy with an existing host scheduling group.
  - Host Scheduling Group: Select an existing host scheduling group.
- Create: Create a new host scheduling group.
  - Host Scheduling Group Name: Enter a name for the host scheduling group.
  - Host: Select one or more hosts to add to the scheduling group.

Manage a VM Scheduling Policy #

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Resource Service > VM Scheduling Policy. Then, the VM Scheduling Policy is displayed.

You can perform the following actions on a VM scheduling policy.

Action	Description
Create VM Scheduling Policy	Create a VM scheduling policy.
Edit VM Scheduling Policy	Edit the name and description of a VM scheduling policy.
Enable VM Scheduling Policy	Enable a disabled VM scheduling policy.
Disable VM Scheduling Policy	Disable an enabled VM scheduling policy.Note: If you disable a VM scheduling policy, the associated VM instances will not be scheduled based on the policy.
Change Execution Mechanism	Changes the execution mechanism of a VM scheduling policy. Two mechanisms are provided: Hard and Soft.
Delete VM Scheduling Policy	Delete a VM scheduling policy.Note: If you delete a VM scheduling policy, the associated VM instances will not be scheduled based on the policy.

SSH Key #

What is SSH Key? #

SSH Key: SSH key is a login authentication method of Linux VM instances. An SSH public key and an SSH private key work together as a pair.

Characteristics #

SSH key has the following characteristics:

Security: SSH key applies the asymmetric encryption mechanism, which help reduces the risk of brute force attacks.
Convenience: With the SSH key, you can access the target VM instance quickly without entering the password.
Restriction: You can use SSH keys to access Linux VM instances as root users.

Quick Start #

You can quickly get started with SSH key by following these steps:

Create a SSH key pair and keep the private key well.
Attach the SSH public key to a VM instance.
Upload the SSH private key to the access terminate, and run ssh -i ${private_key.pem} ${UserName}@${IpAddress} to log in to the VM instance.

Note: In the login command, ${private_key.pem} refers to the private key file path, ${UserName} refers to the username, and ${IpAddress} refers to the IP address of the VM instance to be logged in to. For example,ssh -i private_key.pem root@172.20.20.149

For more information, see Log in to VM Instance with SSH Key.

Create an SSH Key #

On the main menu of ZStack Cloud, choose Resource Center > Resource Pool > Security > SSH Key. On the SSH Key page, click Create SSH Key. Then, the Create SSH Key page is displayed.

On the displayed page, set the following parameters:

Name: Enter a name for the SSH key.
Creation Method: Select a creation method. ZStack Cloud supports two methods to create SSH keys: Generate New SSH Key Pair and Import Existing Key.
- You can choose Generate New SSH Key Pair to create an SSH public key and an SSH private key.Note: ZStack Cloud saves the public key only. The private key is downloaded to local automatically and kept by yourself. Note that it cannot be retrieved if lost.
- You can choose Import Existing Key to import the public key among the SSH key pair you generate through other methods and enable it to be managed and used on the Cloud. If you choose this option, set the following parameter:
  - Public Key: Copy the public key you have generated and paste it here. The following encryption are supported: ssh-rsa, ssh-dss, ecdsa-sha2-nistp256, ssh-ed25519, ssh-ecdsa .

Manage an SSH Key #

On the main menu of ZStack Cloud, click Resource Center > Resource Pool > Security > SSH Key. Then, the SSH Key page is displayed.

The following table lists the actions that you can perform on an SSH key.

Action	Description
Create SSH Key	Generate an SSH key pair or import an SSH public key.
Edit SSH Key	Modify the name and description of an SSH key.
Associate VM Instance	Associate an SSH public key with a VM instance. Then, you can SSH into the VM instance with the corresponding private key. An SSH key can be associated with one or more VM instances.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.
Disassociate VM Instance	Disassociate 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.
Delete SSH Key	Delete the SSH public key information from the Cloud. If the SSH key has been attached to a VM instance, detach it from the VM instance before you can delete it.