Created attachment 1748244 [details] screenshot Created attachment 1748244 [details] screenshot Description of problem: Create a custom template from a provided template. Select "import from URL" or "import via registry" as a boot source option. When the template is created, a PVC is created as well. Version-Release number of selected component (if applicable): OCP 4.7.0-fc.2, CNV 2.6 How reproducible: 100% Steps to Reproduce: 1. Virtualization -> Templates 2. Create a custom template 3. Select "import from URL" or "import via registry" as a boot source option. Actual results: When the template is created, a PVC is created as well. Expected results: A PVC should not be created Additional info: See attached screenshot kind: Template apiVersion: template.openshift.io/v1 metadata: annotations: iconClass: icon-rhel name.os.template.kubevirt.io/rhel8.3: Red Hat Enterprise Linux 8.0 or higher template.kubevirt.ui/parent-provider: Red Hat template.kubevirt.ui/parent-provider-url: 'https://www.redhat.com' template.kubevirt.ui/parent-support-level: Full selfLink: /apis/template.openshift.io/v1/namespaces/default/templates/test-1111 resourceVersion: '5030398' name: test-1111 uid: c4252b63-5bdb-4cf2-8745-5ffb0193713b creationTimestamp: '2021-01-17T11:32:29Z' managedFields: - manager: Mozilla operation: Update apiVersion: template.openshift.io/v1 time: '2021-01-17T11:32:29Z' fieldsType: FieldsV1 fieldsV1: 'f:metadata': 'f:annotations': .: {} 'f:iconClass': {} 'f:name.os.template.kubevirt.io/rhel8.3': {} 'f:template.kubevirt.ui/parent-provider': {} 'f:template.kubevirt.ui/parent-provider-url': {} 'f:template.kubevirt.ui/parent-support-level': {} 'f:labels': .: {} 'f:flavor.template.kubevirt.io/small': {} 'f:os.template.kubevirt.io/rhel8.3': {} 'f:template.kubevirt.io/type': {} 'f:vm.kubevirt.io/template': {} 'f:vm.kubevirt.io/template.namespace': {} 'f:workload.template.kubevirt.io/server': {} 'f:objects': {} 'f:parameters': {} namespace: default labels: flavor.template.kubevirt.io/small: 'true' os.template.kubevirt.io/rhel8.3: 'true' template.kubevirt.io/type: vm vm.kubevirt.io/template: rhel8-server-small vm.kubevirt.io/template.namespace: openshift workload.template.kubevirt.io/server: 'true' objects: - apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: annotations: vm.kubevirt.io/flavor: small vm.kubevirt.io/os: rhel8 vm.kubevirt.io/validations: | [ { "name": "minimal-required-memory", "path": "jsonpath::.spec.domain.resources.requests.memory", "rule": "integer", "message": "This VM requires more memory.", "min": 1610612736 } ] vm.kubevirt.io/workload: server labels: app: '${NAME}' vm.kubevirt.io/template: rhel8-server-small vm.kubevirt.io/template.revision: '1' vm.kubevirt.io/template.version: v0.13.0 name: '${NAME}' spec: running: false template: metadata: labels: kubevirt.io/domain: '${NAME}' kubevirt.io/size: small spec: domain: cpu: cores: 1 sockets: 1 threads: 1 devices: disks: - name: cloudinitdisk disk: bus: virtio - name: rootdisk bootOrder: 1 disk: bus: virtio interfaces: - masquerade: {} name: default model: virtio networkInterfaceMultiqueue: true rng: {} machine: type: pc-q35-rhel8.3.0 resources: requests: memory: 2Gi evictionStrategy: LiveMigrate networks: - name: default pod: {} terminationGracePeriodSeconds: 180 volumes: - name: cloudinitdisk cloudInitNoCloud: userData: | #cloud-config user: cloud-user password: uxcy-xk2x-se0u chpasswd: expire: false - name: rootdisk dataVolume: name: test-1111-rootdisk-8v28s hostname: '${NAME}' parameters: - name: NAME description: Name for the new VM required: true PVC: default test-1111-rootdisk-8v28s Bound pv16 25Gi RWO,RWX nfs 25m
When a template is created from a perishable source like URL or Upload (btw/ this is not the case for registry images) we want to copy the source to a persistent data volume. This is done by design. closing this bug. Note: we should take care that in this cases the new persistent volume is cloned for each new VM via CDI data volume and not used as is, to enable more flexible use of this source.
Note II: > we should take care that in this cases the new persistent volume is cloned for each new VM via CDI data volume and not used as is, to enable more flexible use of this source. To make it clear: Currently, when we use such a template we will convert the rootdisk dataVolume into a datavolume source and clone it in each new VM.
Note III: it may be nice to alert users to such unexpected behaviour
Yaacov, I think we need to document about this, wdyt?
> I think we need to document about this, wdyt? +1, will open a jira to address documentation, leaving "need info" open for tracking
created a jira for alerting user that a new DV/PVC will be created https://issues.redhat.com/browse/CNV-9813