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
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?
This looks to be the same underlying cause as bug 1811886.
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 ***