[libvirt] [PATCH 0/5] Support embedding the QEMU driver in client apps directly

[Peter Krempa]

On Fri, May 17, 2019 at 17:49:31 +0100, Daniel Berrange wrote:
> On Fri, May 17, 2019 at 06:45:08PM +0200, Peter Krempa wrote:
> > On Fri, May 17, 2019 at 15:22:12 +0200, Peter Krempa wrote:
> > > On Fri, May 17, 2019 at 13:24:52 +0100, Daniel Berrange wrote:
> > > > This patch series proposes a new way to build a "libvirt QEMU shim"
> > > > which supports more use cases than the previous approach from last year,
> > > > as well as being vastly simpler to implement.
> > > 
> > > Few thoughts:
> > 
> > two more:
> > 
> > [...]
> > 
> > 9) Users may have different ideas regarding values in qemu.conf
> > (such as default_tls_x509_cert_dir) thus we probably need a way to
> > provide that one as well separately.
> 
> I believe my patch should already deal with that as I prefix all the
> dirs that the QEMU driver knows about.

Hmm, I'm not sure whether just prefixing every path used internally with
the passed prefix will be a good idea.

Ideally we should keep the directory contents opaque to the user so they
don't ever try to mess with the files in the directory. This
disqualifies the use of this for passing in the qemu config file.

This also reminds me that we need some locking for the directory so that
there aren't two processes openning the same prefix and messing up the
files internally. It will even not work in some cases because the
attempt to reopen the monitor sockets would possibly fail. If not we've
got even more of a problem.

Also this would mean that a prefix of '/' would be equal to the system
instance handled by libvirtd so we need also interlocking with libvirt
if we don't change the layout.

One disadvantage of this idea is that I can see users that will
actually use this to replace libvirt's RPC with something else.
This will be caused by the fact that there can be only one process
handling each prefix as extending qemu driver to allow concurrent access
would be a nightmare.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20190520/5a74999e/attachment-0001.sig>