Three Core Attributes

1. Instance Offering:

   Define CPU and memory size for a VM instance. Before resources are allocated, ZStack will select the host that has these resources to act as a candidate host, and then use the candidate host to create a VM instance.

2. Image:

   Determine which image can be used to create a VM instance.

   When you select an image, note the following:

   • If a backup storage attached by the image is ImageStore, ZStack will automatically select a cluster that is attached by a type of primary storage such as LocalStorage, NFS, SharedMountPoint, Ceph, or SharedBlock to act as a candidate cluster.
   • If a backup storage attached by the image is SFTP (for Community version only), ZStack will automatically select a cluster that is attached by a type of primary storage such as LocalStorage, NFS, or SharedMountPoint to act as a candidate cluster.
   • If a backup storage attached by the image is Ceph, ZStack will automatically select the cluster attached by the Ceph primary storage that corresponds to the Ceph backup storage.
3. Network:

   Specify one or more networks for a VM instance. After you select an image, an available cluster has been assigned for the VM instance. Also, ZStack will provide available networks attached by the cluster.

Note:

• After you complete configuring the preceding three attributes, various resources necessary to create the VM instance are all ready. In that case, available resources can be filtered in order of: the image attached to the backup storage->clusters available to the backup storage->associated networks available to the cluster.
• If you select the network attached by multiple clusters that satisfy the preceding requirements, you can continue to filter the corresponding resources such as a cluster, primary storage, and host by expanding Advanced.
• When you fail to select the L3 networks that you created, we recommend that you check whether:
  1. The L2 network attached by an L3 network attaches the corresponding cluster.
  2. The corresponding cluster has attached the corresponding primary storage.

Multi-Primary Storage Strategy

• If a cluster has multiple LocalStorage primary storages attached:
  • You can specify any LocalStorage primary storage when you create a VM instance.
  • If you do not specify a primary storage, the system will automatically select the local primary storage that has the most available capacity.
• If a cluster has multiple shared primary storages attached (currently, multiple NFS primary storages or Shared Block primary storages are supported):
  • You can specify any NFS or Shared Block primary storage when you create a VM instance.
  • If you do not specify a primary storage, the system will automatically allocate an NFS or a Shared Block primary storage that is available.
• If a cluster has a combination of primary storages attached (currently, the supported combinations include: 1 LocalStorage + 1 NFS, 1 LocalStorage + 1 SMP, 1 LocalStorage + 1 Shared Block):
  • You can specify any primary storage when you create a VM instance.
  • When you create a VM instance, if you create a data volume and attach it to the VM instance at the same time, you need to specify a primary storage for the data volume.
  • If you do not specify a primary storage, the system will automatically use a local primary storage to create a VM instance.

VM Instance Operations

• Start:

  Start a VM instance that is in the stopped state. Then, this VM instance will work normally. When you started a VM instance, the last host where the VM instance resides will be enabled by default.

  When you start a VM instance, note the following:

  Scenario	VM Start
  The cluster where the VM instance resides only attaches one or more local storages.	The VM instance can only be started on the last host where the VM instance resides.
  The cluster where the VM instance resides only attaches one or more shared storages. Currently, multiple NFS or SharedBlock primary storages are supported.	The VM instance can be started on the available hosts attached by the primary storage.
  The cluster where the VM instance resides attaches different types of primary storages. Currently, a combination of 1 LocalStorage + 1 NFS, 1 LocalStorage + 1 SMP, or 1 LocalStorage + 1 SharedBlock are supported.	If the VM instance uses the root volume or data volume of a local storage, this VM instance can only be enabled on the last host where the VM instance resides. If this VM instance only uses a shared storage or shared storage with a data volume, this VM instance can be started on the available hosts attached by the primary storage.

  If you fail to start the VM instance, make sure that you check whether:

  • Hosts are connected to and enabled in the cluster where the VM instance resides. If no connected hosts are available, you will prompt for the information that you cannot find any available hosts.
  • Resources of the hosts running on the cluster, such as CPU and memory, are sufficient. Assume that all hosts running on the cluster have their own separate available CPUs and memories. If these CPUs and memories are insufficient to allocate to the VM instance, the Cloud will prompt you that you cannot find any available hosts.
  • The cluster where the VM instance resides attaches an L2 network. If the cluster has not attached any L2 network, the corresponding L3 network will not be assigned for this VM instance. Then, the Cloud will prompt you that this VM instance has no available networks and cannot be started.
  • The L2 network corresponded by the cluster where the VM instance resides is attached to an L3 network. If the L2 network attached by the cluster is not attached to any L3 network, this VM instance cannot attach any L3 network. Then, you will prompt for the information that this VM instance has no available networks and cannot be started.
  • The cluster where the VM instance resides is attached to a primary storage. If the cluster is not attached to any primary storage (generally, the case occurs after a primary storage is detached), you will prompt for the information that no root volumes of this VM instance are found. In that case, attach the original primary storage to the cluster before the VM instance can be normally started.
  • The primary storage where the cluster resides has availably sufficient capacities. This can be judged when you create the VM instance. If the primary storage cannot provide sufficiently required capacities for the VM instance, you will prompt for insufficient capacities of the primary storage.
• Stop:

  Stop the VM instance that is in the running state. The VM instance will be stopped normally.

• Reboot:

  Reboot the VM instance that is in the running state. During rebooting, all configurations for the VM instance will be updated, including boot order, console mode, USB redirection, and session count control.

• Power off:

  Power off the VM instance that is in the running state. That is, the VM instance will be forced to stop. Exercise caution. Performing this operation will put you at risk of losing data.

• Pause:

  Pause the VM instance. The VM instance will continue to consume memories or resources, but will temporarily not schedule hypervisors. Notice that the VM instance can be either resumed to the running or deleted state.

• Resume:

  Resume the VM instance that is in the paused state. Hence, the VM instance can continue to run normally.

• Delete:

  Delete the VM instance. If the VM instance is running, the VM instance will be powered off and enters deleted state. If the VM instance is in other states or statuses, the VM instance will enter directly deleted state.

• Restore:

  Restore the VM instance that is in the deleted state to the stopped state.

• Expunge:

  Expunge the VM instance that is in the deleted state. Afterwards, the VM instance will be expunged from ZStack, and the storage space actually occupied by the root volume will be released.

• Open console:
  Let you access the VM instance via the VNC mode. Ensure that your browser can reach the IP address of the console proxy. If you open the console of the VM instance successfully, but do not receive any content, verify that the IP address specified by the console proxy can be normally accessible to your guests (laptop). Change the IP address of the console proxy as required.

  Note: To change the IP address of a console proxy, choose Platform Management > Console Proxy.
• Local storage migration:

  Mainly refer to the cold migration for root volumes or data volumes. Before cold migration, detach associated data volumes for the VM instance.

  Local storages also support hot migration. Make sure that you enable this service globally. Notice that this operation is not supported by the Windows VM instance. Before hot migration, detach associated data volumes from the Windows VM instances.

• Network shared storage migration:

  To achieve real-time hot migration, mainly copy memories and registers related to CPU. To support migrations across clusters, both destination cluster and source cluster are only required to attach a network and a primary storage used by the VM instance. If these clusters are attached to multiple types of primary storages, detach volumes for the VM instance before migrations are performed.

• Create image:
  Encapsulate the VM instance as an image which can be used to create more VM instances.

  • Create image online: When the VM instance is running, ImageStore and Ceph backup storages let you create an image online.
  • Create image offline: When the VM instance is stopped, various types of backup storages let you create an image.
• Create VM snapshot:
  Before important operations are performed, ensure that the root volume or data volumes are temporarily reserved at a specific time, which can be used to quickly let you perform rollback after failures appear. If you need a long-term backup, use the related backup service. A VM snapshot includes the following types:

  • Single snapshot: Take only snapshots for the root volume of the VM instance.
  • Batch snapshot: Take batch snapshots for the root volume and all data volumes. While you create a VM snapshot, all data volumes attached by the VM instance will be taken snapshots as well. Batch snapshots can be recovered centrally as a unit.
  • You can create snapshots for running or stopped VM instances.
  • You cannot create batch snapshot for VM instances that have a shared volume attached.
  • In a production environment, we recommended that you limit the number of snapshots per disk within 5. Excessive snapshots might affect the I/O performance, data security, and primary storage capacity of the corresponding VM instances and volumes. For long-term backup, we recommend that you use disaster recovery related services.
  • To ensure data integrity in a production environment, we recommend that you do not take snapshots for VM instances with high I/O. When a high I/O operation is performed in a VM instance, some data in the VM memory might fail to be saved to the disk. In this case, these data will not be saved to the snapshot you created for the VM instance.
  • The snapshot of the VM instance on the Ceph primary storage does not occupy capacity. Therefore, the displayed snapshot capacity is the actual capacity of the VM root volume when the snapshot was created.
  • For Ceph primary storages, the VM snapshot capacity might fail to be obtained. Here are some statements:
    • Open source Ceph (version H) and enterprise-level Ceph (earlier than 3.2.0) cannot obtain VM snapshot capacity.
    • Due to the RBD format, enterprise-level Ceph (3.2.0 and later versions) may fail to obtain VM snapshot capacity.
  Note:

  • Snapshots, a short-term solution, mainly can be used in test and development environments. Specifically, these snapshots can quickly be used for packing, upgrading, or testing your Cloud. When normal failures appear, rollbacks can be performed. We recommend that you do not use snapshots in your production environment. However, under some circumstances, snapshots can still be applied to your production environment. For example, if you perform dangerous operations, the probable damage to the operating system may occur due to upgrading or configuration modifications. Then, snapshots are a preferred solution.
  • We recommend that you do not use snapshots in your production environment. The following are the two probable considerations:
    • Data integrity

      When you use snapshots, you are not creating a copy of the virtual hard disk. But actually, you need to create a copy of the VM virtual disk. If the virtual disk is damaged, the snapshot will be invalid, which means that the snapshot cannot be used to recover the damaged disk. Notice that the snapshot cannot be used to solve disk failures. So, you will still encounter a single point of failure.

    • VM performance

      Using too many snapshots will influence the performance of a VM instance. For example, if the old snapshot runs on the VM instance with excessive overloads, this old snapshot will be increased in size, and then the performance of the VM instance will be definitely slowed down. Or, if you create a large number of snapshots, the performance of the VM instance will be also slowed down.

      Reserving a snapshot of a VM instance for a long time is a common mistake. The snapshot will increase in size as the time goes by. Also. the snapshot files will also be changed, and are not stored on the source disk. Hence, restoring the snapshot will take a long time. Also, during restoring, the VM instance may be forced to stop.

• Restore snapshot:

  Restore the VM instance to the current snapshot point. By doing so, the data related to the volume will be reverted to the snapshot point. Before restoring the snapshot, make sure that you back up the volume data of the VM instance.

  Note:

  • For a single snapshot, you can only restore the VM root volume to the time of point when the snapshot was taken.
  • For a batch snapshot, you can restore both the root volume and data volume to the time of point when the snapshot was taken.
  • You can restore snapshots only for VM instances that are stopped. Before you restore a snapshot, stop the corresponding VM instance.
  • You can choose whether to automatically start the corresponding VM instance after restoring from a snapshot.
  • If a VM batch snapshot is displayed as not restorable, the possible reasons are as follows:
    • At least one data volume snapshot in the batch snapshot was deleted. In this case, you can only restore single snapshots.
    • At least one data volume attached by the VM instance was deleted. In this case, you can only restore single snapshots.
    • At least one data volume attached by the VM instance was detached. In this case, you can only restore single snapshots. To restore the batch snapshot, attach the detached data volumes to the VM instance again.
    • The VM instance has a new data volume attached. In this case, you can only restore single snapshots. To restore the batch snapshot, detach the new data volume from the VM instance.
• Delete snapshot:
  Delete the unnecessary snapshots. Snapshots can be deleted in bulk.

  Note:

  • Snapshots created on local storage, NFS, SMP, and Shared Block storages have a tree structure. Deleting the root snapshot will also delete snapshots on the branches and detach the batch snapshots on the branches. Please exercise caution.
  • Snapshots created on the Ceph shared storage are independent and do not have a tree structure. Deleting a snapshot will not affect other snapshots.
  • When you delete snapshots in a tree structure in bulk, the cloud automatically calculates and deletes the candidate snapshots and cascades the delete operation to the associated snapshots.
  • If the snapshots to be deleted contain batch snapshots, note that:
    • Deleting a batch snapshot will also delete the data volume snapshots in the batch snapshot and the snapshots on the branches. Please exercise caution.
    • Deleting single snapshots and batch snapshots in bulk will also delete the single snapshots on the branches and detach the batch snapshots on the branches.
• Detach batch snapshot:

  Detach a VM batch snapshot to a single snapshot. Also, the group relationship between the VM instance and its related volume snapshots will be detached. Exercise caution. After detaching the relationship, you cannot restore snapshots in bulk.

• Clone:

  Copy the root volume and data volumes for the VM instance. Based on the instance offering of the VM instance, a new VM instance will be cloned from and then have the identical operating system as the VM instance.

  • Cloning VM instances online only applies to the disk data that have been written when a cloning job begins, excluding the real-time cache data. To ensure data integrity, high I/O VM instances are recommended to enter paused or stopped state before a cloning job is performed.
  • Configurations, installation programs, and passwords of a VM instance will be copied to the newly cloned VM instance. However, copies of other configurations are not included, such as tags and scheduled jobs.
  • Assume that the cloned VM instance is in the running state. After the VM instance is rebooted, the VM console password will take effect.
  • When a VM instance is cloned, if you use a SharedBlock primary storage, select a provision mode for the VM instance, including thick provision and thin provision.
    • Thick provision: Preallocate the required storage space, and provide sufficient storage capacities for the VM instance to ensure the storage performance.
    • Thin provision: Allocate the storage space to the VM instance as needed to achieve higher storage utilizations.
  • When a VM instance is cloned, if you use a Ceph primary storage, you can specify a storage pool.
    • When a VM instance is cloned without volumes, a Ceph storage pool (root volume pool) can be specified.
    • When you use an ImageStore backup storage to clone a VM instance with volumes, you can specify a data volume pool and a root volume pool.
  • When you clone a VM instance, ensure that you do not set a static IP address for the source VM instance. Otherwise, the IP address will be duplicated in multiple VM instances, which will lead to login errors.
• Create backup data: Backs up the VM instance on the Cloud to an off-site server or to Public Cloud remote disaster recovery server.
• Create volume:

  Create data volumes from the primary storage attached by a cluster where the VM instance resides.

  If you have multiple types of primary storages, you can specify a type of primary storage to create volumes.

  • For multiple LocalStorage primary storages, an availably large capacity of storage will be selected to create volumes for the VM instance by default.
  • For multiple NFS primary storages or multiple SharedBlock primary storages, a type of primary storage will be randomly selected to create volumes for the VM instance by default.
  • For LocalStorage +NFS/Shared Mount Point/Shared Block, a type of primary storage where the root volume of the VM instance currently does not reside will be selected.

  Volumes can be created based on the volume image. If the volume image is attached to an ImageStore backup storage, you can create the volumes on a Ceph primary storage.

• Attach or detach volume:
  • Attach volume: Create volumes for the VM instance on the primary storage attached by a cluster where the VM instance resides.
  • Detach volume: Detach volumes from the VM instance. To perform cold migrations and storage migrations for local storages, detach related data volumes.
• Resize volume:

  Resize data volumes as needed after the VM instance stops. Modifying capacities for the data volumes will take effect after the VM instance starts. Notice that data volumes can only be expanded on the Cloud.

• Create VM image:

  Encapsulate a volume as an image. This image can be used to create more volumes. Also, volumes on a Ceph primary storage can be encapsulated as volume images on an ImageStore backup storage.

• Attach or detach ISO:
  • Attach or detach an ISO image. Make sure that you add an ISO image in advance. After the image is added successfully, the VM instance can detect and attach this image.
  • If you plan to repair the operating system or reinstall the operating system, you can attach an ISO image, adjust the boot order by prioritizing the ISO image, and reboot the VM instance with the ISO wizard.
  • Let you attach multiple ISO images. You can attach 3 ISO images to the VM instance at most. Also, you cannot attach ISO images in bulk.
• Create or delete vDrive:
  • Make sure that you stop the VM instance in advance. Then, you can create or delete the vDrive.
  • To set the maximum number of virtual drives for a VM instance as needed,

    Choose Settings > Global Settings > Advanced, and set maximumCdRomNum. Default value: 3. Options: 1 | 2 | 3.

  • Deleting CDROMs and modifying default devices will affect the device names and ISO mappings. Specifically, the influence is as follows:
    • Deleting CDROMs will change the order for the rest of CDROMs successively. For example, assume that you have three CDROMs: CDROM-1, CDROM-2, and CDROM-3. If you delete CDROM-2, all ISO images attached to the CDROM-3 will be changed to CDROM-2.
    • Modifying default CDROMs will change the device serial numbers of the CDROMs. For example, assume that you have three CDROMs: CDROM-1, CDROM-2, and CDROM-3. If CDROM-2 is set as default, CDROM-2 with all its ISO images will be changed to CDROM-1, and the original CDROM-1 will become CDROM-2.
• SSH Login Method: Allow you to use the SSH key or password if you have image files preconfigured with Cloud-init.
  • If you use an SSH key, set the following parameter:
    • SSH Key: After an SSH key is injected to a VM instance, you can SSH in to the VM instance without entering a password when the VM instance is running.
  • If you use a password, set the following parameters:
    • User Name: By default, the user name is root.
    • Password: After a root password is injected to a VM instance, you can SSH in to the VM instance by entering a password when the VM instance is running.
    Note:

    • The root password setting method only applies to Linux VM instances. For Windows VM instances, you can set passwords by using User Data.
    • Before you set the password, make sure that the VM image has the Cloud-init installed. Recommended versions for Cloud-init: 0.7.9, 17.1, 19.4, and the later versions.
    • After you set a password, do not set the password again in User Data to avoid conflicts.
    • After you set a root password, a clear text password will be displayed in the User Data on the details page of the created VM instance. Keep your password confidential.
  Note: Different types of images support different SSH login methods.

  • Images of different operating systems:
    • Linux image: Fixed user name: root. Supported SSH login methods: SSH key | password.
    • Windows image: Fixed user name: administrator. Supported SSH login method: setting password by using User Data.
  • Images of different formats:
    • Image of the ISO type: Supported SSH login method: SSH key.
    • Image of the Image type: Supported SSH login methods: SSH key | password.
• Set host name:
  • The rules for setting Linux hostname and Windows hostname are different.
    • Linux hostname: The hostname must be 2 to 60 characters long, and can be uppercase, lowercase, numbers, 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 long, and can be uppercase, lowercase, numbers, and hyphens (-). Note that a hostname cannot contain consecutive hyphens (-), cannot start or end with hyphens (-), and cannot contain only numbers.
  • Before you set a hostname, make sure that the DHCP service of the L3 network corresponding to the VM instance is enabled.
  • For Linux images, the hostname must be set to localhost.localdomain.
  • After you set a hostname, do not set it again in User Data to avoid conflicts.
• SSH key management:

  After you inject an SSH key into a VM instance, you can use the SSH key to log in to the VM instance without passwords via SSH.

  For your reference, to inject an SSH key into a VM instance:

  1. Install Cloud-init.
     Currently, you can inject an SSH Key into a VM instance by using Cloud-init. To inject the SSH Key into the VM instance, install Cloud-init in advance.

     1. Install Cloud-init by yourself. Recommended versions: 0.7.9, 17.1, 19.4, and their later versions.
     2. After you complete installing Cloud-init, the SSH password authentication defaults to be disabled. To enable the SSH password authentication, set the ssh_pwauth option under /etc/cloud/cloud.cfg to 1.
  2. Generate an SSH Key.
     1. The SSH Key is generated by the ssh-keygen command. By default, the SSH Key is stored in /root/.ssh/id_rsa.pub.
     2. Paste the file content into the SSH Key input box.
  3. Inject the SSH Key into the VM instance.
     You can inject the SSH Key into the VM instance by the following two methods:

     • Method 1: When you create a VM instance, enter an SSH Key under the Advanced option.
     • Method 2: If you have created a VM instance, enter an SSH Key by selecting Add SSH KEY under the Actions of the VM instance.

     After you inject the SSH Key, you can check the basic information of the corresponding SSH Key at the VM instance details page, such as user name and host information of the corresponding key.

  Note:

  • When you create a VM instance, injecting an SSH Key into the VM instance will take effect immediately.
  • When you inject an SSH Key into the VM instance that is in the start state or running state, clean up the previous configurations by running rm -rf /var/lib/cloud/instances, and then reboot the VM instance. Finally, the SSH Key will take effect.
  • On the VM actions page, click Delete SSH KEY. Only the SSH Key information recorded in the system is deleted, while the related information of the injected SSH Key is not deleted or removed.
  • If you need to delete the SSH Key that has been taken effect, clean up manually the SSH Key under /root/.ssh/authorized_keys in the VM instance.
• Set high availability:

  If resources on hosts are sufficient, the VM instance configured with NeverStop will never be stopped.

  • Assume that the volumes of the VM instance are attached to a local storage. After the host where the VM instance resides is abnormally stopped, this VM instance will not be started again until the host recovers to the availably connected status.
  • Assume that the volumes of the VM instance are attached to a shared storage. When resources on hosts are sufficient, the VM instance will keep running normally. Even if the VM instance stops, it will be rebooted. If the host where the VM instance resides is abnormally powered off and stopped, this VM instance will be rebooted on other available hosts.
  • You can set the NeverStop VM instance to not be automatically rebooted.
  • The rebooting progress of the NeverStop VM instance can be displayed on the web UI.
• Change instance offering or change CPU and memory:
  Changes the CPU, memory, disk QoS, and network QoS.

  • Change online: Let you change the CPU, memory, disk QoS, and network QoS of the VM instance by enabling NUMA globally. These settings will take effect after the VM instance is rebooted or the new VM instance is created. We recommend that you do not change the CPU and memory for the Windows VM instance in your production environment. On the contrary, we recommend that you change online the configurations of the Windows VM instance after the VM instance is stopped. If you change an instance offering online, you can only increase the CPU and memory rather than decrease them.
  • Change offline: Change the configurations of the VM instance after the VM instance is stopped.
• Set boot order:

  After you attach an ISO to the VM instance, set the boot order for the VM instance. The boot order can be used to restore or reinstall the operating system. Set the boot order by prioritizing CDROM. After the VM instance reboots, all settings will take effect. Notice that these settings can only take effect once. If you reboot the VM instance next time, the VM instance will be booted from a hard disk by default. When you create a VM instance for the first time and select an ISO image without setting the boot order, the operating system will be automatically booted from the ISO image.

• Enable (Specify hosts):

  Select the specified host from the available host list to start the VM instance, which is applied to shared storages. If the VM instance uses a local storage, the host where the root volume resides can be used to start the VM instance.

• Set or cancel console password:
  Set or cancel the console password. After you set the console password, you can access the VNC console by entering the correct console password. On the contrary, after you cancel the console password, you can access the console of the VM instance without passwords.

  Note: When you set and cancel the console password, if you do not select Reboot, you need to manually reboot the VM instance on the web UI before all settings take effect.
• Reimage the VM instance:

  Restore the image template to the initial state against the stopped VM instance. By doing so, the data that are changed within the VM instance will be erased. To reimage the VM instance, back up volume data in advance.

• Change owner:

  Change the owner of the VM instance to another regular account.

• Set RDP mode:

  Set the RDF mode under the VDI scenario. By default, the console of the VM instance is opened in RDF mode. The settings take effect immediately.

• USB redirection:

  Mainly used for VDI. Specifically, the USB device that plugs in a client can be redirected to the VM instance. After you change the USB redirection, restart the VM instance before all settings take effect.

• QGA option:

  Before you enable the QGA option, make sure that you have installed and run qemu-guest-agent on the VM instance. After the QGA option is enabled, the VM instance defaults to let you change its password online.

• Change password online:

  Enable the QGA option. Also, you must install and run qemu guest agent on a Linux or Windows VM instance. Make sure that the user name that you entered is existed.

• Resize root volume:
  Expand the root volume for the VM instance.

  • If you use a Linux VM instance partitioned by Logical Volume Manager (LVM), you can expand directly the operating system partitions by running lvextend.
  • A Windows VM instance can also let you right-click Disk Management to expand the root volume.
• Switch console mode:

  The console mode supports VNC, SPICE, and VNC+SPICE. Specifically, VNC lets you open the console of the VM instance via a browser, while SPICE allows you to open the console of the VM instance via an SPICE client. These three console modes are supported. The settings will take effect after the VM instance is rebooted.

• Migrate storage: Perform cold migrations for the VM instance across same types of primary storages, and perform hot migrations for the VM instance across different types of primary storages.
  • Perform cold migrations across the same types of primary storage: Let you perform cold migrations for a VM instance across the same types of primary storage, including Ceph-Ceph, NFS-NFS, and SharedBlock-SharedBlock.
    Note:

    • Storage migrations across Ceph primary storages：
      • Before you perform migrations, you must stop the VM instance and then detach all its data disks.
      • MON nodes between two Ceph primary storages must be interconnected.
    • Storage migrations across NFS primary storages:
      • Before you perform migrations, you must stop the VM instance and then detach all its data disks.
      • The target NFS primary storage can be attached to the cluster where the VM instance to be migrated resides.
    • Storage migrations across SharedBlock primary storages:
      • Before you perform migrations, you must stop the VM instance. You can perform migrations for the VM instance with volumes.
      • If the VM instance attaches shared volumes, the shared volumes cannot be migrated with the VM instance simultaneously.
      • The target SharedBlock primary storage can be attached to the cluster where the VM instance to be migrated resides.
    • The cluster attached by the target primary storage can meet the network needs of the VM instance.
  • Hot migrations across different types of primary storage: Let you perform hot migrations for the VM instance across different types of primary storages, including Ceph-SharedBlock, LocalStorage-SharedBlock, and LocalStorage-Ceph.
    Note:

    • Before you perform migrations, do not stop the VM instance.
    • You can only perform migrations for the VM instance with the regular volumes. If the VM instance attaches shared volumes, the shared volumes cannot be migrated with the VM instance simultaneously.
    • After you perform storage migrations for the running VM instance, snapshots for the VM instance will not be reserved.
    • The cluster attached by the target primary storage can meet the network needs of the VM instance.
• Bind or unbind affinity group: Bind/unbind the VM instance to/from an affinity group.
  Currently, ZStack provides two affinity group policies to better manage VM instances and hosts: anti-affinity group (soft) and anti-affinity group (hard).

  • Anti-affinity group (soft):

    Allocate VM instances in the affinity group to different hosts as much as possible. If no more hosts are available, the VM instances will be allocated randomly.

  • Anti-affinity group (hard):

    Strictly allocate VM instances in the affinity group to different hosts. If no more hosts are available, the allocation fails.

• Change operating system:
  After the VM instance is stopped, you can change the operating system by specifying the target image. Notice that the target image must be the Image type: qcow2 and raw. After you change the operating system, the VM instance stays in the stopped state.

  • Changing the operating system for the VM instance will expunge all its original operating system disks and snapshots. Make sure that the related backups are performed before you confirm the change of the operating system to avoid data loss.
  • If a scheduled job to create snapshots for the VM instance is failed, ensure that you make configurations for the scheduled job again.
  • When the VM instance attaches data volumes, you can switch different types of the operating system, such as switching Linux to Windows.
  • When you switch across different types of the operating system, the partition format of data volumes will probably fail to be detected and identified.
• Set QoS:

  Limit the upstream bandwidth and downstream bandwidth of the VM volumes and networks. All settings will take effect without rebooting the VM instance. Underused QoS will probably lead to the abnormality of the VM instance.

• Inject User Data:
  • Before you import User Data, make sure that both the User Data network service and DHCP network service are available.
  • By default, the User Data network service and DHCP network service in the three network environments of flat network, vRouter network, and VPC network are enabled.
  • If you set a hostname and password by using the User Data, do not set them again in SSH Login Method to avoid conflicts.
  • After you set a root password by using the User Data, a clear text password will be displayed in the User Data field on the details page of the created VM instance. Very that you keep your password confidential.
  • When you import the User Data to a Linux VM instance, note the following:
    • Cloud-init must be installed for the VM image. Recommended versions: 0.7.9, 17.1, 19.4, and the later versions.
    • If you create a Linux VM instance by using a VM image that has Cloud-init installed, you must import the User Data. Otherwise, the Cloud-init task will wait until the task times out.
    • The following is an example of importing the User Data to a Linux VM instance:

      #cloud-config users:  - name: test    shell: /bin/bash    groups: users    sudo: ['ALL=(ALL) NOPASSWD:ALL']    ssh-authorized-keys:        - ssh-rsa AAAAB3NzaC1LXCJfjroD1lT root@10-0-0-18 bootcmd:  - mkdir /tmp/temp  write_files:  - path: /tmp/ZStack_config    content: |        Hello,world!    permissions: '0755' fqdn: Perf-test disable_root: false ssh_pwauth: yes chpasswd:   list: |       root:word   expire: False runcmd:  - echo ls -l / >/root/list.sh

      The preceding script can be realized by following the steps below:

      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 content to the file.
      3. Set the hostname, enable the root user, allow the SSH login with passwords, and change the root password.
      4. Run the echo ls -l / command.
  • When you import the User Data to a Windows VM instance, note the following:
    • Cloudbase-Init must be installed for the VM image. The version of the Cloudbase-Init is not enforced. For information about how to install Cloudbase-Init, see Cloudbase Documentation.
    • If you create a Windows VM instance by using a VM image that has Cloudbase-Init installed, you must import the User Data. Otherwise, the Cloudbase-Init task will wait until the task times out.
    • 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 script above creates b64, b64_1, and gzip files under C drive when the VM instance is started.

    Note: When the User Data is used, one L2 network can only let you configure one L3 network.
  Note: When you use the User Data, notice that you can configure only one L3 network for an L2 network.
• Change platform:

  Change the platform of the VM instance. Options: Linux | Windows | WindowsVirtio | Other | Paravirtualization. Linux, WindowsVirtio, and Paravirtualization support Virtio drivers, while Windows and Other use devices simulated by QEMU. Restart the VM instance before all settings take effect.

• Change session count:

  Set the maximum number of sessions accessible to the VM instance under the VDI scenario. Default value: 1. Once you change the value, the settings will take effect after the VM instance is rebooted. The SPICE mode is supported.

• Attach NIC:

  Select available networks to attach to the VM instance from the available L3 network list.

• Detach NIC:

  Detach the NICs from the VM instance. If the VM instance does not have any NIC, the VM instance will fail to be started after it is stopped. Make sure that you attach at least one NIC to the VM instance.

• Change default network:

  Let you change the default network for the VM instance. Ensure that you restart the network service before all settings take effect.

• Set MAC:

  Specify a MAC address when you create a VM instance. After you stop the VM instance, you can set or modify the MAC address.

• Set specified IP:

  Set a specified IP address for the VM instance. Select an available IP address for the VM instance from the available IP range to avoid IP conflicts.

• Attach GPU device:

  Attach the GPU device of a host to the VM instance. Hence, the GPU device is used solely by the VM instance. However, you cannot perform migrations for the VM instance that attaches the GPU device.

• Detach GPU device:

  Detach the GPU device from the VM instance.

• Attach USB device:

  Attach a USB device for the VM instance by enabling the USB passthrough feature. Once a USB device is attached to a VM instance, the USB device can be solely used by the VM instance. All USB devices attached by one VM instance can only run on the same host.

• Detach USB device:

  Detach the USB device from the VM instance.

• Attach GPU specification:
  Attach GPU specifications for one or more VM instance.

  Note: If the VM instance has already attached a GPU specification, GPU device, or if the VM instance is in the running state, this VM instance cannot attach another GPU specification.
• Change GPU specification:
  Change a GPU specification for one or more VM instances.

  Note:

  • If the VM instance has not attached any GPU specification, or if the VM instance is in the running state, you cannot change the GPU specification for the VM instance.
  • After you change the GPU specification, you can attach a GPU device by using the latest GPU specification to the VM instance when the VM instance is started next time. Also, you can detach the GPU device associated to the original GPU specification from the VM instance.
• Cancel GPU specification:
  Cancel the GPU specification of one or more VM instances.

  Note: If the VM instance has not attached any GPU specification, or if the VM instance is in the running state, you cannot cancel the GPU specification.
• Attach other peripheral devices:

  Attach other peripheral devices to the VM instance by enabling the feature of other peripheral devices.

• Detach other peripheral devices:

  Detach other peripheral devices from the VM instance.

• Scheduled job:

  Create a scheduled job. Create a scheduled job based on a scheduler. Scheduled tasks such as stopping VM instances, starting VM instances, rebooting VM instances, and creating VM snapshots.

• Alarm:

  Create an alarm and add related alarm metrics. The system can automatically monitor multiple alarm metrics such as added CPU, disks, NICs, and memories of VM instances, and pushes alarm messages to you via email, DingTalk, HTTP application, and short message service.

  If you want to use some specific alarm metrics, install agents for your VM instances in advance. For more information about how to install an agent, see Internal Monitoring.

  Note: Compared to the external monitoring, the internal monitoring is more accurate. We recommend that if you want to monitor the internal data, use the internal monitoring.
• Audit:

  Let you audit all operations of a VM instance to effectively safeguard the security of your core data on your cloud environment.

Notice

Volume Operations

• Enable:

  Enable the disabled volumes. Afterwards, you can attach the volumes to a VM instance. If you have already attached the volumes to the VM instance, disabling the volumes will not affect your business continuity. After you detach the volumes from the VM instance, you can no longer attach the volumes to the VM instance.

• Disable:

  Disable the enabled volumes. Afterwards, the volumes cannot act as candidates that can be attached to other VM instances.

• Attach:

  Attach volumes to a VM instance. You can attach the volumes to the VM instance that are in the running state or stopped state.

• Detach:

  Detach volumes from a VM instance. After you detach the volumes from the VM instance, you can attach the volumes to other VM instances.

• Migrate:

  Migrate volumes. After you detach the volumes attached by a local storage, you can migrate the volumes to other hosts. After migration, you can attach the volumes to other VM instances that run on the target host.

• Create backup task:

  Create a backup task for the current VM instances or volumes. The VM instances will be backed up as images, while the volumes will be backed up as volume backups.

• Create image:

  Create volume images. Volumes can be encapsulated as images which can be used to create more volumes. Also, the volumes on a Ceph primary storage can be encapsulated to an ImageStore backup storage.

• Resize volume:

  Let you resize volumes online. Resize data volumes as needed. After data volumes are resized, the capacities will take effect in real time. Data volumes can only be expanded at the minimum of 4 MB rather than be downsized.

• Create snapshot:
  Create volume snapshots. Before you perform any important operations, reserve the temporary state of the root volumes or data volumes at a specific time point. Hence, you can quickly perform rollbacks for the root volumes or data volumes when failures occur. If you need long-term backups, select related features of backup services.

  • In a production environment, we recommended that you limit the number of snapshots per disk within 5. Excessive snapshots might affect the I/O performance, data security, and primary storage capacity of the corresponding VM instances and volumes. For long-term backups, we recommend that you use disaster recovery related services.
  • Currently, you cannot create snapshots for shared volumes.
  • The snapshot of the volume on the Ceph primary storage does not occupy capacity. Therefore, the displayed snapshot capacity is the real capacity of the volume when the snapshot was created.
  • For Ceph primary storages, the volume snapshot capacity might fail to be obtained. Here are some statements:
    • Open source Ceph (version H) and enterprise-level Ceph (earlier than 3.2.0) cannot obtain volume snapshot capacity.
    • Due to the RBD format, enterprise-level Ceph (3.2.0 and later versions) may fail to obtain VM snapshot capacity.
  Similar to creating snapshots for root volumes of a VM instance, after you detach the volumes from the running VM instance, you can also create snapshots.

  Note:

  • Snapshots, a short-term solution, mainly can be used in test and development environments. Specifically, these snapshots can quickly be used for packing, upgrading, or testing your Cloud. When normal failures appear, rollbacks can be performed. We recommend that you do not use snapshots in your production environment. However, under some circumstances, snapshots can still be applied to your production environment. For example, if you perform dangerous operations, the probable damage to the operating system may occur due to upgrading or configuration modifications. Then, snapshots are a preferred solution.
  • We recommend that you do not use snapshots in your production environment. The following are the two probable considerations:
    • Data integrity

      When you use snapshots, you are not creating a copy of the virtual hard disk. But actually, you need to create a copy of the VM virtual disk. If the virtual disk is damaged, the snapshot will be invalid, which means that the snapshot cannot be used to recover the damaged disk. Notice that the snapshot cannot be used to solve disk failures. So, you will still encounter a single point of failure.

    • VM performance

      Using too many snapshots will influence the performance of a VM instance. For example, if the old snapshot runs on the VM instance with excessive overloads, this old snapshot will be increased in size, and then the performance of the VM instance will be definitely slowed down. Or, if you create a large number of snapshots, the performance of the VM instance will be also slowed down.

      Reserving a snapshot of a VM instance for a long time is a common mistake. The snapshot will increase in size as the time goes by. Also. the snapshot files will also be changed, and are not stored on the source disk. Hence, restoring the snapshot will take a long time. Also, during restoring, the VM instance may be forced to stop.

• Restore snapshot:

  Restore volumes to the current snapshot point. Before you restore snapshots, stop the VM instance that attaches the volumes or detach the volumes from the VM instance.

• Delete snapshot:
  Delete the unnecessary the volume snapshots.

  Note:

  • Snapshots created on local storage, NFS, SMP, and Shared Block storages have a tree structure. Deleting the root snapshot will also delete snapshots on the branches and detach the batch snapshots on the branches. Please exercise caution.
  • Snapshots created on the Ceph shared storage are independent and do not have a tree structure. Deleting a snapshot will not affect other snapshots.
  • When you delete snapshots in a tree structure in bulk, the cloud automatically calculates and deletes the candidate snapshots and cascades the delete operation to the associated snapshots.
  • If the snapshots to be deleted contain batch snapshots, note that:
    • Deleting a batch snapshot will also delete the data volume snapshots in the batch snapshot and the snapshots on the branches. Please exercise caution.
    • Deleting single snapshots and batch snapshots in bulk will also delete the single snapshots on the branches and detach the batch snapshots on the branches.
• Change owner:

  Change the owner of the volumes to other regular accounts.

• Migrate storage:
  Volumes support migrations across network shared storages. Currently, Ceph and NFS storage migrations are supported.

  • Migration across Ceph primary storages:
    • Volumes to be migrated across Ceph primary storages cannot be attached to any VM instance.
    • Shared volumes that are not attached to VM instances can be migrated across Ceph primary storages. However, shared volumes that have been attached to VM instances cannot be migrated across Ceph primary storages.
    • To migrate between two Ceph primary storages, make sure that the Ceph MON nodes between these two Ceph primary storages are interconnected.
  • Migration across NFS primary storages:
    • Volumes that are migrated across NFS primary storages cannot be attached to any VM instance.
    • To migrate volumes between two NFS primary storages, make sure that the destination NFS primary storage can be attached to the cluster of the volumes to be migrated.
  • Migration across SharedBlock primary storages:
    • Volumes on SharedBlock primary storages can be attached to VM instances that are in the stopped state and migrated across SharedBlock primary storages.
    • Shared volumes that are not attached to VM instances can be migrated across SharedBlock primary storages. However, shared volumes that are attached to the VM instances cannot be migrated across SharedBlock primary storages.
    • To migrate volumes between two SharedBlock primary storages, make sure that the destination SharedBlock primary storage can be attached to the cluster of the volumes to be migrated.
• Delete:

  Delete the attached, unattached, or uninstantiated volumes. If you delete the uninstantiated volumes, the volumes will be deleted immediately. After deletion, the system will no longer record these volumes.

• Restore:

  Restore the deleted volumes to the running state.

• Expunge:

  Expunge the deleted volumes. The system will no longer record these volumes, and delete the actual data.

• Scheduled job:

  Create scheduled jobs based on schedulers. Currently, scheduled jobs of the volumes only support scheduled snapshot jobs of the data volumes, such as creating snapshots, enabling snapshots, disabling snapshots, and deleting snapshots.

Notice

Image Operations

• Enable:

  Enable the disabled images. These images can act as candidates used to create VM instances.

• Disable:

  Disable images. These images cannot act as candidates used to create VM instances.

• Export:

  Export ImageStore images. You can download the images directly. By default, the exported images are stored on the export subdirectory under the ImageStore directory. The details pages of the exported images can display MD5 values of the images. These values can be used to authenticate whether the downloaded images and the exported images are the same.

  For SFTP backup storages, you can copy directly the path where the images are stored, and export the images.

  For Ceph backup storages, you can export manually the images by running rbd export via the Pool information where the images are stored.

• Share to all:

  Share images to all accounts. Hence, all regular accounts and project users can use these images.

• Share:

  Share images to one or more regular accounts or project users.

• Recall from all:

  Recall images from all regular accounts and projects users. Recalling the images from all regular accounts and project users does not affect independent image sharing. You can specify some images. Hence, regular accounts and project users can still use these images.

• Recall:

  Recall images from the specified regular accounts and project users.

• Change owner:

  Change the owners of the images to the regular accounts and project users.

• Migrate storage:

  Migrate the data of the images across network shared storages. Currently, migrations for the images can be performed across Ceph backup storages.

  Migrate the images on a Ceph backup storage to other Ceph backup storages. After migration, the new Ceph backup storages can use these images, while the original Ceph backup storage will no longer reserve these original images. Before storage migrations are performed, make sure that the target Ceph backup storage has sufficient capacities.

• Delete:

  Delete images. To expunge or restore the images, delete them first.

• Restore:

  Restore the deleted images to the running state.

• Expunge:

  Expunge the deleted images. Then, the actual data on the backup storage will be deleted.

• Download exported image:

  Download the exported images to the corresponding local disk via a browser.

• Copy URL:

  Copy the URLs of the images, and add them to other clouds. Also, you can download these URLs by using wget directly.

• Delete exported image:

  Remove the exported images from a backup storage. These images will no longer occupy storage capacities.

• Change platform:

  Change the platform type for images. Afterwards, the new VM instances will determine which device drivers will be used according to the new type of platform. Platform options: Linux | Windows | WindowsVirtio | Other | Paravirtualization. Linux, WindowsVirtio, and Paravirtualization adopt Virtio drivers, while Windows and Other adopt QEMU emulation devices.

• Change QGA option:

  Enable the QGA option. Before you enable this option, make sure that you have preinstalled and run qemu-guest-agent in the images. After you enable this option, the VM instances with these images let you change the VM passwords.

• Refresh capacity:

  Refresh the actual capacities of the backup storage where the images reside.

Notice