Hide Forgot
The qemu and seabios in RHEL7 are new enough that libvirt can and should take advantage of the "-boot strict" option, as described below. +++ This bug was initially created as a clone of Bug #888635 +++ +++ This bug was initially created as a clone of Bug #888633 +++ Description of problem: As I said in https://bugzilla.redhat.com/show_bug.cgi?id=831273#c10 VMs after failure of network boot tries to boot from other devices even if the they are not selected, this problem also exists in seabios upstream. Currently we would adjust the priority according boot_deivces parameter in seabios, the default priority is 9999. We can resolve this issue by ignoring boot dev if its priority is 9999. Version-Release number of selected component (if applicable): seabios-0.6.1.2-25.el6.x86_64 How reproducible: Steps to Reproduce: 1. qemu-kvm -boot order=c rhel6.image.qcow2 (vm disk is non-bootable) Actual results: 1. vm will try to boot from disk, and failed 2. vm also try to boot from un-selected network Expected results: vm only try to boot from disk. Additional info: related bug: Bug 821331 - [RFE] KVM guest retry pxe booting even after failure --- Additional comment from Jiri Denemark on 2012-12-20 04:22:43 EST --- I think we do all we can in libvirt and no further changes should be required. Libvirt explicitly sets bootindex (starting from 1) for devices that are configured as bootable in domain XML. All other devices have no bootindex associated with them. --- Additional comment from Gleb Natapov on 2012-12-20 04:25:13 EST --- (In reply to comment #1) > I think we do all we can in libvirt and no further changes should be > required. Libvirt explicitly sets bootindex (starting from 1) for devices > that are configured as bootable in domain XML. All other devices have no > bootindex associated with them. We likely will not change current default behaviour. New parameter, to select this new behaviour, will be needed. --- Additional comment from Dave Allan on 2013-01-08 21:08:07 EST --- Unfortunately, this behavior cannot be changed without work in seabios, but the existing behavior is now documented. --- Additional comment from Laine Stump on 2013-02-06 11:30:13 EST --- The current behavior, and suggested workaround, has been documented in a knowledgebase article: https://access.redhat.com/knowledge/node/306863 --- Additional comment from Laine Stump on 2013-12-03 05:21:12 EST --- For future reference, newer qemu has added a "-boot strict" option which prevents this behavior, and upstream libvirt will now add that option to the qemu commandline any time it is present in the qemu binary: commit 96fddee322c7d39a57cfdc5e7be71326d597d30a Author: Laine Stump <laine> Date: Mon Dec 2 14:07:12 2013 +0200 qemu: add "-boot strict" to commandline whenever possible See Bug 888633 and Bug 903204 for details of the qemu fix. --- Additional comment from Laine Stump on 2013-12-03 07:37:34 EST --- The above commit also requires this commit to avoid build failures: commit 9f6f2fa467e57f41e60835e7e94fd2487c9b0e5e Author: Laine Stump <laine> Date: Tue Dec 3 12:58:50 2013 +0200 tests: add forgotten boot-strict test files
Patches backported and posted to rhvirt-patches for inclusion in the next libvirt build: http://post-office.corp.redhat.com/archives/rhvirt-patches/2013-December/msg00034.html
I can reproduce the bug with packages: # rpm -qa libvirt qemu-kvm-rhev seabios libvirt-1.1.1-13.el7.x86_64 qemu-kvm-rhev-1.5.3-20.el7.x86_64 seabios-1.7.2.2-4.el7.x86_64 Steps: Add a test.img which without an os installed to guest, keep one hard disk in guest, do not add other bootable devices, xml is: <..snip..> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/libvirt/images/test.img'/> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <..snip..> then start the guest, guest will try: Boot from Hard Disk... Boot failed: not a bootable disk then try: Boot from ROM... .... iPXE... Nothing to boot: No such file or directory No more network devices then: Booting from Floppy... Boot failed: could not read the boot disk
Verified failed with qemu-kvm-1.5.3-21.el7.x86_64,libvirt-1.1.1-14.el7.x86_64 and seabios-1.7.2.2-4.el7.x86_64 as bug 1039446 is not fixed yet, adding it to depends on list, and will re-verify this bug after depend bug fixed. Talked with a developer of qemu Amos Kong, he thought the problem for strict=on does not work is caused by the bug 997817 's fix patches.
Bug 997817 is re-opened to track the qemu regression problem, which blockes this bug's verification.
Reproduced as comment #2. Verifying this bug with packages: # rpm -qa libvirt qemu-kvm-rhev seabios libvirt-1.1.1-23.el7.x86_64 seabios-1.7.2.2-11.el7.x86_64 qemu-kvm-rhev-1.5.3-48.el7.x86_64 Steps: Add a test.img which without an os installed to guest, keep one hard disk in guest, do not add other bootable devices: # virsh dumpxml test | grep -B 15 "disk" <os> <type arch='x86_64' machine='pc-i440fx-rhel7.0.0'>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source file='/var/lib/libvirt/images/test.img'/> <target dev='hda' bus='ide'/> <alias name='ide0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> then start the guest, qemu process looks like: # ps aux | grep test ...-boot strict=on ... -drive file=/var/lib/libvirt/images/test.img,if=none,id=drive-ide0-0-0,format=raw,cache=none -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1... guest will try: Boot from Hard Disk... Boot failed: not a bootable disk No bootable device. then stop there, not try to boot from other un-selected devices like network, cdrom and so on, working as expected. So setting as VERIFIED.
This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request.