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 :|