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.