Description of problem: It seems that vms are trying to boot from PXE when using SR-IOV. trying to modify the xml by removing <boot dev='hd'/> and adding boot order to disk didn't help. ... <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/nova/instances/b8..../disk'/> <boot order='1'/> .... Customer has to modify the xml and adding to each network device the boot option: <rom bar='off'/> This way PXE is started but all network interfaces are discarded. How to ensure PXE boot is not enabled in this case, how to mod the images properties to avoid this behavior? Version-Release number of selected component (if applicable): RHOSP 10.0 How reproducible: With VF function enabled and VMs using those. Actual results: VMs try first to PXE boot Expected results: VMs start on their disk by default
Nova does not provide option to tweak rom bar element. I would say we should consider this as a RFE. Note, based on the documentation it seems the default changed in libvirt from 'off' to 'on'. Let see whether Daniel has a workaround or inputs to share about this specific feature.
I double checked with Daniel we don't have any way to configure that option instead of specifically set the attribute when building the domain XML. Currently Nova does not set this attribute letting the default QEMU behavior which changed during the time from 0 to 1. We can specifically set it to 0 in Nova until that we specifically support such feature.
Hi Sahid, Daniel, The question of being able to customize rom bar is a good one, but the mail request from the customer is more about how to avoid the pxe boot process for the instance and force it to just start on the vm local disk. Currently, setting global option <boot dev='hd'/> still make the pxe boot as first device. Removing this global option and setting the first disk boot index=1, doesn't also solves the issue. To avoid issues, customer set rom bar to off, but it still iterates through all network interfaces before booting on the disk. Regards, Pierre-André
FYI, Gerd has determined that the root problem here is that the firmware of the NIC card (Intel XL710) for some reason is replacing the system boot interrupt vectore (int 19h) with its own code (rather than just registering its bootability with the BIOS, which should be adequate on any system modern enough to have a slot that will accept such a card), so no matter what you do with boot ordering, the NIC firmware will always execute first, and it attempts PXE boot before dropping back to the original BIOS boot code. He has made a patch for SeaBIOS that watches for attempts by firmware to replace the int 19h vector, and undo it when detected. This appears to work for the customer in question here. See Bug 1642135 Comment 28 and onward for details (including a pointer to the SeaBIOS patch, and a test build)