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

[Marc-André Lureau]

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.

-- 
Marc-André Lureau