[virt-tools-list] [PATCH 22/22] spice: hook into QMP port

[Daniel P. Berrangé]

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 at redhat.com> 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 at redhat.com> 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 at redhat.com> 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 :|