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

[Eric Blake]

On 10/31/2013 12:09 PM, Daniel P. Berrange wrote:

> 
> If  <disk type='network'/> were made to require a storage pool in order
> to use it, that would be a regression in functionality IMHO. This setup
> should be completely independant of the storage driver code. It needs to
> be able to resolve the backing file chain directly, without calling into
> the storage driver.

I'm not requiring that a storage pool be present, only that the storage
backend be present, by limiting the compilation against the network
libraries to just the storage backends.  Booting something that doesn't
belong to a pool has always been supported (ideally, what we SHOULD do
is make anything that a <domain> refers to but which does not map to an
existing pool would then create a transient pool for the lifetime of the
domain, so that all domain <disk> sources are backed by a pool - but
that's a bigger project).  And I don't see a regression - allowing
network/raw without a storage backend will still work; where we need to
change is that we currently allow network/qcow2 to boot, but this is
cheating, and breaks if sVirt doesn't label the backing file.  That is,
we are treating network/qcow2 as if it were network/raw always; and if
the storage backend is not present, we'd _still_ have to treat it as
network/raw (rather than refuse to boot, as that would be a regression;
but if there is any backing chain, boot may still fail anyways because
of sVirt).  But where we DO have a storage backend, then pool or no
pool, we are able to chase the backing chain correctly, at the expense
of dragging in the additional libraries.  And since qemu is trying to go
modular to avoid libraries, we should also make our storage backends
modular to avoid libraries (where we then are forced to fall back to
network/raw as the only sane handling of network sources).

-- 
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/bc05e0f3/attachment-0001.sig>