Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property

[Laszlo Ersek]

On 03/22/17 16:19, Janne Huttunen wrote:
> On Wed, 2017-03-22 at 15:36 +0100, Laszlo Ersek wrote:
>>  
>> To my knowledge, currently the bootindex properties cannot be changed
>> dynamically (for example with monitor commands) after they have been
>> specified on the QEMU command line.
> 
> Yes they can, via QMP:
> 
> {'execute': 'qom-get', 'arguments': { 'path': 'scsi0.0/child[0]',
> 'property': 'bootindex' }}
> {"return": 10}
> 
> {'execute': 'qom-set', 'arguments': { 'path': 'scsi0.0/child[0]',
> 'property': 'bootindex', 'value': 11 }}
> {"return": {}}
> 
> {'execute': 'qom-get', 'arguments': { 'path': 'scsi0.0/child[0]',
> 'property': 'bootindex' }}
> {"return": 11}
> 
> 
> I have no idea if doing so breaks something, like e.g.
> migration, but it definitely can be done.
> 
>> And, even if some settings can be changed, the question is what agent
>> changes them. If the management layer (libvirt etc) changes them
>> using
>> monitor commands, then libvirt itself can keep track of that state,
>> and
>> then start the QEMU process on the destination  host with a suitably
>> modified command line.
>>
>> Whereas, if it is the guest that changes device state, memory state
>> etc,
>> then those things have to be part of the migration stream.
> 
> True.
> 
>>> If it
>>> is, migrating the "bootonceindex" values the same way should
>>> be sufficient, no?
>> To my knowledge, "bootindex" properties are not migrated now, and
>> they
>> also need not to, because they never change at runtime.
> 
> Like demonstrated above, they can change, but of course
> there might be an assumption that they won't change
> "unexpectedly".
> 
>> If the second system sets a temporary boot order for the first system
>> "every now and then", which I guess entails on-demand talking to the
>> first system's management processor, then how can you replace that
>> with
>> a static QEMU command line (with the proposed bootonceindex
>> property)?
> 
> I'm not. I'm using QMP to change the index dynamically.

Wait, if you are already changing the "bootindex" property dynamically
(do I understand that right?), and it even takes effect after guest
reboot, then why is "bootonceindex" necessary at all?

(I apologize, I think I'm confused.)

Thanks
Laszlo

> 
>> I'm not saying that the use case is without merit. My point is that
>> this
>> new property would introduce obscure interactions with other
>> components
>> in the virt stack around QEMU, and it could have a significant
>> maintenance footprint, while the feature does look niche (to me
>> anyway).
> 
> Maybe, and it is definitely good to analyze it. Like I
> already admitted, I did not think about migration at all
> and there may very well have been other things I have
> overlooked too.
> 
>