On Thu, Oct 31, 2013 at 12:17:54PM -0600, Eric Blake wrote:
> 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).
IIUC, this is still going to be introducing a direct code path dependancy
between the QEMU and storage driver code though.
Currently src/qemu depends only on code in src/util & src/conf[1]. For
the storage pool bits, it can call indirectly via src/libvirt.c APIs, but
it does not call anything in src/storage/ directly. I really want this
to remain that way, because avoiding direct calls is key to enabling
us to split libvirtd up into separate daemons per driver in the future.
Daniel
[1] Yes, there's a dep on src/network too, which i was never at all happy
about, and which needs to be refactored / removed in some manner in
the future
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list