Description of problem: Run once VM with boot order 1st device hdd, 2nd device network, is accepted in vdsm as 1st device network. The problem we have as a result of that is that a VM is booted from pxe, installed with some image, reboot, and instead of loading from HDD, it is again boot from pxe, and this repeats iteself. This happen when We run VM once either from GUI, or from REST. How reproducible: In setups it occurred it always repeats. It is currently unclear why on some setups it works OK, and on others not. Actual results: load from HDD, after installation from pxe boot, an reboot.
Closing as notabug - not because it isn't, but because it's a well known QEMU issue (and there's somewhere an explicit BZ about fixing this correctly)
*** This bug has been marked as a duplicate of bug 751854 ***
Created attachment 599799 [details] engine log
Created attachment 599807 [details] vdsm log
It seems we have a problem at engine stage. We send via REST/GUI 1st device HDD, 2nd device network. On engine log we see Boot Order = 0 On vdsm log, vmCreate (corresponding to run Vm once) parameters show network Boot order = 1 (which means network first device) When it works fine, we expect vdsm vmCreate Boot order be as follows: network Boot Order = 2 disk Boot Order = 1 which means 1st device hdd, 2nd device network.
After further investigation with ofrenkel: When adding a new disk to VM using Rest API the default value for bootable parameter is false . When running the VM and sending "hd network" as boot order backend ignores the non bootable devices and send only "network" to vdsm , which leads to continuous boot from pxe. In the past same test with same code worked for us , I think that backend used to send "hd network" when we activated run once command with same parameters , even when the disk was logically defined as non bootable . In the GUI the default value for bootable parameter for first disk is true . I have few questions: 1. Do we need to add default value bootable=true for first disk in Rest API , same as in GUI or 2.fail run VM operation ( or add a proper warning message in the events log ) when trying to boot from non bootable device ? I think the current behavior is misleading and leads to errors.
i would go with option 1 for now to preserve old behaviour. and maybe add an RFE with suggestion to better boot order configuration
If first disk in a VM should be marked as bootable, I think this should be done in the backend. There is no good reason to force the API to have this logic, IMO.
Ilanit - why is this a bug? if user added a non bootable disk, we shouldn't boot from it. reading the above, it sounds omer's option 2 is the more correct (CanDoAction should fail running boot from disk when there is no bootable disk)
(In reply to comment #10) > Ilanit - why is this a bug? if user added a non bootable disk, we shouldn't > boot from it. > reading the above, it sounds omer's option 2 is the more correct > (CanDoAction should fail running boot from disk when there is no bootable > disk) We didn't pass bootable=false explicitly , we probably didn't pass anything for this property and the default is false . In the past backend used to pass to vdsm also non bootable devices when we choose "hd network" boot order and now it sends only network. This behavior is quite misleading and hard to debug since there are no warning / errors.
I've checked our code, and found for unattended installation, we define the first disk as bootable. The case we run into this "bug" was such where add disk was done separatly, and this should be user responsibilty to set the first disk as bootable (if desired). So nothing to fix.
I would set this field to be mandatory in order to refrain from such problems. Another option is to add event message which explain that VM run with non bootable disk . (In reply to comment #13) > I've checked our code, and found for unattended installation, we define the > first disk as bootable. The case we run into this "bug" was such where add > disk was done separatly, and this should be user responsibilty to set the > first disk as bootable (if desired). So nothing to fix.
(In reply to comment #14) > I would set this field to be mandatory in order to refrain from such > problems. I would prefers to reduce the mandatory fields to minimum > Another option is to add event message which explain that VM run with non > bootable disk . > The ack is for this, however this is an RFE. You are requesting to add a message saying that HD was selected in the boot order for a VM that does not have boot HD.
After discussing it in length with yaniv.kaul. We reached the conclusion that this is not a bug, but still requires a release note So I don't close this BZ yet (not sure how to close it in a way to be still picked up by the doc team) Removing blocker? flag and cleared keywords
closing - release note bugs don't need to be opened, just to have version flag and release note flag
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: In previous releases the Manager would attempt to boot virtual machines using an attached disk, in accordance with the user's specified boot order, even when no attached disk was marked as <literal>bootable</literal>. This behaviour has since changed. Disks for booting virtual machines <emphasis>must</emphasis> be marked as <literal>bootable</literal>. This includes disks created using the REST API and associated developer tools.