5:54 p.m.
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.
* Parsing of UUID from SEXPR assumed that the UUID fetched would always
have four '-' in the usual places. Well, when you run 'dumpxml' from
virsh the <uuid> element has the UUID encoded without any '-' chars.
If you feed this back into 'virsh create' and then once again run
'dumpxml' parsing will fail & libvirt throws errors. So this patch
allows for parsing of UUID's without '-'.
* The XML document size was limited to 1k - we just 'malloc(1000)'. While
this was enough for common cases, if someone creates lots of disk or
network devices this would overflow and libvirt return an error. So I
increased it to 4k which ought to be enough for forseeable future - in
any case my previous patch to fetch XML via the proxy is limited to 4k
in size too.
Now onto the fine details...
When converting SEXPR into XML current code is doing the following:
(boot a) -> <boot dev='/dev/fd0'/>
(boot c) -> <boot dev='hda'/>
(boot d) -> <boot dev='/dev/cdrom'/>
This is rather inconsistent - the 'hda' is intended to map to an entry
in <devices> block. The '/dev/fd0' and '/dev/cdrom' entries did not
map to anything.
Meanwhile, when converting from XML to SXEXPR it is doing the following
<boot dev='hda'/> -> (boot a)
<boot dev='hdd'/> -> (boot d)
<boot dev='*'/> -> (boot c)
Obviously this sucks because these processes should be matching each
other.
Secondly, the (image (hvm....)) SEXPR has three entries for defining
the ISO / disk image file backing the CDROM / Floppy devices. These
were just being ignored, rather than turned into <disk> entries within
the <devices> block. Similarly there was no way to express a <disk>
entry for CDROM/Floppy in the XML when creating a domain.
The upshot of all this is that although the last release of libvirt
included HVM support it was basically unusable for domain creation
unless you were using HD to boot. The XML returned was also incorrect.
Now the good news. Since it was sooo broken, we can fix without worrying
about XML compatability since there is no way any application could be
relying on it in its current state.
Now before I discuss the solution, one final point. The Xen IOMMU model
allows specifiying the boot device in terms of 'a', 'c', 'd' which
has
the meaning:
a - first connected floppy device
c - first connected harddrive
d - first connected cdrom
In particular it does *not* allow for expressing boot device in terms
of an explicit disk device - you can't say boot off 'hdb' or 'hdc'.
So
the current libvirt code which tries to fake such semantics is doomed
to failure. This isn't really too bad IMHO - VMware has these same
semantics, so does QEMU and so do normal bare metal BIOS
This in the patch I have attached I have implemented the following mapping:
(boot a) <-> <boot dev='fd'/>
(boot c) <-> <boot dev='hd'/>
(boot d) <-> <boot dev='cdrom'/>
The other part of the patch is to deal with definition of the floppy and
cdrom device backing files. For this I have done the following:
(image (hvm (fda /root/diskboot.img)))
<devices>
<disk type='file'>
<source file='/root/diskboot.img'/>
<target dev='fda'/>
</disk>
</devices>
And similar for 'fdb'. Then for cdroms:
(image (hvm (cdrom /root/image.iso)))
<devices>
<disk type='file'>
<source file='/root/image.iso'/>
<target dev='cdrom'/>
</disk>
</devices>
The patch has a little bit of logic such that when converting the
<devices> block backinto an SEXPR it filters out the disk entries
with a dev of 'fda', 'fdb' and 'cdrom' since they need to end up
in
a different part of the SEXPR.
Finally, although PV guests automatically get a serial console created
for them (and i don't think you can turn it off), HVM guests need to have
a serial console explicitly requested. Since I recently added support in
the DumpXML method for including details of serial console like this:
<devices>
<console tty="/dev/pts/5"/>
</devices>
I decided to leverage this same structure when creating HVM domains. So
if you have:
<devices>
<console/>
</devices>
Then the SEXPR sent to XenD will include
(image (hvm (serial pty)))
Which enables allocation of PseudoTTY for the HVM's serial console.
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).
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.
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 -=|