Bug 1477375 - v2v: In audit log IMPORTEXPORT_STARTING_IMPORT_VM is accompanied by ID of the source VM instead of the destination one
Summary: v2v: In audit log IMPORTEXPORT_STARTING_IMPORT_VM is accompanied by ID of the...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Backend.Core
Version: 4.1.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-4.1.5
: 4.1.5.2
Assignee: Shmuel Melamud
QA Contact: Nisim Simsolo
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-01 22:45 UTC by Shmuel Melamud
Modified: 2017-08-23 08:02 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-23 08:02:29 UTC
oVirt Team: Virt
Embargoed:
rule-engine: ovirt-4.1+
rule-engine: exception+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 80079 0 master MERGED core: Set vmId to the target VM ID in ImportVmCommandBase 2017-08-02 06:35:38 UTC
oVirt gerrit 80120 0 ovirt-engine-4.1 MERGED core: Set vmId to the target VM ID in ImportVmCommandBase 2017-08-02 16:00:01 UTC

Description Shmuel Melamud 2017-08-01 22:45:07 UTC
Description of problem:

When v2v process starts, IMPORTEXPORT_STARTING_IMPORT_VM event is written into the audit log accompanied by all details, including VM ID. But this ID represents the source VM instead of the destination one. This creates a problem for ManageIQ that uses this information for fetching the newly created VM into ManageIQ inventory.

The information in IMPORTEXPORT_IMPORT_VM event is correct.

How reproducible:
100%

Steps to Reproduce:
1. Import a VM from external provider to oVirt several times under different names.
2. Run the following SQL query on the engine database:

select log_time,vms.vm_name from audit_log
inner join vms on audit_log.vm_id=vms.vm_guid
where log_type_name='IMPORTEXPORT_STARTING_IMPORT_VM'
order by log_time desc
limit 10;

Actual results:
The query shows the same vm_name in all rows.

Expected results:
The query shows different vm_name in all rows.

Comment 1 Michal Skrivanek 2017-08-02 06:17:46 UTC
we need this to finish CFME v2v

Comment 2 rhev-integ 2017-08-03 16:29:11 UTC
INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Tag 'ovirt-engine-4.1.5.1' doesn't contain patch 'https://gerrit.ovirt.org/80120']
gitweb: https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=shortlog;h=refs/tags/ovirt-engine-4.1.5.1

For more info please contact: infra

Comment 3 Tomas Jelinek 2017-08-07 07:27:01 UTC
yes, the patch has been merged after the 4.1.5.1 was tagged - will get into the next build.

Comment 4 Nisim Simsolo 2017-08-16 13:38:18 UTC
Verification builds:
ovirt-engine-4.1.5.2-0.1.el7
libvirt-client-3.2.0-14.el7_4.2.x86_64
vdsm-4.19.28-1.el7ev.x86_64
sanlock-3.5.0-1.el7.x86_64
qemu-kvm-rhev-2.9.0-16.el7_4.3.x86_64
virt-v2v-1.36.3-6.el7_4.2.x86_64

Verification scenario:
1. Import a VM from external provider to oVirt several times under different names.
2. Run the following SQL query on the engine database:
select log_time,vms.vm_name from audit_log
inner join vms on audit_log.vm_id=vms.vm_guid
where log_type_name='IMPORTEXPORT_STARTING_IMPORT_VM'
order by log_time desc
limit 10;
3. Verify query shows different vm_name in all rows.

Actual result:
engine=# select log_time,vms.vm_name from audit_log
inner join vms on audit_log.vm_id=vms.vm_guid
where log_type_name='IMPORTEXPORT_STARTING_IMPORT_VM'
order by log_time desc
limit 10;
          log_time          |    vm_name     
----------------------------+----------------
 2017-08-16 16:33:24.314+03 | 1c4
 2017-08-16 16:14:43.549+03 | 1c3
 2017-08-16 16:14:23.267+03 | 1c2
 2017-08-16 16:14:01.265+03 | 1c1
 2017-07-26 18:29:09.455+03 | rhel7_21_disks
 2017-07-26 17:37:39.206+03 | rhel7_qcow
 2017-07-25 15:15:50.577+03 | centos44%/\&+=?
 2017-07-20 14:43:09.781+03 | vGPU_win10
(8 rows)

engine=#


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