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.
Bug 628823 - DOCS: Document that the bootable disk must be first in the XML
Summary: DOCS: Document that the bootable disk must be first in the XML
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Jiri Denemark
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: LibvirtBootOrder
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-31 06:31 UTC by Alex Jia
Modified: 2012-06-20 06:24 UTC (History)
11 users (show)

Fixed In Version: libvirt-0.9.10-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 06:24:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:0748 0 normal SHIPPED_LIVE Low: libvirt security, bug fix, and enhancement update 2012-06-19 19:31:38 UTC

Description Alex Jia 2010-08-31 06:31:27 UTC
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

Comment 3 Justin Clift 2011-01-10 13:37:37 UTC
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.

Comment 4 Jiri Denemark 2011-01-11 10:17:45 UTC
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.

Comment 5 Justin Clift 2011-01-11 12:36:20 UTC
Ok.  I'll wait for you to get that BZ done, and then update the docs to reflect the results of that.

Comment 6 Suzanne Logcher 2011-03-28 21:12:47 UTC
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.

Comment 7 dyuan 2011-06-22 06:07:57 UTC
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.

Comment 11 Jiri Denemark 2012-02-03 12:45:58 UTC
Patch enhancing documentation of <boot dev='...'/> element was sent upstream for review: https://www.redhat.com/archives/libvir-list/2012-February/msg00175.html

Comment 12 Jiri Denemark 2012-02-06 08:49:02 UTC
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.

Comment 15 yuping zhang 2012-02-15 02:39:00 UTC
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.

Comment 17 errata-xmlrpc 2012-06-20 06:24:55 UTC
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


Note You need to log in before you can comment on or make changes to this bug.