Juan, can you explain what is the issue in vdsm that cause this issue?
Having enging and vdsm logs may also help.

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.

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.

(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?

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.

The issue is manifested in a shared DC as well. Removing internal whiteboard.

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.

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.

Discussed off line with Maor - comment #5 is a non issue, please ignore.

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

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.

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

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

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 1094865 [details]
engine and vdsm logs

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?

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.

Freddy is having a look

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>