Bug 1562093

Created attachment 1414781 [details]
engine.log look at 2018-03-29 16:59:18,491+03 ERROR

Created attachment 1414783 [details]
vdsm.log

Additional info:
The import process of the OVA again causing to the first VM disk to change status from OK to Illegal. 
Raising the severity of this bug.

Supporting import of the same OVA more than once (i.e., as a clone) is a low priority.
However, We should avoid the exception and the transition of the disks to an illegal state. This can be achieved by adding a proper validation.

We saw it also on V2V import from vmware, after problem with storage 
we get the duplicate exception.
from engine log:
2018-07-16 16:14:19,455+03 INFO  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-13) [503be901] EVENT_ID: ADD_DISK_INTERNAL_FAILURE(2,037), Add-Disk operation of 'test_v2v_windows_2012_automation_vmware' failed to complete.
2018-07-16 16:14:19,563+03 ERROR [org.ovirt.engine.core.bll.exportimport.ImportVmFromExternalProviderCommand] (default task-13) [503be901] Command 'org.ovirt.engine.core.bll.exportimport.ImportVmFromExternalProviderCommand' failed: org.springframework.dao.DuplicateKeyException: CallableStatementCallback; SQL [{call insertdiskvmelement(?, ?, ?, ?, ?, ?)}]; ERROR: duplicate key value violates unique constraint "pk_disk_vm_element"
  Detail: Key (vm_id, disk_id)=(003eaa6f-590c-4d0d-9a4b-457701691c6d, a03eb673-da26-4ba3-a218-149df795271e) already exists.
  Where: SQL statement "INSERT INTO disk_vm_element (
        disk_id,
        vm_id,
        is_boot,
        pass_discard,
        disk_interface,
        is_using_scsi_reservation)
    VALUES (
        v_disk_id,
        v_vm_id,
        v_is_boot,
        v_pass_discard,
        v_disk_interface,
        v_is_using_scsi_reservation)"
PL/pgSQL function insertdiskvmelement(uuid,uuid,boolean,boolean,character varying,boolean) line 3 at SQL statement; nested exception is org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "pk_disk_vm_element"
  Detail: Key (vm_id, disk_id)=(003eaa6f-590c-4d0d-9a4b-457701691c6d, a03eb673-da26-4ba3-a218-149df795271e) already exists.
  Where: SQL statement "INSERT INTO disk_vm_element (
        disk_id,
        vm_id,
        is_boot,
        pass_discard,
        disk_interface,
        is_using_scsi_reservation)
    VALUES (
        v_disk_id,
        v_vm_id,
        v_is_boot,
        v_pass_discard,
        v_disk_interface,
        v_is_using_scsi_reservation)"
PL/pgSQL function insertdiskvmelement(uuid,uuid,boolean,boolean,character varying,boolean) line 3 at SQL statement
2018-07-16 16:14:19,563+03 ERROR [org.ovirt.engine.core.bll.exportimport.ImportVmFromExternalProviderCommand] (default task-13) [503be901] Exception: javax.ejb.EJBException: org.springframework.dao.DuplicateKeyException: CallableStatementCallback; SQL [{call insertdiskvmelement(?, ?, ?, ?, ?, ?)}]; ERROR: duplicate key value violates unique constraint "pk_disk_vm_element"
  Detail: Key (vm_id, disk_id)=(003eaa6f-590c-4d0d-9a4b-457701691c6d, a03eb673-da26-4ba3-a218-149df795271e) already exists.
  Where: SQL statement "INSERT INTO disk_vm_element (
        disk_id,
        vm_id,
        is_boot,
        pass_discard,
        disk_interface,
        is_using_scsi_reservation)
    VALUES (
        v_disk_id,
        v_vm_id,
        v_is_boot,
        v_pass_discard,
        v_disk_interface,
        v_is_using_scsi_reservation)"
PL/pgSQL function insertdiskvmelement(uuid,uuid,boolean,boolean,character varying,boolean) line 3 at SQL statement; nested exception is org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "pk_disk_vm_element"
  Detail: Key (vm_id, disk_id)=(003eaa6f-590c-4d0d-9a4b-457701691c6d, a03eb673-da26-4ba3-a218-149df795271e) already exists.
  Where: SQL statement "INSERT INTO disk_vm_element (
        disk_id,
        vm_id,
        is_boot,
        pass_discard,
        disk_interface,
        is_using_scsi_reservation)
    VALUES (
        v_disk_id,
        v_vm_id,
        v_is_boot,
        v_pass_discard,
        v_disk_interface,
        v_is_using_scsi_reservation)"
PL/pgSQL function insertdiskvmelement(uuid,uuid,boolean,boolean,character varying,boolean) line 3 at SQL statement

Adding engine log.

Created attachment 1459404 [details]
engine_log_import_vmware

(In reply to Israel Pinto from comment #6)
I think that deserves a separate bug - if the cleanup on failure is incomplete and thus leads to DuplicateKeyException on the following attempt, it is a different issue than supporting import-as-clone.

(In reply to Arik from comment #4)
> Supporting import of the same OVA more than once (i.e., as a clone) is a low
> priority.
> However, We should avoid the exception and the transition of the disks to an
> illegal state. This can be achieved by adding a proper validation.

Most of the work needed to support import-as-clone was done as part of bz 1526033. Adjusting import-vm-from-ova to that should not be too difficult.

(In reply to Arik from comment #9)
> (In reply to Israel Pinto from comment #6)
> I think that deserves a separate bug - if the cleanup on failure is
> incomplete and thus leads to DuplicateKeyException on the following attempt,
> it is a different issue than supporting import-as-clone.

Reproduced. Please see https://bugzilla.redhat.com/show_bug.cgi?id=1651137

Ryan, this bug looks like similar to the one Steven is working on now, but triggered from a bit different scenario.
Could you please mark that somehow not as a duplicate but as a bug that should be verified once the fix for the bug Steven works on is resolved?

The fix for "https://bugzilla.redhat.com/show_bug.cgi?id=1656092" does resolve this issue as per development testing.

Verified:
ovirt-engine-4.3.0-0.8.master.20190122121624.git9a8a519.el7
vdsm-4.30.8-9.gitf28e377.el7.x86_64
qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64
libvirt-client-4.5.0-10.el7_6.4.x86_64
virt-v2v-1.38.2-12.el7_6.1.x86_64

This bugzilla is included in oVirt 4.3.0 release, published on February 4th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.0 release, it has been closed with a resolution of CURRENT RELEASE.

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