Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1079739

Summary: Exporting a vm based on a template, exports the template disks as well
Product: Red Hat Enterprise Virtualization Manager Reporter: Meital Bourvine <mbourvin>
Component: ovirt-engineAssignee: Maor <mlipchuk>
Status: CLOSED WORKSFORME QA Contact: Aharon Canan <acanan>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.4.0CC: acanan, acathrow, amureini, eedri, gickowic, gklein, iheim, juwu, lpeer, nlevinki, obasan, Rhev-m-bugs, scohen, tnisan, yeylon
Target Milestone: ---Keywords: Triaged
Target Release: 3.5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: storage
Fixed In Version: Doc Type: Known Issue
Doc Text:
Cause: n/a Consequence: n/a Workaround (if any): n/a Result: This is not a note to describe a bug, but the way the system behaves, that may not be clear enough from the current documentation: - When exporting a VM that is thinly provisioned from a template, the template is exported too. - When exporting a VM cloned from the template, the template is NOT exported.
Story Points: ---
Clone Of:
: 1143768 (view as bug list) Environment:
Last Closed: 2014-07-01 11:24:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1143768    
Attachments:
Description Flags
logs none

Description Meital Bourvine 2014-03-23 15:57:04 UTC
Created attachment 877861 [details]
logs

Description of problem:
Exporting a vm based on a template, exports the template disks as well

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

How reproducible:
100%

reproduce:
1) Created a Template with disk id 13a2e228-b1d3-4ff2-807c-9dc367b975fd
2) Created a VM based on that template with disk id
e6f846c9-f5ce-4299-8892-1813cf59373e
3) Export the VM to the export domain.

Export VM (see [1])  is being done with the correct parameters, we can
see in the log that MoveImageGroupVDSCommand is being called only once
with the correct image group id e6f846c9-f5ce-4299-8892-1813cf59373e
(the VM image Group id):

MoveImageGroupVDSCommand(storagePoolId =
70ef088b-7852-4617-b396-8789395dbecf, ignoreFailoverLimit = false,
storageDomainId = 6ba792ba-3225-49d6-996e-f943c02c5c46, imageGroupId =
e6f846c9-f5ce-4299-8892-1813cf59373e, dstDomainId =
62f79c86-633c-4cd0-b1fd-3505f84b93b9, vmId =
3d9f45c7-4791-433f-a978-1a2710a7fafb, op = Copy, postZero = false, force
= false), log id: 11423f57

[1]
2014-03-23 16:43:17,839 INFO
[org.ovirt.engine.core.bll.ExportVmCommand] (ajp--127.0.0.1-8702-3)
[33ae32fb] Lock Acq
uired to object EngineLock [exclusiveLocks= key:
3d9f45c7-4791-433f-a978-1a2710a7fafb value: VM
, sharedLocks= ]
2014-03-23 16:43:17,871 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.GetVmsInfoVDSCommand]
(ajp--127.0.0.1-8702-3
) [33ae32fb] START, GetVmsInfoVDSCommand( storagePoolId =
70ef088b-7852-4617-b396-8789395dbecf, ignoreFailoverLimit =
 false, storageDomainId = 62f79c86-633c-4cd0-b1fd-3505f84b93b9, vmIdList
= null), log id: 3324cd8d
2014-03-23 16:43:17,885 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.GetVmsInfoVDSCommand]
(ajp--127.0.0.1-8702-3) [33ae32fb] FINISH, GetVmsInfoVDSCommand, log id:
3324cd8d
2014-03-23 16:43:17,905 INFO
[org.ovirt.engine.core.bll.ExportVmCommand]
(org.ovirt.thread.pool-6-thread-47) [33ae32fb] Running command:
ExportVmCommand internal: false. Entities affected :  ID:
62f79c86-633c-4cd0-b1fd-3505f84b93b9 Type: Storage
2014-03-23 16:43:17,907 INFO
[org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand]
(org.ovirt.thread.pool-6-thread-47) [33ae32fb] START,
SetVmStatusVDSCommand( vmId = 3d9f45c7-4791-433f-a978-1a2710a7fafb,
status = ImageLocked), log id: 67eea69d
2014-03-23 16:43:17,920 INFO
[org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand]
(org.ovirt.thread.pool-6-thread-47) [33ae32fb] FINISH,
SetVmStatusVDSCommand, log id: 67eea69d
2014-03-23 16:43:17,923 INFO
[org.ovirt.engine.core.bll.ExportVmCommand]
(org.ovirt.thread.pool-6-thread-47) [33ae32fb] Lock freed to object
EngineLock [exclusiveLocks= key: 3d9f45c7-4791-433f-a978-1a2710a7fafb
value: VM
, sharedLocks= ]
2014-03-23 16:43:17,938 INFO
[org.ovirt.engine.core.bll.CopyImageGroupCommand]
(org.ovirt.thread.pool-6-thread-47) [7022194] Running command:
CopyImageGroupCommand internal: true. Entities affected :  ID:
62f79c86-633c-4cd0-b1fd-3505f84b93b9 Type: Stocrage
2014-03-23 16:43:18,030 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.MoveImageGroupVDSCommand]
(org.ovirt.thread.pool-6-thread-47) [7022194] START,
MoveImageGroupVDSCommand( storagePoolId =
70ef088b-7852-4617-b396-8789395dbecf, ignoreFailoverLimit = false,
storageDomainId = 6ba792ba-3225-49d6-996e-f943c02c5c46, imageGroupId =
e6f846c9-f5ce-4299-8892-1813cf59373e, dstDomainId =
62f79c86-633c-4cd0-b1fd-3505f84b93b9, vmId =
3d9f45c7-4791-433f-a978-1a2710a7fafb, op = Copy, postZero = false, force
= false), log id: 11423f57
2014-03-23 16:43:18,212 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.MoveImageGroupVDSCommand]
(org.ovirt.thread.pool-6-thread-47) [7022194] FINISH,
MoveImageGroupVDSCommand, log id: 11423f57
2014-03-23 16:43:18,280 INFO
[org.ovirt.engine.core.bll.CommandAsyncTask]
(org.ovirt.thread.pool-6-thread-47) [7022194] CommandAsyncTask::Adding
CommandMultiAsyncTasks object for command
05f10f51-6b29-478b-85c1-3c3cc5c6bda2
2014-03-23 16:43:18,281 INFO
[org.ovirt.engine.core.bll.CommandMultiAsyncTasks]
(org.ovirt.thread.pool-6-thread-47) [7022194]
CommandMultiAsyncTasks::AttachTask: Attaching task
8ffc9f4d-e49e-408d-aad2-874714a08def to command
05f10f51-6b29-478b-85c1-3c3cc5c6bda2.
2014-03-23 16:43:18,330 INFO
[org.ovirt.engine.core.bll.AsyncTaskManager]
(org.ovirt.thread.pool-6-thread-47) [7022194] Adding task
8ffc9f4d-e49e-408d-aad2-874714a08def (Parent Command ExportVm,
Parameters Type
org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters), polling
hasn't started yet..
2014-03-23 16:43:18,428 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(org.ovirt.thread.pool-6-thread-47) [7022194] Correlation ID: 33ae32fb,
Job ID: d0d3c63a-1549-4f61-8c36-b89ecb619a5f, Call Stack: null, Custom
Event ID: -1, Message: Starting export Vm VM_from_template to export
2014-03-23 16:43:18,429 INFO  [org.ovirt.engine.core.bll.SPMAsyncTask]
(org.ovirt.thread.pool-6-thread-47) [7022194]
BaseAsyncTask::startPollingTask: Starting to poll task
8ffc9f4d-e49e-408d-aad2-874714a08def.
2014-03-23 16:43:19,206 INFO
[org.ovirt.engine.core.bll.AsyncTaskManager]
(DefaultQuartzScheduler_Worker-7) [72998423] Polling and updating Async
Tasks: 2 tasks, 1 tasks to poll now
2014-03-23 16:43:19,214 INFO  [org.ovirt.engine.core.bll.SPMAsyncTask]
(DefaultQuartzScheduler_Worker-7) [72998423] SPMAsyncTask::PollTask:
Polling task 8ffc9f4d-e49e-408d-aad2-874714a08def (Parent Command
ExportVm, Parameters Type
org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters) returned
status finished, result 'success'.
2014-03-23 16:43:19,220 INFO  [org.ovirt.engine.core.bll.SPMAsyncTask]
(DefaultQuartzScheduler_Worker-7) [72998423]
BaseAsyncTask::OnTaskEndSuccess: Task
8ffc9f4d-e49e-408d-aad2-874714a08def (Parent Command ExportVm,
Parameters Type
org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters) ended
successfully.
2014-03-23 16:43:19,222 INFO
[org.ovirt.engine.core.bll.CommandAsyncTask]
(DefaultQuartzScheduler_Worker-7) [72998423]
CommandAsyncTask::EndActionIfNecessary: All tasks of command
05f10f51-6b29-478b-85c1-3c3cc5c6bda2 has ended -> executing endAction



VDSM returns two image group ids:
[root@master-vds13 ~]# vdsClient -s 0 getImagesList
62f79c86-633c-4cd0-b1fd-3505f84b93b9 70ef088b-7852-4617-b396-8789395dbecf
e6f846c9-f5ce-4299-8892-1813cf59373e
13a2e228-b1d3-4ff2-807c-9dc367b975fd

Comment 1 Allon Mureinik 2014-03-24 13:23:32 UTC
This has been the behavior since RHEVM 3.2, at least (AFAIK, 3.1 too).
This is not a 3.4 item, let alone a blocker.

Comment 2 Ohad Basan 2014-03-24 13:28:19 UTC
The reason I marked it as an automation blocker is that this failure could masks other failures encountering in this job.

Comment 3 Allon Mureinik 2014-03-24 13:48:05 UTC
(In reply to Ohad Basan from comment #2)
> The reason I marked it as an automation blocker is that this failure could
> masks other failures encountering in this job.
This job NEVER completed successfully. It should not be running in a CI env.

Comment 5 Meital Bourvine 2014-03-24 14:04:49 UTC
I'm not removing a test that discovers a bug because we actually found a bug with it...

Comment 13 Allon Mureinik 2014-06-25 08:41:28 UTC
Unclear from comment #1 what the issue is.
If the VM is thinly provisioned from the template - it SHOULD be exported.
If the VM is cloned from the template - it SHOULD NOT be exported.

Comment 14 Gadi Ickowicz 2014-07-01 09:17:22 UTC
(In reply to Allon Mureinik from comment #13)
> Unclear from comment #1 what the issue is.
> If the VM is thinly provisioned from the template - it SHOULD be exported.
> If the VM is cloned from the template - it SHOULD NOT be exported.
Tested on 3.5 alpha, behaves as expected:
* exporting cloned vm does *not* export template
* exporting thin-provisioned vm *does* export template