Configuring your KVM virtual machines
The SC//Reliant™ platform supports Linux and Windows 10 KVM virtual machines. The following KVM virtual node configurations may be used.
- Singleton - These are virtual nodes running on a single, stand-alone, edge security device with no clustering.
- Cluster - Multiple virtual nodes running in a highly available cluster on two edge security devices.
- A mix of the two - These are singleton virtual nodes running outside the cluster alongside virtual nodes running in a cluster on the same edge security device.
Configuring singleton virtual machines
Virtual machines (VMs) run as single, stand-alone, virtual nodes are often referred to as being run outside a cluster. The resources for singleton VMs are defined using the KVM Resources hash in SC//Reliant Platform Manager.
When administering KVM virtual nodes outside of the cluster, the usual utilities such as RLSI and RVC will not support operations on these virtual nodes. To manage these nodes from the command line, you will need to utilize commands from the libvirt library (virsh). More info on the virsh command can be found in the Debian manpages. You can also use crm_mon to list resources that are managed by the cluster and distinguish which virtual nodes are inside and outside of the cluster.
IMPORTANT: Do not use virsh commands to manage virtual nodes that run in a cluster. The cluster will see this as an unexpected shutdown or reboot and fail over the entire cluster.
Configuring clustered virtual machines
Virtual machines (VMs) run as highly available virtual nodes are referred to as being run inside a cluster. These VMs are monitored and will fail over to backup virtual nodes when an issue occurs. The resources for VMs inside a cluster are defined using the Cluster KVM Resources hash. In addition to the standard resource properties for VMs running outside a cluster, you must also define Distributed Replicated Block Device (DRBD) settings for these VMs. DRBD is a distributed system for replicating storage. It is used to mirror the storage data between the physical hosts.
Using raw values vs property references
When defining the values for each resource property, you may specify either a raw value or a property reference. We recommend using a property reference for values that are best defined at the individual node level, such as the details of a network interface. On the node group, you define the Node Properties that the property references refer to and associate them with the nodes in the node group. When a property reference isn't appropriate, you should specify a raw value for the resource property.
IMPORTANT: When using SC//Reliant Platform Manager, it's important to use the drop-down menu on the property value to choose either Raw Value or Property Reference. If you specify the name of a property reference but have Raw Value selected, it won't be treated as a property reference.
Understanding the resource property hierarchy
The resource property values may be specified at either the node or node group level. If a value is specified at the node level, it will be prioritized over the value at the node group level. For the full hierarchy, including values set at the site level, see Understanding configuration data.
KVM resources hash properties reference
The following are the properties that are used when defining the resources for your virtual machines. They are defined in the KVM Resources and Cluster KVM Resources hashes in SC//Reliant Platform Manager.
| Property | Type | Description | Required | Default value |
|---|---|---|---|---|
Auto Boot | Boolean | If Enabled, the VM will start automatically on boot. If you are running the VM inside a cluster, you should disable auto boot so that the platform can manage the starting and stopping of the VM. If you are running the VM outside a cluster, we recommend enabling auto boot. | Yes | - |
CPU Allocation - Cores | Integer | The number of virtual CPU (vCPU) cores to allocate to the VM. For guidance on choosing a value, see Allocating CPU. | Yes | - |
CPU Allocation - Threads | Integer | The number of threads per core. The total number of vCPUs the guest detects is cores multiplied by threads. For guidance on choosing a value, see Allocating CPU. | Yes | - |
CPU Allocation - Features | Key-value pairs | The elements used to fine-tune the features provided by the CPU model. For Windows VMs, you should disable Supervisor Mode Execution Prevention (SMEP) here. See Tuning CPU features. | No | - |
Memory | Integer | The amount of memory, in MB, to allocate to the VM. You should be aware of how much memory the physical hardware has to avoid overcommitting or allocating more memory than what is available. | Yes | - |
Disk Size | Integer | The size, in GB, of the disk. This property is used for singleton virtual nodes. | No | - |
DRBD Device | Text | The DRBD device name for the virtual node. For example, drbd1. This property is used for clustered virtual nodes. | Yes, in the Cluster KVM Resources hash | - |
DRBD Disk Size | Text | The size of the DRBD disk, which determines the amount of storage for the virtual node. This property is used for clustered virtual nodes. | Yes, in the Cluster KVM Resources hash | - |
DRBD Port | Integer | The port DRBD communicates over when sending data between the physical hosts. This property is used for clustered virtual nodes. | Yes, in the Cluster KVM Resources hash | - |
DRBD Volume Group | Text | The Logical Volume Management (LVM) group that the DRBD volumes reside in. This property is used for clustered virtual nodes. | Yes, in the Cluster KVM Resources hash | - |
Disk Cache | Text | The disk cache mode for all virtual disks. The supported values are none, writethrough, writeback, directsync, and unsafe. Use none to enable direct I/O, which suits the I/O-intensive VMs typical of this platform. If you use internal snapshots on the VM, use writethrough instead. | No | none |
Disk Bus | Text | The disk bus for all virtual disks used on the virtual node. The supported values are virtio and scsi. | No | virtio |
Interfaces | Text | The network interface(s) that the virtual node will bind to. | Yes | - |
Interface Mac Address | Text | This value defines the MAC address for all KVM network interfaces. We recommend using a random MAC address generator. This property is required when running VMs inside a cluster so that the VM presents the same MAC address after it fails over to the peer host. | Only in the Cluster KVM Resources hash | - |
Graphics Type | Text | The graphics protocol used to reach the VM console. The supported values are vnc and spice. Use spice if you want a richer console experience, including copy and paste between the host and the guest. | No | vnc |
Graphics Port | Integer | The port on the host that the graphics protocol listens on so the console can be accessed. Set this to a specific port so that the console address can be documented for the deployment. Set it to -1 to have an available port assigned automatically. | Yes | - |
Graphics Address | Text | The address that the graphics engine binds to. See Setting the graphics address. | Yes | - |
UUID | Text | The version 4 unique identifier (UUID) to associate with the VM. You can generate one by running uuidgen on any Linux host. This property is required when running VMs inside a cluster so that the VM keeps a stable identity across a failover. | Only in the Cluster KVM Resources hash | - |
Operating System | Text | The operating system the VM is using. Set this property to win10 for Windows 10 VMs, which turns on several options that are known to improve Windows performance. Leave this property blank for Linux VMs. | No | - |
Enable CD-ROM | Boolean | If Enabled, a CD-ROM device is added to the VM definition and becomes available in the boot order. Enable this property when you need to install an operating system or boot the VM from an ISO image. | No | - |
redefine | Boolean | If Enabled, when changes are made to the VM, the VM will be redefined. | No | - |
Enable hotplug | Text | Determines whether or not to turn on the ability to plug and unplug USB devices from the VM and have them automatically passed to the KVM instance. The supported values are present and absent. | No | absent |
Hotplug devices | Text | The list of USB device IDs to use for the hotplug option. | No | - |
USB devices | Text | The list of USB device IDs to turn on in the VM. | No | - |
Require USB devices | Text | Determines whether or not to require the usb_array items at boot time. The supported values are optional and mandatory. | No | optional |
Second Disk | Boolean | If Enabled, this turns on a second disk within the same VM with a copy of the qcow2 image used to boot the VM. | No | - |
Operations | Text | Optional operation settings for the VMs. | No | - |
Gold Image Filepath | Text | The file path to the image used during a SC//Reliant Virtual Controller (RVC) backup operation. | No | - |
UEFI Support | Boolean | If Enabled, Unified Extensible Firmware Interface (UEFI) support is turned on for the virtual machine. | No | - |
Allocating CPU
The total number of virtual CPUs (vCPUs) the guest detects is the number of cores multiplied by the number of threads per core.
Model a single processor socket rather than multiple sockets. Windows guests handle multiple sockets poorly and may fail to recognize more than one. The simplest approach is to set CPU Allocation - Cores to the total number of vCPUs you want the guest to have and set CPU Allocation - Threads to 1.
Before allocating, check how many logical cores the physical host has so that you don't overcommit. A CPU with 4 physical cores that is capable of hyper-threading presents 8 logical cores. Avoid allocating more vCPUs than there are logical cores on the host.
Tuning CPU features
The CPU Allocation - Features property takes key-value pairs that turn individual CPU features on or off for the virtual processor.
By default, KVM enables Supervisor Mode Execution Prevention (SMEP) on the virtual processor. On Windows VMs, this often causes sustained high CPU usage in which the guest reports close to 100% utilization with the System process consuming most of it. Disable SMEP on Windows VMs to avoid this.
| Key | Value |
|---|---|
smep | disable |
Setting the graphics address
The Graphics Address property is the address that the VM's graphics server listens on. This value normally changes over the life of the deployment.
- During initial installation, set the address to
0.0.0.0so that the console is reachable while you build the VM. - After installation is complete, change the address to
127.0.0.1to restrict console access to the host itself, or to the IP address of a specific interface if the customer needs to reach the console from their network.
IMPORTANT: Leaving the graphics address set to 0.0.0.0 exposes the VM console on every interface on the host. Narrow this value once installation is complete.
Recommended settings for Windows virtual machines
The following settings are recommended for Windows VMs on the SC//Reliant platform.
| Property | Recommended value | Reason |
|---|---|---|
Operating System | win10 | Turns on Windows-specific performance options |
CPU Allocation - Features | smep set to disable | Prevents sustained high CPU usage in the guest |
CPU Allocation - Cores | The total vCPU count you want | Presents the guest with a single processor socket |
CPU Allocation - Threads | 1 | Presents the guest with a single processor socket |
Disk Cache | none, or writethrough if you use internal snapshots | Enables direct I/O for I/O-intensive guests |
Graphics Type | spice | Supports copy and paste to the guest console |
Gold image synchronization
The /mnt/gold-images directory on a designated host stays in sync with the corresponding gold images stored in the Scale Computing managed Cloudflare R2 bucket. New VM images are uploaded to Cloudflare automatically when they are moved into the /mnt/gold-images directory on a host that is configured for DataSync upload. The host responsible for the upload is defined by Scale Computing in conjunction with the customer.
DataSync behavior is controlled by two environment variables in the Docker hash on each host:
| Variable | Description |
|---|---|
COMMAND | The sync direction. Set periodic_upload on the host where gold images are created, so that new images are uploaded to the cloud. Set periodic_download on hosts that consume gold images, so that they download the latest images. |
RDATA | The bucket prefix the host syncs with. Use the customer prefix alone (for example, CUS) on the uploading host, CUS/dev on hosts that test candidate images, and CUS/prod on hosts that run approved images. |
For the end-to-end workflow that these settings support, see KVM virtual machine deployment workflow.
For an example of using a property reference to control whether a virtual machine is built on a node, see Use case: Controlling whether a KVM virtual machine gets built on a node.