Attached is an updated patch providing some support for HVM guests. I have tested listing info on running guests and creating guests. cdrom support for HVM guests still needs some work, as does graphics options. Guests using graphics type 'sdl' still need some work. Using type 'vnc' is functional, but you must then manually use e.g. "vncviewer localhost:<dom_id>" to view.

I've also included a patch that backs out some optimizations done xend_internal.c. There is a bug in xend (from testing - I think Anthony fixed it and patch got applied to unstable) that does not close the connection after initial create op causing libvirt to block indefinitely. Backing out the optimizations allowed me to use the hvm patch on _testing branch of xen. I've included it for anyone else that may want to experiment with the hvm patch on _testing xen.

Finally, the attached archive contains: 1. a sample xml input file for hvm guest, 2. corresponding s-expr sent to xend, and 3. s-expr returned from xend when getting info on the running guest.

On Mon, Jul 10, 2006 at 06:22:39AM -0400, Daniel Veillard wrote: > I have made changes to the XML conversion code to reflect this, I will commit > whithin one hour or two. Attached is one example of the XML for HVM. Okay, I commited it, I also extended the page describing the XML format to cover the new HVM domains. I was able to launch a domain and attach to the vnc server so it seems to work for me at least in a minimal canonical configuration.

On Mon, Jul 10, 2006 at 06:59:03PM +0100, Daniel P. Berrange wrote: > On Mon, Jul 10, 2006 at 09:02:32AM -0400, Daniel Veillard wrote: > > On Mon, Jul 10, 2006 at 06:22:39AM -0400, Daniel Veillard wrote: > > > I have made changes to the XML conversion code to reflect this, I will commit > > > whithin one hour or two. Attached is one example of the XML for HVM. > > > > Okay, I commited it, I also extended the page describing the XML format > > to cover the new HVM domains. I was able to launch a domain and attach to > > the vnc server so it seems to work for me at least in a minimal canonical > > configuration. > > On the subject of VNC server, the element currently just contains > > <graphics type='vnc'/> > > Now the (undocumented) assumption is that the VNC server is listening on > a port number 5900+<domain id>. eg, Domain 3 listens on port 5903. This > may be fine for dev / testing purposes, but this is not really a acceptable > assumption to make long term. Xen could quite easily change to allocate > arbitrary ports to each domain on a first-come, first-serve basis. When > libVirt is ported to QEMU, there will be no correlation between domain > ID and vnc port number. Thus I'd suggest we extend the XML for VNC thus: > > <graphics type='vnc'> > <listen port="5903"/> > </graphics> I definitely agree that the current device description is very limited, nearly undocumented (but I put a warning at the end of http://libvirt.org/format.html#Fully1 ) starting it would certainly be extended. So yes definitely we need to expose more (and if you know parameters for sdl I'm all ears, I didn't found any docs about it !) Now from a syntactic point of view, I think it would be just fine to use <graphics type='vnc' port='5903'>, in that case there is only one port and keeping it as an optional attribute will make it easir to parse in/out

> XenD doesn't currently give us the port number in the SEXPR it returns > so we'll have to have code to explicitly insert a suitable <listen/> > tag manually, but its well worth it, avoiding need to hardcode port number > assumptions in application code. Hum, so you would like to automatically default it ? I still think <graphics type='vnc'/> should be an accepted input meaning "whatever is the default", but fine to add it back on any dump. Would that suit you ?

> Curently people access it with 'xm console <blah>', however, the actual > console is just a psuedo TTY, so if one knows the /dev/pts/<N> path > there is no need to use 'xm console' at all. Thus I think we could have > another TODO item, to add '<serial port="/dev/pts/3"/>' element to the > <devices> section of the XML. Okay, how do you extract the right N ?

On Tue, Jul 11, 2006 at 01:47:05PM +0100, Daniel P. Berrange wrote: > On Mon, Jul 10, 2006 at 04:27:55PM -0400, Daniel Veillard wrote: > > Hum, so you would like to automatically default it ? I still think > > <graphics type='vnc'/> should be an accepted input meaning "whatever is > > the default", but fine to add it back on any dump. Would that suit you ? > > I don't want to have any knowledge about 'defaults' in my app because I > know this will break in the future :-( You don't have to rely on defaults. Either you write the XML, then you put the port and you are fine, and if you read the XML then we garantee you get the port associated. So I don't see how my suggestion would break your requirement.

Daniel Veillard wrote: >On Mon, Jul 10, 2006 at 06:22:39AM -0400, Daniel Veillard wrote: > >>I have made changes to the XML conversion code to reflect this, I will >>commit >>whithin one hour or two. Attached is one example of the XML for HVM. >> > > Okay, I commited it, I also extended the page describing the XML format >to cover the new HVM domains. I was able to launch a domain and attach to >the vnc server so it seems to work for me at least in a minimal canonical >configuration. > Thanks for finishing this Daniel - sorry to have dumped it with no updated documentation, etc.

If I find some spare cycles this week would like to experiment with more exotic HVM configurations and improve support for cdrom, graphics, and anything else that may be deficient for HVM guests.