> 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.
I must admit I didn't think about passed through devices, that is a very good
point. While we could introduce better addressing scheme, it would get more
complicated easily thus ruining the advantages of this approach.
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
text.
Ah, I should have been explicit about that... It is not changing current
attribute, since we now have <boot dev='fd|hd|cdrom|network'/> and this is
suggesting to use target attribute. So a user/app can decide whether to use
the <boot dev='...'/> style or move to <boot target='...'/>
which allows for
better control over boot devices but which is not supported by all
hypervisors.
I don't entirely like either option in the end since they both
have negative aspects
Exactly.
but for sake of compatibility I'd likely have a slight preference
for the
second case.
You are starting to convince me :-)
Jirka