Created attachment 1906517 [details] nfs-client selected by default Description of problem: The template rhel8-small, datasource is having PVC in storage class ocs-external-storagecluster-ceph-rbd. ~~~ oc get pvc rhel8 -o yaml -n openshift-virtualization-os-images |yq -y '.spec' accessModes: - ReadWriteMany resources: requests: storage: '21474836480' storageClassName: ocs-external-storagecluster-ceph-rbd volumeMode: Block ~~~ However, while creating the VM using UI with customize option, by default storage class is set to the one which is first matched in alphabetical order instead of the template boot source storage class. Here it is nfs-client SC. Refer attached screenshot. The SC available in this environment is below: ~~~ oc get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE nfs-client k8s-sigs.io/nfs-subdir-external-provisioner Delete Immediate false 29h ocs-external-storagecluster-ceph-rbd openshift-storage.rbd.csi.ceph.com Delete Immediate true 32d ocs-external-storagecluster-cephfs openshift-storage.cephfs.csi.ceph.com Delete Immediate true 32d openshift-storage.noobaa.io openshift-storage.noobaa.io/obc Delete Immediate false 32d ~~~ If there is a default storage class, the default storage class is selected by default instead of the template source storage class. Version-Release number of selected component (if applicable): OpenShift Virtualization 4.10.4 How reproducible: 100% Steps to Reproduce: Refer above. Actual results: Customizing VM creation via template sets storageclass configuration to default Expected results: Like quick creation from the template, the template source storage class should be selected by default while using the customization option while creating the VM. Additional info:
The bug for 4.12 is https://bugzilla.redhat.com/show_bug.cgi?id=2118967. We should fix this problem on 4.12/4.11.z/4.10.z.
Create a VM from CLI, the VM is also using the default storage class, not the storage class of the template's boot source. So UI is consistent with CLI, move this bug to storage/virt for a look.
The UI should change its logic to use same storage class as the source pvc when no default sc is provided.
(In reply to Yan Du from comment #3) > The UI should change its logic to use same storage class as the source pvc > when no default sc is provided. This is not about no default SC is provided or not. It's about what SC should be used while creating a VM from a template which has the data source available. The default SC or the SC of the data source. Can you tell what SC should be used?
Hi Adam, What do you think? When the default SC is not same with the template boot source storage class, what SC should be used? Current both CLI and UI are using the default SC, but this bug report is expecting to take SC from the template boot source.
We would like to maintain the existing kubernetes semantics in order to avoid surprises. As has been mentioned previously, when the cluster has a default storage class defined the VM will use the default storage class unless the user opts for a different one. This is true regardless of whether the source PVC uses the same SC or a different SC. Let's discuss the case where the cluster does not have a default storage class defined. If a user were to create a DV (or VM with a dataVolumeTemplate) without specifying the storage class the DataVolume would remain in a Pending state because either no PVC could be created or the created PVC would not be bound by Kubernetes. Therefore, a Storage Class must be specified by the user. Coming back to the UI. When the system has no default storage class the UI should prompt the user to choose one. I see two possible options: 1) the UI suggests using the same storage class as the source PVC, or 2) the UI presents a list box where the initial state is no storage class selected and the user is required to select something. I think option #1 would be more user friendly.
(In reply to Adam Litke from comment #6) > We would like to maintain the existing kubernetes semantics in order to > avoid surprises. As has been mentioned previously, when the cluster has a > default storage class defined the VM will use the default storage class > unless the user opts for a different one. This is true regardless of > whether the source PVC uses the same SC or a different SC. > > Let's discuss the case where the cluster does not have a default storage > class defined. If a user were to create a DV (or VM with a > dataVolumeTemplate) without specifying the storage class the DataVolume > would remain in a Pending state because either no PVC could be created or > the created PVC would not be bound by Kubernetes. Therefore, a Storage > Class must be specified by the user. > > Coming back to the UI. When the system has no default storage class the UI > should prompt the user to choose one. I see two possible options: 1) the UI > suggests using the same storage class as the source PVC, or 2) the UI > presents a list box where the initial state is no storage class selected and > the user is required to select something. I think option #1 would be more > user friendly. Thanks for the very detailed updates. I did a check on UI for 4.10.z and 4.12, 4.10.z did perfectly but not 4.12. For 4.10.z, the cluster has no default SC: - if the template has boot source, the wizard use the same SC as the boot source - if the template has no boot source, no storage class is selected For 4.12, the cluster has no default SC: - if the template has boot source, the quick wizard use the same SC as the boot source, but the customize wizard use the first storage class or none. - if the template has no boot source, the first storage class is selected Move the bug to 4.13 for fix.
verified the bug on kubevirt-console-plugin-container-v4.11.2-5, the storage class of VM disk is taking from the template's PVC while creating vm either via quick mode or customize mode
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 (OpenShift Virtualization 4.11.3 Images), 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/RHEA-2023:0621