Description of problem: When creating a VM on 4.14 without explixitely mentioning machineType, it does not pick-up default from Kubevirt CR [akriti@fedora ~]$ oc get vm vm1-rhel87-ocs -o yaml | grep -A 2 machine* machine: type: q35 [akriti@fedora ~]$ oc get kubevirt kubevirt-kubevirt-hyperconverged -n openshift-cnv -o yaml | grep machineType machineType: pc-q35-rhel9.2.0 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. create a vm , without explicitely mentioning machineType 2. check default machineType onm running VM 3. Actual results: machine: type: q35 Expected results: machine: type: pc-q35-rhel9.2.0 Additional info:
@akrgupta thanks for filing this, the culprit is this PR https://github.com/kubevirt/kubevirt/pull/8293 which changed KubeVirt to ignore `spec.configuration.machineType` in favor of the new arch-specific configuration in `spec.configuration.architectureConfiguration.amd64.machineType`. While I fix this you can just use the new field as a workaround. To fix it I'll do 2 PRs, the first downstream to use the new field by default and another one to still take into account the old field while declaring it as deprecated.
verify with build: CNV-v4.14.0.rhel9-1553 1. check default from kubevirt CR $ oc get kubevirt kubevirt-kubevirt-hyperconverged -n openshift-cnv -o yaml | grep machineType machineType: pc-q35-rhel9.2.0 machineType: pc-q35-rhel9.2.0 2. create a vm with default setting check default machineType on VM $ oc get vm vm-fedora -o yaml | grep -A 2 machine* machine: type: pc-q35-rhel9.2.0 resources: move to verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: OpenShift Virtualization 4.14.0 Images security and bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2023:6817