[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On Wed, Nov 15, 2017 at 06:19:38PM +0000, Daniel P. Berrange wrote:
On Wed, Nov 15, 2017 at 05:57:45PM +0000, Richard W.M. Jones wrote:
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

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

  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?

Yes, that is pretty much exactly what I am suggesting.

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.

The libvirt-qemu would register itself with libvirtd, and then libguestfs
would have to speak to libvirtd for ongoing management. Though for the
purposes of shutdown, it would be valid to just kill() the children
directly if desired.  In the second mail in this series, I describe a way
to decompose libvirtd, whereupon ongoing management could be handled inside
libvirt-qemu itself. That would potentially avoid the need for libguestfs
to talk to libvirtd at all. Though this would be a secondary piece of work

Initially we could avoid the raciness if libvirt-qemu implemented the
systemd startup notification protocol. That would let libvirt-qemu notify
libguestfs (or whoever spawns it), /after/ it has successfully registered
itself with libvirtd.  So you can then virDomainLookupByUUID without any
race (ie you can then assume that if virDomainLookupByUUID fails, it means
the new QEMU has already quit)

I like the whole idea.  I'm replying here because this is the most
relevant part of this particular sub-thread.  Would it be too much for us
to go beyond this and offer more functionality without actually talking
to the daemon?  Let's say we:

- return the UUID instead of requiring it

- allow having more signal handlers than for just SIGTERM

- maybe add some simple protocol that libvirt-qemu shim would implement
 on stdin/out

these three things would provide the shim usable for things not compiled
with libvirt at all, maybe even users.  I'm not saying this must be
something we strive for from day one, just something we could consider
not forbidding.

|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

libvir-list mailing list
libvir-list redhat com

Attachment: signature.asc
Description: Digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]