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

[Janne Huttunen]

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.

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