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

[Peter Krempa]

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:

I like this approach in general. We were bound to lose the full host
view of VMs started by libvirt shim sooner or later anyways as people
would want to stuff the libvirtd into a container.

Few things we should consider prior to making this a feature:

1) We should introduce a hard limit that the 'root' directory must not
be created by a library version greater than we are running right when
connecting. This is to prevent downgrades and thus all the problems with
them right upfront.

2) The library needs to make sure that the event loop is registered in
this case and ideally also make sure that it has run so that we avoid
problems with stuck instances.

3) The capability caching is not leveraged when creating a new instance
of the 'root'.

4) Internally we'll need to relax few checks in the migration region as
igrating to a different "root" will certainly make sense now.

5) It would be cool to have a way to virConnectDomainEventRegisterAny
prior to actually opening the connection. This would allow e.g. get the
events for block jobs which terminated while the app was away for some
reason so that it does not have to poll.

6) We need to write a doc setting the expectations how to use this in
the APP. (Clarify threading and that users can't avoid domain jobs etc.
[1])

7) We should get of rid of the 'autostart' feature for 'embed' type
connections.

8) Some kind of label depending on 'root' should be used in logs as
things may log into the same place and that would be a pain to debug.

> Specifically
> 
>  - We can use this to embed the QEMU driver in unit tests allowing
>    the full range of odriver functionality to be exercised during
>    *unit* testing without interfering with the host OS libvirtd.

This implies ... [2]

[...]

>  - Using a virtual root directory for QEMU driver state meams we do
>    not need to solve the hard refactoring problem of getting the main
>    libvirtd to detect the VMs launched via the shim. They can safely
>    live independantly.

[1] Or that removing the directory may e.g. get rid of some state which
may be needed like snapshot metadata etc.

>  - Thanks to the driver refactoring work it is still possible for the
>    embedded drivers to talk to main libvirtd to use the secondary
>    drivers for storage/network/etc if needed. Ideally we would allow
>    those secondary drivers to be embedded too but that's not implemented
>    here. Most important would be the secrets driver. Other drivers are
>    much less important.

[1] ... that this is ideally supported as well. It'll be surprising if
your tests spawn VMs which will infiltrate your 'default' network for
example. We might want to also have a way how to specify this during
connection.

> 
> Daniel P. Berrangé (5):
>   access: report an error if no access manager is present
>   libvirt: pass a root directory path into drivers
>   qemu: honour the root parameter during driver initialization
>   libvirt: support an "embed" URI path selector for QEMU driver
>   qemu: introduce a new style libvirt_qemu_shim program

Also this new program since it's advertised as 'copy this into your
code' should avoid using virAsprintf for constructing the URI.
-------------- 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/20190517/1a425bcf/attachment-0001.sig>