> > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list