KubeVirt

In order to use the machine-controller to create machines using KubeVirt you must first install the latter. We provide a manifest for this, simply run kubectl apply -f examples/kubevirt-operator-0.19.0.yaml. We strongly recommend installing a version which is equal or higher than 0.19.0. machine-controller also uses the KubeVirt CDI which can be found under examples/cdi-operator.yaml to provision storage. It is important to have a basic understanding of Kubernetes storage. For more information regarding which types of storage can be used please refer to KubeVirt documentation.

Afterwards, you can use the provided examples/kubevirt-machinedeployment.yaml as base.

Sample machinedeployment.yaml

apiVersion: "cluster.k8s.io/v1alpha1"
kind: MachineDeployment
metadata:
  name: my-kubevirt-machine
  namespace: kube-system
spec:
  paused: false
  replicas: 1
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  minReadySeconds: 0
  selector:
    matchLabels:
      name: foo
  template:
    metadata:
      labels:
        name: foo
    spec:
      providerSpec:
        value:
          sshPublicKeys:
            - "<< YOUR_PUBLIC_KEY >>"
          cloudProvider: "kubevirt"
          cloudProviderSpec:
            clusterName: cluster-name
            auth:
              kubeconfig:
                # Can also be set via the env var 'KUBEVIRT_KUBECONFIG' on the machine-controller.
                # If instead specified directly, this value should be a base64 encoded kubeconfig.
                value: "<< KUBECONFIG_BASE64 >>"
            virtualMachine:
              instancetype:
                name: "standard-2"
                kind: "VirtualMachineInstancetype" # Allowed values: "VirtualMachineInstancetype"/"VirtualMachineClusterInstancetype"
              preference:
                name: "sockets-advantage"
                kind: "VirtualMachinePreference" # Allowed values: "VirtualMachinePreference"/"VirtualMachineClusterPreference"
              template:
                cpus: "1"
                memory: "2048M"
                primaryDisk:
                  osImage: http://10.109.79.210/<< OS_NAME >>.img
                  size: "10Gi"
                  storageClassName: kubermatic-fast
            affinity:
              nodeAffinityPreset:
                type: "" # Allowed values: "", "soft", "hard"
                key: "foo"
                values:
                  - bar
            topologySpreadConstraints:
              - maxSkew: "1"
                topologyKey: "kubernetes.io/hostname"
                whenUnsatisfiable: "" # Allowed values: "DoNotSchedule", "ScheduleAnyway"
          # Must align with the configured registryImage above
          operatingSystem: "ubuntu"
          operatingSystemSpec:
            distUpgradeOnBoot: false
            disableAutoUpdate: true
            # 'rhelSubscriptionManagerUser' is only used for rhel os and can be set via env var `RHEL_SUBSCRIPTION_MANAGER_USER`
            rhelSubscriptionManagerUser: "<< RHEL_SUBSCRIPTION_MANAGER_USER >>"
            # 'rhelSubscriptionManagerPassword' is only used for rhel os and can be set via env var `RHEL_SUBSCRIPTION_MANAGER_PASSWORD`
            rhelSubscriptionManagerPassword: "<< RHEL_SUBSCRIPTION_MANAGER_PASSWORD >>"
            # 'rhsmOfflineToken' if it was provided red hat systems subscriptions will be removed upon machines deletions, and if wasn't
            # provided the rhsm will be disabled and any created subscription won't be removed automatically
            rhsmOfflineToken: "<< REDHAT_SUBSCRIPTIONS_OFFLINE_TOKEN >>"
      versions:
        kubelet: 1.30.5

There are some things you need to keep in mind:

The machine-controller will create VMIs that have the same name as the underlying machine. To avoid collisions, use one namespace per cluster that runs the machine-controller
EvictionStratey of VMIs is set to external, so VMI eviction needs to handled properly by a custom external controller or manual action
Service CIDR range: The CIDR ranges of the cluster that runs KubeVirt and the cluster that hosts the machine-controller must not overlap, otherwise routing of services that run in the KubeVirt cluster won’t work anymore. This is especially important for the DNS ClusterIP.
clusterName is used to label VMs for LoadBalancer selection.

Serving Supported Images

For KubeVirt clusters, we use Containerized Data Importer (CDI), which is is a utility to import, to upload and clone Virtual Machine images for use with KubeVirt. At a high level, a persistent volum claim (PVC), which defines VM-suitable storage via a storage class, is created.

The Containerized Data Importer is capable of performing certain functions that streamline its use with KubeVirt. It automatically decompresses gzip and xz files, and un-tars tar archives. Also, qcow2 images are converted into the raw format which is required by KubeVirt, resulting in the final file being a simple .img file.

Supported file formats are:

Tar archive
Gzip compressed file
XZ compressed file
Raw image data
ISO image data
Qemu qcow2 image data

KubeVirt reads those images from an HTTP endpoint which is passed to the MachineDeployment spec. The field that should be used for to import those images is sourceURL.