[libvirt] [PATCH] storage: implement rudimentary glusterfs pool refresh

[Eric Blake]

On 10/31/2013 11:49 AM, Daniel P. Berrange wrote:

> The QEMU driver should be near 100% functional without needing the
> storage driver at all. The only dep should be if you use <disk type=vol>.
> A <disk type=network> should have no dependancy on the storage driver,
> so we'd need rbd there even if the storage driver was not there.

<disk type='network'><driver type='raw'/></disk> should be just fine
without rbd driver pulled in by libvirt.  But you are right that qemu
will have pulled it in to be able to use the image.  So as long as qemu
is monolithic, even a raw-only use of a backing file doesn't free your
system from needing the libraries.

<disk type='network'><driver type=qcow2'/></disk> currently boots, but
that is a mistake under sVirt because we can't chase the backing chain
to guarantee that any backing files are present with correct permissions
unless we have the rbd/gluster/... storage backend present.  I'm arguing
that <disk type='network'><driver type='qcow2'/> should be made an error
unless the storage backend also provides the tools for chasing that
backing chain, and that the storage backend be modular so that you only
require the libraries for the particular network storage that you plan
on using; while you're arguing one step further that <disk
type='network'> is itself useless if qemu doesn't also support that
network protocol.

Where it gets interesting is that qemu itself is trying to go modular,
so that you can decide via .so files whether rbd and gluster libraries
are required for running qemu - once qemu is modular, then you can have
a case where the same qemu binary either supports or fails to support
rbd based on whether the rbd .so was installed; if that's the case, then
libvirt should also have the ability to support or fail to support rbd
based on whether the storage rbd is installed.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20131031/8a04eef3/attachment-0001.sig>