On Tue, Aug 07, 2018 at 02:39:06PM +0200, Marc-André Lureau wrote: > Hi > > On Tue, Aug 7, 2018 at 1:28 PM, Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > 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. > > So you are asking that spice and vnc should also do what libvirt is > doing? I disagree. They have some overlap with libvirt but they are ultimately distinct, as SPICE/VNC are not tied to QEMU, or even tied to virt. You could have the power control options in SPICE/VNC, with a server talkng to Xorg or Wayland, and have them wired to shutdown the physical machine, or talk to an ILO, etc. > I suggest we start by exposing a subset of QMP and let virt-viewer > handling it with those 100 loc for this specific use case (qemu > -display app). We wouldn't have to duplicate so much effort to define > new protocols, API etc... I don't want to see any QMP code in virt-viewer. If you do want a subset of QMP then it should be exposed by spice-gtk as a proper API. 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
