[libvirt] Redesigning Libvirt: Better supporting non-hypervisor agnostic concepts

[Richard W.M. Jones]

On Tue, Nov 14, 2017 at 05:25:03PM +0000, Daniel P. Berrange wrote:
> I would anticipate a standalone process "libvirt-qemu" that an
> application can spawn, providing a normal domain XML file via the
> command line or stdin. It would then connect to libvirtd to register
> its existance and claim its ownership of the guest name +
> UUID. Assuming that succeeds, 'libvirt-qemu' would directly spawn
> QEMU.

To be really clear about this, the application would run something
like:

  libvirt_xml = sprintf ("<domain><uuid>%s</uuid> etc etc", uuid);
  libvirt_xml_file = /* write libvirt_xml to a temporary file */;

  if (fork () == 0) {
    execlp ("libvirt-qemu",
            "libvirt-qemu", "--config", libvirt_xml_file, NULL);
  }

  dom = virDomainLookupByUUID (conn, uuid);

libvirt-qemu would exec(2) qemu?

Above I've assumed that we need to get a libvirt handle for ongoing
interactions with the new qemu process.  Would we get that via the
name or UUID from the XML, ie. calling virDomainLookupByUUID?  I guess
there's some raciness here.  The libvirt domain wouldn't exist
immediately in the application process.

In general it does sound like a good plan, and solves a problem for
libguestfs too.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org