This patchset is a proof-of-concept implementation of power-control support in the SPICE protocol, allowing some basic operations like reset and power-off without a separate management protocol/connection.
Marc-André Lureau already added power-control in virt-viewer [0], but it is limited to direct-QEMU-connections since it's using QMP. This also means it can't be used with libvirt, while there is virt-qemu-qmp-proxy [1] it is "strongly recommended that this tool only be used to send commands which query information about the running guest." In a related patchset Victor Toso [2] recalls "discussions around having a way to power-on/off/reboot in spice and that it was rejected to keep spice as a viewer, etc.", however I couldn't find them in the various mailing list archives. The also mentioned comment by Daniel P. Berrangé [3] to rather have power control in SPICE was the basis for my initiative. The basic idea is to have a new "power" channel, which makes compatibility (including backwards) easy: Using a power-capable SPICE server with a power-incapable SPICE client works, and also the other way around. SPICE servers announce support for individual power-control- actions (like reset or power-on/off) via capabilities. SPICE clients can check these to enable the appropriate UI elements. To actually trigger a power action, SPICE clients send a dedicated action-message to the SPICE server, which passes the request on to the underlying management plane, which does whatever it needs to actually make it happen. To make sure the scope doesn't explode, the supported actions should be strictly specified by the protocol, and only cover the most basic/ general ones. I would restrict the actions to "hard" ones which don't require any help/interaction with the controlled target, so exclude any "graceful" actions like shutdown or reboot (which can be done using the input channel if I am not mistaken). The most useful is "reset" to revive a frozen/hung target system, which also has the nice property of not changing the power status (in contrast to e.g. power-off) so you can't cut off the branch you are sitting on; you can't power-on again a QEMU guest using SPICE, since there is no SPICE server when the guest is not running. The other two actions I would consider are power-off and power-on, especially useful for the BMC use-case. These three probably already cover the majority of use-cases, and would be a significant improvement in usefulness. The patchset should be considered PoC quality, and is not meant to be merged as-is, but serve as a basis for further discussion and experimentation. It contains the implementation in the SPICE-protocol and -libraries as well as an example server-implementation in QEMU and client-implementation in virt-viewer. The patchset spans across six git repos, the individual patches are tagged and each touches exactly one repo. Patches 1-6 add the new power-channel, 7-12 implement the reset action and 13-18 the power-off action, 19-21 add capabilities, and finally 22 some documentation. I implemented (only) reset and power-off, since those two already had UI elements in virt-viewer. A lot of the work was done by looking at and copying existing source code, adjusting it as needed. I tried my best to understand how all the pieces fit together and remove any unneeded parts, but expect to have missed some. While the existing documentation was mostly helpful, it was also very misleading regarding the "client classes" [4]: I spent quite some time searching for the factories, until realizing those only existed in the old client but not in spice-gtk/ virt-viewer. I tested only with QEMU VMs, started directly and also using libvirt (which works fine too). TODOs and open questions: - Instead of a dedicated channel you could also add the handful of required messages to the main channel, but that sounds messy and not like a good idea. - Actively restrict to one power channel per connection, or allow (and handle) multiple power channels in parallel? No idea if there is actually a use case for multiple. - Do one (empty) message per action (like now), or one message for all with an action-id in the payload? You have to discriminate in both cases, and using messages removes one layer. - Acknowledge the successful execution of an action from the server to the client. The existing ack mechanism currently only works the other way around (client-to-server). Or just rely on the guaranteed delivery provided by the underlying TCP transport. - Better error reporting from the server to the client, and also to the user. Instead of a notify may require a dedicated answer message. - Report the current power status (on or off) from the server to the client. Send updates when it changes. Can be used by clients to inform the user and further restrict actions (no power-on when already running) - Should pause/continue actions be supported? Not useful for hardware targets, and I imagine seldom used with VMs. - Could this completely replace the current QMP implementation in virt- viewer? - Channel migration was ignored for simplicity, but should be easy as there is no state to maintain/transfer. - Proper tests and documentation. [0] https://lists.virt-tools.org/2018-July/015213.html [1] https://libvirt.org/manpages/virt-qemu-qmp-proxy.html [2] https://lists.freedesktop.org/archives/spice-devel/2018-August/045210.html [3] https://lists.virt-tools.org/2018-August/015263.html [4] https://www.spice-space.org/spice-for-newbies.html#_spice_client Best regards -- Corubba
