SUSE Virtualization v1.6.1 Release Notes

The kubeovn-operator add-on is a tool for managing Kube-OVN as a secondary container network interface (CNI) on SUSE Virtualization clusters. Kube-OVN provides advanced software-defined networking (SDN) capabilities such as virtual private cloud (VPC) and subnets for virtual machine workloads. When you enable the add-on, it deploys Kube-OVN to your SUSE Virtualization cluster and creates the default Configuration CRD, which defines the desired state of the Kube-OVN installation.

Documentation | GitHub issue

The SUSE Virtualization network-controller leverages Kube-OVN to create an OVN-based virtualized network that supports advanced SDN capabilities such as VPCs and subnets for virtual machine workloads. An overlay network represents a virtual layer 2 switch that encapsulates and forwards traffic between virtual machines.

Documentation | GitHub issue

In SUSE Virtualization, a VPC is a logical network container that you can use to manage and isolate subnets and traffic. SUSE Virtualization provides a default VPC named ovn-cluster and allows you to create custom VPCs. At a high level, VPC creation involves enabling the kubeovn-operator add-on, creating an overlay network and a subnet, and linking the two networks.

The VPC implementation in v1.6 enables scalable, isolated L3 and L2 network structures across the cluster. Kube-OVN creates the VPC and its subnets, and manages all L3 logic (routing, NAT, VPC peering, and isolation). SUSE Virtualization defines the overlay networks and provisions virtual machines that are connected to those overlay networks. This architecture provides a clear separation of concerns: Kube-OVN handles SDN, while SUSE Virtualization handles virtualization.

Demo | Documentation | GitHub issue

In v1.6, virtual machines can connect with external networks if they are part of a subnet within the default VPC (ovn-cluster) and if the natOutgoing setting is enabled on that subnet. This setting enables network address translation (NAT) for all traffic leaving the subnet and heading to destinations outside of the VPC.

Communication between virtual machines in different VPCs is also possible. To achieve this, you must configure a VPC peering connection and static routes that define how traffic is forwarded. However, peering is limited to custom VPCs. You cannot establish a peering connection between the default VPC (ovn-cluster) and a custom VPC.

Demo | Documentation | GitHub issue

Isolation between virtual machines is typically achieved using either VLANs (in traditional networks) or virtual switches (in Kube-OVN). If you want to isolate virtual machines within the same virtual switch network, you can use subnet access control lists (ACLs) and Kubernetes network policies to achieve the required micro-segmentation.

Demo | Documentation | GitHub issue

SUSE Virtualization uses CDI to manage virtual machine image operations for certain StorageClasses. Starting with v1.6, you can use the UI to configure CDI settings when creating or updating a StorageClass. Each field on the CDI Settings tab corresponds to an annotation that modifies a specific StorageClass parameter. With this enhancement, you can avoid direct changes to the storage profile or CDI, which may result in unexpected system behavior. Instead, allow the SUSE Virtualization controller to synchronize and persist the storage profile configuration through the use of CDI annotations.

Demo | Documentation | GitHub issue

Starting with v1.6, you can increase a virtual machine’s CPU and memory resources while it is running. To use this feature, you must enable CPU and memory hotplug when you create the virtual machine. Once the virtual machine is created, you can add more CPU and memory resources at any time. SUSE Virtualization automatically migrates the virtual machine to a node that has the necessary resources.

Demo | Documentation | GitHub issue

In v1.6, you can monitor the progress of virtual machine live migration directly from the UI. The Migration tab of the virtual machine details screen displays migration event information and real-time metrics such as remaining data and memory transfer rate. To view the information, you must ensure that the rancher-monitoring add-on is enabled.

Demo | Documentation | GitHub issue

v1.6 allows you to expand volumes that are in use, as long as the underlying storage provider supports the feature. This works for volumes that are attached to a running virtual machine, or that have persistent volume claims (PVCs) connected to a running pod in a guest cluster.

The Longhorn V1 Data Engine fully supports online volume expansion, but the V2 Data Engine currently does not support it. For third-party storage, SUSE Virtualization blocks online volume expansion requests by default. To allow such requests, you must use the csi-online-expand-validation setting to validate the storage provider.

Demo | Documentation | GitHub issues: #2811 and #7358

In v1.5, support for third-party storage is limited to provisioning of root and data volumes for virtual machines. v1.6 improves on this by also allowing you to provision guest clusters and their corresponding workloads with third-party storage solutions.

In your guest cluster, you must first create a new StorageClass that references the StorageClass you created in SUSE Virtualization for the third-party storage solution. Then, you must create a PVC using this new StorageClass and mount it to your workload.

Demo | GitHub issues: #8075 and #8076

When importing virtual machine images using the vm-import-controller add-on, you can now specify a third-party storage solution instead of using SUSE Storage by default. To use this functionality, simply add the storageClass field to the VirtualMachineImport spec and specify the StorageClass for the third-party storage solution. SUSE Virtualization handles the import and storage placement without requiring you to perform additional manual steps.

Demo | Documentation | GitHub Issue

By default, SUSE Virtualization migrates virtual machines over the built-in cluster network mgmt, which is limited to one interface and is shared with cluster-wide workloads. If network segregation is required, you can configure a VM migration network to isolate migration traffic and improve bandwidth utilization.

Configuring a VM migration network involves enabling the vm-migration-network setting and constructing a Multus NetworkAttachmentDefinition CRD. Once the setting is applied, all virt-handler pods are restarted to apply the new network configuration.

Demo | Documentation | GitHub issue