Installation

Scaling limits

The module is designed for a cluster of this size:

• up to 1000 nodes;
• up to 50000 virtual machines.

The module has no additional restrictions and is compatible with any hardware supported by the operating systems on which it can be installed.

Hardware and software requirements

Hardware requirements for the virtualization module match the requirements for the Deckhouse Platform (DP), plus an additional requirement of CPU virtualization support on the hosts where virtual machines will be launched.

Additional requirements for virtualization support

On all cluster nodes where virtual machines are planned to be launched, hardware virtualization support must be provided:

• CPU: Support for Intel-VT (VMX) or AMD-V (SVM) instructions.
• BIOS/UEFI: Hardware virtualization support enabled in the BIOS/UEFI settings.

It is recommended to use Linux kernels with up-to-date security updates provided by the maintainers of your chosen distribution. Such updates are not a prerequisite for virtualization to function, but they reduce security risks for the cluster as a whole.

Supported guest operating systems

DP supports operating systems running on the x86 and x86_64 architectures as guest operating systems. For correct operation in paravirtualization mode, VirtIO drivers must be installed to ensure efficient interaction between the virtual machine and the hypervisor.

Successful startup of the operating system is determined by the following criteria:

• Correct installation and booting of the OS.
• Uninterrupted operation of key components such as networking and storage.
• No crashes or errors during operation.

For Linux family operating systems, it is recommended to use guest OS images with cloud-init support, which allows initializing virtual machines after their creation.

For Windows family operating systems, DP supports initialization with autounattend installation.

Virtual machine configuration limits

A single virtual machine has the following limits:

• Maximum number of cores supported: 248.
• Maximum amount of RAM: 1024 GB.
• The maximum number of block devices to be attached: 16.

Supported storage systems

Virtual machine disks are created using PersistentVolume resources. To manage these resources and allocate disk space in the cluster, one or more supported storage systems must be deployed:

Installation

Virtualization is deployed in several steps:

1. Deploy the Deckhouse Platform cluster following the instructions.

2. To store virtual machine data (virtual disks and images), enable one or multiple supported storages.

3. Set the default StorageClass:

   # Specify the name of your StorageClass object.
   DEFAULT_STORAGE_CLASS=replicated-storage-class
   sudo -i d8 k patch mc global --type='json' -p='[{"op": "replace", "path": "/spec/settings/defaultClusterStorageClass", "value": "'"$DEFAULT_STORAGE_CLASS"'"}]'

4. Turn on the console module, which will allow you to manage virtualization components through the Deckhouse web UI.

5. Enable the virtualization module:

   Enabling the virtualization module involves restarting kubelet/containerd and cilium agents on all nodes where virtual machines are supposed to start. This is necessary to configure the connectivity of containerd and DVCR.

   To enable the virtualization module, create a ModuleConfig resource with the module settings.

   Before enabling the module, carefully review its settings in the Administrator guide.

   Example of module configuration:

   d8 k apply -f - <<EOF
   apiVersion: deckhouse.io/v1alpha1
   kind: ModuleConfig
   metadata:
     name: virtualization
   spec:
     enabled: true
     settings:
       dvcr:
         storage:
           persistentVolumeClaim:
             size: 50G
           type: PersistentVolumeClaim
       virtualMachineCIDRs:
         - 10.66.10.0/24
     version: 1
   EOF

   To check if the module is ready, use the following command:

   d8 k get modules virtualization

   Example output:

   NAME             WEIGHT   SOURCE      PHASE   ENABLED   READY
   virtualization   900      deckhouse   Ready   True      True
   

   The module phase should be Ready.

Component placement across nodes

The distribution of components across cluster nodes depends on the cluster’s configuration. For example, a cluster may consist of:

• Only master nodes, for running the control plane and workload components.
• Only master nodes and worker nodes.
• Master nodes, system nodes, and worker nodes.
• Other combinations (depending on the architecture).

What each component is responsible for is described in Virtualization subsystem. The table below lists the components of the virtualization control plane and the nodes where they can be placed. Components are scheduled by priority, and if a suitable node type is available in the cluster, the component lands on it.

The virt-handler-* component runs only on the nodes where DP detected KVM support and set the virtualization.deckhouse.io/kvm-enabled label, and the virtualization-dra-* component runs only on nodes labeled virtualization.deckhouse.io/usbip.

Components used to create and import virtual machine images or disks (they run only for the duration of the creation or import operation):

Cluster with taints on all nodes

In some clusters, taints are configured on every node. This lets administrators explicitly control which nodes pods and virtual machines can be scheduled onto.

When running the virtualization module in this setup, keep the following in mind:

1. When creating a VirtualDisk, pay attention to the StorageClass volumeBindingMode. With Immediate, a PersistentVolume is created as soon as the disk is created — before the virtual machine is scheduled. Make sure the provisioner can create volumes on nodes that are allowed for virtual machines through placement settings, including nodeSelector, tolerations, and settings in the virtual machine spec or VirtualMachineClass. Otherwise, the disk may end up on a node where the virtual machine cannot run. With WaitForFirstConsumer, the volume is created on the node where the virtual machine is scheduled, and this issue does not occur.

2. VirtualImage and ClusterVirtualImage require the temporary components from the table above. They have a toleration for the dedicated.deckhouse.io=system taint.

3. The cluster must have a system NodeGroup, or the administrator can add the dedicated.deckhouse.io=system taint to selected nodes without creating a NodeGroup. Without such nodes, these components will not be scheduled, and images will not reach the Ready phase.

Module update

The virtualization module uses five update channels designed for use in different environments that have different requirements in terms of reliability:

The virtualization module components can be updated automatically or with manual confirmation, as updates are released in update channels.

For information on versions available at the update channels, see the release channels site.