[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [RFC] Explicit boot device ordering

On Tue, Jan 11, 2011 at 03:17:26PM +0100, Jiri Denemark wrote:
> Hi,
> I'm working on $SUBJ and I can't decide on XML representation of that. The
> goal is to let users specify an ordered list of devices to boot from, e.g.,
> 2nd NIC, 1st NIC, 1st CD-ROM, 2nd IDE disk. We already have boot elements in
> /domain/os so we could make use of them or we could add a boot element inside
> device elements.
> So for the first case, we could have something like
> <os>
>     <boot target='net1'/>
>     <boot target='net0'/>
>     <boot target='hdc'/>
>     <boot target='hdb'/>
> <os>
> Where target attributes would match /domain/devices/*/target dev

I'm not a huge fan of using */target dev as the identifier for the
device though, since that isn't an attribute that exists for all
device types in the XML - only NICs + disks. This would make it
hard to boot from a PCI NIC that has been passed through from the
host using <hostdev>. It would be nice to use the unique device
alises, but we only assign those at guest startup, and not letting
the end user have any control over them, since in many case the
hypervisor itself is in charge of the naming scheme.

There's also the issue that allowing arbitrary new names in
the boot/@target attribute will confuse apps which expect
it to only have cdrom/floppy/network/hd. It is basically
changing that attribute from an enumeration, to freeform

> For the second case, appropriate devices would contain <boot order='n'/>
> elements.
> Personally I like the first option more since it is very easy to change boot
> order in that case and the whole boot list is co-located at a single place in
> domain XML.

Yes it is slightly tedious to change them, but it does avoid the
question of how to refer to devices by name which is appealing.

I don't entirely like either option in the end since they both
have negative aspects, but for sake of compatibility I'd likely
have a slight preference for the second case.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]