At 2016-08-08 23:00:38, "Michal Privoznik" <mprivozn@xxxxxxxxxx> wrote: >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. > Cool! We should had a API than using qemu monitor command. ... >virStreamEventAddCallback(st, VIR_STREAM_EVENT_READABLE, >domainCommandCallback, ...); > >/* ... */ > >virDomainCommandJoin(dom, cmd); > >virStreamEventRemoveCallback(con->st) > >virDomainCommandFree(cmd); > Do we had timeout mechanism? Some command may hang for a long time in guest. Regards, - Chen > > >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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list