Bug 1128150 - [RFE] - Clone VM: cloning a Thin/Dependent VM on a template creates Clone/Independent VM
Summary: [RFE] - Clone VM: cloning a Thin/Dependent VM on a template creates Clone/Ind...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: General
Version: ---
Hardware: Unspecified
OS: Unspecified
medium
medium vote
Target Milestone: ---
: ---
Assignee: bugs@ovirt.org
QA Contact: Nisim Simsolo
URL:
Whiteboard:
Depends On: 1058832 1176806
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-08 12:34 UTC by Pavel Novotny
Modified: 2019-04-28 09:55 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1176806 (view as bug list)
Environment:
Last Closed: 2018-07-06 15:37:20 UTC
oVirt Team: Virt
tjelinek: ovirt-future?
ylavi: planning_ack?
ylavi: devel_ack?
ylavi: testing_ack?


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 32112 master ABANDONED core: on clone vm the thin provisioned become clone provisioned Never

Description Pavel Novotny 2014-08-08 12:34:01 UTC
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:

Comment 1 Omer Frenkel 2014-09-07 14:41:28 UTC
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.

Comment 2 Omer Frenkel 2014-09-15 07:44:37 UTC
Paval, please change the test case and close this bug according to Comment 1

Comment 3 Pavel Novotny 2014-09-17 12:31:22 UTC
(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?

Comment 4 Pavel Novotny 2014-10-01 09:49:31 UTC
Scott, any thoughts on this?

Comment 5 Pavel Novotny 2014-10-13 16:16:02 UTC
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.

Comment 6 Michal Skrivanek 2014-11-24 16:24:50 UTC
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)

Comment 7 Omer Frenkel 2014-11-24 16:47:09 UTC
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..

Comment 8 Michal Skrivanek 2014-11-25 09:26:54 UTC
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?

Comment 9 Allon Mureinik 2014-11-30 16:33:32 UTC
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?

Comment 10 Sean Cohen 2014-12-22 17:40:05 UTC
I suggest to clone it to downstream to allow prioritization 
Sean

Comment 11 Allon Mureinik 2014-12-23 10:37:58 UTC
(In reply to Sean Cohen from comment #10)
> I suggest to clone it to downstream to allow prioritization 
> Sean
Done, see bug 1176806.

Comment 12 Tomas Jelinek 2015-08-24 12:05:15 UTC
this is an RFE, not going to make 3.6, pushing to 4.0

Comment 13 Red Hat Bugzilla Rules Engine 2015-10-19 10:58:42 UTC
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Comment 14 Tomas Jelinek 2016-09-08 06:06:01 UTC
The storage side does not seem to get in soon (https://bugzilla.redhat.com/show_bug.cgi?id=1176806#c16), pushing out from 4.1

Comment 15 Martin Tessun 2018-07-06 15:37:20 UTC
Looking at the usecase in c#3 Template versioning should be able to address this.

You should not start cloning VMs where new software has been added, but instead create a (new) template from it. I don't see any reason why a clone should keep the history of the template.

Closing this and BZ 1176806.


Note You need to log in before you can comment on or make changes to this bug.