[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,