On Mon, Oct 31, 2011 at 10:52:33AM +0100, Philipp Hahn wrote:
Hello,
On Wednesday 01 June 2011 17:58:32 Jiri Denemark wrote:
Commit 2d6adabd53c8f1858191d521dc9b4948d1205955 replaced qsorting disk and controller devices with inserting them at the right position. That was to fix unnecessary reordering of devices. However, when parsing domain XML devices are just taken in the order in which they appear in the XML since. Use the correct insertion algorithm to honor device target.
This commit (c1a98d88255197a8446d08c0b1589861660e9064) broke the Xen-PC-PyGrub case (see also "[PATCH 3/4] xen: fix PyGrub boot device order" from Oct 12th 2011, which worked only for preious versions of libvirt): XenD used the order of disks on domain-to-native to set the bootable flag to 1 only for the first device. This flag is then used on domain-start to determine the disk, which gets passed ty PyGrub to extract the Kernel and IniRD. Now the order is determined by /domain/devices/disk/target/@dev, which makes chaning the order impossible without also changing the devices names, which are visible to the VM! The Nr. 1 use-case for this is chaning the boot-order after installing from a PV-CDROM to the PV-disk. Since the Xen-PV-case has no BIOS bootable section, using /domain/os/boot/ here does not work.
Either that libvirt needs to explicitly support Xens bootable flag (via /domain/devices/disk/boot/@order?), or this patch should be reverted. Comments?
We should support the 'bootable' flag regardless. We gained an explicit <boot order='1'/> in the <disk> element, which could easily be wired up to Xen's boot order flag. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|