kubevirt: Unable to set a cpu mode for a VM

Is this a BUG REPORT or FEATURE REQUEST?:

kind bug

What happened: Attempted to set a VM to use host-passthrough for the CPU mode in the template, as per https://kubevirt.io/user-guide/#/workloads/virtual-machines/virtualized-hardware-configuration?id=mode

I can successful edit the VM template:

apiVersion: kubevirt.io/v1alpha2
kind: VirtualMachine
<...snip...>
    spec:
      domain:
        cpu: 
          mode: host-passthrough
<...snip...>

But upon starting the VM, the cpu property gets reset to {}:

apiVersion: kubevirt.io/v1alpha2
kind: VirtualMachine
<...snip...>
    spec:
      domain:
        cpu: {}
<...snip...>

What you expected to happen: That the CPU property would be honoured and the VM would boot in host-passthrough mode.

How to reproduce it (as minimally and precisely as possible): Create a VM and attempt to set the CPU property to ‘host-passthrough’ as above.

Anything else we need to know?:

Environment: $ virtctl version Client Version: version.Info{GitVersion:“v0.6.2”, GitCommit:“467db5c8ce17c5ca8e851809af1d890cf8dd900d”, GitTreeState:“clean”, BuildDate:“2018-07-18T11:24:15Z”, GoVersion:“go1.9.4”, Compiler:“gc”, Platform:“linux/amd64”} Server Version: &version.Info{GitVersion:“v0.6.2”, GitCommit:“467db5c8ce17c5ca8e851809af1d890cf8dd900d”, GitTreeState:“clean”, BuildDate:“2018-07-06T21:23:23Z”, GoVersion:“go1.9.4”, Compiler:“gc”, Platform:“linux/amd64”}

kubectl version Client Version: version.Info{Major:“1”, Minor:“10+”, GitVersion:“v1.10.0+b81c8f8”, GitCommit:“b81c8f8”, GitTreeState:“clean”, BuildDate:“2018-06-25T19:44:16Z”, GoVersion:“go1.9.4”, Compiler:“gc”, Platform:“linux/amd64”} Server Version: version.Info{Major:“1”, Minor:“10+”, GitVersion:“v1.10.0+b81c8f8”, GitCommit:“b81c8f8”, GitTreeState:“clean”, BuildDate:“2018-07-03T22:26:30Z”, GoVersion:“go1.9.4”, Compiler:“gc”, Platform:“linux/amd64”}

  • VM or VMI specifications:
- apiVersion: kubevirt.io/v1alpha2
  kind: VirtualMachine
  metadata:
    creationTimestamp: null
    labels:
      kubevirt-vm: ${NAME}-vm
    name: ${NAME}
  spec:
    running: true
    template:
      metadata:
        creationTimestamp: null
        labels:
          kubevirt-vm: ${NAME}-vm
      spec:
        domain:
          cpu:
            mode: host-passthrough
          devices:
            disks:
            - disk:
                bus: virtio
              name: disk0
              volumeName: ${NAME}-pvc
            - cdrom:
                bus: sata
                readonly: true
              name: cloudinitdisk
              volumeName: cloudinitvolume
          machine:
            type: q35
          resources:
            requests:
              memory: 8192Mi
        terminationGracePeriodSeconds: 0
        nodeSelector:
          kubernetes.io/hostname: computenode0.example.com
        volumes:
        - name: ${NAME}-pvc
          persistentVolumeClaim:
            claimName: ${NAME}-pvc
        - name: cloudinitvolume
          cloudInitNoCloud:
            userData: |-
              #cloud-config
              password: ${PASSWORD}
              disable_root: false
              chpasswd: { expire: False }
              ssh_authorized_keys:
              - ${KEY}
  • Cloud provider or hardware configuration: Dell PowerEdge R930

  • OS (e.g. from /etc/os-release): NAME=“Red Hat Enterprise Linux Server” VERSION=“7.5 (Maipo)” ID=“rhel” ID_LIKE=“fedora” VARIANT=“Server” VARIANT_ID=“server” VERSION_ID=“7.5” PRETTY_NAME=“Red Hat Enterprise Linux Server 7.5 (Maipo)” ANSI_COLOR=“0;31” CPE_NAME=“cpe:/o:redhat:enterprise_linux:7.5:GA:server” HOME_URL=“https://www.redhat.com/” BUG_REPORT_URL=“https://bugzilla.redhat.com/

REDHAT_BUGZILLA_PRODUCT=“Red Hat Enterprise Linux 7” REDHAT_BUGZILLA_PRODUCT_VERSION=7.5 REDHAT_SUPPORT_PRODUCT=“Red Hat Enterprise Linux” REDHAT_SUPPORT_PRODUCT_VERSION=“7.5”

  • Kernel (e.g. uname -a): Linux master.example.com 3.10.0-862.el7.x86_64 #1 SMP Wed Mar 21 18:14:51 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 16 (12 by maintainers)

Commits related to this issue

Most upvoted comments

maybe it’s to early to add secure?

For this specific issue I wonder if we can do an opt-in for pastshrough, as it’s a pretty special case (i.e. influences migration).

usePassthrough: true would be something for this specific case.

Then it’s also easily validateable i.e. when we get live migration.