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

Daniel P. Berrange berrange at redhat.com
Thu Nov 23 10:36:22 UTC 2017


On Thu, Nov 23, 2017 at 11:32:13AM +0100, Michal Privoznik wrote:
> On 11/15/2017 06:57 PM, 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
> >> 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);
> 
> Problem with this is libvirt-qemu binary would need a connection object
> so that ...

That's not really a problem - I certainly expected that to be the case.
There would be a '--connect URI' arg, but since this is a QEMU specific
process, it could sensibly default to qemu:///session or qemu://system
as appropriate

> 
> >   }
> > 
> >   dom = virDomainLookupByUUID (conn, uuid);
> 
> ... it registers the domain under @conn connection (= it needs to
> register the domain at the right libvirtd [or whomever is going to keep
> list of running domains]).

Yes.

Regards,
Daniel
-- 
|: 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 :|




More information about the libvir-list mailing list