On Mon, Jul 10, 2006 at 04:27:55PM -0400, Daniel Veillard wrote: > 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 I really don't think we should have it optional, because this will force every application using libvirt, to hardcode the assumption 'VNC port ==5900 + domain id' If this changes in the future then all these apps would break - libvirt should be providing a reliable API for apps, so we should move the assumption inside libvirt in the code which generates the '<graphics ...>' block, isolating the application from any change in this assumption. > > 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 ? I don't want to have any knowledge about 'defaults' in my app because I know this will break in the future :-( > > 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 ? That's what I'm not too clear on yet - I hoped it was in the information returned byu XenD SEXPR, but it doesn't look like it is. Instead it looks like it is in the XenStore tree somewhere. This isn't an urgent feature request - I just wanted to put it on the TODO list for when someone had time to look at it. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|