[Libvir] Fix handling of HVM boot parameters

Daniel P. Berrange berrange at redhat.com
Thu Aug 10 00:00:17 UTC 2006


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




More information about the libvir-list mailing list