Hi On Tue, Aug 7, 2018 at 1:28 PM, Daniel P. Berrangé <berrange@xxxxxxxxxx> 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@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. > > 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. _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
