[Libvir] Re: support for hvm guests
First sorry for being a bit late answering,
On Fri, Apr 28, 2006 at 06:07:43PM -0600, Jim Fehlig wrote:
Type 'bridge' can be valid for hvm guests. Perhaps it is
better to not
expose ioemu in the XML for now as there will probably be changes in
this area anyway. We know the domain is type hvm, so just add 'ioemu:'
where necessary when talking to xend/xenstore. I'm currently thinking
about the following XML for OS element when type is hvm:
<os>
<type>hvm</type>
<kernel>/usr/lib/xen/boot/hvmloader</kernel>
<device_model>/usr/lib/xen/bin/qemu-dm</device_model>
<boot dev='c'>
<graphics type='vnc'>
<cdrom dev='/dev/hdd'>
</os>
Hum, I agree with Karel on the use of <boot dev='c' />, that's not
really
a logical naming, can we avoid that and use more strcutured names like
'/dev/hda' .
Also I don't understand why graphics and cdrom are not defined in the
<devices> section for example
<devices>
<disk type='block'>
<source dev='hdd'/>
<target dev='hdd'/>
<cdrom/>
</disk>
<graphic type='vnc'>
</graphic>
</devices>
boot, graphics, and cdrom elements are optional.
- boot: The device from which the guest should boot. If not specified
the guest will
be booted from hard disk. 'a' = floppy, 'c' = hard disk,
'd' = cdrom
not fond of that
- graphics: Graphics model to use for the guest. Valid type
attribute
values are 'vnc'
and 'sdl'. If not specified the guest will be
launched with sdl.
use a graphic element in the devices section instead, that way it
stay structured. Also be make code which may allow to pass extra informations
in the future as subelements, for example the vnc device may define
authentication mechanism, and default resolution/depth may also be passed
down in the future
- cdrom: The cdrom device, e.g. '/dev/hdd',
'/path/to/iso/plan9.iso'
Well should be a disk device too, with an extra <cdrom/> subelement,
and a source and a target as usual.
The patch I'm currently working on assumes this XML format. What
do you
think?
that I would prefer thing to stay more in line with existing format
details from http://libvirt.org/format.html, it's just semantic sugar but
design error there are usually a burden in the long term,
thanks !
Daniel
--
Daniel Veillard | Red Hat http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/