Hi On Tue, Aug 7, 2018 at 12:01 PM, Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > On Tue, Jul 31, 2018 at 03:41:25PM +0200, marcandre.lureau@xxxxxxxxxx wrote: >> From: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx> >> >> If the "org.qemu.monitor.qmp.0" port is available: >> - enable the VM UI >> - get and follow the VM state >> - send the requested VM actions >> >> This adds a json-glib dependency on spice-gtk display. If necessary, >> we could make it optional. > > This patch is something I much don't much like the precedent / idea > of. Its only stop/pause/resume right now, but over time this will > inevitably expand and end up re-implementing much of libvirt's QMP > monitor handling, but worse. For example, the patch below has a CVE > in it because it is not limiting the amount of data it reads before > the \r\n pair, so a malicious QEMU can make it consume GB worth of RAM. True, low impact, easy to fix. > I would suggest it should use libvirt for these actions, but that > kind of defeats the goal of what you're trying to achieve by providing > a UI that is usable by standalone QEMU. > > The other thing that occurs to me is that the idea of remote power > control is interesting / useful for pretty much all uses of SPICE and > VNC with QEMU, even when libvirt is managing QEMU. > > As it stands we would not want to expose the monitor over SPICE in > many cases as it gives the SPICE user way too high privileges, but > remote power control is useful especially for cloud users. A way > to force a reboot of a dead/hung guest from the SPICE client instad > of having to jump out to openstack CLI API for example. > > In VNC there was a 3rd party extension defined to allow remote power > control actions over VNC. > > Thus I think SPICE could define a remote power control extension of > its own that could be safely enabled in all cases, even where the > remote user is unprivileged. This is portable to all SPICE server > side impls that care to provide it since it would not be QMP. If we have to define a new channel, new protocol messages etc, this will overlap with what QMP is already providing. Qemu or Spice could filter/limit the QMP monitor to a subset of commands/events. > > > 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 :| _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
