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. -- Marc-André Lureau _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
