Guest Operating System Information

Guest operating system identity for the VirtualMachineInstance will be provided by the label kubevirt.io/os :

  1. metadata:
  2.   name: myvmi
  3.   labels:
  4.     kubevirt.io/os: win2k12r2

The kubevirt.io/os label is based on the short OS identifier from libosinfo database. The following Short IDs are currently supported:

Short IDNameVersionFamilyID

win2k12r2

Microsoft Windows Server 2012 R2

6.3

winnt

https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2012-r2

Use with presets

A VirtualMachineInstancePreset representing an operating system with a kubevirt.io/os label could be applied on any given VirtualMachineInstance that have and match the kubevirt.io/os label.

Default presets for the OS identifiers above are included in the current release.

Windows Server 2012R2 VirtualMachineInstancePreset Example

  1. apiVersion: kubevirt.io/v1
  2. kind: VirtualMachineInstancePreset
  3. metadata:
  4.   name: windows-server-2012r2
  5.   selector:
  6.     matchLabels:
  7.       kubevirt.io/os: win2k12r2
  8. spec:
  9.   domain:
  10.     cpu:
  11.       cores: 2
  12.     resources:
  13.       requests:
  14.         memory: 2G
  15.     features:
  16.       acpi: {}
  17.       apic: {}
  18.       hyperv:
  19.         relaxed: {}
  20.         vapic: {}
  21.         spinlocks:
  22.           spinlocks: 8191
  23.     clock:
  24.       utc: {}
  25.       timer:
  26.         hpet:
  27.           present: false
  28.         pit:
  29.           tickPolicy: delay
  30.         rtc:
  31.           tickPolicy: catchup
  32.         hyperv: {}
  33. ---
  34. apiVersion: kubevirt.io/v1
  35. kind: VirtualMachineInstance
  36. metadata:
  37.   labels:
  38.     kubevirt.io/os: win2k12r2
  39.   name: windows2012r2
  40. spec:
  41.   terminationGracePeriodSeconds: 0
  42.   domain:
  43.     firmware:
  44.       uuid: 5d307ca9-b3ef-428c-8861-06e72d69f223
  45.     devices:
  46.       disks:
  47.       - name: server2012r2
  48.         disk:
  49.           dev: vda
  50.   volumes:
  51.     - name: server2012r2
  52.       persistentVolumeClaim:
  53.         claimName: my-windows-image
  55. Once the `VirtualMachineInstancePreset` is applied to the
  56. `VirtualMachineInstance`, the resulting resource would look like this:
  58. apiVersion: kubevirt.io/v1
  59. kind: VirtualMachineInstance
  60. metadata:
  61.   annotations:
  62.     presets.virtualmachineinstances.kubevirt.io/presets-applied: kubevirt.io/v1
  63.     virtualmachineinstancepreset.kubevirt.io/windows-server-2012r2: kubevirt.io/v1
  64.   labels:
  65.     kubevirt.io/os: win2k12r2
  66.   name: windows2012r2
  67. spec:
  68.   terminationGracePeriodSeconds: 0
  69.   domain:
  70.     cpu:
  71.       cores: 2
  72.     resources:
  73.       requests:
  74.         memory: 2G
  75.     features:
  76.       acpi: {}
  77.       apic: {}
  78.       hyperv:
  79.         relaxed: {}
  80.         vapic: {}
  81.         spinlocks:
  82.           spinlocks: 8191
  83.     clock:
  84.       utc: {}
  85.       timer:
  86.         hpet:
  87.           present: false
  88.         pit:
  89.           tickPolicy: delay
  90.         rtc:
  91.           tickPolicy: catchup
  92.         hyperv: {}
  93.     firmware:
  94.       uuid: 5d307ca9-b3ef-428c-8861-06e72d69f223
  95.     devices:
  96.       disks:
  97.       - name: server2012r2
  98.         disk:
  99.           dev: vda
  100.   volumes:
  101.     - name: server2012r2
  102.       persistentVolumeClaim:
  103.         claimName: my-windows-image

For more information see VirtualMachineInstancePresets

HyperV optimizations

KubeVirt supports quite a lot of so-called “HyperV enlightenments”, which are optimizations for Windows Guests. Some of these optimization may require an up to date host kernel support to work properly, or to deliver the maximum performance gains.

KubeVirt can perform extra checks on the hosts before to run Hyper-V enabled VMs, to make sure the host has no known issues with Hyper-V support, properly expose all the required features and thus we can expect optimal performance. These checks are disabled by default for backward compatibility and because they depend on the node-feature-discovery and on extra configuration.

To enable strict host checking, the user may expand the featureGates field in the KubeVirt CR by adding the HypervStrictCheck to it.

  1. apiVersion: kubevirt.io/v1
  2. kind: Kubevirt
  3. metadata:
  4.   name: kubevirt
  5.   namespace: kubevirt
  6. spec:
  7.   ...
  8.   configuration:
  9.     developerConfiguration:
  10.       featureGates:
  11.         - "HypervStrictCheck"

Alternatively, users can edit an existing kubevirt CR:

kubectl edit kubevirt kubevirt -n kubevirt

  1. ...
  2. spec:
  3.   configuration:
  4.     developerConfiguration:
  5.       featureGates:
  6.         - "HypervStrictCheck"
  7.         - "CPUManager"