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

[Daniel P. Berrangé]

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.

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 :|