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

[Igor Mammedov <imammedo@redhat.com>]

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:
> >  
> >> Igor Mammedov <imammedo@redhat.com> writes:  
> 
> [...]
> 
> >> > It's likely /me who to blame for asking to invent generic
> >> > device-set QMP command.
> >> > I see another application (beside ARM CPU power-on/off) for it,
> >> > PCI devices to simulate powering on/off them at runtime without
> >> > actually removing device.    
> >> 
> >> I prefer generic commands over collecting ad hoc single-purpose
> >> commands, too.  Getting the design right can be difficult.
> >>   
> >> > wrt command,
> >> > I'd use only 'id' with it to identify target device
> >> > (i.e. no template matching nor QMP path either).
> >> > To enforce rule, what user hasn't named explicitly by providing 'id'
> >> > isn't meant to be accessed/manged by user later on.     
> >> 
> >> Works well, except when we need to access / manage onboard devices.
> >> That's still an unsolved problem.
> >>   
> >> > potentially we can invent specialized power_set/get command as
> >> > an alternative if it makes design easier.
> >> > But then we would be spawning similar commands for other things,
> >> > where as device-set would cover it all. But then I might be
> >> > over-complicating things by suggesting a generic approach.     
> >> 
> >> Unclear.
> >> 
> >> 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?


> 
> 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?
> 
> [...]
>