+++ This bug was initially created as a clone of Bug #2182938 +++

Description of problem:
Cannot clone VM to other namespace if the VM is created from instanceType.
It has no this problem if the VM is created from catalog template.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create a VM from instanceType
2. Clone the VM to another namespace
3.

Actual results:
error happens:
Error "Failure to find instancetype: controllerrevisions.apps "puzzled-lemming-server.medium-8c5a7842-7a9e-424e-ae89-324cf42433cd-1" not found" for field "spec.instancetype".

Expected results:
Clone is successful

Additional info:

— Additional comment from Ronen on 2023-03-30 16:47:18 CST —

@lyarwood@redhat.com and @fdeutsch@redhat.com this was opened as a UI issue, but how does the backend handles this?

— Additional comment from Ugo Palatucci on 2023-03-30 17:36:27 CST —

I think this happens because the instancetype is not cluster-level (ClusterInstanceType)

@rsdeor@redhat.com i would clone also the instance type in the new namespace.
@gouyang@redhat.com but i'm not sure its the right move.

How many useless instancetype we'll have at that point?

— Additional comment from Fabian Deutsch on 2023-03-30 17:40:14 CST —

What do we do for PVCs in the cloning case?
PVCs, just like InstanceTypes (namespaced), are namespace bound.

If we clone PVCs over to a new namespace, then cloning the specific instance type a VM is using sounds right.

— Additional comment from Fabian Deutsch on 2023-03-30 17:41:04 CST —

However, this shows the danger of namespaced instance types: We will quickly have bloat.

@lyarwood@redhat.com thoughts?

— Additional comment from Ronen on 2023-03-30 17:45:09 CST —

Is is only Instance Types or do we need the same for preferences?
If we use everything as global (not namespace bound) I'm concerned how customized items will be viewed by users

— Additional comment from Lee Yarwood on 2023-03-30 17:46:10 CST —

What API calls or CRDs is the UI using to orchestrate the clone of the VirtualMachine to another namespace? I don't see any support for cross namespace cloning in the VirtualMachineClone or VirtualMachineRestore resources AFAICT:

http://kubevirt.io/api-reference/main/definitions.html#_v1alpha1_virtualmachineclone

https://kubevirt.io/api-reference/main/definitions.html#_v1alpha1_virtualmachinerestore

The failure here isn't finding the instance type, it's finding the original copy of the instance type we stashed in a ControllerRevision within the original namespace. The current VirtualMachineClone/VirtualMachineRestore code expects this to be in the same namespace as the target VirtualMachine thus the failure at the moment.

If someone from UI could spell out how they are calling for the clone (or point to their code that handles this) I can see if there's some way of determining when the target namespace is different so we can copy over the ControllerRevision.

I don't think we should copy the underlying instance types around, if a user wants to refresh the ControllerRevision they can do this manually.

— Additional comment from Lee Yarwood on 2023-03-30 17:48:13 CST —

chowning this anyway and moving to infra as it's likely something we can handle on the backend.

— Additional comment from Lee Yarwood on 2023-03-30 18:53:36 CST —

Ah if I'm reading this code correctly the UI is manually orchestrating the creation of a cloned VirtualMachine into a new namespace without using anything on the backend to handle this:

https://github.com/openshift/console/blob/7b4ffbf8b121fbb9509bc757abfc945058878d53/frontend/packages/kubevirt-plugin/src/k8s/helpers/vm-clone.ts

IOW this is a UI bug as it needs to handle the cloning of any referenced ControllerRevisions for instance types or preferences into the new namespace as it already does for PVCs etc.

Moving back to the UX component. Happy to answer any questions related to our use of ControllerRevisions for instance types and preferences btw but please do review our user guide docs first:

https://kubevirt.io/user-guide/virtual_machines/instancetypes/#versioning

The following upstream issue and PR might be interesting, it covers changes that were required to handle the cloning on instance types and preferences when orchestrated by the VirtualMachineClone CRD:

https://github.com/kubevirt/kubevirt/issues/8446

https://github.com/kubevirt/kubevirt/pull/8466

Fabian, FWIW we likely need epics/stories capturing the need to support cloning between namespaces when using VirtualMachineClone so the UI could drop this custom code and leave the operation up to the backend in the future to avoid shortcomings like this from happening again.

— Additional comment from Ugo Palatucci on 2023-03-30 19:55:11 CST —

Hi @lyarwood@redhat.com

Since 4.12 we've switched to the dynamic plugin and this is the modal that handle vm cloning:

https://github.com/kubevirt-ui/kubevirt-plugin/blob/710264b4edc98b24b2f39c45f32ea87865737c91/src/views/virtualmachines/actions/components/CloneVMModal/CloneVMModal.tsx

Doing some tests. Seems like cloning VMs is not supported for different namespaces:

"The target and source must reside in the same namespace."

which is what we actually need.

I'm trying to clone a VM with dataVolumeTemplates and I get this error here:

`Error "Virtual Machine volume psychiatric-dragon-disk does not support snapshots" for field "spec.Source".`

— Additional comment from Ugo Palatucci on 2023-03-30 19:57:46 CST —

@fdeutsch@redhat.com
> What do we do for PVCs in the cloning case?

We use dataVolumeTemplates to handle the pvc cloning into a different namespace.

https://github.com/kubevirt-ui/kubevirt-plugin/blob/56362d5dedc933a15164923ee6293dda52533f49/src/views/virtualmachines/actions/components/CloneVMModal/utils/helpers.tsx#L81

— Additional comment from Lee Yarwood on 2023-03-30 20:22:45 CST —

(In reply to Ugo Palatucci from comment #9)
> Hi @lyarwood@redhat.com
>
> Since 4.12 we've switched to the dynamic plugin and this is the modal that
> handle vm cloning:
>
> https://github.com/kubevirt-ui/kubevirt-plugin/blob/
> 710264b4edc98b24b2f39c45f32ea87865737c91/src/views/virtualmachines/actions/
> components/CloneVMModal/CloneVMModal.tsx

This still looks like it's creating a fresh VirtualMachine and isn't using VirtualMachineClone etc to handle the clone on the backend?

> Doing some tests. Seems like cloning VMs is not supported for different
> namespaces:
>
> "The target and source must reside in the same namespace."

If that's the case then the fact it was possible to attempt in c#0 is a bug right?

> which is what we actually need.
>
> I'm trying to clone a VM with dataVolumeTemplates and I get this error here:
>
> `Error "Virtual Machine volume psychiatric-dragon-disk does not support
> snapshots" for field "spec.Source".`

Wait this is an error from the following VirtualMachineClone validation webhook code:

https://github.com/kubevirt/kubevirt/blob/32eb05f3038f28d2d0ecd77613660cd2097be5e5/pkg/virt-api/webhooks/validating-webhook/admitters/vmclone-admitter.go#L307-L311

So are we actually using VirtualMachineClone from the UI?

— Additional comment from Ugo Palatucci on 2023-03-30 20:26:20 CST —

No, we are not using it.

— Additional comment from Ugo Palatucci on 2023-03-30 20:29:25 CST —

Actually, we create vms using Cluster level instancetypes so we can fix this bug by removing the revisionName before creating the new vm.

But do we have to cover also the case of vms with namespaced instancetype?

— Additional comment from Lee Yarwood on 2023-03-30 20:44:02 CST —

(In reply to Ugo Palatucci from comment #13)
> Actually, we create vms using Cluster level instancetypes so we can fix this
> bug by removing the revisionName before creating the new vm.

That would cause the latest revision of the instance type to be pulled down and stashed in a new ControllerRevision. This might be different for the original so I wouldn't recommend doing it.

> But do we have to cover also the case of vms with namespaced instancetype?

Yes, I'd just copy the original over into the new namespace in both cases tbh.

— Additional comment from Guohua Ouyang on 2023-05-10 14:17:03 CST —

verified on kubevirt-console-plugin-rhel9:v4.14.0-1195