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

On 10/31/2013 11:49 AM, Daniel P. Berrange wrote: <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