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

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.