Bug 1815068 - Fail to create Windows VM from UI Wizard - cannot attach disk(s)
Summary: Fail to create Windows VM from UI Wizard - cannot attach disk(s)
Keywords:
Status: CLOSED DUPLICATE of bug 1811886
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Console Kubevirt Plugin
Version: 4.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: Tomas Jelinek
QA Contact: Nelly Credi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-19 12:03 UTC by Ruth Netser
Modified: 2020-03-23 06:37 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-23 06:37:26 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
screenshots (253.01 KB, application/x-xz)
2020-03-19 12:03 UTC, Ruth Netser
no flags Details

Description Ruth Netser 2020-03-19 12:03:45 UTC
Created attachment 1671428 [details]
screenshots

Description of problem:
When using the UI wizard to create a new Windows VM, it is not possible to attach disks.
Creating a Windows VM using PVC will fail.

(works with RHEL)

Version-Release number of selected component (if applicable):
OCP: 4.4.0-rc.1
CNV: 2.3 (operatorVersion: v0.26.3)

How reproducible:
100%

Steps to Reproduce:
1. Create a DV

apiVersion: cdi.kubevirt.io/v1alpha1
kind: DataVolume
metadata:
  name: win-16
spec:
  contentType: kubevirt
  pvc:
    accessModes:
    - ReadWriteMany
    resources:
      requests:
        storage: 38Gi
    storageClassName: nfs
    volumeMode: Filesystem
  source:
    http:
      url: "http://x.x.x.x/files/cnv-tests/windows-images/win_16.qcow2"2


2. From the UI, select "Workloads" -> "Virtual machines" -> "Create Virtual Machine" -> "New with Wizard"

3. General screen - enter the following:
-source: disk
- Operating system: Windows Server 16 (Could be any Windows OS)
- Flavor: medium (could be large)
- Workload profile: server
- Name:

4. Network Interfaces - continue
5. Disks screen - >"Add disk" - enter the following:
- Source: Attach disk
- Persistent Volume Claim: select the above-created PVC

Click "Add"

Actual results:
Windows VM from Wizard, using PVC, cannot be created.
- "Disk with this name already exists!" error appears in the "Add Disk" screen
- The disk is added in the Disks screen
- If the disk is selected in the "Boot Source" dropdown menu and "Next" is clicked, the following error appears:
=========================
Required fields not completed
Please select the boot source.
=========================

Expected results:
Disk can be attached, VM can be created.

Additional info:

- See attached screenshots

windows-server-medium-v0.7.0
apiVersion: template.openshift.io/v1
kind: Template
metadata:
  annotations:
    defaults.template.kubevirt.io/disk: rootdisk
    defaults.template.kubevirt.io/network: default
    description: This template can be used to create a VM suitable for Microsoft Windows
      Server 2012 R2 and newer. The template assumes that a PVC is available which
      is providing the necessary Windows disk image.
    iconClass: icon-windows
    name.os.template.kubevirt.io/win2k8: Microsoft Windows Server 2008
    name.os.template.kubevirt.io/win2k8r2: Microsoft Windows Server 2008 R2
    name.os.template.kubevirt.io/win2k12r2: Microsoft Windows Server 2012 R2
    name.os.template.kubevirt.io/win2k16: Microsoft Windows Server 2016
    name.os.template.kubevirt.io/win2k19: Microsoft Windows Server 2019
    openshift.io/display-name: Microsoft Windows Server 2012 R2+ VM
    openshift.io/documentation-url: https://github.com/kubevirt/common-templates
    openshift.io/provider-display-name: KubeVirt
    openshift.io/support-url: https://github.com/kubevirt/common-templates/issues
    tags: kubevirt,virtualmachine,windows
    template.kubevirt.io/editable: |
      /objects[0].spec.template.spec.domain.cpu.cores
      /objects[0].spec.template.spec.domain.resources.requests.memory
      /objects[0].spec.template.spec.domain.devices.disks
      /objects[0].spec.template.spec.volumes
      /objects[0].spec.template.spec.networks
    template.kubevirt.io/version: v1alpha1
    template.openshift.io/bindable: "false"
    validations: |
      [
        {
          "name": "minimal-required-memory",
          "path": "jsonpath::.spec.domain.resources.requests.memory",
          "rule": "integer",
          "message": "This VM requires more memory.",
          "min": 536870912
        }, {
          "name": "windows-virtio-bus",
          "path": "jsonpath::.spec.domain.devices.disks[*].disk.bus",
          "rule": "enum",
          "message": "virto disk bus type has better performance, install virtio drivers in VM and change bus type",
          "values": ["virtio"],
          "justWarning": true
        }, {
          "name": "windows-disk-bus",
          "path": "jsonpath::.spec.domain.devices.disks[*].disk.bus",
          "rule": "enum",
          "message": "disk bus has to be either virtio or sata",
          "values": ["virtio", "sata"]
        }
      ]
  creationTimestamp: "2020-03-18T08:43:54Z"
  labels:
    flavor.template.kubevirt.io/medium: "true"
    os.template.kubevirt.io/win2k8: "true"
    os.template.kubevirt.io/win2k8r2: "true"
    os.template.kubevirt.io/win2k12r2: "true"
    os.template.kubevirt.io/win2k16: "true"
    os.template.kubevirt.io/win2k19: "true"
    os.template.kubevirt.io/win10: "true"
    template.kubevirt.io/type: base
    template.kubevirt.io/version: v0.9.1
    workload.template.kubevirt.io/server: "true"
  name: windows-server-medium-v0.7.0
  namespace: openshift
  ownerReferences:
  - apiVersion: kubevirt.io/v1
    kind: KubevirtCommonTemplatesBundle
    name: common-templates-kubevirt-hyperconverged
    uid: 65a8525f-b496-4578-8c51-750d5c7b567c
  resourceVersion: "29524"
  selfLink: /apis/template.openshift.io/v1/namespaces/openshift/templates/windows-server-medium-v0.7.0
  uid: 5de92d39-c9f3-4f91-9f1c-2fafb45ba478
objects:
- apiVersion: kubevirt.io/v1alpha3
  kind: VirtualMachine
  metadata:
    labels:
      app: ${NAME}
      vm.kubevirt.io/template: windows-server-medium
      vm.kubevirt.io/template.revision: "1"
      vm.kubevirt.io/template.version: v0.9.1
    name: ${NAME}
  spec:
    running: false
    template:
      metadata:
        labels:
          kubevirt.io/domain: ${NAME}
          kubevirt.io/size: medium
      spec:
        domain:
          clock:
            timer:
              hpet:
                present: false
              hyperv: {}
              pit:
                tickPolicy: delay
              rtc:
                tickPolicy: catchup
            utc: {}
          cpu:
            cores: 1
            sockets: 1
            threads: 1
          devices:
            disks:
            - disk:
                bus: sata
              name: rootdisk
            interfaces:
            - masquerade: {}
              model: e1000e
              name: default
          features:
            acpi: {}
            apic: {}
            hyperv:
              relaxed: {}
              spinlocks:
                spinlocks: 8191
              vapic: {}
          machine:
            type: pc-q35-rhel8.1.0
          resources:
            requests:
              memory: 4Gi
        evictionStrategy: LiveMigrate
        networks:
        - name: default
          pod: {}
        terminationGracePeriodSeconds: 0
        volumes:
        - name: rootdisk
          persistentVolumeClaim:
            claimName: ${PVCNAME}
parameters:
- description: VM name
  from: windows-[a-z0-9]{6}
  generate: expression
  name: NAME
- description: Name of the PVC with the disk image
  name: PVCNAME
  required: true


See attached screenshots

Comment 1 Filip Krepinsky 2020-03-20 15:39:50 UTC
This seems to be a weird transpilation issue and it manifests itself as this bug. 

And cannot be reproduced locally (only in the builds in the test env):
oc version
Client Version: 4.4.0-0.nightly-2020-02-17-022408
Server Version: 4.4.0-rc.2
Kubernetes Version: v1.17.1


It fails in DiskBusValidationResult class in getErrorMsg method with an error RangeError: Invalid array length at array spread.

The function tries to spread a Set to an array. This is a typescript feature which is turned on by  "downlevelIteration": true in our tsconfig which transpiles it to es5.

So there is nothing apparently wrong in the code/config and it indeed works fine when you build it locally.


The weirdest part is, that in the env where it can be reproduced, this spread feature works in some places (e.g. rules.jsx) and in other places it doesn't.


What was the exact process of the build and the versions used? Were there any tweaks to the config or the versions?

Comment 2 Samuel Padgett 2020-03-20 16:01:56 UTC
This looks to be the same underlying cause as bug 1811886.

Comment 4 Tomas Jelinek 2020-03-23 06:37:26 UTC
Thank you Sam for the link!
To avoid tracking the same issue on two places, marking as duplicate.

*** This bug has been marked as a duplicate of bug 1811886 ***


Note You need to log in before you can comment on or make changes to this bug.