Dear list,
while wiring qemu-ga into libvirt I've noticed that it has ability to
spawn commands inside guest. I haven't paid much attention to it then as
implementing libvirt <-> qemu-ga communication was more important. But
lately couple of requests on the list showed up where ability to spawn
various commands inside guests would be much appreciated (e.g. when
fetching some stats that HV can't know or has no support for yet -
free/df/..).
When it comes to spawning commands we distinguish two modes: sync and
async. I think we should stick to this on the public API level too. Yet
better, we can have async APIs and the sync API would just be a wrapper
around async then.
One picture instead of thousand words:
/* obtain conn and dom somehow */
const char argv[] = {"argv1", "argv2", "argv3", ...}
size_t argc = ARRAY_CARDINALITY(argv);
unsigned int flags = 0;
virDomainCommandPtr cmd = virDomainCommandNew("/path/to/binary", argv,
argc, flags);
/* Should we care about env too? */
virStreamPtr st = virSreamNew(conn, VIR_STREAM_NONBLOCK);
virDomainCommandRun(dom, cmd, st, VIR_COMMAND_STRING_IO);
virStreamEventAddCallback(st, VIR_STREAM_EVENT_READABLE,
domainCommandCallback, ...);
/* ... */
virDomainCommandJoin(dom, cmd);
virStreamEventRemoveCallback(con->st)
virDomainCommandFree(cmd);
While qemu-ga can handle input for a binary its executing, this must be
put right into JSON when constructing the qemu-ga command. It's not
common that by that time users know the input they want to enter. So I
have to figure out something.
Opinions?
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list