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

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).