Igor Mammedov <imammedo@redhat.com> writes:
On Mon, 20 Oct 2025 13:22:08 +0200 Markus Armbruster <armbru@redhat.com> wrote:
Igor Mammedov <imammedo@redhat.com> writes:
On Thu, 09 Oct 2025 16:55:54 +0200 Markus Armbruster <armbru@redhat.com> 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.
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?
[...]