Red Hat Bugzilla – Bug 628823
DOCS: Document that the bootable disk must be first in the XML
Last modified: 2012-06-20 02:24:55 EDT
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.
Bug 646895 requests support for explicit boot order specification and I hope to have it finished in time so this could then be mentioned in the docs.
Ok. I'll wait for you to get that BZ done, and then update the docs to reflect the results of that.
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.
According to fixing in bug 646895(https://bugzilla.redhat.com/show_bug.cgi?id=646895#c18), the <boot> element can be used to specify the exact order of boot devices, seems there is no need to document that the bootable disk must be first in the xml.
Patch enhancing documentation of <boot dev='...'/> element was sent upstream for review: https://www.redhat.com/archives/libvir-list/2012-February/msg00175.html
This is now fixed upstream by v0.9.10-rc1-4-g4f20ded: commit 4f20dedfd46a0fbd1cdf11d54aba01e4da20435d Author: Jiri Denemark <jdenemar@redhat.com> 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