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:
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.
Paval, please change the test case and close this bug according to Comment 1
(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?
Scott, any thoughts on this?
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.
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)
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..
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?
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?
I suggest to clone it to downstream to allow prioritization Sean
(In reply to Sean Cohen from comment #10) > I suggest to clone it to downstream to allow prioritization > Sean Done, see bug 1176806.
this is an RFE, not going to make 3.6, pushing to 4.0
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.
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
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.