| Summary: | get_storage_volume_by_path() returns an error for valid volumes which aren't in a storage pool | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Huang Wenlong <whuang> |
| Component: | libvirt | Assignee: | Osier Yang <jyang> |
| Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.1 | CC: | berrange, cwei, dallan, eblake, mshao, rwu, xen-maint, yoyzhang, yupzhang |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-11-23 03:27:17 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Huang Wenlong
2011-01-18 07:03:30 UTC
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. |