Daniel Veillard wrote:
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,
OK, these are great comments that I will incorporate into the patch.
Currently I can get info on hvm domains but unable to create them. The
create request is sent to xend but then blocks reading from xend in
xend_req(). No problem creating the domain using xm. I have looked at
the config coming into xend and it is identical between xm and
virsh/libvirt. Need to poke around xend and see why there is no
response to the virsh/libvirt create request for hvm domains.
Thanks for the comments.
Jim