Bug 1468944 - Failed to import guest whose disk is not listed in storage pool from kvm/xen source at rhv4.1
Failed to import guest whose disk is not listed in storage pool from kvm/xen ...
Status: ON_QA
Product: vdsm
Classification: oVirt
Component: Core (Show other bugs)
x86_64 Unspecified
medium Severity medium (vote)
: ovirt-4.2.0
: ---
Assigned To: Tomáš Golembiovský
meital avital
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2017-07-10 00:01 EDT by mxie@redhat.com
Modified: 2017-09-27 08:37 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-07-11 06:26:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.2+

Attachments (Terms of Use)
vdsm.log (15.22 KB, text/plain)
2017-07-10 00:01 EDT, mxie@redhat.com
no flags Details
screenshot (52.53 KB, image/png)
2017-07-10 00:02 EDT, mxie@redhat.com
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 79832 master POST v2v: allow import of disks not in storage pool 2017-07-26 06:52 EDT

  None (edit)
Description mxie@redhat.com 2017-07-10 00:01:24 EDT
Created attachment 1295699 [details]

Description of problem:
Failed to import guest whose disk is not listed in storage pool from kvm/xen source at rhv4.1

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Prepare a guest whose disk is not listed in storage pool
# virsh dumpxml avocado-vt-vm1
   <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/root/RHEL-7.3-x86_64-latest.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
2.Try to import this guest in rhv4.1 from KVM host
Open virtual machine option at rhv4.1 -> click import button -> choose source as KVM ->input URL:qemu+tcp://ip/system, username/password->Load guests successfully-> select guest avocado-vt-vm1" to import

4.Failed to import the guest as screenshot and get error info from vdsm.log
2017-07-10 11:37:03,391+0800 ERROR (jsonrpc/7) [root] Error getting disk size (v2v:1089)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 1078, in _get_disk_info
    vol = conn.storageVolLookupByPath(disk['alias'])
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4555, in storageVolLookupByPath
    if ret is None:raise libvirtError('virStorageVolLookupByPath() failed', conn=self)
libvirtError: Storage volume not found: no storage vol with matching path '/root/RHEL-7.3-x86_64-latest.qcow2'
2017-07-10 11:37:03,393+0800 WARN  (jsonrpc/7) [root] Cannot add VM avocado-vt-vm1 due to disk storage error (v2v:1020)

Actula results:
As above description

Expected results:
Could import guest whose disk is not listed in storage pool from kvm/xen source at rhv4.1 successfully

Additional info:
1.Try to convert this guest to rhv by virt-v2v on v2v conversion server,then could import the guest from export domain to data domain on rhv4.1 after finishing v2v conversion,so the problem is due to vdsm
# virt-v2v avocado-vt-vm1 -o rhv -os
[   0.0] Opening the source -i libvirt avocado-vt-vm1
[   0.0] Creating an overlay to protect the source from being modified
[   0.4] Initializing the target -o rhv -os
[   0.7] Opening the overlay
[   6.1] Inspecting the overlay
[  13.8] Checking for sufficient free disk space in the guest
[  13.8] Estimating space required on target for each disk
[  13.8] Converting Red Hat Enterprise Linux Server 7.3 (Maipo) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[  52.2] Mapping filesystem data to avoid copying unused and blank areas
[  52.4] Closing the overlay
[  52.7] Checking if the guest needs BIOS or UEFI to boot
[  52.7] Assigning disks to buses
[  52.7] Copying disk 1/1 to /tmp/v2v.Zzc4KD/c9cfeba7-73f8-428a-aa77-9a2a1acf0063/images/c8eb039e-3007-4e08-9580-c49da8b73d55/f76d16ea-5e66-4987-a496-8f378b127986 (qcow2)
[ 152.4] Creating output metadata
[ 152.6] Finishing off
Comment 1 mxie@redhat.com 2017-07-10 00:02 EDT
Created attachment 1295700 [details]
Comment 3 Michal Skrivanek 2017-07-11 06:26:12 EDT

*** This bug has been marked as a duplicate of bug 1469077 ***
Comment 4 Tomáš Golembiovský 2017-07-11 09:14:02 EDT
Reopening. This problem is different from bug 1469077.

We sort of rely on the fact that disk image is in some storage pool and that is
wrong. Libvirt does not mandate this and in fact using it without any storage
pools defined at all is perfectly valid use case.

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