[libvirt] [RFC] Explicit boot device ordering
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 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. Do you feel the same or do you even have a better solution in your mind? Jirka
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
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.
I agree. Is it necessarily the case that every boot device is a real device in the XML? Maybe there is a system that can boot from internal ROM or some other abstraction that doesn't correspond to a libvirt <device>.
Do you feel the same or do you even have a better solution in your mind?
Well how about ... <boot> net1 net0 hdc hdb </boot> Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
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 text.
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. Daniel
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
participants (3)
-
Daniel P. Berrange -
Jiri Denemark -
Richard W.M. Jones