Hide Forgot
Description of problem: virt-v2v can't convert xen hypervisor's guest to libvirt-pool or rhev-m but can convert kvm and esx hypervisors' Version-Release number of selected component (if applicable): virt-v2v-0.7.0-1.el6.x86_64 libvirt-0.8.7-2.el6.x86_64 libguestfs-1.7.11-11.el6.x86_64 How reproducible: Steps to Reproduce: 1.virt-v2v -ic xen+ssh://10.66.72.123 -o rhev -osd 10.66.90.115:/vol/v2vrwu2/esx_export rhel6-64b-pv-withX or virt-v2v -ic xen+ssh://10.66.72.123 -op sda5 rhel6-64b-pv-withX Actual results: virt-v2v: Failed to retrieve storage volume /var/lib/xen/images/rhel6-pv-64b-withX.img:libvirt error code: 50, message: Storage volume not found: no storage vol with matching path Expected results: conversion is successful Additional info: no log from LIBGUESTFS_TRACE=1 LIBGUEST_DEBUG=1
Wenlong, Could you please SSH into 10.66.72.123 and check that /var/lib/xen/images/rhel6-pv-64b-withX.img exists? This looks like there's a problem with the original guest, rather than a conversion problem. I suspect it references a volume which has been removed. Thanks, Matt
> Wenlong, > > Could you please SSH into 10.66.72.123 and check that > /var/lib/xen/images/rhel6-pv-64b-withX.img exists? This looks like there's a > problem with the original guest, rather than a conversion problem. I suspect it > references a volume which has been removed. > > Thanks, > > Matt Hi,Matt I SSH 10.66.72.123 ,then # ll /var/lib/xen/images/rhel6-pv-64b-withX.img -rwxr-xr-x 1 root root 6291456000 Jan 18 13:23 /var/lib/xen/images/rhel6-pv-64b-withX.img the image is there ,not only this guest will fail ,all the other guest fail too
Hi ,Matt We found some info about this bug , it is not relate with hypervisor , the reason of this bug is the guest converted does not belong to any host local pool , but the old version virt-v2v can convert well with the same guest-host and the same guest
Reassigning this to libvirt. virt-v2v does: $vol = $self->{vmm}->get_storage_volume_by_path($path); where $path is taken from the guest's domain XML. This should always return volume information.
A virConnectPtr is associated with n * virStoragePoolPtr. A virStoragePoolPtr is associated with n * virStorageVolPtr objects. A virStorageVolPtr object can't exist without a corresponding virStoragePoolPtr object to contain it. Thus it is expected that virStorageVolLookupByPath will return NULL if the path exists on disk, but is not a location that is managed by a storage pool. For applications like virt-v2v which aren't the ones actually provisioning the VMs & their storage this can be a inconvenience because they're not in a position to decide what storage pools exist. We don't want to automatically create new storage pools when looking up a volume. There is also not an easy way for an app to decide what sort of storage pool needs creating at a given point. We do have a virConnectFindStoragePoolSources method which can be used to generate source XML that can be used to then create storage pools. This is not quite usable in this scenario though because you need to know the type of pool you want to search for. Perhaps we could add virConnectFindStoragePoolForPath method. virt-v2v could use this to get XML which could be used to create a transient storage pool for its work, which can be discarded once complete. In any case, the problem as initially reported here is not a bug. This is really usage misunderstanding, and an likely RFE.