Bug 1468535 - Device.map can't be updated to vda if import rhel7.4 guest from kvm source at rhv4.1
Device.map can't be updated to vda if import rhel7.4 guest from kvm source at...
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libguestfs (Show other bugs)
7.4
x86_64 Unspecified
medium Severity medium
: rc
: ---
Assigned To: Richard W.M. Jones
Virtualization Bugs
: Reopened, TestOnly
Depends On: 1484199
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-07 07:04 EDT by mxie@redhat.com
Modified: 2017-08-28 04:47 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-22 22:27:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
rhel7.4-import-kvm (300.01 KB, image/png)
2017-07-07 07:04 EDT, mxie@redhat.com
no flags Details
vdsm.log (413.13 KB, text/plain)
2017-07-07 07:04 EDT, mxie@redhat.com
no flags Details
import.log (13.15 KB, text/plain)
2017-07-07 21:33 EDT, mxie@redhat.com
no flags Details

  None (edit)
Description mxie@redhat.com 2017-07-07 07:04:08 EDT
Created attachment 1295256 [details]
rhel7.4-import-kvm

Description of problem:
Device.map can't be updated to vda if import rhel7.4 guest from kvm source at rhv4.1

Version-Release number of selected component (if applicable):
rhv:4.1.3-0.1.el7
vdsm-4.19.20-1.el7ev.x86_64
virt-v2v-1.36.3-6.el7.x86_64
libguestfs-1.36.3-6.el7.x86_64
libvirt-client-3.2.0-14.el7.x86_64
qemu-kvm-rhev-2.9.0-14.el7.x86_64
libguestfs-winsupport-7.2-2.el7.x86_64
virtio-win-1.9.1-0.el7.noarch.rpm

How reproducible:
100%

Steps to Reproduce:
1.Log in rhv and import guest from kvm
Open virtual machine option at rhv4.1 -> click import button -> choose source as vmware->input URL:qemu+tcp://ip/system, username/password->Load guests successfully-> select guest "rhel7.4" to import


2.After finishing import, power on the guest but find device.map is not updated to vda, pls refer to screenshot"rhel7.4-import-kvm"

Actula results:
As above description

Expected results:
Device.map can be updated to vda if import rhel7.4 guest from kvm source at rhv4.1


Additional info:
1.Device.map can be updated to vda if import rhel7.4 guest from vmware source at rhv4.1
2.Device.map can be updated to vda if import rhel7.3 guest from kvm source at rhv4.1
3.Device.map can be updated to vda if convert rhel7.4 guest to rhv by virt-v2v on v2v conversion server
Comment 2 mxie@redhat.com 2017-07-07 07:04 EDT
Created attachment 1295257 [details]
vdsm.log
Comment 3 Richard W.M. Jones 2017-07-07 07:51:53 EDT
This can't be debugged without the virt-v2v log, which VDSM
doesn't preserve.
Comment 4 Richard W.M. Jones 2017-07-07 07:53:12 EDT
According to the resolution for
https://bugzilla.redhat.com/show_bug.cgi?id=1350465

"Previously, when importing a Virtual Machine, if the import failed, the output of the virt-v2v tool was not available for investigating the reason for the failure, and the import had to be reproduced manually. In this release, the output of virt-v2v is now stored in the /var/log/vdsm/import directory. All logs older than 30 days are automatically removed."

Can you see if the virt-v2v log file is present there?
Comment 5 mxie@redhat.com 2017-07-07 21:33 EDT
Created attachment 1295423 [details]
import.log
Comment 6 Richard W.M. Jones 2017-07-08 02:44:36 EDT
Same comment as:
https://bugzilla.redhat.com/show_bug.cgi?id=1468540#c6
Comment 7 Pino Toscano 2017-08-14 11:22:38 EDT
Hi Ming Xie,

were you able to get verbose logs for this conversion?
Comment 8 mxie@redhat.com 2017-08-21 09:52:35 EDT
Hi Pino,

   As https://bugzilla.redhat.com/show_bug.cgi?id=1468540#c6 said, vdsm can't collect virt-v2v logs properly at /var/log/vdsm/import/* sometimes, so I can't provide verbose log of this bug for you, but I still could reproduce this bug with below latest builds, do you think bug 1350465 should be reopened?

Packages:
virt-v2v-1.36.3-6.el7_4.3.x86_64
libguestfs-1.36.3-6.el7_4.3.x86_64
vdsm-4.19.28-1.el7ev.x86_64
libvirt-client-3.2.0-14.el7_4.2.x86_64
qemu-kvm-rhev-2.9.0-16.el7_4.4.x86_64
rhv:4.1.3-0.1.el7
Comment 9 Pino Toscano 2017-08-22 02:45:15 EDT
(In reply to mxie@redhat.com from comment #8)
>    As https://bugzilla.redhat.com/show_bug.cgi?id=1468540#c6 said, vdsm
> can't collect virt-v2v logs properly at /var/log/vdsm/import/* sometimes, so
> I can't provide verbose log of this bug for you, but I still could reproduce
> this bug with below latest builds, do you think bug 1350465 should be
> reopened?

Tomáš, do you have further ideas about this?
Comment 10 Tomáš Golembiovský 2017-08-22 04:39:59 EDT
This is not a virt-v2v issue. For importing from KVM sources we have our own tool called kvm2ovirt. It is rather crude tool that basically only copies the disks. It does not alter the guest in anyway.
Comment 11 Pino Toscano 2017-08-22 06:30:40 EDT
Ah I see, thanks for the information (I didn't know about that, I assumed v2v was used also in that case).

In that case, and considering that reassigning bugs to oVirt does not work: Ming Xie, please report the issue for oVirt, so they can track, and hopefully fix this issue (either by doing simple manipulations on the guest, or using v2v).
Comment 12 mxie@redhat.com 2017-08-22 22:27:18 EDT

*** This bug has been marked as a duplicate of bug 1484199 ***

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