Bug 628823

Summary: DOCS: Document that the bootable disk must be first in the XML
Product: Red Hat Enterprise Linux 6 Reporter: Alex Jia <ajia>
Component: libvirtAssignee: Jiri Denemark <jdenemar>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: low    
Version: 6.0CC: berrange, dallan, dyuan, eblake, jclift, jdenemar, llim, mzhan, rwu, xen-maint, yupzhang
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: libvirt-0.9.10-1.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 06:24:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 646895    
Bug Blocks:    

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