On Tue, Aug 07, 2018 at 01:13:38PM +0200, Marc-André Lureau wrote: > Hi > > On Tue, Aug 7, 2018 at 1:02 PM, Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > On Tue, Aug 07, 2018 at 12:52:46PM +0200, Marc-André Lureau wrote: > >> Hi > >> > >> On Tue, Aug 7, 2018 at 12:01 PM, Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > >> > 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. > > > > Relying on layering QMP over the chardev channel means the entire > > thing it essentially opaque from Spice POV. We have virt-viewer > > implementing a QEMU protocol directly. Someone who wires up Spice > > to a non-QEMU backend may provide a different way to do the same > > thing since nothing is standardized as part of Spice. > > Ok, Spice could standardize based on QMP protocol though, to avoid > reinventing that. > > > IMHO spice-server library should provide some callbacks hooks for > > power control that QEMU can provide the impl for server side, while > > spice server could embed a small QMP server > > > spice-gtk should provide some APIs for power control client side. > > spice-gtk can handle the QMP-subset (essentially moving the 100 loc to > spice-gtk and providing new API) > > > virt-viewer shouldn't see a wire protocol at all. > > That would achive that goal, but every new functionality would have to > go through a bunch of API changes in server and client libraries, > making it way less flexible than the current proposal. QMP as a protocol, however, is not a self-contained general purpose mgmt protocol suitable for exposing to all users. Some of the commands might be generally useful, but a significant part of it is poking QEMU internals, and can't be practically used without knowing how QEMU is configured in detail, nor used with non-QEMU backend impls. Other commands should be exposed, but either represented in a different manner than QMP exposes, and/or with very strict restrictions on which argument values are permitted. IMHO requiring explicit modelling in the SPICE library API is thus a desirable feature, largely for the same reasons it is better to use the QMP protocol, or QEMU guest agent protocol, via libvirt APIs rather than directly passed through. 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
