bootdevice.c | 112 ++++++++++++++++++++++++++++++++++++----------- hw/net/virtio-net.c | 3 ++ hw/nvram/fw_cfg.c | 2 + hw/ppc/spapr.c | 2 + hw/s390x/ipl.c | 2 + hw/scsi/scsi-bus.c | 3 ++ hw/virtio/virtio-pci.c | 2 + include/hw/block/block.h | 1 + include/net/net.h | 1 + include/sysemu/sysemu.h | 4 ++ 10 files changed, 106 insertions(+), 26 deletions(-)
This series implements a "bootonceindex" property for setting the boot source priorities for the next boot only. In principle it is supposed to do the same thing as the '-boot once=' argument but in a compatible way with the 'bootindex' mechanism. The basic idea is to have a second list that is sorted by the values of the "bootonceindex" properties. When the boot order is requested, the new list is returned if it is not empty and the list is cleared. The normal bootindex list is only used when there are no devices on the "once" list. So far I have only added the support for a couple of devices and lightly tested it on x86_64 system emulation. Some questions: - Is there already some (reasonable) way to accomplish the same effect in QEMU? - Does this approach make sense? Any better ideas? - Any suggestions for better function / property names? - Should the series be split or squashed differently? I tried to make it easy to review, but... - Are the object life times (no dangling pointers left behind) and (lack of) locking correct? As far as I can see, they should be, but someone with more experience with this codebase may see something I don't... - If this approach is going to be merged, any volunteers for converting the rest of the devices? Or can the conversion be left to be done one by one at some later date? I can try to convert more of them, but testing them all is likely not going to be possible. - Any other suggestions/ideas/comments? Janne Huttunen (6): Re-factor bootdevice list handling, pt1. Re-factor bootdevice list handling, pt2. Add support for "bootonceindex" property. Clear the boot once list after it has been used. Support "bootonceindex" property for virtio-net interfaces. Support "bootonceindex" property for SCSI disks. bootdevice.c | 112 ++++++++++++++++++++++++++++++++++++----------- hw/net/virtio-net.c | 3 ++ hw/nvram/fw_cfg.c | 2 + hw/ppc/spapr.c | 2 + hw/s390x/ipl.c | 2 + hw/scsi/scsi-bus.c | 3 ++ hw/virtio/virtio-pci.c | 2 + include/hw/block/block.h | 1 + include/net/net.h | 1 + include/sysemu/sysemu.h | 4 ++ 10 files changed, 106 insertions(+), 26 deletions(-) -- 2.7.4
Hi, > - Does this approach make sense? Any better ideas? What is the use case? Sometimes I'm wondering why we actually need the "once" thing. Looks like people use it for installs, but I fail to see why. I usually configure my guests with hard disk as bootindex=1 and install media (cdrom or net) as bootindex=2. In case the hard disk is blank it automatically falls back to the second and boots the installer, and when the installer is finished the hard disk isn't blank any more and the just installed system gets booted ... cheers, Gerd
> > - Does this approach make sense? Any better ideas? > > What is the use case? The short answer: emulating real hardware. Since real HW has this capability, there exist certain auxiliary systems that are built on it. Having similar semantics available in QEMU allows me to build a virtual machine that works with these systems without modifying them in any way. Also, the support I'm after already almost was in QEMU ('-boot once='). It just didn't quite provide the functionality I wanted i.e. the 'bootindex' like operation. This patch series tries to bridge that gap. But hey, I wasn't sure if this was useful for other people too, and that's why the RFC. In principle I agree with you that in some specific cases QEMU has other means of doing things that necessarily don't exist in real HW. Obviously systems that are built for real HW don't use any such QEMU specific methods. Again, in some specific cases it might be possible to get close enough semantics without real "boot once" support and in others it probably won't be. Note that part of the semantics I'm after is that the "boot once" order can be set while the system is up and running. It may or may not be strictly necessary depending on the specific use case, but that's the way the real HW works.
Hi, > The short answer: emulating real hardware. > > Since real HW has this capability, there exist certain > auxiliary systems that are built on it. Having similar > semantics available in QEMU allows me to build a virtual > machine that works with these systems without modifying > them in any way. Ok, that is reason enough. Adding bootonceindex everywhere doesn't look like the best plan to me though. Possibly we can pimp up bootindex in a backward-compatible way? Something like bootindex=<normal>[.<once>] ? cheers, Gerd
On Wed, 2017-03-15 at 08:24 +0100, Gerd Hoffmann wrote: > > > > The short answer: emulating real hardware. > > Ok, that is reason enough. > > Adding bootonceindex everywhere doesn't look like the best plan to me > though. Possibly we can pimp up bootindex in a backward-compatible > way? > Something like bootindex=<normal>[.<once>] ? That would (likely) avoid modifying all devices, but wouldn't that make the 'bootindex' property a string (now: 'int32') and thus change the QOM API? I did consider making device_add_bootindex_property() to automatically add the new property too, but since that API is currently such that the _caller_ provides the name of the added property, it would mean that the function would need to generate the second name using some magic mangling rule and that didn't seem very nice to me. Of course the API could be modified so that the caller provides two names, but then we are already back to modifying all relevant devices.
On Do, 2017-03-16 at 11:46 +0200, Janne Huttunen wrote: > On Wed, 2017-03-15 at 08:24 +0100, Gerd Hoffmann wrote: > > > > > > The short answer: emulating real hardware. > > > > Ok, that is reason enough. > > > > Adding bootonceindex everywhere doesn't look like the best plan to me > > though. Possibly we can pimp up bootindex in a backward-compatible > > way? > > Something like bootindex=<normal>[.<once>] ? > > That would (likely) avoid modifying all devices, but wouldn't > that make the 'bootindex' property a string (now: 'int32') > and thus change the QOM API? Good point. I was thinking about the cmd line only where it is a string anyway. > I did consider making device_add_bootindex_property() to > automatically add the new property too, but since that API > is currently such that the _caller_ provides the name of the > added property, it would mean that the function would need > to generate the second name using some magic mangling rule > and that didn't seem very nice to me. I think the only case where this is something != "bootindex" is the floppy controller, which has bootindexA and bootindexB for the two drives. So name mangling doesn't look too bad to me. Maybe we could just add a "first-" or "once-" prefix. But the second bootindex still needs to be stored somewhere in the device state struct ... > Of course the API could > be modified so that the caller provides two names, but then > we are already back to modifying all relevant devices. ... so I guess there isn't really some way around that. cheers, Gerd
On 03/16/2017 04:46 AM, Janne Huttunen wrote: > On Wed, 2017-03-15 at 08:24 +0100, Gerd Hoffmann wrote: >>> >>> The short answer: emulating real hardware. >> >> Ok, that is reason enough. >> >> Adding bootonceindex everywhere doesn't look like the best plan to me >> though. Possibly we can pimp up bootindex in a backward-compatible >> way? >> Something like bootindex=<normal>[.<once>] ? > > That would (likely) avoid modifying all devices, but wouldn't > that make the 'bootindex' property a string (now: 'int32') > and thus change the QOM API? Is there any way to make use of an alternate that supports both int and string simultaneously? But see also Markus' recent addendum on the difficulties of supporting multiple types on command-line vs. through QMP: https://lists.gnu.org/archive/html/qemu-devel/2017-03/msg04125.html -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 15/03/2017 07:58, Janne Huttunen wrote: > > Since real HW has this capability, there exist certain > auxiliary systems that are built on it. Having similar > semantics available in QEMU allows me to build a virtual > machine that works with these systems without modifying > them in any way. How does real hardware do it? I suppose you'd do it with a firmware setup menu or something like that; would it be enough to add a way to modify bootindex during runtime? Paolo
On Tue, 2017-03-21 at 18:55 +0100, Paolo Bonzini wrote: > > > Since real HW has this capability, there exist certain > > auxiliary systems that are built on it. Having similar > > semantics available in QEMU allows me to build a virtual > > machine that works with these systems without modifying > > them in any way. > > How does real hardware do it? I suppose you'd do it with a firmware > setup menu or something like that; would it be enough to add a way to > modify bootindex during runtime? On the real hardware the "boot once" really means *once* i.e. it only affects the next reboot regardless of how the next boot is triggered (reset button, power button, software, etc.). After the next boot the normal boot order is automatically restored. Theoretically it should be possible to get a close approximation of this by changing the main boot order, waiting for the boot to happen and then restoring the original order back. This would require having some process that constantly monitors what QEMU is doing so that it can notice when the boot happens and then restore the order. I'm trying to avoid having such a process if possible, which in this case means that QEMU would need to restore the order by itself.
----- Original Message ----- > From: "Janne Huttunen" <janne.huttunen@nokia.com> > To: "Paolo Bonzini" <pbonzini@redhat.com>, "Gerd Hoffmann" <kraxel@redhat.com> > Cc: qemu-devel@nongnu.org > Sent: Wednesday, March 22, 2017 7:36:54 AM > Subject: Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property > > On Tue, 2017-03-21 at 18:55 +0100, Paolo Bonzini wrote: > > > > > Since real HW has this capability, there exist certain > > > auxiliary systems that are built on it. Having similar > > > semantics available in QEMU allows me to build a virtual > > > machine that works with these systems without modifying > > > them in any way. > > > > How does real hardware do it? I suppose you'd do it with a firmware > > setup menu or something like that; would it be enough to add a way to > > modify bootindex during runtime? > > On the real hardware the "boot once" really means *once* > i.e. it only affects the next reboot regardless of how > the next boot is triggered (reset button, power button, > software, etc.). After the next boot the normal boot > order is automatically restored. Understood---my question is how you would set up the alternate boot order: is it something like "keep a button pressed while turning on", or something written in NVRAM, or something else that is completely different? Paolo > Theoretically it should be possible to get a close > approximation of this by changing the main boot order, > waiting for the boot to happen and then restoring the > original order back. This would require having some > process that constantly monitors what QEMU is doing so > that it can notice when the boot happens and then > restore the order. I'm trying to avoid having such > a process if possible, which in this case means that > QEMU would need to restore the order by itself. > > >
On Wed, 2017-03-22 at 04:43 -0400, Paolo Bonzini wrote: > > Understood---my question is how you would set up the alternate > boot order: is it something like "keep a button pressed while > turning on", or something written in NVRAM, or something else > that is completely different? In my case the real hardware has a management processor on the board and the temporary boot source (and also the permanent one for that matter) for the main processor can be set from there. Since neither the BIOS nor the management firmware are open source, I don't know how it technically works, but I assume there either is some shared memory between the main BIOS and the management processor or alternatively the BIOS talks with the management processor with some protocol during boot to get the order.
On 03/22/17 10:00, Huttunen, Janne (Nokia - FI/Espoo) wrote: > On Wed, 2017-03-22 at 04:43 -0400, Paolo Bonzini wrote: >> >> Understood---my question is how you would set up the alternate >> boot order: is it something like "keep a button pressed while >> turning on", or something written in NVRAM, or something else >> that is completely different? > > In my case the real hardware has a management processor > on the board and the temporary boot source (and also the > permanent one for that matter) for the main processor can > be set from there. Since neither the BIOS nor the management > firmware are open source, I don't know how it technically > works, but I assume there either is some shared memory > between the main BIOS and the management processor or > alternatively the BIOS talks with the management processor > with some protocol during boot to get the order. > I'm generally opposed to the proposed implementation for this feature / use case; that is, the new "bootonceindex" device property. (1) My somewhat hand-waving counter-argument is simply the complexity / confusion that it introduces. See for example recent QEMU commit c0d9f7d0bced ("docs: Add a note about mixing bootindex with "-boot order"", 2017-02-28). Even if the proposed solution keeps the "bootorder" fw_cfg file intact, and firmware wouldn't have to look at other fw_cfg files -- I can already guarantee that OVMF will not look at other fw_cfg files --, the command line changes look undesirable to me. (2) My more technical counter-arguments are: (2a) Exposing this in the libvirt domain XML would be a huge pain. AFAICS, libvirt already doesn't expose "-boot once" in the domain XML, which is a *good* thing. (2b) With the proposed change, "having rebooted once" becomes explicit runtime state that is guest-controlled. As such, it would have to be migrated. Assume that you start the guest on the source host, using both bootindex and bootonceindex properties. Then, for migration, libvirt (or the user, manually) starts QEMU on the target host using the same command line. After migration, if the guest reboots on the target host, its behavior should depend on whether said reboot is its first reboot since launching the domain, so the fact whether it rebooted on the source host should reach the target host. I think you must already have a means to massage the management processor to change the boot order, for the next boot. Are you doing that massaging in code that runs on the main processor? If so, that means the "guest code" is highly privileged, as it can control outside components in order to influence the boot order. For that, I can offer the following analogy: - use a guest with libvirt - whenever you want to modify the boot order from within the guest, ssh back out to the host, and use virsh-dumpxml (--inactive), the xmlstarlet utility, and virsh-define, to dump, edit, and save the domain XML non-interactively. Xmlstarlet is extremely versatile for modifying domain XMLs (or any other kinds of XMLs), and virsh-define explicitly supports the case when the domain is already running. In a normal virtualization environment, this would be a huge security hole, of course, but you are already manipulating the management processor from code that runs on the main processor. Exact same privilege escalation. - whenever you want to relaunch the domain fully (i.e., restart QEMU with a new command line), again ssh out to the host, and start a process (a shell script) in the background. The script should first initiate a domain shutdown (virsh-shutdown), then wait for domain termination (virsh-qemu-monitor-event, and see the SHUTDOWN event in "qapi/event.json"), then start the domain (virsh start). Which is when the modified boot order will take effect. Alternatively, if you are fine using OVMF (as UEFI firmware) within the guest, to run your payload, you can try the following commands, to set the BootNext UEFI variable & to reboot: efibootmgr --bootnext XXXX reboot While OVMF heavily massages the UEFI boot order (based on the "bootorder" fw_cfg file), *if* you stick with a constant set of bootindex properties (== constant boot order setting in the libvirt domain XML), then most of the UEFI BootXXXX variables that you get to see in the guest *should* be stable, and the above commands should hopefully work (no guarantees though). Thanks Laszlo
On Wed, 2017-03-22 at 11:51 +0100, Laszlo Ersek wrote: > > I'm generally opposed to the proposed implementation for this feature > / > use case; that is, the new "bootonceindex" device property. > > (1) My somewhat hand-waving counter-argument is simply the complexity > / > confusion that it introduces. See for example recent QEMU commit > c0d9f7d0bced ("docs: Add a note about mixing bootindex with "-boot > order"", 2017-02-28). I agree that it may be confusing, but I was under the (possibly false?) impression that the "-boot order" was on its way to being deprecated. I thought supporting the same functionality on "bootindex" -based configuration would actually _help_ eventually getting rid of "-boot order". Of course it can be argued that the "-boot once" was always a misfeature and should be removed at the same time, but as it stands I find it even more confusing that there exists this "bootindex" mechanism but "-boot once" isn't compatible with it and no compatible alternative seems to exist at all. > Even if the proposed solution keeps the "bootorder" fw_cfg file > intact, > and firmware wouldn't have to look at other fw_cfg files -- I can > already guarantee that OVMF will not look at other fw_cfg files --, > the > command line changes look undesirable to me. The current implementation doesn't require any firmware changes. > (2) My more technical counter-arguments are: > > (2a) Exposing this in the libvirt domain XML would be a huge pain. > AFAICS, libvirt already doesn't expose "-boot once" in the domain > XML, > which is a *good* thing. I'm nowhere nearly qualified to comment on that so I'll leave it to others. > (2b) With the proposed change, "having rebooted once" becomes > explicit > runtime state that is guest-controlled. As such, it would have to be > migrated. Assume that you start the guest on the source host, using > both > bootindex and bootonceindex properties. Then, for migration, libvirt > (or > the user, manually) starts QEMU on the target host using the same > command line. After migration, if the guest reboots on the target > host, > its behavior should depend on whether said reboot is its first reboot > since launching the domain, so the fact whether it rebooted on the > source host should reach the target host. Whether the first boot has happened or not is reflected in the values of the "bootonceindex" properties. The current implementation resets them back to -1 when the boot happens. I'm not qualified to say if that is sufficient or not, but if it isn't don't you already have problems migrating other things? If e.g. someone sets the "bootindex" property while the system is running, is that going to get migrated? If it is, migrating the "bootonceindex" values the same way should be sufficient, no? You can probably tell that I'm not very familiar with the migration and I must admit that I did not think about it at all when doing the implementation, but things like this are exactly the reason I wanted to get comments on the idea. > I think you must already have a means to massage the management > processor to change the boot order, for the next boot. Are you doing > that massaging in code that runs on the main processor? No, the changes are made externally. My setup is such that first there is a computer that has a main processor with an attached management processor. Then there is a second external system that remotely monitors and controls the first one. Part of what the second system does requires setting a temporary boot order for the next reboot of the first system every now and then. Many of the used components are beyond my control (like e.g. operating systems etc.) meaning that I either cannot modify them or doing so would make the whole exercise moot. All this exists in real hardware, but since there's never enough hardware available and there are better uses for it, I tried to set up a virtual machine that could act as a cheap substitute.
On 03/22/17 14:58, Janne Huttunen wrote: > On Wed, 2017-03-22 at 11:51 +0100, Laszlo Ersek wrote: >> >> I'm generally opposed to the proposed implementation for this feature >> / >> use case; that is, the new "bootonceindex" device property. >> >> (1) My somewhat hand-waving counter-argument is simply the complexity >> / >> confusion that it introduces. See for example recent QEMU commit >> c0d9f7d0bced ("docs: Add a note about mixing bootindex with "-boot >> order"", 2017-02-28). > > I agree that it may be confusing, but I was under the > (possibly false?) impression that the "-boot order" was on > its way to being deprecated. I thought supporting the same > functionality on "bootindex" -based configuration would > actually _help_ eventually getting rid of "-boot order". > > Of course it can be argued that the "-boot once" was > always a misfeature and should be removed at the same time, Yes, that's my argument. > but as it stands I find it even more confusing that there > exists this "bootindex" mechanism but "-boot once" isn't > compatible with it and no compatible alternative seems to > exist at all. All of the "-boot" options have guest architecture and firmware-specific behavior (they are even documented so, in both the libvirt domain XML docs and the QEMU manual page). For example, "-boot order" is translated to x86 CMOS settings that are unusable in any firmware that isn't "legacy x86 BIOS". > >> Even if the proposed solution keeps the "bootorder" fw_cfg file >> intact, and firmware wouldn't have to look at other fw_cfg files -- >> I can already guarantee that OVMF will not look at other fw_cfg >> files --, the command line changes look undesirable to me. > > The current implementation doesn't require any firmware > changes. > >> (2) My more technical counter-arguments are: >> >> (2a) Exposing this in the libvirt domain XML would be a huge pain. >> AFAICS, libvirt already doesn't expose "-boot once" in the domain >> XML, which is a *good* thing. > > I'm nowhere nearly qualified to comment on that so I'll leave > it to others. > >> (2b) With the proposed change, "having rebooted once" becomes >> explicit runtime state that is guest-controlled. As such, it would >> have to be migrated. Assume that you start the guest on the source >> host, using both bootindex and bootonceindex properties. Then, for >> migration, libvirt (or the user, manually) starts QEMU on the >> target host using the same command line. After migration, if the >> guest reboots on the target host, its behavior should depend on >> whether said reboot is its first reboot since launching the domain, >> so the fact whether it rebooted on the source host should reach the >> target host. > > Whether the first boot has happened or not is reflected in > the values of the "bootonceindex" properties. The current > implementation resets them back to -1 when the boot happens. > I'm not qualified to say if that is sufficient or not, but > if it isn't don't you already have problems migrating other > things? If e.g. someone sets the "bootindex" property while > the system is running, is that going to get migrated? 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. 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. > 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. > You can probably tell that I'm not very familiar with the > migration and I must admit that I did not think about it > at all when doing the implementation, but things like this > are exactly the reason I wanted to get comments on the idea. > >> I think you must already have a means to massage the management >> processor to change the boot order, for the next boot. Are you doing >> that massaging in code that runs on the main processor? > > No, the changes are made externally. My setup is such that > first there is a computer that has a main processor with > an attached management processor. Then there is a second > external system that remotely monitors and controls the > first one. Part of what the second system does requires > setting a temporary boot order for the next reboot of the > first system every now and then. How does this work in more detail? 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)? It suggests that you are able to start QEMU processes on demand, if for nothing else then to set the bootonceindex properties. > Many of the used components > are beyond my control (like e.g. operating systems etc.) > meaning that I either cannot modify them or doing so would > make the whole exercise moot. All this exists in real > hardware, but since there's never enough hardware available > and there are better uses for it, I tried to set up a virtual > machine that could act as a cheap substitute. 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). If there is another way to achieve what you need, possibly using other tools as well, I suggest that we research that more (which is why we keep inquiring about your setup I guess). Thanks Laszlo
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.
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. > >
On Wed, 2017-03-22 at 16:29 +0100, Laszlo Ersek wrote: > > 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?) No, I'm not changing "bootindex" dynamically. I'm changing "bootonceindex" dynamically. The point is that whatever change I'm making is supposed to affect only one boot, the next one. Since the guest can trigger reboots by itself, I don't necessarily know when they are going to happen. Like I said earlier, I can get very close to the semantics I need if set the "bootindex" and get an event when the boot happens so that I know when to reset the bootindex back to the original value. However doing it like that is (at least in theory) racy if the event isn't synchronous and it requires some process that actively monitors those events which I'm trying to avoid. > ...and it could have a significant maintenance footprint, > while the feature does look niche (to me anyway). Whatever I'm currently doing is definitely a niche, but very similar setting of a one time boot source while the system is running is e.g. part of the IPMI standard (see "Set System Boot Options Command" in IPMI Specification), so the concept itself is not that much of a niche.
On 03/23/17 07:53, Janne Huttunen wrote: > On Wed, 2017-03-22 at 16:29 +0100, Laszlo Ersek wrote: >>> 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?) > > No, I'm not changing "bootindex" dynamically. I'm changing > "bootonceindex" dynamically. The point is that whatever > change I'm making is supposed to affect only one boot, the > next one. Since the guest can trigger reboots by itself, > I don't necessarily know when they are going to happen. > > Like I said earlier, I can get very close to the semantics > I need if set the "bootindex" and get an event when the > boot happens so that I know when to reset the bootindex > back to the original value. However doing it like that > is (at least in theory) racy if the event isn't synchronous > and it requires some process that actively monitors those > events which I'm trying to avoid. > >> ...and it could have a significant maintenance footprint, >> while the feature does look niche (to me anyway). > > Whatever I'm currently doing is definitely a niche, but very > similar setting of a one time boot source while the system > is running is e.g. part of the IPMI standard (see "Set > System Boot Options Command" in IPMI Specification), so > the concept itself is not that much of a niche. > ... Okay, I've spoken my mind on this, and have nothing more to add. I'm still not convinced, but that doesn't mean you can't convince others. (And you need to convince others more than me, because I'm not a QEMU maintainer -- I just wanted to voice my opinion, since this was an RFC.) What really matters to me though is that the "bootorder" fw_cfg file preserve - both its current, exclusive role, for communicating the boot order to the firmware, - and its syntax & semantics. Thanks Laszlo
© 2016 - 2024 Red Hat, Inc.