Igor Mammedov <[email protected]> writes: > On Wed, 29 Oct 2025 12:38:02 +0100 > Markus Armbruster <[email protected]> wrote: > >> Igor Mammedov <[email protected]> writes: >> >> > On Mon, 20 Oct 2025 13:22:08 +0200 >> > Markus Armbruster <[email protected]> wrote: >> > >> >> Igor Mammedov <[email protected]> writes: >> >> >> >> > On Thu, 09 Oct 2025 16:55:54 +0200 >> >> > Markus Armbruster <[email protected]> wrote: >> >> [...] >> >> >> >> I feel it's best to start the design process with ensvisaged uses. Can >> >> >> you tell me a bit more about the uses you have in mind? >> >> > >> >> > We have nic failover 'feature' >> >> > https://www.qemu.org/docs/master/system/virtio-net-failover.html >> >> > to make it work we do abuse hotplug and that poses problem >> >> > during migration, since: >> >> > - unplugging primary device releases resources (which might not be >> >> > possible to claim back in case migration failure) >> >> >> >> Serious reliability issue with no work-around. >> >> >> >> > - it's similar on destination side, where attempt to hotplug >> >> > primary might fail die to insufficient resources leaving guest >> >> > on 'degraded' virtio-net link. >> >> >> >> Obvious work-around is failing the migration. Same as we do when we >> >> can't create devices. >> >> >> >> > Idea was that instead of hotplug we can power off primary device, >> >> > (it will still exist and keep resources), initiate migration, >> >> > and then on target do the same starting with primary fully realized >> >> > but powered of (and failing migration early if it can't claim resources, >> >> > safely resuming QEMU on source incl. primary link), and then guest >> >> > failover driver on destination would power primary on as part of >> >> > switching to primary link. >> >> >> >> I can see how power on / off makes more sense than hot plug / unplug. >> >> >> >> > Above would require -device/device_add support for specifying device's >> >> > power state as minimum. >> >> >> >> The obvious way to control a device's power state with -device / >> >> device_add is a qdev property. Easy enough. >> >> >> >> Do we need to control a device's power state after it's created? If I >> >> understand your use case correctly, the answer is yes. -device / >> >> device_add can't do that. >> > >> > Could you elaborate why why -device/device_add can't do that? >> >> -device / device_add create, configure, and realize a new device. >> >> They can't reconfigure an existing device. In particular, they can't be >> used to control an existing device's power state. > > Sorry, I've misread as we can't use both for creating device in powered off > state. > > Perhaps we should consider a new specialized QMP command to > manipulate runtime power state. (Like it was suggested by Daniel)
I prefer few generic commands to many specialized commands whenever practical. However, designing a generic interface can be harder, sometimes much harder, than designing a specialized one. The generic command Salil proposed has serious flaws, as discussed upthread. None of us has promising ideas on how to do a generic command that isn't flawed by design. A more specialized one seems to be the only visible path forward. >> >> qom-set could, but friends don't let friends use it in production. >> >> >> >> Any other prior art for controlling device state at run time via QMP? >> >> >> >> [...]
