Re: [PATCH RFC V6 22/24] monitor,qdev: Introduce 'device_set' to change admin state of existing devices

[Markus Armbruster <armbru@redhat.com>]

Igor Mammedov <imammedo@redhat.com> writes:

> On Wed, 29 Oct 2025 12:38:02 +0100
> Markus Armbruster <armbru@redhat.com> wrote:
>
>> 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.
>
> 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?
>> >> 
>> >> [...]