[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Libvir] Re: support for hvm guests

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:

  <boot dev='c'>
  <graphics type='vnc'>
  <cdrom dev='/dev/hdd'>

 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

   <disk type='block'>
      <source dev='hdd'/>
      <target dev='hdd'/>
   <graphic type='vnc'>

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]