On Wed, Aug 09, 2006 at 11:54:26PM +0100, Daniel P. Berrange wrote:
Jeremy mentioned that it looked like libvirt wasn't able to create an HVM domain configured to boot off cdrom, so I took a closer look at the code and indeed the code dealing with <boot> section was both incomplete, and just plain broken. Incomplete in so much as it never included details of the ISO file backing the CDROM, and broken in so much as it was doing string comparisons against the wrong variables. Digging further found lots more work relating to creation of HVM domains so I've had a go at writing a patch to resolve matters. [snip] I have tested that with this patch I can successfully create a HVM domain which boots off a floppy, harddrive or cdrom. Furthermore if you then dump the XML of this domain,the XML you get back will match the XML you fed in (with the obvious exception of domain ID, and the Pseudo TTY path).
I meant to include a complete example XML doc showing the changes in place, so here is a XML dump from a HVM domain which has been booted off a CDROM: <domain type='xen' id='9'> <name>too</name> <uuid>b5d70dd275cdaca517769660b059d8bc</uuid> <os> <type>hvm</type> <loader>/usr/lib/xen/boot/hvmloader</loader> <boot dev='cdrom'/> </os> <memory>409600</memory> <vcpu>1</vcpu> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/lib64/xen/bin/qemu-dm</emulator> <interface type='bridge'> <source bridge='xenbr0'/> <mac address='00:16:3e:1b:b1:47'/> <script path='vif-bridge'/> </interface> <disk type='file'> <source file='/root/foo.img'/> <target dev='ioemu:hda'/> </disk> <disk type='file'> <source file='/root/boot.iso'/> <target dev='cdrom'/> </disk> <graphics type='vnc' port='5909'/> <console tty='/dev/pts/3'/> </devices> </domain>
If you have been monitoring xen-devel mailing lists you'll be aware that in 3.0.3 the way CDROM devices are configured is changing:
http://lists.xensource.com/archives/html/xen-devel/2006-08/msg00369.html
Although the patch attached does not support the config outlined in that mail, I'm pretty confident that a small incremental patch will be able to support it without breaking compatability with the changes I've outlined in this mail. The only tricky bit will be that we need to detect whether libvirt is running against a 3.0.2 or 3.0.3 version of XenD to decide how to convert XML -> SEXPR & vica verca.
Jeremy also just posted a patch to xen-devel allowing multiple boot devices to be specified: http://lists.xensource.com/archives/html/xen-devel/2006-08/msg00576.html So you can do the classic installer use case of "Try harddisk, if no boot sector, then fallback to [installation] cdrom" It would seem the obvious way to express this in libvirt XML would be to allow multiple <boot> elements with their ordering translating to the boot orrdering. So for example that use case would be expressed as: <domain type='xen' id='9'> <name>too</name> <uuid>b5d70dd275cdaca517769660b059d8bc</uuid> <os> <type>hvm</type> <loader>/usr/lib/xen/boot/hvmloader</loader> <boot dev='hd'/> <boot dev='cdrom'/> </os> The other (non-compatible) change would be to allow nested device entries <domain type='xen' id='9'> <name>too</name> <uuid>b5d70dd275cdaca517769660b059d8bc</uuid> <os> <type>hvm</type> <loader>/usr/lib/xen/boot/hvmloader</loader> <boot> <dev type='hd'/> <dev type='cdrom'/> </boot> </os> I'm inclined to just go for the former. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|