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.
>
>
