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