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

[Marc-André Lureau]

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.

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

If you need fuller control over a VM in general, you should use
virt-viewer and libvirt, or libgovirt.