Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
When user manually insert a disk block xml in the front of booting disk(installing a os) in guest XML configuration, and user may successfully start the guest, but it seems libvirt hasn't done any check instead of defaultly booting the first disk device in guest XML, however, the first disk probably hasn't any os in it, so libvirt raises a "No bootable device" error in GUI such as virt-viewer and virt-manager, whether libvirt can identify a bootable device by the following xml:
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' cache='none'/>
<source file='/var/lib/libvirt/images/rhel6-demo.qcow2'/>
<target dev='hda' bus='ide'/>
<address type='drive' controller='0' bus='0' unit='0'/>
</disk>
<controller type='ide' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
</controller>
If it is a libvirt designing solution, user must insert disk xml in the end of booting disk, documents of libvirt need to be enhanced, because of I can't get any relevant information by man page and website of libvirt.
Version-Release number of selected component (if applicable):
# uname -r
2.6.32-59.1.el6.x86_64
# rpm -q libvirt
libvirt-0.8.1-27.el6.x86_64
# rpm -q qemu-kvm
qemu-kvm-0.12.1.2-2.112.el6.x86_64
How reproducible:
always
Steps to Reproduce:
1. install a guest
2. shut down the guest
3. editor a disk xml block
4. insert the disk xml in front of booting disk xml
5. start the guest
Actual results:
# cat disk.xml
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/myqcow2'/>
<target dev='hdb' bus='virtio'/>
</disk>
# qemu-img info /var/lib/libvirt/images/myqcow2
image: /var/lib/libvirt/images/myqcow2
file format: qcow2
virtual size: 20M (20971520 bytes)
disk size: 140K
cluster_size: 65536
backing file: /dev/sda1 (actual path: /dev/sda1)
# virsh edit rhel6-demo
Domain rhel6-demo XML configuration edited.
# virsh dumpxml rhel6-demo
<domain type='kvm' id='10'>
<name>rhel6-demo</name>
<uuid>55b041fd-9f64-714d-daf2-0ee491b63217</uuid>
<memory>1048576</memory>
<currentMemory>1048576</currentMemory>
<vcpu>1</vcpu>
<os>
<type arch='x86_64' machine='rhel6.0.0'>hvm</type>
<boot dev='hd'/>
</os>
......
<devices>
<emulator>/usr/libexec/qemu-kvm</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/myqcow2'/>
<target dev='hdb' bus='virtio'/>
<alias name='virtio-disk1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
</disk>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' cache='none'/>
<source file='/var/lib/libvirt/images/rhel6-demo.qcow2'/>
<target dev='hda' bus='ide'/>
<alias name='ide0-0-0'/>
<address type='drive' controller='0' bus='0' unit='0'/>
</disk>
<controller type='ide' index='0'>
<alias name='ide0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
</controller>
......
</domain>
# virsh start rhel6-demo
Domain rhel6-demo started
# virt-viewer rhel6-demo
Expected results:
Additional info:
libvirt passes the following argument to qemu-kvm:
-boot c -drive file=/var/lib/libvirt/images/myqcow2
# ps aux | grep qemu-kvm
qemu 2876 8.5 0.3 1403932 25088 ? Sl 13:46 0:10 /usr/libexec/qemu-kvm -S -M rhel6.0.0 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name rhel6-demo -uuid 55b041fd-9f64-714d-daf2-0ee491b63217 -nodefconfig -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/rhel6-demo.monitor,server,nowait -mon chardev=monitor,mode=control -rtc base=utc -boot c -drive file=/var/lib/libvirt/images/myqcow2,if=none,id=drive-virtio-disk1,boot=on,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/var/lib/libvirt/images/rhel6-demo.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=26,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:ea:24:ef,bus=pci.0,addr=0x3 -chardev tty,id=serial0,path=/dev/ttyS0 -device isa-serial,chardev=serial0 -usb -vnc 127.0.0.1:1 -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
This seems to be the case with present libvirt as well (0.8.7). We should probably update the website at least, to mention that the boot order is controlled by the placement of disk elements in the XML.
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as an
exception or blocker.
Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
This is now fixed upstream by v0.9.10-rc1-4-g4f20ded:
commit 4f20dedfd46a0fbd1cdf11d54aba01e4da20435d
Author: Jiri Denemark <jdenemar>
Date: Fri Feb 3 13:33:36 2012 +0100
docs: Enhance documentation of the old-style boot configuration
Also encourages people to use per-device boot elements for better
control.
Verified this issue in http://libvirt.org/formatdomain.html
boot
The dev attribute takes one of the values "fd", "hd", "cdrom" or "network" and is used to specify the next boot device to consider. The boot element can be repeated multiple times to setup a priority list of boot devices to try in turn. Multiple devices of the same type are sorted according to their targets while preserving the order of buses. After defining the domain, its XML configuration returned by libvirt (through virDomainGetXMLDesc) lists devices in the sorted order. Once sorted, the first device is marked as bootable. Thus, e.g., a domain configured to boot from "hd" with vdb, hda, vda, and hdc disks assigned to it will boot from vda (the sorted list is vda, vdb, hda, hdc). Similar domain with hdc, vda, vdb, and hda disks will boot from hda (sorted disks are: hda, hdc, vda, vdb). It can be tricky to configure in the desired way, which is why per-device boot elements (see disks, network interfaces, and USB and PCI devices sections below) were introduced and they are the preferred way providing full control over booting order. The boot element and per-device boot elements are mutually exclusive. Since 0.1.3, per-device boot since 0.8.8
So change the bug status to VERIFIED.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHSA-2012-0748.html
Description of problem: When user manually insert a disk block xml in the front of booting disk(installing a os) in guest XML configuration, and user may successfully start the guest, but it seems libvirt hasn't done any check instead of defaultly booting the first disk device in guest XML, however, the first disk probably hasn't any os in it, so libvirt raises a "No bootable device" error in GUI such as virt-viewer and virt-manager, whether libvirt can identify a bootable device by the following xml: <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/libvirt/images/rhel6-demo.qcow2'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' unit='0'/> </disk> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> If it is a libvirt designing solution, user must insert disk xml in the end of booting disk, documents of libvirt need to be enhanced, because of I can't get any relevant information by man page and website of libvirt. Version-Release number of selected component (if applicable): # uname -r 2.6.32-59.1.el6.x86_64 # rpm -q libvirt libvirt-0.8.1-27.el6.x86_64 # rpm -q qemu-kvm qemu-kvm-0.12.1.2-2.112.el6.x86_64 How reproducible: always Steps to Reproduce: 1. install a guest 2. shut down the guest 3. editor a disk xml block 4. insert the disk xml in front of booting disk xml 5. start the guest Actual results: # cat disk.xml <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/myqcow2'/> <target dev='hdb' bus='virtio'/> </disk> # qemu-img info /var/lib/libvirt/images/myqcow2 image: /var/lib/libvirt/images/myqcow2 file format: qcow2 virtual size: 20M (20971520 bytes) disk size: 140K cluster_size: 65536 backing file: /dev/sda1 (actual path: /dev/sda1) # virsh edit rhel6-demo Domain rhel6-demo XML configuration edited. # virsh dumpxml rhel6-demo <domain type='kvm' id='10'> <name>rhel6-demo</name> <uuid>55b041fd-9f64-714d-daf2-0ee491b63217</uuid> <memory>1048576</memory> <currentMemory>1048576</currentMemory> <vcpu>1</vcpu> <os> <type arch='x86_64' machine='rhel6.0.0'>hvm</type> <boot dev='hd'/> </os> ...... <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/myqcow2'/> <target dev='hdb' bus='virtio'/> <alias name='virtio-disk1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/libvirt/images/rhel6-demo.qcow2'/> <target dev='hda' bus='ide'/> <alias name='ide0-0-0'/> <address type='drive' controller='0' bus='0' unit='0'/> </disk> <controller type='ide' index='0'> <alias name='ide0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> ...... </domain> # virsh start rhel6-demo Domain rhel6-demo started # virt-viewer rhel6-demo Expected results: Additional info: libvirt passes the following argument to qemu-kvm: -boot c -drive file=/var/lib/libvirt/images/myqcow2 # ps aux | grep qemu-kvm qemu 2876 8.5 0.3 1403932 25088 ? Sl 13:46 0:10 /usr/libexec/qemu-kvm -S -M rhel6.0.0 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name rhel6-demo -uuid 55b041fd-9f64-714d-daf2-0ee491b63217 -nodefconfig -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/rhel6-demo.monitor,server,nowait -mon chardev=monitor,mode=control -rtc base=utc -boot c -drive file=/var/lib/libvirt/images/myqcow2,if=none,id=drive-virtio-disk1,boot=on,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/var/lib/libvirt/images/rhel6-demo.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=26,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:ea:24:ef,bus=pci.0,addr=0x3 -chardev tty,id=serial0,path=/dev/ttyS0 -device isa-serial,chardev=serial0 -usb -vnc 127.0.0.1:1 -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5