Bug 1365411 - [RFE] virt-v2v from RHEL Xen: Listing VMs failed if there are Xen VMs with block device.
Summary: [RFE] virt-v2v from RHEL Xen: Listing VMs failed if there are Xen VMs with bl...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt
Version: 4.0.2.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-4.0.4
: 4.0.4
Assignee: Shahar Havivi
QA Contact: Nisim Simsolo
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-09 08:19 UTC by Nisim Simsolo
Modified: 2016-09-26 12:37 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-09-26 12:37:33 UTC
oVirt Team: Virt
Embargoed:
rule-engine: ovirt-4.0.z+
mgoldboi: planning_ack+
michal.skrivanek: devel_ack+
mavital: testing_ack+


Attachments (Terms of Use)
vdsm.log (675.90 KB, application/x-xz)
2016-08-09 08:32 UTC, Nisim Simsolo
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1303548 0 unspecified CLOSED [RFE] Add ability to import RHEL Xen guest images directly into oVirt 2021-02-22 00:41:40 UTC
oVirt gerrit 62368 0 master MERGED v2v: filter out Xen VMs with block storage 2016-09-01 09:16:24 UTC
oVirt gerrit 63133 0 ovirt-4.0 MERGED v2v: filter out Xen VMs with block storage 2016-09-05 13:42:05 UTC

Internal Links: 1303548

Description Nisim Simsolo 2016-08-09 08:19:16 UTC
Description of problem:
- Currently, when trying to list available VMs to import from Xen using RHEV webadmin, if there is a block device disk configured on Xen, the list failed to load with the next vdsm.log error:
jsonrpc.Executor/5::ERROR::2016-08-08 15:59:30,265::v2v::918::root::(_add_disk_info) Error getting disk size
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 915, in _add_disk_info
    vol = conn.storageVolLookupByPath(disk['alias'])
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4596, in storageVolLookupByPath
    if ret is None:raise libvirtError('virStorageVolLookupByPath() failed', conn=self)
libvirtError: cannot read dir '/dev/sdb': Not a directory

- According to virt-v2v wiki, If the guest disks are located on a host block device, then the conversion will fail. 
see http://libguestfs.org/virt-v2v.1.html#xen-or-ssh-conversions-from-block-devices for a workaround.

- It would be nice to have an ability to import VM with block device from Xen using virt-v2v workaround.

Version-Release number of selected component (if applicable):
rhevm-4.0.2.4-0.1.el7ev

How reproducible:
100%

Steps to Reproduce:
1. Add Block device to Xen
2. Using webadmin import dialog, enter Xen details and click "load" button.
3.

Actual results:
list failed to load.

Expected results:
using virt-v2v workaround, it should be possible to list source VMs and import them.

Additional info:
vdsm.log attached (issue occured at: 2016-08-08 15:59:30,265)

Comment 1 Nisim Simsolo 2016-08-09 08:32:18 UTC
Created attachment 1189132 [details]
vdsm.log

Comment 2 Michal Skrivanek 2016-08-10 04:39:33 UTC
For a start, we need to make suren the list is returned correctly without the problematic VM, or flagged accordingly

Comment 3 Michal Skrivanek 2016-08-10 07:30:42 UTC
Workaround is to use virt-v2v-copy-to-local from libguestfs 1.32 and virt-v2v on a command line

Comment 4 Michal Skrivanek 2016-08-12 09:44:15 UTC
note - the ack for 4.0.4 is for fixing the VM listing, not the actual workaround. That one is no feasible and we will look at that later eventually

Comment 5 Nisim Simsolo 2016-09-13 12:07:52 UTC
Verified: 
ovirt-engine-4.0.4.2-0.1.el7ev
vdsm-4.18.13-1.el7ev.x86_64
qemu-kvm-rhev-2.6.0-23.el7.x86_64
libvirt-client-2.0.0-8.el7.x86_64
sanlock-3.4.0-1.el7.x86_64

Listing VMs issue fixed, in case there are VMs in Xen with block device.

Comment 6 Nisim Simsolo 2016-09-13 12:17:27 UTC
See RFE https://bugzilla.redhat.com/show_bug.cgi?id=1375563 - [RFE] virt-v2v from RHEL Xen: Implement virt-v2v workaround for converting VM with block device.


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