Bug 1147011 - Can't import/clone a snapshot-less VM from export domain without unnecessarily setting copy-collapse to true via REST.
Summary: Can't import/clone a snapshot-less VM from export domain without unnecessaril...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: General
Version: 3.3
Hardware: x86_64
OS: Linux
unspecified
medium vote
Target Milestone: ovirt-3.6.2
: 3.6.2.5
Assignee: Fred Rolland
QA Contact: Raz Tamir
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-26 14:49 UTC by Sven Kieske
Modified: 2016-03-10 13:38 UTC (History)
13 users (show)

Fixed In Version: 3.6.0-11
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-02-18 11:15:37 UTC
oVirt Team: Storage
rule-engine: ovirt-3.6.z+
ylavi: planning_ack+
rule-engine: devel_ack+
rule-engine: testing_ack+


Attachments (Terms of Use)
engine and vdsm logs (566.13 KB, application/x-bzip)
2015-11-16 12:41 UTC, Raz Tamir
no flags Details


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 44181 master MERGED core: Fix copyCollapse ambiguity when there are no snapshots Never
oVirt gerrit 44658 ovirt-engine-3.6 MERGED core: Fix copyCollapse ambiguity when there are no snapshots Never
oVirt gerrit 48728 master MERGED engine: Import clone VM without copy-collapse 2016-01-10 09:06:40 UTC
oVirt gerrit 51580 ovirt-engine-3.6 MERGED engine: Import clone VM without copy-collapse 2016-01-10 14:14:51 UTC
oVirt gerrit 51597 ovirt-engine-3.6.2 MERGED engine: Import clone VM without copy-collapse 2016-01-10 14:35:56 UTC

Description Sven Kieske 2014-09-26 14:49:37 UTC
Description of problem:
  POST
https://REDACTED/api/storagedomains/e89fdbcb-cb51-42b7-b42c-7f4f0ec1f580/vms/fc0f82f3-fb34-429b-aa52-e8276cdc49c0/import
{

"storageDomain":{"id":"15679d40-0f20-4a0e-9880-eb5795cb8d1e","name":"LOCAL_DATA_DOMAIN_NAME"},
  "cluster":{"id":"e65dc5f5-61e6-4d17-a5bf-33c677d129c7"},
  "vm":{"name":"VM_NAME_1"},
    "clone":true
}



ANSWER:
{
"storageDomain":{
"name":"LOCAL_DATA_DOMAIN_NAME",
"id":"15679d40-0f20-4a0e-9880-eb5795cb8d1e"
},
"cluster":{
"id":"e65dc5f5-61e6-4d17-a5bf-33c677d129c7"
},
"vm":{
"name":"VM_NAME_2"
},
"clone":true,
"status":{
"state":"failed"
},
"fault":{
"reason":"Operation Failed",
"detail":"[action type failed import clone not collapsed]"
}
}

Version-Release number of selected component (if applicable):
this bug is present from at least ovirt 3.3.3
until latest master (tested by jhernand)

How reproducible:
always

Steps to Reproduce:
1. export vm onto storage domain
2. try to import (clone) from export domain to the same storage domain, with different vm name via REST(xml or json doesn't matter)
3. watch error message

Actual results:
action type failed import clone not collapsed

Expected results:
import works

Additional info:

workaround: add this to xml/json:

  <vm>
   <name>VM_NAME_1</name>
   <snapshots>
     <collapse_snapshots>true</collapse_snapshots>
   </snapshots>
 </vm>

more info:

I double checked that all vms have no snapshots attached.
Hence, this collapse option should not be necessary, thanks go to jhernand
who helped me to test this and who provided the workaround.

jhernand suspects this is a flaw in vdsm, vdsm was in his case from 3.5
and in my case:

 rpm -qa | grep vdsm
vdsm-python-4.13.3-3.el6.x86_64
vdsm-4.13.3-3.el6.x86_64
vdsm-cli-4.13.3-3.el6.noarch
vdsm-xmlrpc-4.13.3-3.el6.noarch

Comment 1 Nir Soffer 2014-09-26 21:24:23 UTC
Juan, can you explain what is the issue in vdsm that cause this issue?
Having enging and vdsm logs may also help.

Comment 2 Juan Hernández 2014-09-29 08:13:50 UTC
No, I can't explain the issue. I just suspects that the issue is in VDSM (or a lower layer) because the error message displayed to the user (action type failed import clone not collapsed) comes from VDSM, not from the engine. My guess at the moment is that we are trying by default to collapse snapshots, but in this case there aren't snapshots to collapse, however I still need to investigate it.

Comment 3 Juan Hernández 2014-09-29 11:52:18 UTC
After investigating this I found the following:

* The error message doesn't come from VDSM, but from the engine. It corresponds to the VdcBllMessages.ACTION_TYPE_FAILED_IMPORT_CLONE_NOT_COLLAPSED, which doesn't have a translation in the AppErrors.properties file, thus it is translated literally from the constant name by ErrorTranslatorImpl.

* The default value of the "collapse_snapshots" in the backend is "false".

* The ImportVm command uses the value of this parameter without checking if there are snapshots to collapse, thus rejecting otherwise valid requests. This is the root cause of this bug.

In my opinion we should check for the existence of snapshots, and ignore this parameter if there are no snapshots. We should also add the translation to the AppErrors.properties file.

Comment 4 Allon Mureinik 2014-09-29 18:29:35 UTC
(In reply to Juan Hernández from comment #3)
> In my opinion we should check for the existence of snapshots, and ignore
> this parameter if there are no snapshots. We should also add the translation
> to the AppErrors.properties file.
Agree on both statements.
Tal - please handle this?

Comment 5 Vered Volansky 2015-06-10 06:51:56 UTC
Same issue should be manifested with ACTION_TYPE_FAILED_IMPORT_UNREGISTERED_NOT_COLLAPSED, taking care of this in the same scope as well.
QE, please make sure this scenario is verified as well.

Comment 6 Vered Volansky 2015-07-29 12:33:09 UTC
The issue is manifested in a shared DC as well. Removing internal whiteboard.

Comment 7 Vered Volansky 2015-07-29 12:39:45 UTC
Maor, I'd appreciate your input my comment (#5):
Should we indeed fail on the following when there are no snapshots (Currently this fails)?

if (isImagesAlreadyOnTarget() && getParameters().getCopyCollapse()) {
   return failCanDoAction(
        EngineMessage.ACTION_TYPE_FAILED_IMPORT_UNREGISTERED_NOT_COLLAPSED);
}

This is in canDoActionBeforeCloneVm().
Thanks.

Comment 8 Maor 2015-07-29 13:53:05 UTC
It looks that the user try to import a VM from an export domain, 
in that case, the flag of isImagesAlreadyOnTarget should be false, since the disks does not exists on the target Storage Domain.

Comment 9 Vered Volansky 2015-07-30 07:38:49 UTC
Discussed off line with Maor - comment #5 is a non issue, please ignore.

Comment 10 Raz Tamir 2015-08-23 15:21:42 UTC
POST api/storagedomains/<sd_id>/vms/<vm_id>/import

<action>
  <cluster id="fa15ee1c-aef4-4871-a51e-0d76471d126c"/>
  <storage_domain id="16b928e0-169f-4ce2-a9ca-4c9240f9ce7f"/>
  <clone>True</clone>
  <vm>
    <name>IMPORTED_VM</name>
  </vm>
</action>

response:
status 400 Bad Request

<action>
    <storage_domain id="16b928e0-169f-4ce2-a9ca-4c9240f9ce7f"/>
    <cluster id="fa15ee1c-aef4-4871-a51e-0d76471d126c"/>
    <vm>
        <name>IMPORTED_VM</name>
    </vm>
    <clone>true</clone>
    <status>
        <state>failed</state>
    </status>
    <fault>
        <reason>Operation Failed</reason>
        <detail>[action type failed import clone not collapsed]</detail>
    </fault>
</action>


rhevm-3.6.0-0.12.master.el6.noarch
rhevm-backend-3.6.0-0.12.master.el6.noarch

Comment 11 Vered Volansky 2015-08-25 10:12:40 UTC
3.6.0-10 does not include this patch (though 3.6 stable does).
Why this bz was moved to ON-QA is a mystery, moving back to modified.

Comment 12 Eyal Edri 2015-08-28 00:46:07 UTC
please notice that 3.6.0-10 (build id) =! 3.6.0-12 which is the ovirt-engine package version. both shouldn't match as each has other meaning.

can you provide info on how did you look for the patch?
since i do see the code inside the build:
https://code.engineering.redhat.com/gerrit/gitweb?p=ovirt-engine.git;a=shortlog;h=refs/tags/rhev-3.6.0-10

if you're relaying on the cutoff point on release notes, that was a bug and should be ignored, according to the link above from the build id tag, the code is in.

if you wish to verify it, you can check if the code has changed here:
http://download.devel.redhat.com/brewroot/packages/org.ovirt.engine-root/3.6.0/12/src/rhevm-3.6.0-0.12.master.el6.src.rpm

Comment 13 Raz Tamir 2015-11-16 12:41:05 UTC
POST api/storagedomains/<sd_id>/vms/<vm_id>/import

<action>
  <cluster id="fa15ee1c-aef4-4871-a51e-0d76471d126c"/>
  <storage_domain id="16b928e0-169f-4ce2-a9ca-4c9240f9ce7f"/>
  <clone>True</clone>
  <vm>
    <name>IMPORTED_VM</name>
  </vm>
</action>

response:
status 202 Accepted

<action href="/api/storagedomains/4b29e51b-f407-4de1-b1ca-84ea498b3a58/vms/53fde477-c1d0-4bf2-afbd-b91f727df803/import/4bdfa0eb-add7-4645-bedb-b8bde70c4e54" id="4bdfa0eb-add7-4645-bedb-b8bde70c4e54">
    <link href="/api/storagedomains/4b29e51b-f407-4de1-b1ca-84ea498b3a58/vms/53fde477-c1d0-4bf2-afbd-b91f727df803" rel="parent"/>
    <link href="/api/storagedomains/4b29e51b-f407-4de1-b1ca-84ea498b3a58/vms/53fde477-c1d0-4bf2-afbd-b91f727df803/import" rel="replay"/>
    <async>true</async>
    <storage_domain id="324ebdd6-9149-4b04-9a54-72e3f21cd8f6"/>
    <cluster id="f5142639-7ba2-44ae-a707-ffd2e4c39094"/>
    <vm>
        <name>NEW_VM</name>
    </vm>
    <clone>true</clone>
    <job href="/api/jobs/56f2ff07-0a49-4162-b6c8-be52753edba9" id="56f2ff07-0a49-4162-b6c8-be52753edba9"/>
    <status>
        <state>pending</state>
    </status>
</action>

rhevm-backend-3.6.0.3-0.1.el6.noarch
rhevm-3.6.0.3-0.1.el6.noarch

The operation failed!

From the engine:
2015-11-16 14:34:53,577 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-62) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: VDSM host_mixed_2 command failed: Volume already exists
2015-11-16 14:34:53,577 INFO  [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (DefaultQuartzScheduler_Worker-62) [] SPMAsyncTask::PollTask: Polling task '4bdfa0eb-add7-4645-bedb-b8bde70c4e54' (Parent Command 'ImportVm', Parameters Type 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters') returned status 'finished', result 'cleanSuccess'.
2015-11-16 14:34:53,581 ERROR [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (DefaultQuartzScheduler_Worker-62) [] BaseAsyncTask::logEndTaskFailure: Task '4bdfa0eb-add7-4645-bedb-b8bde70c4e54' (Parent Command 'ImportVm', Parameters Type 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters') ended with failure:
-- Result: 'cleanSuccess'
-- Message: 'VDSGenericException: VDSErrorException: Failed in vdscommand to HSMGetAllTasksStatusesVDS, error = Volume already exists',
-- Exception: 'VDSGenericException: VDSErrorException: Failed in vdscommand to HSMGetAllTasksStatusesVDS, error = Volume already exists'


From vdsm:
Thread-24906::ERROR::2015-11-16 14:34:53,672::task::866::Storage.TaskManager.Task::(_setError) Task=`e923f5c9-12e7-47be-95f0-f1d965a24bcf`::Unexpected error
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/task.py", line 873, in _run
    return fn(*args, **kargs)
  File "/usr/share/vdsm/logUtils.py", line 49, in wrapper
    res = f(*args, **kwargs)
  File "/usr/share/vdsm/storage/hsm.py", line 1511, in deleteImage
    raise se.ImageDoesNotExistInSD(imgUUID, sdUUID)
ImageDoesNotExistInSD: Image does not exist in domain: u'image=fa9f023e-47c3-4462-8cf9-c16b988e4ac4, domain=324ebdd6-9149-4b04-9a54-72e3f21cd8f6'

Attaching relevant logs and moving back to assigned

Comment 14 Red Hat Bugzilla Rules Engine 2015-11-16 12:41:09 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 15 Raz Tamir 2015-11-16 12:41:36 UTC
Created attachment 1094865 [details]
engine and vdsm logs

Comment 16 Allon Mureinik 2015-11-16 13:32:29 UTC
This looks like an issue that's irrelevant for this bug:

-- Result: 'cleanSuccess'
-- Message: 'VDSGenericException: VDSErrorException: Failed in vdscommand to HSMGetAllTasksStatusesVDS, error = Volume already exists',
-- Exception: 'VDSGenericException: VDSErrorException: Failed in vdscommand to HSMGetAllTasksStatusesVDS, error = Volume already exists'

Tal - let's look into this, though, please?

Comment 17 Red Hat Bugzilla Rules Engine 2015-11-16 13:33:22 UTC
This bug is not marked for z-stream, yet the milestone is for a z-stream version, therefore the milestone has been reset.
Please set the correct milestone or add the z-stream flag.

Comment 18 Tal Nisan 2015-11-16 16:57:18 UTC
Freddy is having a look

Comment 19 Raz Tamir 2016-01-20 11:19:39 UTC
Verified - rhevm-3.6.2.5-0.1.el6.noarch

POST api/storagedomains/<sd_id>/vms/<vm_id>/import

<action>
  <cluster id="861efbfe-3cef-47fc-9605-b1a926249b85"/>
  <storage_domain id="ede2b230-cd92-4427-b3c8-6c859f2b73ee"/>
  <clone>True</clone>
  <vm>
    <name>IMPORTED_VM</name>
  </vm>
</action>

response:
status 202 Accepted

<action href="/ovirt-engine/api/storagedomains/4a860109-33d3-4db6-98ca-405de70e29f5/vms/85258df7-192c-40c6-a005-c124559e274f/import/eba8a0b2-7aa7-4baf-a16c-3e6dbb58afcc" id="eba8a0b2-7aa7-4baf-a16c-3e6dbb58afcc">
    <link href="/ovirt-engine/api/storagedomains/4a860109-33d3-4db6-98ca-405de70e29f5/vms/85258df7-192c-40c6-a005-c124559e274f" rel="parent"/>
    <link href="/ovirt-engine/api/storagedomains/4a860109-33d3-4db6-98ca-405de70e29f5/vms/85258df7-192c-40c6-a005-c124559e274f/import" rel="replay"/>
    <async>true</async>
    <storage_domain id="ede2b230-cd92-4427-b3c8-6c859f2b73ee"/>
    <cluster id="861efbfe-3cef-47fc-9605-b1a926249b85"/>
    <vm>
        <name>IMPORTED_VM</name>
    </vm>
    <clone>true</clone>
    <job href="/ovirt-engine/api/jobs/3961c337-490f-4fdb-b21e-7b3efd76f07c" id="3961c337-490f-4fdb-b21e-7b3efd76f07c"/>
    <status>
        <state>pending</state>
    </status>
</action>


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