Welcome to part #6 of this series following the development of instance types and preferences within KubeVirt!
It’s been over two years since the last update, during which the instance type
and preference APIs have matured significantly. This update covers the major
milestones achieved between KubeVirt v1.0.0 and v1.7.0.
Feedback
Feedback is always welcome through the upstream mailing list of kubevirt-dev, upstream Slack channel #kubevirt-dev or directly to me via lyarwood at redhat dot com.
Please also feel free to file bugs or enhancements against
https://github.com/kubevirt/kubevirt/issues using the /area instancetype
command to label these for review and triage.
Major Milestones
Removal of instancetype.kubevirt.io/v1alpha{1,2}
As planned in the previous update, the deprecated v1alpha1 and v1alpha2 API
versions have been removed. Users should ensure they’ve migrated to v1beta1 before upgrading to recent KubeVirt releases.
Deployment of common-instancetypes from virt-operator
A long-awaited feature has landed - virt-operator now deploys the
common-instancetypes bundles directly. This eliminates the need for separate
installation steps and ensures that a standard set of instance types and
preferences are available out of the box.
The latest deployed version is v1.5.1, providing a comprehensive set of
instance type classes and OS-specific preferences.
New Instance Type Features
IOThreads Support
Instance types can now configure IOThreads for improved storage performance:
apiVersion: instancetype.kubevirt.io/v1beta1
kind: VirtualMachineInstancetype
metadata:
name: io-optimized
spec:
cpu:
guest: 4
memory:
guest: 8Gi
ioThreadsPolicy: auto
CPU Hotplug Support via MaxSockets
The maxSockets field enables CPU hotplug capabilities:
apiVersion: instancetype.kubevirt.io/v1beta1
kind: VirtualMachineInstancetype
metadata:
name: scalable
spec:
cpu:
guest: 2
maxSockets: 4
memory:
guest: 4Gi
Memory Hotplug Support via MaxGuest
Similarly, maxGuest enables memory hotplug:
apiVersion: instancetype.kubevirt.io/v1beta1
kind: VirtualMachineInstancetype
metadata:
name: memory-scalable
spec:
cpu:
guest: 2
memory:
guest: 4Gi
maxGuest: 16Gi
Scheduling Controls
Instance types now support nodeSelector and schedulerName for fine-grained
scheduling control. The nodeSelector accepts any Kubernetes node labels
defined by cluster administrators:
apiVersion: instancetype.kubevirt.io/v1beta1
kind: VirtualMachineInstancetype
metadata:
name: gpu-workload
spec:
cpu:
guest: 8
memory:
guest: 16Gi
nodeSelector:
nvidia.com/gpu.present: "true"
schedulerName: custom-scheduler
Required Annotations
Instance types can now specify required annotations to be applied to VirtualMachineInstances:
apiVersion: instancetype.kubevirt.io/v1beta1
kind: VirtualMachineInstancetype
metadata:
name: annotated
spec:
cpu:
guest: 2
memory:
guest: 4Gi
annotations:
example.com/required-annotation: "value"
New Preference Features
Enhanced CPU Topology Control
New CPU topology options provide greater flexibility:
- Spread topology: Evenly distributes vCPUs between cores and sockets
- Any topology: Allows VirtualMachine to define topology while still using preferences
- SpreadOptions: Fine-grained control over spreading with
across(SocketsCores, CoresThreads, SocketsCoresThreads) andratiofields
apiVersion: instancetype.kubevirt.io/v1beta1
kind: VirtualMachinePreference
metadata:
name: spread-example
spec:
cpu:
preferredCPUTopology: spread
spreadOptions:
across: SocketsCores
ratio: 2
Note: The original preferCores, preferSockets, preferThreads constants
have been deprecated in favor of shorter cores, sockets, threads names.
Architecture Support
Preferences can now specify a preferred architecture:
apiVersion: instancetype.kubevirt.io/v1beta1
kind: VirtualMachinePreference
metadata:
name: arm64-optimized
spec:
preferredArchitecture: arm64
Panic Device Support
Panic devices can now be configured through preferences for improved crash diagnostics.
Firmware Preferences Update
PreferredEfi has been introduced to replace the deprecated PreferredUseEfi
and PreferredUseSecureBoot fields, providing a more flexible firmware
configuration mechanism.
Preferred Annotations
Similar to instance types, preferences can specify preferred annotations:
apiVersion: instancetype.kubevirt.io/v1beta1
kind: VirtualMachinePreference
metadata:
name: windows
spec:
annotations:
example.com/os: "windows"
ControllerRevision Upgrades
Support for upgrading ControllerRevisions to newer API versions has been implemented, enabling seamless migration as the API evolves.
What’s Coming Next
The most significant upcoming change is the promotion of the API to v1,
planned for KubeVirt v1.8.0. This milestone is tracked through
VEP #17 and implemented
in PR #16598.
https://github.com/kubevirt/kubevirt/issues?q=is%3Aopen%20label%3Aarea%2Finstancetype
The instance type and preference APIs continue to evolve based on community feedback. Check the KubeVirt issue tracker for upcoming enhancements and contribute your ideas!
