On Mon, 2 Feb 2026 at 10:42, corubba <[email protected]> wrote: > > 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.
I prefer new messages in the main channel. A separate channel for some control message is quite overkilling. > - 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. Usually multiple channels per connection are used for multiple devices (like multiple monitors or multiple usb redirection). > - 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. I would prefer separate messages for each action. > - 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. If the ack if for simply "I got the message" I would say TCP is enough. If it is for something more like "I got the message, I processed, here is the result", then a message back would suit. > - 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) How could you implement the power-on, when the machine is powered down there's no SPICE to talk to. > - Should pause/continue actions be supported? Not useful for hardware > targets, and I imagine seldom used with VMs. I see them as more Qemu options. Not sure if you can talk using SPICE to a suspended machine. > - Could this completely replace the current QMP implementation in virt- > viewer? I'm not sure, QMP is used for a lot of things. > - Channel migration was ignored for simplicity, but should be easy as > there is no state to maintain/transfer. Yes, agreed. > - 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 Frediano
