Bug 1176806

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

Description of problem:
Clone of a Thin/Dependent VM on a template is Clone/Independent, but it should be also thin-provisioned & dependent on the template as the original VM is.

Version-Release number of selected component (if applicable):
ovirt-engine-3.5.0-0.0.master.20140804172041.git23b558e.el6.noarch (rc1).

How reproducible:
100%

Steps to Reproduce:
1. Create new VM from a template as Thin/Dependent.
2. Clone this VM.
3.

Actual results:
The cloned VM is created as Clone/Independent, i.e., doesn't depend on the template any more.

Expected results:
Cloned VM should be created also as Thin/Dependent on the template.

Additional info:

--- Additional comment from Omer Frenkel on 2014-09-07 17:41:28 IDT ---

Clone vm means copy of the vm, the cloned cannot be dependent on the template anymore, the same when you select "clone" when you create vm from template, its a copy of the disks and collapse of the snapshots, and then the vm is not dependent on the template any more, this is how cloning works, the same is for clone from snapshot.

--- Additional comment from Omer Frenkel on 2014-09-15 10:44:37 IDT ---

Paval, please change the test case and close this bug according to Comment 1

--- Additional comment from Pavel Novotny on 2014-09-17 15:31:22 IDT ---

(In reply to Omer Frenkel from comment #1)
> Clone vm means copy of the vm, the cloned cannot be dependent on the
> template anymore, the same when you select "clone" when you create vm from
> template, its a copy of the disks and collapse of the snapshots, and then
> the vm is not dependent on the template any more, this is how cloning works,
> the same is for clone from snapshot.

I think this deserves wider discussion, adding Scott...

From usability POV, I don't agree it should work like you say. Cloning VM and cloning VM disk(s) is not the same.
Cloning a VM should do copy of
- VM profile: RAM, vCPUs, boot options and also *template reference and resource allocation settings*
- VM devices: vNICs, *disks* (meaning VM disks, not template disks), ...

Reason for filing this bug came from following use case, which will be IMO common among customers:
- Have a Windows 7 (or other OS) template with 50 GB disk (actual size).
- Create new Thin/Dependent VM from the template.
- In the guest change some settings and install few programs that take, let's say, 2 GB.
- Clone the VM.

Result:
You have to wait until the whole 50 GB disk from template + 2 GB COW disk from VM are copied, which takes much more time, comparing to creating a Thin/Dependent VM.
The user is initially also not aware that the cloned VM takes 52 GB of storage instead of 2 GB, as one would expect.

The above example shows that in current state the "Clone VM" feature is quite useless for Thin/Dependent VMs, because it doesn't offer any advantages to Thin/Dependent VM provisioning, thus no body will use it in this case.

@Scott, what's your opinion on this?

--- Additional comment from Pavel Novotny on 2014-10-01 11:49:31 IST ---

Scott, any thoughts on this?

--- Additional comment from Pavel Novotny on 2014-10-13 18:16:02 IST ---

No response so far, adding also Michal.
Michal, can you please read comment 3 and tell what's your opinion? We need some resolution on this bug.

--- Additional comment from Michal Skrivanek on 2014-11-24 18:24:50 IST ---

the change makes sense. Omer, can you see if we can make it a default behavior? Seems to me it can't hurt ...

clone would just clone the VM the same way it was deployed from template. So we will have base disk(from template) + 'clone' of the changes disk(of the original VM)

--- Additional comment from Omer Frenkel on 2014-11-24 18:47:09 IST ---

afair, there is no way to do it currently, because we need some way to copy the chain of the disk (don't forget snapshots) and changing the volumes ids also.

today we can change disk id during copy only when doing collapse.
in order to allow this behavior, we probably need to ask storage to implemet this kind of ability, then on the engine side we need also to copy the vm snapshots and update the snapshots content (its OVF file saved in the db) because there are references to the disks ids inside.

bottom line, pretty complicated..

--- Additional comment from Michal Skrivanek on 2014-11-25 11:26:54 IST ---

IMHO the best would be to copy the chain of disks and update the IDs to point to the same base image. Then we can make it a choice:
copy VM - create a full independent copy (that's what current "clone VM" does today)
clone VM - create the "same" VM, thin provisioned off the same template disk (i.e. another dependent VM)

for that we need a new storage vdsm verb to copy only the disk chain, not the base image. It would be enough to ignore collapsing options for now, just copy the whole chain *after* the base image. Allon, is that feasible?

--- Additional comment from Allon Mureinik on 2014-11-30 18:33:32 IST ---

Basically, you'd want to create a NEW chain based off the same template, and then sync the contents, in a similar way that LSM does.

Generally speaking, this is feasible, but not sure about the timeline (although definitely not for oVirt 3.5.1!).

Scott/Sean, can you give some feedback about the priority of this RFE?

--- Additional comment from Sean Cohen on 2014-12-22 19:40:05 IST ---

I suggest to clone it to downstream to allow prioritization 
Sean
===============================================================================
Cloning to RHEV to have the PM discussion here.