On 24/01/20 10:50, Daniel P. Berrangé wrote: > * qemu-launcher-$TARGET > > A binary that is able to launch qemu-runtime-$TARGET > with jailers active. > > This has no command line arguments except for a pair > of UNIX socket paths. One is a QMP server, the other > is the path for the QMP of qemu-runtime-$TARGET. > > Commands it processes will be in automatically proxied > through to the qemu-runtime-$TARGET QMP, with appropriate > jailer updates being done in between. >
What would be the advantage of this over the Libvirt embedded driver? Especially if you include in the picture something like libvirt-go-xml (or libvirt-GObject, does it still exist?) that hides the XML from the code that uses it. The main complication in the launcher is hotplug, which means that a simple "do a couple bind mounts, unshare, drop privileges and forget about it" approach doesn't work. Proxying QMP commands doesn't seem that easy, and I don't see much code being shared between the launcher and QEMU; if the existing QEMU code is not suitable for Libvirt, it wouldn't be suitable for a qemu.git launcher either. Also, as you mentioned earlier, QEMU wants to keep its vocabulary lower-level, and therefore the launcher's vocabulary would end up diverging from QEMU. Some example: - QEMU wants a qemu-pr-helper socket path, the launcher would take care of launching qemu-pr-helper itself - QEMU wants the complete configuration on the migration destination, the launcher might take care of sending it from the source? At this point, you get something that looks very much like Libvirt and, especially if you include live migration, it has to take into account the same compatibility considerations as Libvirt. Thanks, Paolo
