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. /
Edit VM Instance Edit the name and description of a VM instance. Running/Stopped/Paused
Start VM Instance Start a VM instance that is in the stopped state. Stopped
Stop VM Instance Stop a VM instance that is in the running state.
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 VM instance that is in the running state. Running
Restore VM Instance Restore a VM instance that is in paused state. Paused
Pause VM Instance Pause a VM instance that is in running state.
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
Power Off VM Instance Power off a VM instance that is in the running state.
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.
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.
  • 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 storages 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 storages 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 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 VM instances that use an ImageStore or a Ceph backup storage, when you clone a VM instance with attached volumes, you can specify a data volume pool and a root volume pool.
  • You can specify whether to power off the newly cloned VM instances after cloning.
  • When you clone a VM instance, you can set a storage allocation policy, including system allocation and manual allocation.
    • System allocation: The system allocates a primary storage according to the preconfigured policy.
    • Manual allocation: You can manually select a primary storage.
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, we recommend that you manually select an available primary storage for the root volume.
  • 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
Attach Tag to VM Instance Attach tags to a VM instance.
  • The Cloud provides two types of tags: admin tag and tenant tag.
    • Admin tags are created and owned by admins (administrators 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.
  • Tenants can only detach tags on the resources of these tenants, and administrators can detach tags on all resources.
 Running/Stopped/Paused
Migrate VM Instance Migrate a VM instance to the other node.
  • Hot migration:
    • Migrate a VM instance that is in the running state. 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 the VM instance with data volumes.
      In this scenario, perform the hot migration by following these steps:
      1. In the Global Setting, enable Live Migration in Local Storage.
      2. Detach the data volumes attached to the VM instance.
      3. Migrate the VM instance and data volumes to other nodes, respectively.
      4. Attach the detached data volumes to the VM instance again.
    • Windows VM instances cannot be hot migrated in LocalStorage primary storages.
    • 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 the migration is successful.
      • You can enable auto converge for all VM instances in the Cloud. Method: In the Global Setting, enable Auto Converge.
      • You can also enable auto converge for a single VM instance. By default, this setting complies with that in the Global Setting.
      Note: If your applications are performance sensitive, we recommend that you do not enable auto converge.
    Note:
    • If the VM instance has a VF NIC attached, detach the VF NIC before the hot migration.
    • If the VM instance has a LUN attached and is deployed as the Master node of Failover Clustering, hot migrating the VM instance might cause the Failover Clustering unavailable. Please exercise caution.
  • Cold migration:
    • Migrate a VM instance that is in the stopped state.
    • 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.
    • To perform a cold migration, follow these steps:
      1. Stop the VM instance.
      2. Detach the data volumes from the VM instance.
      3. Migrate the VM instance and data volumes to other nodes, respectively.
      4. Attach the detached data volumes to the VM instance again.
  • You can migrate VM instances based on the workloads of the destination compute node.
    • In the list of recommended destination compute nodes, you can sort the destination compute nodes by the average CPU utilization or memory utilization. By default, the compute nodes are sorted by the average memory utilization in ascending order.
    • If the scale of compute nodes in the cluster is large, you can sort the top 20 or top 50 compute nodes.
Note:
  • Before you hot or cold migrate a VM instance, detach the data volumes, ISOs, or peripheral devices (if any) from the VM instance first.
  • The migration speed is related to the network configuration of the source and destination compute nodes. Low network configuration might cause lower migration speed.
 Running/Stopped
Storage Migration Cold migrate a VM instance across the same type of primary storages, or hot migrate a VM instance across different types of primary storage.
  • Cold migration across the same type of primary storages:
    • Supported primary storage types: Ceph, NFS, SharedBlock.
    Note:
    • When you cold migrate a VM instance across Ceph primary storages, note that:
      • Power off the VM instance and detach all of the data volumes from the VM instance before migration.
      • Make sure that the MON nodes of these two Ceph primary storages can communicate with each other.
    • When you cold migrate a VM instance across NFS primary storages, note that:
      • Power off the VM instance and detach all of the data volumes from the VM instance before migration.
      • Make sure that the destination NFS primary storage can be attached to the cluster where the VM instance to be migrated is located.
    • When you cold migrate a VM instance across SharedBlock primary storages, note that:
      • Power off the VM instance before migration.
      • You can migrate the VM instance with attached volumes (excluding shared volumes).
      • Make sure that the destination SharedBlock primary storage can be attached to the cluster where the VM instance to be migrated is located.
    • Make sure that the cluster attached by the destination primary storage meets the network requirements of the VM instance.
  • Hot migration across different types of primary storages:
    • Supported combination of primary storage types: Ceph-SharedBlock, LocalStorage-SharedBlock, LocalStorage-Ceph, LocalStorage-NFS, SharedBlock-NFS, and Ceph-NFS.
    Note:
    • You can migrate the VM instance with attached volumes (excluding shared volumes).
    • Hot migrating a running VM instance does not save its snapshots after the migration.
    • Make sure that the cluster attached by the destination primary storage meets the network requirements of the VM instance.
    • Before you migrate a running VM instance, detach the VF NICs (if any) from the VM instance first.
Note: Before you migrate a VM instance, detach the ISOs, LUNs, or peripheral devices (if any) from the VM instance first.
 Running/Stopped
Modify Instance Offering Modify the instance offering of a VM instance.
Note: After the modification, only the CPU, memory, and host allocation policy in the new instance offering take effect for the VM instance.
  • You can modify the instance offering of Linux VM instances when they are running or powered off.
    • To modify the instance offering of a running VM instance, follow these steps:
      1. Open NUMA.
        • You can enable NUMA for all VM instances in the Cloud. Method: In the Global Setting, enable NUMA.
        • You can also enable NUMA for a single VM instance. By default, this setting complies with that in the Global Setting.
      2. Restart the VM instance.
      3. Modify the instance offering of the VM instance.
    Note: When you modify the instance offering of a running VM instance, make sure that the new CPU core count and memory size are greater than the current one.
  • You can also modify the instance offering of Windows VM instances when they are running or powered off. The method is the same as that of Linux VM instances.
    Note: We recommend that you do not modify the number of CPU cores and memory size of a Windows VM instance in the production environment.
 Running/Stopped
Set GPU Specification Set the GPU specification of a VM instance.
  • Set pGPU specification: Attach or modify the physical GPU (pGPU) specification of a VM instance.
    • You cannot set the pGPU specification for a running VM instance.
    • After you modify the pGPU specification of a VM instance, the next time the VM instance starts, the VM instance attaches pGPU devices by using the latest pGPU specification. 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 still exist after the VM instance is powered off.
      • If enabled, the VM instance automatically detaches the attached pGPU devices (if any) after the VM instance is powered off.
  • Set vGPU specification: Attach or modify the virtual GPU (vGPU) specification of a VM instance.
    • You cannot set the vGPU specification for a running VM instance.
    • After you modify the vGPU specification of a VM instance, the next time the VM instance starts, the VM instance attaches vGPU devices by using the latest vGPU specification. 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) after the VM instance is powered off.
      • If disabled, the attached vGPU devices still exist after the VM instance is powered off.
  • No set: The VM instance does not load 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 of a VM instance.
  • You can expand the root volume of a VM instance when the VM instance 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, enable Snapshot Auto-Creation upon Volume Resizing.
  • The setting of a single VM instance complies with that in the Global Setting.
 Running/Stopped
Change Owner Change the owner of a VM instance.
Note: Changing a VM owner detaches all of the tenant tags on this VM instance. Admin tags are not affected.
 Running/Stopped
Change System Change the system of a VM instance.
  • Before you change the system, stop or power off the VM instance first. The new system takes effect after the VM instance reboots.
  • Make sure that the type of the destination image is Image.
Note:
  • Changing the operating system expunges 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 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 action 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 loss.
 Stopped
Set Boot Order Set the 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 instance boots from CD ROM after creation.
  • If you attach an ISO to an existing VM instance, the default boot order is as follows:
    1. First boot order: Hard disk
    2. Second boot order: CD ROM
  • If you want the VM instance boot from 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 only 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.
 Stopped
Set VM HA Set the high availability (HA) policy of 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 can reboot automatically in case of 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, enable VM HA.
  • If a VM instance has HA enabled, you can make the VM instance not automatically reboot this time after being stopped.
 Running/Stopped
Set Time Sync Set whether the time of a VM instance is the same as that of the host. By default, these two times are the same.
Note: If the VM instance is running or paused, reboot the time for the setting to take effect.
 Running/Stopped/Paused
Set Error Policy Set the error policy for a VM instance, including error inspection and error handling.
  • Error inspection
    • You can enable error inspection for a running VM instance.
      • By default, error inspection is disabled. If enabled, reboot the VM instance to make the setting take effect. Note that you cannot reboot the VM instance through the VM console.
      • After you enable error inspection, if a VM instance crashes, the system automatically handles the error based on 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, enable Error Inspection.
    • 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-based VM instance, the kdump module is disabled after you reboot the instance.
  • Error handling
    • After you enable error inspection, you can set an error handling policy for the VM instance. Supported policies:
      • Preserve: 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-based VM instance or Linux-based VM instance crash, 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-based VM instance or Linux-based VM instance crash, 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 some delays might occur during the starts or reboots.
 Running
Set SSH Key Set the SSH key for a VM instance, including injecting an SSH key, change an SSH key, or delete an SSH key.
  • After you inject an SSH key into a VM instance, you can SSH to the VM instance without a password when the VM instance is running.
  • Currently, SSH keys are injected by using cloud-init. Therefore, before you inject an SSH key, install cloud-init on the VM image first.
  • If you inject an SSH key when you create a VM instance, the SSH key takes effect after the VM instance starts for the first time.
  • If you inject an SSH key into an existing VM instance, reboot the VM instance to make the SSH key take effect.
  • If you inject an SSH key into a VM instance that already has an SSH key, run the rm -rf /var/lib/cloud/instances command to clear the previous configurations and inject the SSH key again. Then, reboot the VM instance to make the new SSH key take effect.
  • Deleting an SSH key only deletes the SSH key information recorded in the system. The SSH key information injected into the VM configuration is not deleted. If you need to completely delete the SSH key information, manually clean up the VM configuration file /root/.ssh/authorized_keys.
  • For more information about SSH key, see SSH Key Management.
 Running/Stopped
Change VM Password Change the username or password of a VM instance.
  • You can change the VM username or password when the VM instance is running. The change takes effect immediately.
  • 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, you can also change the password of the images of the VM instance or the cloned VM instances.
 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.
  • 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 of 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 Resource Priority to High only for vital VM instances.
  • VPC vRouters have 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 disabled, the VM instance can only operate in the cluster where the VM instance resides when this policy takes effect.
  • 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 host might be selected from other clusters if these clusters attached the same L3 networks and storages.
    • 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 resides when this policy takes effect.
  • 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) 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 on a VM instance, you can schedule snapshot creation at specified time points to record the state of the root volume or data volume of the instance. This allows rollback in case of breakdowns.
  • You can create a single snapshot or snapshot group.
    • Single snapshot: Create a snapshot for the root volumes of the VM instance.
    • Snapshot Group: Create a snapshot for both the root volumes and data volumes of the VM instance.
Note:
  • In the production environment, we recommend that you create no more than five snapshots for a volume. Too many snapshots will lower the VM performance, increase data security risks, and occupy storage space of the primary storage. To back up data for the long term, you can use a 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 with I/O, some data in the memory might fail to be saved to the hard disk and thus cannot be saved in the snapshot.
 Running/Stopped/Paused
Create Backup Create a backup for a VM instance.
  • 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 a VM instance with its shared volumes (if any).
  • 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
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-based VM instances, you need to install VirtIO drivers manually.
    • If the owner of the volume is different from the owner of the instance and you attach the volume to the instance, the VM instance may become invisible to the tenant, which makes the tenant unable to manage the VM instance.
 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.
 Running/Stopped
Create Image Create a template image based on a VM instance so that you can create VM instances in bulk in a custom way.
  • 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.
 Running/Stopped
Attach ISO Attach an ISO for a VM instance.
  • The ISO will be attached in the sequence of the virtual drive name of the VM instance.
  • By default, a VM instance can attach up to three ISOs. Bulk attach is not supported.
  • You can set the maximum number of virtual drives that can be attached to 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 exceeds 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
Associate Affinity Group Associate an affinity group with a VM instance. Then, the affinity policy takes effect for the VM instance immediately. Running/Stopped
Disassociate Affinity Group Disassociate an affinity group from a VM instance. Then, the affinity policy does not take effect for the VM instance any more. Running/Stopped
Delete VM Instance Deleting a VM instance releases the associated CPU, memory, and IP address. The deleted VM instance is displayed on the Recycle Bin tab.
  • By default, a VM instance in the recycle bin is expunged 7 days after the deletion.
  • You can set a deletion 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 its all attached classic volumes except for shared volumes.
 Running/Stopped/Paused
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 be returned 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 again.
 Deleted