Nova instances disks aren't displayed by libvirt / virsh as volumes

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Nova instances disks aren't displayed by libvirt / virsh as volumes

Emanuele Verga
Hi,

we have an Openstack test installation, and recently decide to install on
one of the compute nodes a monitoring solution using ganglia 3.2 and
hsflowd.

After some strange error in hsflowd debug output

(Several lines like those:
libvir: Storage error : Storage volume not found: no storage vol with
matching path
virStorageLookupByPath(/var/lib/nova/instances/instance-00000050/disk)
failed
It would be a reasonable error, if it weren't that the path is absolutely
correct.)

we noticed that nova instances disk files (
es. /var/lib/nova/instances/INSTANCENAME/disk) aren't registered in libvirt
as volumes.
( *virsh* *pool-list* only shows the *default *pool, and *virsh vol-list
default* shows the pool as empty), and this causes hsflowd lookups to fail.
The Virtual Machines themselves are working perfectly, *virsh list *shows
the list of running instances, and their xmldump contains the appropriate
disk section

Example:
<devices>
    <emulator>/usr/bin/kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/nova/instances/instance-0000002d/disk'/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04'
function='0x0'/>
    </disk>

My question is: is this (instance disks not being registered as libvirt
volumes) expected behavior, or do we have a problem in our configuration?
Is there any fix / workaround that makes it so that libvirt recognizes them,
possibly dinamically, when Openstack creates a new instance?

Please let me know if you need any further detail.
Thanks in advance for the help!

Emanuele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20110817/606394d0/attachment.html>