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