[libvirt] [PATCH v2 4/4] tests: Add tests for per-device boot elements

Jiri Denemark jdenemar at redhat.com
Mon Jan 17 10:17:16 UTC 2011


On Fri, Jan 14, 2011 at 11:51:56 -0700, Eric Blake wrote:
> On 01/14/2011 10:04 AM, Jiri Denemark wrote:
> > +    <disk type='network' device='disk'>
> > +      <driver name='qemu' type='raw'/>
> > +      <source protocol='sheepdog' name='image'>
> > +        <host name='example.org' port='6000'/>
> > +      </source>
> > +      <target dev='vda' bus='virtio'/>
> > +      <boot order='3'/>
> > +    </disk>
> 
> Just to make sure I'm clear - if any <disk> has a <boot> sub-element,
> then all remaining disks (in this case, /dev/HostVG/QEMUGuest1) that
> lack <boot> are not even considered for booting within the guest bios.

Devices with <boot> are tried first in the given order. What happens if the
boot doesn't succeed after trying all of them is undefined and depends on the
guest bios. E.g., seabios in qemu will try a usual set of devices (something
like hda, cdrom, nic) in that case. We could make the semantics stricter but I
don't think we would be able to enforce that.

> What happens if <boot order='1'/> is accidentally specified twice among
> two different <disk>/<interface> elements? Or what if I only supply <boot
> order='2'/>, but no 1?

In current state of the patches, this depends on the hypervisor...

> Does this series need an additional patch that ensures that there are no
> duplicates, or even that once all devices are visited, the boot order is
> contiguous from 1 to n?

Yeah, I it makes sense. Although I think we should just check and fail if
there are duplicates or if the boot order is not from 1 to n instead of
changing the order automagically. I'll prepare a follow-up patch for this.

Jirka




More information about the libvir-list mailing list