Resource Pool

The logical collection of computing, storage, and network resources provided for VM creation. The three supported resource pool types and their respective characteristics, operational requirements, and restrictions are as follows:

• VMware: If you select this resource pool type, the creation method can be set only to Create Virtual Machine. SCP connects to VMware vCenter to manage VMware resource pools for centralized resource scheduling and allocation. This ensures resource consistency between SCP and VMware vCenter.

• Managed Cloud Services: If you select this resource pool type, you will be redirected to Managed Cloud Services for resource allocation. You need to complete the connection configuration between SCP and Managed Cloud Services first. Otherwise, you cannot be redirected to allocate resources.

• HCI: If you select this resource pool type, the VM to create can use the x86, Arm, or c86 architecture. The Arm architecture has restrictions on app deployment and does not support the deployment of SQL Server and Oracle databases. The other two architectures do not have such restrictions and are compatible with various general business scenarios.

Note: If no resource pools can be selected, or you want to add a new resource pool, refer to the Resource Pool Creation and Management section of the SCP Resource Management Guide.[3]

HCI

Choose a way to create a new virtual machine

The creation type of the VM. Valid values of this parameter are as follows:

• Create Virtual Machine: You can configure all parameters of the VM, including Image, Compute, and Storage, as needed.

• Import Virtual Machine: You can import an image in OVA, VMA, OVF, MF, or VMDK format to create a VM. Parameters such as the storage policy, NIC, group, and tag can be configured, while the computing resources are determined by the default parameters of the image to import and cannot be modified.

• Create VDI VM: You can create a VM for aDesk VDI, and the created VM will be displayed on VDI.

• Import VDI VM: You can import an image file compatible with aDesk VDI to create a VM and sync the created VM to VDI.

• Create SQL Server: You can configure all parameters of the VM, with a built-in SQL Server database (standalone instance or AlwaysOn cluster) deployed (including standby database cloning and shared disk configuration).

• Create Oracle Database: You can configure all parameters of the VM, with a built-in Oracle database (standalone instance or RAC cluster) deployed.

Create Virtual Machine

Image

The OS image used for VM creation. Supported image types are as follows:

• Public image: A standardized OS image that contains the OS and pre-installed public apps, available to all users.

• Private image: A custom OS image created based on a VM image or external image file, available only to the creator. It contains the OS, public apps, and custom configuration, reducing the time for repetitive configuration.

Supported image formats: ISO and built-in (VMA)

Note

1. If no images are selectable, it may be because no images have been uploaded to the current resource pool, or you do not have permission to use existing images in the resource pool. In this case, refer to the Image Upload and Allocation section of the SCP Image Management Guide.[4]
2. If the required image is in a format other than ISO and VMA (such as OVA or OVF), select Import Virtual Machine and create the VM by importing the image file.

Deployment Method

The method to deploy the VM based on the selected image. The correlations between deployment methods and image types are as follows:

1. ISO images support only the full deployment method. If you select an ISO image, you do not need to select a deployment method. The system will automatically complete the full deployment.
2. Built-in images support the following three deployment methods:

• Instant Full Deployment: The new VM can start up in seconds based on the VM template image before deployment is complete. Data will continue being deployed after the VM is started. When all the template data is deployed, it will be independent of the parent VM, with no impact on the performance of the parent VM. This method is suitable for scenarios where VMs need to be bulk deployed quickly for independent data processing tasks (such as bulk creation of test environments and temporary service node deployment). Note: Both the image and the new VM must be stored on virtual storage (external storage and passthrough disks are not supported). VMs deployed with this method can start up in seconds and will have independent data after the deployment is complete, with the same performance as independently deployed VMs.

• Full Deployment: The new VM can start up only after the VM template data is synced completely, and the template data is always independent of the parent VM. This method is suitable for scenarios where the requirements for data independence are high, and startup delays are acceptable (such as critical services and sensitive data nodes in production environments). It does not have special restrictions on storage types and supports various compatible storage media. VMs deployed with this method start up slowly, but the data is always independent, and no performance loss occurs after startup.

• Linked Deployment: The new VM shares the image of the parent VM, but data changes made to the new VM will be logged and redirected to a new image to save the storage space. This method is suitable for scenarios where storage resources are insufficient and the data change frequency is low (such as the deployment of read-only service nodes or homogeneous nodes). Note: The original built-in image must be retained for a long time and cannot be deleted in advance. Otherwise, the new VM cannot start up, and its data will be inaccessible. VMs deployed with this method can start up in seconds, but they do not have independent data, which saves storage space. They suffer minor performance loss and are subject to the storage performance of the original image.

1. If you select an ISO image, you do not need to select a deployment method. The system will automatically perform the full deployment.
2. If you select a built-in image, you need to select a deployment method according to your business needs:

- If you need to quickly bulk deploy VMs for independent data processing tasks, select Quick Deployment. Ensure that both the image and new VM are stored on virtual storage to avoid configuration failures caused by incompatible storage types.

- For critical services and sensitive data nodes in production environments, select Full Deployment. This method delays the new VM startup to ensure data independence and does not have restrictions on storage types.

- For services with insufficient storage resources and low data change frequency (such as read-only services), select Linked Deployment. Retain the original built-in image as required to avoid business interruption or data loss.

3. Notes:

- Select Quick Deployment only if both the image and new VM are stored on virtual storage. Otherwise, select Full Deployment.

- If you select Linked Deployment, create a list of original images for retention and incorporate it into daily O&M to prevent accidental deletion.

- If you want to strike a balance between startup speed and data independence, and virtual storage is supported, it is recommended to select Quick Deployment.

CPU

The number of vCPU cores configured when the VM is created, corresponding to the number of hyperthreads of the node. The following requirements must be met:

• The number of vCPUs of a VM cannot be greater than the number of logical CPUs of the node. The actual maximum number of vCPUs of a Windows or Linux VM is 192, while the theoretical value is 512.

• Architecture restriction: The maximum number of vCPUs that can be configured for a VM is equal to the total number of physical threads of the node with the most CPUs in the cluster. (Example: If the total number of physical threads of the node with the most CPUs in the cluster is 32, the maximum number of vCPUs that can be configured for a VM is 32.)

8

Memory Size

The memory capacity configured when the VM is created. The following requirements must be met:

• Recommended configuration: It is recommended to set the memory size of a VM to less than 2 TB. The maximum memory size supported by an Arm VM is 255 GB.

• Maximum limit: The memory size of a VM cannot exceed the actual physical memory size of the node.

32

Virtual Sockets

The number of CPU sockets simulated for the VM through virtualization technology (such as QEMU). A virtual socket is a logical collection of virtual CPU resources, and the number of virtual sockets is not directly restricted by the number of physical sockets of the node (multiple virtual sockets can be simulated for a physical socket). Virtual sockets are used for some software that requires specific multi-CPU architectures (such as some databases and industrial software). To optimize resource scheduling, the system automatically recommends a value for this parameter based on the logic of minimum virtual sockets required and an even number of CPU cores per socket (when the total number of CPU cores is not 1). The number of virtual sockets changes with the total number of CPU cores, and you do not need to manually calculate it. By default, 1 virtual socket is configured for 12 or fewer CPU cores. When the number of CPU cores is large, multiple virtual socket options will be available for you to choose from.

1. Use the recommended value in most business scenarios (including office services and noncritical services). The recommended value is calculated by the system to optimize resource utilization.
2. Manually modify the value when the software prompts a specific requirement for the number of CPUs, such as 2 or 4, without the need to consider the number of physical sockets on the node.

3. To avoid software compatibility issues, ensure the number of CPU cores per socket is an even number (except when the total number of CPU cores is 1).

Cores per Socket

The number of CPU cores allocated to each virtual socket of the VM, calculated by dividing the total number of CPU cores by the number of virtual sockets. This parameter is used to optimize vCPU scheduling efficiency. By default, the system ensures this parameter is set to an even number (when the total number of CPU cores is not 1) to avoid compatibility issues with some systems or software. The value of this parameter is not directly restricted by the number of CPU cores per physical socket of the node. However, it is recommended to set a value no greater than the actual number of CPU cores per physical socket, thereby reducing performance loss caused by cross-physical core scheduling. The value of this parameter changes with the total number of CPU cores and virtual sockets, and you do not need to manually calculate it.

1. Use the value automatically calculated by the system based on the total number of CPU cores and virtual sockets (the value is an even number, except when the total number of CPU cores is 1).
2. If you manually modify the number of virtual sockets, check whether the value of this parameter is an even number. For example, if the total number of CPU cores is 18, and you set the number of virtual sockets to 2, the number of CPU cores in each virtual socket is 9, which is an odd number. In this case, the system will automatically adjust the number of virtual sockets to 1 and the number of CPU cores per virtual socket to 18.
3. For optimal performance, ensure the number of CPU cores per virtual socket is smaller than the actual number of CPU cores per physical socket on the node. For example, if a physical socket contains 16 CPU cores, it is recommended to set the number of CPU cores per virtual socket to 16 or lower.

CPU Clock Speed Limit

The upper limit on the frequency of CPU resource usage. This parameter is configured to prevent excessive CPU usage caused by viruses, abnormal processes, and other reasons on the VM, avoiding impacts on other VMs on the same node and ensuring the stability of resource usage for business services.

It is recommended to enable this parameter only for noncritical VMs (such as VMs in test environments or on temporary business nodes) when CPU resources are insufficient. To avoid business impacts, it is not recommended to enable this parameter for critical VMs.

Note

1. By default, this parameter is disabled to meet the resource elasticity requirements of most services.
2.  Enabling this parameter will limit the maximum CPU performance of the VM, which may cause the VM to respond slowly when handling high-load tasks.

1. In most scenarios, this parameter is disabled by default, and you do not need to configure it.
2. Enable this parameter only for noncritical VMs when CPU resources are insufficient.
3. The value recommended by the system is preferred. You can modify the value if you have specific requirements for resource consumption control.
4. To avoid impacts on the VM's response speed to high-load tasks, enable this parameter only if it is necessary for the business.

Huge-Page Memory

A memory management optimization technique at the OS level. Dividing memory into pages way larger than the conventional memory page size (4 KB) can reduce the number of memory pages, lower memory management costs, and improve memory access efficiency and hit rate. The main features of this technique are as follows:

1. Advantages: In business scenarios with high memory performance requirements (such as database systems, big data analysis, and other scenarios that require a large number of continuous memory accesses), huge-page memory can decrease the number of memory page queries and reduce system resource loss.

2. Architecture differences: If huge-page memory is enabled, the default memory page size is 2 MB for x86/C86 VMs and 512 MB for Arm VMs.

3. VM compatibility: If huge-page memory is enabled for a VM, huge-page physical memory will be allocated when the VM starts up, and the memory pre-allocation mechanism will be triggered. The memory reclaiming feature will be disabled to ensure the VM has sufficient memory, thus improving business performance.
4. Memory dependency: The allocation of huge-page memory depends on the size of the node's pre-allocated memory. If the VM fails to be deployed, or you want to configure huge-page memory, you can check whether the pre-allocated memory is sufficient on the VM details page. For details, see the xx section of xx.[5]

5. System-level configuration: The huge-page memory configuration of the OS is disabled by default and needs to be manually enabled to work with the huge-page memory configuration of the VM.

1. Scenario-based configuration: Huge-page memory is disabled by default. It is only required for services with high memory requirements (such as database and big data analysis services). To ensure optimized performance, you need to manually enable it in both VM and OS settings. You do not need to enable it in scenarios such as noncritical office services and lightweight services.
2. Resource assessment: After huge-page memory is enabled, memory reclaiming will be disabled. Therefore, you need to assess the overall memory capacity of the node to avoid insufficient memory resources for other VMs due to excessive memory usage by the VM.
3. Synergistic effect: Ensure huge-page memory is enabled in both VM and OS settings to meet the expectations for memory management optimization.

NUMA Scheduler

A resource usage optimization feature that reduces cross-node memory access by binding the vCPUs of the VM to physical CPUs and the corresponding local memory. This parameter is enabled by default and requires no manual configuration, suitable for most business scenarios. If enabled, the memory access speed will increase by 20% and overall computing performance will increase by 7%-30%. In addition, business performance fluctuations will be reduced by avoiding remote memory access caused by random vCPU switches between physical CPUs.

This feature is suitable for high-performance business scenarios with frequent memory access, such as Oracle and SQL Server databases (extensive memory caching and read/write operations are required). For noncritical office services and lightweight services, keep this parameter in the default status (enabled).

Notes

1. To project NUMA topology into the VM (meeting special high-performance requirements), ensure the VM is installed with vmTools and has more than 8 CPU cores.
2. When the number of vCPU cores of the VM exceeds the number of CPU cores of a NUMA node, the system will automatically allocate the vCPUs evenly across multiple nodes and minimize cross-node memory access to ensure local memory access is prioritized.

1. This parameter is enabled by default and requires no manual operation.
2. To project NUMA topology into the VM, install vmTools and configure more than 8 CPU cores for the VM first.
3. This parameter cannot be disabled in normal scenarios. You can disable it temporarily only when troubleshooting performance anomalies or special software compatibility issues.
4. When the number of vCPU cores of the VM exceeds the number of CPU cores of a NUMA Node, the system will address the issue, and no manual intervention is required.

Host CPU

A configuration item that allows the VM to directly use the node CPU's native instruction set, rather than a general-purpose CPU model simulated by the virtualization layer (such as the default Intel (R) Core (TM) 2 Duo CPU T7700 @ 2.40GHz model on the Intel platform). This parameter is closely related to the hardware platform and directly determines the VM's performance and migration compatibility. The details are as follows:

1. Platform compatibility

• Arm: This parameter is enabled by default. The VM can be migrated if the CPUs of the source and destination nodes use the same major version and instruction set, and vendor identifier verification is not required.

• Intel: This parameter is disabled by default. If enabled, the VM can call the native instruction set of Intel CPUs. However, the VM can be migrated only if the CPUs of the source and destination nodes are of the exact same model. Otherwise, compatibility risks will arise.

• c86 (including Hygon): This parameter is disabled by default. It is recommended to enable this parameter when China-made CPUs are used (if not enabled, the CPU model of the VM will be displayed as AMD, which does not meet the compliance requirements). After this parameter is enabled, the VM can be migrated only if the CPU instruction sets of the source and destination nodes are consistent.

2. Advantages and disadvantages

• Advantages of enabling it: Avoid resource consumption for virtualized instruction set simulation and fully tap the computing performance of physical CPUs. Disadvantages of enabling it: VM migration and HA are restricted by physical CPU parameters (such as the model, instruction set, and vendor compatibility).

• Advantages of disabling it: A general-purpose virtualized CPU model will be used, which allows the VM to be migrated across nodes with different models of CPUs.

• Disadvantages of disabling it: Performance loss occurs during instruction set conversion at the virtualization layer, which limits the performance of compute-intensive services.

1. Intel server scenarios: Keep this parameter to the default value (disabled). Manually enable it only when the VM has a clear performance bottleneck (such as in big data modeling and high-frequency trading scenarios). Before enabling this parameter, configure an HA plan to ensure the CPU model of the destination node is the same as that of the current node, thereby avoiding migration failures due to hardware incompatibility.
2. c86 (including Hygon) server scenarios: It is recommended to enable this parameter when China-made CPUs are used. If you want to expand the cluster, confirm that the CPU instruction set of the new node is consistent with that of the existing node to avoid instruction set incompatibility issues when VMs with Host CPU enabled are migrated to the new node.

3. Arm server scenarios: Keep this parameter to the default value (enabled). Before migration, confirm that the CPUs of the source and destination nodes use the same major version and instruction set. 4. General configuration requirements: Before you enable Host CPU, it is recommended to export the CPU parameters (including the model, instruction set, and vendor ID) of the current node from the cluster management platform and select the destination node for subsequent migration accordingly. It is recommended to disable this parameter for VMs that need to be migrated frequently (such as VMs on service nodes with elastic expansion enabled).

Para-virtualized Clock

A clock optimization feature that only applies to Windows VMs. This parameter is disabled by default and can be enabled only if Host CPU is enabled (ensuring the VM clock is synced with the physical CPU clock).

The stability of the logic system clock directly affects the operational efficiency of services that rely on timestamps. When the clock is unstable, the Windows system needs to frequently calibrate the time, which leads to additional system overhead. Timestamp deviations may cause time-consuming operations, such as retries and waiting, in business processes (such as data read/write and task scheduling). Enabling this feature improves clock sync accuracy and reduces additional overhead.

This feature is suitable for VMs used for database services (such as SQL Server and MySQL) that have high requirements for clock accuracy, specifically in scenarios such as transaction processing (transaction sorting by timestamp), concurrency control (MVCC version differentiation), and scheduled tasks (precise task triggering). It can significantly improve the performance of database services on Windows systems.

This feature is suitable for VMs used for clock-sensitive database services (such as e-commerce order databases, financial transaction databases, realtime data storage, and daily incremental sync business databases) on Windows systems. It is not required for noncritical office services and lightweight data query services.

This feature can be enabled only if Host CPU is enabled, which means the VM can only be hot-migrated or recovered from the suspended state to another node with the same CPU model as the node where the VM runs.

1. This parameter is disabled by default and does not need to be manually enabled.
2. Enable this parameter only for VMs used for clock-sensitive database services on Windows systems.
3. To enable this parameter, enable Host CPU and confirm that the source and destination nodes for VM migration in the cluster have consistent CPU models.
4. Do not enable this parameter for noncritical office services and lightweight query services.

CPU Exclusive Mode

A resource management feature that allows the vCPUs of the VM to exclusively use the allocated physical CPU thread. This feature is disabled by default. If enabled, other VMs' vCPUs can no longer use the physical CPU thread, which prevents CPU resource contention. This feature can ensure the stability of business processing when the CPU load of the VM is high. However, it reduces the overall CPU utilization of the node because the exclusive physical CPU thread of the VM cannot be released to other VMs even when the actual CPU usage of the VM is low.

This feature is suitable for VMs used in scenarios with extremely high CPU performance requirements (including CPU-intensive computing scenarios such as scientific computing and big data modeling, and high-concurrency CPU processing scenarios such as realtime audio and video transcoding and critical nodes in high-frequency trading systems).

This feature is not suitable for scenarios with low CPU utilization (such as lightweight office VMs and low-concurrency backend service nodes) because it will result in resource waste. Keep it in the default status for VMs with ordinary CPU load to balance performance and resource efficiency.

1. By default, this parameter is disabled to optimize overall resource utilization.
2. Enable this parameter only in scenarios with high CPU load and high stability requirements.

3. To avoid resource waste, do not enable this parameter in scenarios with low CPU utilization (such as lightweight office services and low-concurrency services). 4. Enable this parameter only if it is necessary, and ensure business stability and resource utilization are balanced.

Run Location

A configuration item that determines the node where the VM is deployed and runs, and defines the association between the VM and the node. You can select Auto, or specify a preferred or fixed node. Different options correspond to different scheduling policies and HA capabilities.

1. Auto: The system automatically schedules the VM to a suitable node based on the node's reliability, performance, and available resources. DRS-based scheduling and HA policies will stay in effect and be automatically triggered when the node fails. This option is suitable for most scenarios, without specific dependencies.
2. Specified node (preferred): You need to specify a node to which the VM will be scheduled preferentially. If the specified node does not have sufficient resources or fails, the VM will be automatically scheduled to another node. DRS-based scheduling and HA policies will stay in effect. This option is suitable for scenarios where the VM needs to run on a specified high-performance node but can be automatically scheduled to another node if necessary.

3. Specified node (fixed): You need to specify the node to which the VM will be scheduled and select Run on specified node only. DRS-based scheduling and HA policies will be disabled, and manual intervention is required when the node fails. This option is suitable for scenarios where the business depends on specific hardware and automatic recovery is not required. To change the fixed node, deselect Run on specified node only first.

1. It is recommended to select Auto in most scenarios without special requirements.
2. If you want to run the VM on a specified high-performance node while retaining HA and DRS-based scheduling capabilities, specify a node but do not select Run on specified node only.
3. If the business depends only on specific hardware and automatic recovery from failure is not required, specify a node and select Run on specified node only.

4. To change the fixed node, deselect Run on specified node only first.

vCPU Model

The model of vCPUs allocated to the VM. Different vCPU models correspond to different generations of processors and support different nodes and CPU features. You can specify a vCPU model to define the processors, nodes, and CPU features compatible with the VM, striking a balance between VM performance and cross-node or cross-cluster migration stability while meeting different services' requirements for CPU instruction sets (such as compatibility with legacy services and high-performance requirements of new services). Valid values of this parameter are as follows:

• core2duo: This model is compatible with early generations of Intel processors (such as Merom and Penryn) and also some later generations. It provides basic features and supports legacy services. Haswell-noTSX: This model supports Intel Haswell and multiple later generations of processors (including Broadwell and Skylake). It provides more features (such as AVX2 and RDRAND) than core2duo.

• Cascadelake-Server-noTSX: This model supports Cascade Lake and later generations of processors, and provides more advanced features (such as AVX512 and PDPE1GB) than Haswell-noTSX.

• Icelake-Server-v4: This model supports Ice Lake and later generations of processors, and provides the most comprehensive features (including SHA and Vectorized AES). AMD and Hygon processors (such as EPYC and Phenom) are supported by other vCPU models, and the system will automatically select an appropriate vCPU model based on the priority of processors. Ensure that the selected vCPU model is supported by all nodes in the cluster. Otherwise, VM migration and startup will be affected.

In most scenarios, use the default value. HCI will automatically select the most suitable vCPU model based on the features of the cluster's physical CPUs (balancing performance and compatibility). You need to manually select a value only in the following scenarios:

1. Dependence on new features: Select Cascadelake-Server-noTSX or Icelake-Server-v4 for services (such as high-performance computing and encryption) that require new features like AVX512 and SHA instruction set extensions.
2. Compatibility with legacy environments: Select core2duo for services that run on legacy systems or software. 3. VM migration and adding: If the selected vCPU model is not supported by the destination node in another cluster, or compatibility issues occur after a new node is added, you need to change the value of this parameter to a vCPU model supported by all nodes. For instructions on how to modify the default configuration, see the attachment Supported vCPU Models and the vCPU Model Settings section of the HCI Configuration Manual.[6]

Provisioning

The allocation method of the virtual disk. You can select a method to balance performance and storage utilization. Valid values of this parameter are as follows:

• Pre-allocating: Pre-allocate all storage space when the virtual disk is initialized to improve IOPS and throughput and ensure optimal IO performance. However, a lot of storage space is pre-occupied, and the maximum disk capacity supported is 16 TB.

• Dynamic provisioning: Allocate the space for metadata when the virtual disk is created, and allocate the actual storage space only when data is written to the disk. This ensures good performance and can effectively save storage space. The maximum disk capacity supported is 16 TB. The actual storage usage will dynamically increase with data writes, and business interruption may occur when the storage usage approaches 100%. Monitor the storage usage to prevent storage overcommitment risks.

• Thin provisioning: Allocate the metadata space and storage space only when data is written to the virtual disk. This optimizes storage utilization but undermines IO performance. The maximum disk capacity supported is 63 TB. Storage overcommitment risks may arise.

1. Select Pre-allocating for databases and other high-IO critical services to ensure optimal IO performance.
2. Select Dynamic provisioning for noncritical services (such as office services and lightweight services) to balance performance and storage utilization. Monitor storage usage to prevent storage overcommitment risks.
3. Select Thin provisioning in scenarios where storage resources are insufficient and IO requirements are low to optimize storage utilization. Ensure storage overcommitment risks are acceptable.
4. Comply with the capacity limit of each allocation method, and switch to an appropriate method when the limit is exceeded.

VirtIO Disk

A type of disk that is based on a high-performance virtual driver. It uses a dedicated IO path to significantly improve disk IO performance. To enable this parameter, install vmTools first. If you do not enable this parameter, the disk type is IDE, which provides relatively poor IO performance. A VM supports only a maximum of 4 IDE disk drives (disks and CD/DVD drives), but up to 64 VirtIO disks (excluding 2 CD/DVD drives) are supported for a VM.

1. If the VM OS is Windows Server 2008 R2 and later or Linux 2.6.32 and later, it is recommended to enable this parameter to optimize IO performance and disk scalability. (For Windows VMs, vmTools must be installed before this parameter can be enabled.)
2. Disable this parameter only if the system does not recognize VirtIO disks and cannot start up. (In this case, IDE disks will be used, which undermines IO performance and disk scalability.)

Disk IO Limit

The maximum read/write speed and IOPS of the virtual disk. Enable this parameter to prevent noncritical VMs (such as infected VMs) from overly consuming storage IO resources and ensure the stable operation of critical VMs. Note: Do not set the limits too low. Otherwise, the VM may fail to start up or cannot run properly.

1. This parameter is disabled by default. You can enable it for noncritical VMs (such as test VMs and VMs on temporary nodes) when physical storage IO resources are insufficient.
2. After this parameter is enabled, specify the maximum read/write speed (Value range: 128 KB/s-102400 MB/s) and the maximum read/write IOPS (Value range: 16-2147483647) as needed.

Read Cache

A feature that caches read data in node memory to improve IO performance for read-intensive services (with no data loss risks). Configure this parameter when the VM is powered off. It is recommended to set the cache size to 1%-10% of the disk size and no greater than 64 GB. Enable this parameter only when read performance cannot meet business requirements, avoiding unnecessary memory consumption.

1. Enable this parameter in scenarios where read performance cannot meet business requirements (such as slow response to database queries), and set the cache size to 1%-10% of the disk size (no greater than 64 GB).
2. To reduce node memory usage, do not enable this parameter for noncritical services.
3. Configure this parameter when the VM is powered off, and the space for cache will be reserved after the VM starts up.

Space Reclamation

If this parameter is enabled, storage space will be released immediately after files are deleted. To enable this parameter, ensure the OS and underlying storage both support the discard command. For compatible OSes, visit the following link:[7]

This parameter does not take effect on IDE disks.

1. Enable this parameter if the VM OS and storage support the discard command. (For Windows VMs, you can directly enable this parameter. For Linux VMs, use the mount -O discard command to mount the disk so that the space reclamation mechanism can be triggered.)

Disk Encryption

A feature that uses the AES256 symmetric encryption algorithm to encrypt all disks on the VM to enhance data security. It cannot be disabled once enabled. If you enable this parameter, the following features will be unavailable: cloning, cross-cluster migration, image creation, export, and CDP backup. After enabling this parameter, you can select Built-in Server or KMS Server for Key Source, and the corresponding key needs to be configured in advance (For instructions, see the xx section of xx).[8] This is a software-based encryption feature that does not require any additional encryption hardware. You need to configure only one disk encryption key for each VM, and all disks on the VM share the same key after encryption. Disk encryption and decryption have certain impacts on VM performance.

1. Scenarios: Enable this parameter for services that need to meet compliance requirements and involve sensitive data (such as financial and government systems). You do not need to enable it for noncritical services.
2. Configuration: When you create a VM based on an ISO image, you can directly enable this parameter. For a VM created based on a built-in image, you need to enable this parameter after the VM is created and powered off during off-peak hours (when the VM is not accessed by any service). 3. Key management: Refer to the xx section of xx to create an encryption key,[9] and then select Built-in Server or KMS Server for Key Source.

4. Restrictions: This parameter cannot be disabled once enabled, and enabling it will make some features unavailable. To enable it, ensure features such as cloning and migration are not required throughout the entire business lifecycle. For performance-sensitive services, ensure the impacts of disk encryption and decryption on VM performance are acceptable.

Parameter

Description

Example Value

NIC

The switch that controls whether a virtual NIC is enabled. You can enable an NIC to connect it to the network and disable the NIC to disconnect it from the network.

1. Enable this parameter for services that require network communication (such as web services and database access). 2. To reduce resource usage, do not enable this parameter in scenarios where network communication is not required (such as local test environments).

Connected To

The network device (such as a virtual switch or VLAN) to which the virtual NIC is connected. You can use this parameter to define network segments or implement network isolation.

1. To implement network isolation between business services and test services, connect the corresponding NICs to different network devices. 2. To enable communication between nodes in a cluster, connect the corresponding NICs to the same network device.

Specify IP

The IPv4 or IPv6 address settings of the NIC. The settings will take effect after vmTools is installed. The specified IP address or DNS settings will be distributed to the VM. If the specified IP address is changed later in the VM OS, related settings will be disabled. You can enable them again as needed.

1. Configure and enable IP address settings in scenarios where fixed IP addresses are required (such as servers providing external services with fixed IP addresses or network policies relying on fixed IP addresses).
2. Install vmTools to ensure the specified IP address settings can take effect (For instructions, see the xx section of xx).
3. If the specified IP address is changed in the VM OS, check the status of the IP address settings on SCP and, if necessary, manually enable them again to ensure network consistency.

MAC Address

The MAC address of the virtual NIC. You can use the automatically generated address or manually specify one. Specify a MAC address in scenarios where IP-MAC address binding is required (such as software license verification and network access control). To simplify the configuration process, use the automatically generated MAC address.

1. In scenarios where IP-MAC address binding is required (such as software license verification and network access control), specify a MAC address and keep it properly.

2. In scenarios without special network policy requirements, use the automatically generated MAC address to reduce configuration complexity.

Adapter Model

The model of the virtual NIC. Different models have obvious differences in compatibility, transfer rate, and stability. Valid values of this parameter are as follows: ● Realtek RTL8139: This model is compatible with early versions of Windows and Linux systems, such as Windows 98 and Windows XP, with a maximum transfer rate of 100 Mbps and lower stability. It is suitable for scenarios where early versions of OSes are used.

• Intel E1000: This model is compatible with Windows 7 and later systems and Linux systems, with a maximum transfer rate of 1000 Mbps and moderate stability. It is suitable for general scenarios with medium network performance requirements.

• virtio: This model can be selected after vmTools is installed. It provides high stability and a transfer rate of over 1000 Mbps, matching the transfer rate of the physical NIC. It is suitable for scenarios with high network performance requirements, such as high-concurrency big data processing (this model is optimized by HCI).

1. Select Realtek RTL8139 in scenarios where compatibility with early versions of OSes (such as Windows XP) is required.
2. Select Intel E1000 in general business scenarios (such as common office services and noncritical services).
3. Install vmTools (For instructions, see the xx section of xx) and select virtio in scenarios with high network performance requirements, thereby optimizing the transfer rate and stability.[10]

4. Before you select a model, confirm that it is compatible with the VM OS to avoid network errors caused by system incompatibility.

Traffic Limit

The maximum outbound and inbound bandwidth (in Kbps) of the virtual NIC. You can configure this parameter to prevent noncritical VMs from overly consuming network bandwidth and ensure the stability of the critical business service network. This parameter is disabled by default and can be enabled only after vmTools is installed.

1. Enable this parameter for noncritical VMs (such as VMs on test or temporary nodes) when network resources are insufficient.
2. Specify the maximum outbound and inbound bandwidth based on the actual bandwidth requirements. It is recommended to specify a value that is higher than the minimum bandwidth required (for example, at least 1000 Kbps for office services) but does not exceed the maximum allocatable capacity.

3. Install vmTools (For instructions, see the xx section of xx) before enabling this parameter. Otherwise, this parameter will not take effect.

Set IP-MAC Address Binding

A configuration item that binds an IP address to the MAC address of the NIC. The VM is accessible only through the bound IP-MAC address, which improves network access security. Note: With IP-MAC address binding enabled, the bound IP addresses will not be distributed to the VM via vmTools until you configure an IP address for the NIC.

1. Enable this parameter in scenarios that require network access security control and IP theft prevention (such as critical server clusters and service nodes with sensitive data).
2. Configure an IP address for the NIC.and then enable this parameter to ensure IP address sync and binding policies work properly at the same time.

3. Perform a network connectivity test to confirm that the VM can be accessed through the bound IP-MAC address.

Graphics Card

The virtual graphics card used for graphics display on the VM. Different types of graphics cards have obvious differences in compatibility, performance, and scenario adaptability. Valid values of this parameter are as follows:

• Standard VGA GPU: It is compatible with almost all early versions of OSes (such as Windows XP and early versions of Linux systems), but its performance is low and can only meet basic desktop display needs.

• Cirrus GPU: It provides high performance and supports high-definition desktop display and lightweight graphics processing, compatible with most modern OSes (such as Windows 7 and later systems, and mainstream Linux systems).

• VMware Compatible GPU: It is optimized to ensure consistent graphics display performance for VMs migrated from VMware vCenter to HCI, balancing performance and compatibility.

• QXL GPU: It provides outstanding graphics processing performance and supports high-resolution and complex graphics rendering, suitable for scenarios with high requirements for desktop display and graphics processing performance (such as design apps and high-definition desktop cloud services).

1. Select Standard VGA GPU in scenarios where early versions of OSes (such as Windows XP and early versions of Linux systems) are used to ensure system compatibility and meet basic display needs.
2. 2. Select Cirrus GPU for general-purpose VMs (such as office desktops and common business systems) to balance performance and compatibility.

3. Select VMware Compatible GPU for VMs migrated from VMware vCenter to ensure normal graphics display after migration.

4. Select QXL GPU in scenarios with high requirements for graphics processing performance (such as design software and high-definition desktops) to improve desktop display and graphics processing experience.

5. If the VM OS fails to recognize the selected type of graphics card or display errors occur, try switching to another graphics card type until the issue is fixed.

Mouse Type

The interface type of the VM's mouse. Valid values: USB and PS2. This parameter is set to USB by default. If the mouse does not work due to compatibility issues, change the value to PS2. The change will take effect after you access the console again. If the mouse works properly, you do not need to change the value of this parameter.

1. Use the default value if the mouse works properly.

2. If the mouse does not work when this parameter is set to USB, change the value to PS2 and access the console again for the change to take effect.

Keyboard Layout

The default keyboard layout of the VM's VNC console. You can configure this parameter to adapt to the keyboard input habits for different languages or regions, and the configuration will affect your keyboard input experience in the VNC console.

1. Select a value based on the actual keyboard type (such as Chinese, English, or another language) you use.

2. If key mapping issues occur in the VNC console, change the value until the issues are fixed.

BIOS Type

The firmware boot mode of the VM. Valid values of this parameter are as follows:

• SeaBIOS: In this mode, hardware is initialized and tested, and the OS is set up by loading basic code. It is compatible with all 32-bit and 64-bit OSes, but the power-on self-test (POST) is time-consuming.

• UEFI: In this mode, hardware initialization and OS setup are complete in a faster and simpler manner using a unified and extensible firmware interface. It supports graphical interfaces and hardware driver installation, but it is incompatible with 32-bit OSes and some 64-bit systems (such as Windows Server 2008 and Windows Server 2008 R1). If UEFI installation fails, switch to the BIOS mode.

1. Select SeaBIOS for VMs running 32-bit OSes and 64-bit OSes that are incompatible with UEFI, such as Windows Server 2008 and Windows Server 2008 R1.
2. Select UEFI for VMs running 64-bit OSes that are compatible with UEFI (such as Windows 2012 and later systems, and mainstream 64-bit Linux systems) to enjoy fast VM startup and graphics processing.

3. If UEFI installation fails, change the value to SeaBIOS and try again.

BIOS Pause Time

The duration (in seconds) for BIOS configuration during VM startup. Set this parameter to 0 if you want to directly start the system without modifying BIOS configuration. If the administrator needs to modify BIOS configuration (including startup items and hardware parameters), set this parameter to a positive integer (such as 5 or 10).

1. If you do not need to modify BIOS configuration, set this parameter to 0 to accelerate the VM startup.

2. If you need to modify BIOS configuration as the administrator, set this parameter to a positive integer (such as 5 or 10) as needed. 3. To avoid startup delay, do not set this parameter to a large value (30 or above) unless it is necessary.

Power on at host startup

A feature that automatically starts the VM when the node powers on. It is suitable for services that must run immediately upon node startup (such as core gateways and basic monitoring services). If enabled, the VM starts automatically without manual intervention, which increases the node's startup load and may cause startup delays.

1. This parameter is disabled by default. Enable it only if some services (such as core gateways and basic monitoring services) must start automatically upon node startup. 2. For noncritical services, keep it disabled to avoid unnecessary startup load.

Boot Order

A feature that defines the boot order of devices (including the system disk and CD/DVD drives) during VM startup. You can configure this parameter when you create a VM or when a created VM is shut down. If you select CD/DVD for 1, the boot will start from CD/DVD drives, which is suitable for scenarios such as OS reinstallation and boot disk switching. Improper configuration may cause boot failures.

1. By default, 1 is set to Disk 1, which means that the boot will start from the system disk to ensure business efficiency. 2. To start the boot from CD/DVD drives, set 1 to CD/DVD 1. 3. In scenarios where multiple storage devices are used, adjust the order as needed to prevent boot errors.

HA Settings

A feature that automatically migrates the VM to another node when the current node fails, ensuring service continuity. It allows the VM to recover automatically without manual intervention but incurs resource scheduling overhead. Note: For HA trigger rules and sensitivity, see the xx section of xx.[11]

1. HA is enabled by default. Keep it enabled for critical services (such as databases and trading systems) to ensure automatic VM recovery upon node failure. 2. Disable it for noncritical business that can tolerate downtime to reduce resource scheduling overhead.

Mark as high-priority VM

A feature that provides necessary resources (including CPUs, memory, and storage) to guarantee VM performance and service continuity. If enabled, CPU resources will be allocated to the VM preferentially, memory reclaiming will be disabled to ensure the VM has sufficient memory resources, and storage resources will be guaranteed for the VM by performing data rebuilding in the event of failure and migrating other VMs during data balancing. It is recommended to select a storage policy configured with high-performance automated QoS to achieve the best performance. Enabling this parameter will automatically disable memory reclaiming, and disabling this parameter will automatically disable CPU reservation.

1. This parameter is disabled by default. Enable it only for critical services with extremely high requirements for continuity and performance (such as critical databases and financial trading systems). 2. Before enabling this parameter, select a storage policy configured with high-performance automated QoS to achieve the best performance. 3. To avoid unnecessary resource consumption, do not enable this parameter for noncritical services.

Mark as high-performance VM

A configuration item that integrates the following features: Mark as high-priority VM, Huge-page Memory, Host CPU, and Pre-allocating. It ensures optimal CPU, memory, and storage IO performance for the VM, but consumes a lot of physical resources. It is suitable for business with heavy and continuous resource demands (such as big-data analytics and high-end ERP systems). When Host CPU is enabled, the VM can be hot-migrated only between nodes with the same CPU model. If you disable this parameter, you need to adjust related settings manually (including huge-page memory and disk provisioning type).

1. This parameter is disabled by default. Enable it only for services that require extremely high CPU, memory, and storage IO performance. 2. Before enabling this parameter, confirm that all related nodes use the same CPU model to prevent VM live migration failures. 3. Do not enable this parameter for noncritical services because the additional resource cost outweighs the performance benefits.

Reboot if fault occurs

A feature that automatically restarts the VM when the VM is not responding (due to crash, blue screen, etc.). It takes effect after vmTools is installed. If enabled, the VM can recover automatically without manual intervention. However, frequent restarts may lead to data consistency issues (vmTools needs to be installed to ensure reliability).

1. This parameter is disabled by default. Enable it for business that require high continuity (such as online services and trading systems). Ensure vmTools is installed on the VM (For instructions, see the xx section of xx).[12] 2. In test environments, keep this parameter disabled to facilitate root-cause troubleshooting.

Enable CPU hot add/Enable memory hot add

A feature that allows you to add CPU or memory resources for the VM while the VM is running. Install vmTools and use a supported OS (such as Windows Server 2012 or later, or Linux 3.0 or later) to ensure this parameter can take effect. If you enable this parameter, you can expand the VM capacity without shutting down the VM, avoiding service interruption. However, OS incompatibility may lead to risks such as capacity expansion failures.

1. This parameter is disabled by default. Enable it only for business that require scaling and cannot be interrupted. Before enabling it, check OS compatibility (view the list of supported OSes)[13] and install vmTools. 2. For business that can tolerate interruption, it is recommended to shut down the VM and then add CPU or memory resources, so as to ensure stability.

Enable UUID generator

A feature that generates a universally unique identifier (UUID) for the VM. Some apps running on the VM, especially those that rely on hardware-level licensing, require the UUID to work properly. However, if the UUID is changed after generation, app features may become unavailable. When you clone a VM or deploy a VM from a template, decide whether to generate a new UUID based on licensing requirements.

1. This parameter is disabled by default. Enable it if apps running on the VM require UUID-based licensing. 2. When you clone a VM, generate a new UUID if separate licensing is required. Keep the original UUID if the license can be inherited. 3. For general use cases, use the default setting to avoid unexpected software failures.

Enable TPM 2.0

A feature that enables TPM 2.0 for the VM. Windows 11 VMs have this parameter enabled by default and must run in UEFI mode (the system automatically switches to UEFI). TPM 2.0 is used for Windows 11 activation, BitLocker encryption, and similar security features. With this parameter enabled, the VM meets Windows 11 activation requirements and delivers better data security performance. This parameter is supported only in UEFI mode and is incompatible with early versions of OSes.

1. This parameter is enabled by default for Windows 11 VMs. Keep it enabled when TPM-based security features (such as encryption and compliance) are required for the VM, and ensure the boot mode is set to UEFI. 2. To avoid boot failures, disable this parameter if the VM OS does not support UEFI.

Enable VM escape detection

A feature that detects VM escape and generates alert logs for security and compliance auditing. Enabling this parameter enhances realtime risk detection and meets high compliance requirements, but increases extra monitoring overhead.

1. This parameter is disabled by default. Enable it in scenarios with high security requirements, such as financial and government services, to enhance risk detection. 2. For noncritical services, keep it disabled to reduce resource consumption.

Enable network affinity

A feature that preferentially schedules the VM to the NUMA node where the CPU core exclusively used for network forwarding is located to improve the VM network performance. It takes effect only when the NUMA scheduler or CPU exclusive mode is enabled. If this parameter is enabled, the network IO performance of the VM will be improved to suit the requirements of high-concurrency network services. However, the effectiveness of this parameter is subject to the status of the NUMA scheduler or CPU exclusive.

1. This parameter is disabled by default. Enable it for services with high network load (such as high-concurrency web services and realtime data transmission) when NUMA scheduler or CPU exclusive mode is enabled. 2. Keep it disabled if NUMA scheduler and CPU exclusive mode are disabled, because it will not take effect in such conditions.

Regularly sync guest time with node

A feature that syncs the VM's time with the node at regular intervals to ensure consistent timestamps in scenarios such as HA failover, live migration, and recovery from a snapshot. This parameter takes effect when periodic time sync is enabled for the cluster where the VM is located, and vmTools is installed. It prevents time differences during HA or migration. However, user-defined time settings will be restricted.

1. This parameter is enabled by default. Keep it enabled to ensure time consistency if features such as HA, migration, and recovery from a snapshot are required for the VM. 2. Disable it if the VM must use custom time configuration (such as for services that require a specific time zone). In this case, manually sync the VM time with the RTC time of the node.

Enable memory reclaiming

A feature that automatically reclaims free memory of idle VMs. This parameter is automatically disabled when the VM is marked as a high-priority VM. Enabling it improves memory usage. In High-priority VM scenarios, this parameter becomes invalid and the system relies on other resource-protection mechanisms.

1. This parameter is enabled by default. Keep it enabled for ordinary VMs (such as those used for office services or lightweight services) to improve memory usage. 2. The system automatically disables this parameter for high-priority VMs, and no manual operation is required.

Support VirtIO

A feature that enables VirtIO disks for the VM to significantly improve disk IO performance. This parameter is supported for VMs running Linux 2.6.18 or later systems and VMs that run Windows systems, excluding Windows 2000, and have vmTools installed. Enabling it improves the disk IO performance of the VM to meet the requirements of IO-intensive services such as databases and big data services. Unsupported OSes cannot recognize VirtIO disks.

1. This parameter is enabled by default. Keep it enabled for VMs used for IO-intensive services, such as databases and big data services, and ensure vmTools is installed. 2. Disable it for VMs with legacy OSes, such as Windows 2000 and Linux versions earlier than 2.6.18, to avoid disk recognition issues.

Enable Turbo mode

A feature that reduces storage IO latency and boosts storage performance. It accelerates storage IO responses and is suitable for databases and apps with high IO concurrency. This parameter does not have obvious downsides, and you can enable it as needed.

1. This parameter is disabled by default. Enable it for storage-sensitive services such as databases and apps with high IO concurrency. 2. For general storage scenarios, disable it to reduce resource overhead.

Filter out pagefile

A feature that is effective only on Windows systems. If enabled, page files will be filtered out during backup to reduce storage usage and backup duration (no filtering during backup when the VM is shut down). This parameter takes effect after vmTools is installed. Although enabling it significantly reduces storage consumption and backup duration, page files cannot be filtered out during backup when the VM is shut down.

1. This parameter is disabled by default. Enable it for Windows VMs with frequent backups and ensure vmTools is installed. 2. Disable it when a full backup (including page files) is required.

Enable L3 cache

A feature that improves VM performance in heavy-load business scenarios with frequent process switches. The scheduler schedules processes to neighboring CPUs without sending an IPI request, which reduces the performance cost caused by IPI. Enable it only for high-concurrency, multi-process services (such as middleware clusters and large-scale computing). Disable it for noncritical services to reduce resource overhead.

1. This parameter is disabled by default. Enable it for high-concurrency services such as middleware clusters and large-scale computing. 2. Disable it for noncritical services to reduce resource overhead.

Basics

Name

The name of the VM. VM names are used to distinguish VMs serving different business functions and facilitate VM management and search.

1. Specify a name according to the business scenario (such as Production Database - Primary Node or Test Web Service - 01) to ensure clarity. 2. When you bulk create VMs, the system automatically adds incrementing suffixes to the VM names (e.g., xxx-0001). You can also set a custom starting value for the suffixes (such as 1126).

Tag

The identifier for classifying and managing the VM. VM tags can be used for resource search, permission control, cost attribution, etc., and you can set multiple tags for a VM.

1. Set tags by business line, environment (production or test), department, etc. (such as Finance and Test Environment). 2. Keep tags concise and distinct for easy bulk operations and resource statistics.

Description

The additional information about the VM's business purpose or configuration. It improves the readability and maintainability of resources.

1. Enter key information (e.g., for critical trading systems, CPU 8 cores, and 32G memory). 2. If no additional information is required, leave this parameter blank to avoid redundant information.

Group

The resource group to which the VM belongs. Put VMs in different groups for resource isolation, and independent permission control and administrator domain management.

1. Select a group based on the business cluster or security domain (such as Critical Financial Cluster or R&D Test Group). 2. If no special isolation requirement exists, use the default group.

System Information

Login Mode - Key pair

An authentication method based on the public key and private key. The public key is deployed on the VM, and the private key is kept by the user. This method ensures high security and is supported only on Linux VMs.

1. For Linux VMs used for services that require high security, select Key Pair for Login Mode. Keep the private key securely (encrypt it and change it regularly). 2. For non-Linux VMs or when key pairs are not required, set Login Mode to Specify password to avoid invalid configuration.

Login Mode - Specify password

An authentication method based on the username and password configured for the VM. This method is universal and works for both Windows and Linux VMs.

1. Set Login Mode to Specify password in most scenarios (including Windows VMs and Linux VMs without key-pair requirements). Use a strong password that includes uppercase letters, lowercase letters, digits, and special characters. 2. Change the password regularly to avoid weak password risks.

Login Mode - Original image password

An authentication method based on the default password built into the VM image. Make sure you already know the password before selecting this option.

1. Select Original image password for Login Mode only when the default password is known and quick setup is required. Otherwise, select another option to prevent login failures.

Reset SID

For Windows VMs created through cloning or deployed from templates, the security identifier (SID) may be duplicated. A reset ensures each VM has a unique identifier. Notes: If the VM is powered off, the SID will be reset after the VM is powered on. Resetting the SID of a Windows VM will disable the default administrator account. Make sure a custom administrator account is available before the reset. If the VM password is also reset, the administrator account remains enabled.

1. For Windows VMs created through cloning or deployed from templates, enable this parameter to avoid security and permission conflicts. 2. Create an additional administrator account before the reset to avoid lockout. 3. For Windows VMs with no SID conflict risks, keep this parameter disabled.

Hostname

The hostname of the VM, used for system and network identification. You can set this parameter to Use default hostname or New. This parameter takes effect after vmTools is installed.

1. Select New and specify a hostname if the business requires a specific hostname pattern (for example, web-server-01). 2. Select Use default hostname if no special naming requirements exist. 3. Ensure vmTools is installed (For instructions, see the xx section of xx).[14]

Expiration Date

The expiration date of the VM. When the VM expires, it can be released automatically or generate a reminder. This helps manage temporary business resources (such as test environments and short-term projects).

1. In temporary business or tenant scenarios, select Specified and specify an expiration date so that the VM can be released automatically after expiration.