Bug 1302780

This is a known issue which described at https://bugzilla.redhat.com/1108904:

  * Register the remaining disks to the existing VM in the setup
  ....
  * Register a template with part of the storage domains.

Basically the Disaster Recovery process should register entities only after all the existing Storage Domains are active and valid in the setup (see [1]).
The reason for that is that we assume that the recovery process after a setup gets destroyed is that the admin will first activate all its Storage Domains and only then will try to register the rest of the VMs/Templates, otherwise one might import a partial VM, use it, and then the rest of the disks, which were not registered yet will be out of sync with the VM's snapshots.

Can you please describe the automation test steps?
Can the automation test egister the Template only after all the relevant Storage Domains gets imported to the engine?

Reducing this to medium since this is a known issue.

[1] http://www.ovirt.org/Features/ImportStorageDomain#Restrictions:
  "Currently all the Storage Domains which are related to the VMs/Templates disks must exist and be active in the Data Center once the entity get registred."

Hi Maor,
I think you didn't understand me, so I'll try to be more clear following the steps to reproduce:
I'm not trying to register anything, I just want to be able to clone vm from template as thin copy to the imported SD.

1) To be able to clone a vm from template as thin, I should first need to make sure the template disk is located in the target SD (The domain I want to clone the vm to).
After copying the template's disk to the target domain, I can do the thin clone (the target SD will now appear in the target domain drop down list).

2) In that point, if I remove this domain, the target domain, without formatting it, I expect that the template's disk copy will still be there after I will import this domain back.

3) So after importing the domain, I'm trying again to:

4) Clone a vm from template as thin but this time I can't select the same target domain I just imported to the environment.

5) So I'm trying, again, to copy the template's disk to this domain but now I fail on the error:
error = Cannot create Logical Volume, code = 550

* Please raise the severity again to urgent in case it is not a known issue

That is basically what I meant, the import of Storage Domain is mainly used for recovery flow, for partial use (At this example, import of a Storage Domain which have a copied volume of a template disk which already exists in the setup) is not yet supported.
It is part of 
  "* Register the remaining disks to the existing VM in the setup"

Can you please describe what the automation test is testing for?
Maybe the test should be changed (at least until the RFE will be solved).

Hi Maor,
The test flow is what described in comment #2.

The solution I suggest is that when a copy will done, the engine will show a message saying that there is already a copied disk on this Storage Domain and the user should register it directly from the Import Disks sub tab (see https://bugzilla.redhat.com/1138139)

Eventually the solution will be much more simple:
Once a copied disk will be issued, if there will be an existing unregistered disk in the Storage Domain then the copy operation will not be issued but only a DB operation will add a new mapping to the unregistered disk.

Verified on ovirt-engine-4.0.0.4-0.1.el7ev.noarch using the steps to reproduced.
- Copy the template's disk to the imported domain - passed
- Cloning a vm as thin copy to the imported domain - passed

Seems like this is still happening.
New logs attached

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.

Created attachment 1168765 [details]
new logs

Hi,

Your vdsm log does not include the error which engine reports at 
2016-06-16 18:24:34,071 ERROR [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (DefaultQuartzScheduler6) [39c1ad6e] BaseAsyncTask::logEndTaskFailure: Task '0a4b9ca0-1230-4b0f-8066-55ec114ef475' (Parent Command 'MoveOrCopyDisk', Parameters Type 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters') ended with failure:
-- Result: 'cleanSuccess'
-- Message: 'VDSGenericException: VDSErrorException: Failed to HSMGetAllTasksStatusesVDS, error = Cannot create Logical Volume, code = 550',
-- Exception: 'VDSGenericException: VDSErrorException: Failed to HSMGetAllTasksStatusesVDS, error = Cannot create Logical Volume, code = 550'

Can you please attach it so I can analyze it

(In reply to Maor from comment #11)
> Hi,
> 
> Your vdsm log does not include the error which engine reports at 
> 2016-06-16 18:24:34,071 ERROR [org.ovirt.engine.core.bll.tasks.SPMAsyncTask]
> (DefaultQuartzScheduler6) [39c1ad6e] BaseAsyncTask::logEndTaskFailure: Task
> '0a4b9ca0-1230-4b0f-8066-55ec114ef475' (Parent Command 'MoveOrCopyDisk',
> Parameters Type
> 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters') ended with
> failure:
> -- Result: 'cleanSuccess'
> -- Message: 'VDSGenericException: VDSErrorException: Failed to
> HSMGetAllTasksStatusesVDS, error = Cannot create Logical Volume, code = 550',
> -- Exception: 'VDSGenericException: VDSErrorException: Failed to
> HSMGetAllTasksStatusesVDS, error = Cannot create Logical Volume, code = 550'
> 
> Can you please attach it so I can analyze it

Also, what were the reproduce steps I can see that there was a copy operation from storageDomainId '0f0215c9-478e-4749-8a25-742f6ae22d1b' to '21eca906-6332-40b9-990e-499bc54df353' but I can't see to find their attach operation in the engine log

Looks like there is a bug when a template disk has more than one copy of unregistered disk.
As part of the unregistered disks flow, the second attach of the storage domain will only keep only one copy of the unregistered disk.

Verified on rhevm-4.0.2-0.2.rc1.el7ev.noarch

It appears that automation ovirt moved the bug to modify although not all the patches were merged downstream.
I opened a ticket about it at : https://projects.engineering.redhat.com/browse/BUGZILLA-591

(In reply to Maor from comment #15)
> It appears that automation ovirt moved the bug to modify although not all
> the patches were merged downstream.
> I opened a ticket about it at :
> https://projects.engineering.redhat.com/browse/BUGZILLA-591

Changing the bug to modify so it can be re-verify with change 60125

Verified on rhevm-4.0.1.1-0.1.el7ev.noarch

Since the problem described in this bug report should be
resolved in oVirt 4.0.1 released on July 19th 2016, it has been closed with a
resolution of CURRENT RELEASE.

For information on the release, and how to update to this release, follow the link below.

If the solution does not work for you, open a new bug report.

http://www.ovirt.org/release/4.0.1/

*** Bug 1358171 has been marked as a duplicate of this bug. ***