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 -=|