Re: [libvirt] Redesigning Libvirt: Better supporting non-hypervisor agnostic concepts
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