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

Re: [Libvir] Updated patch for hvm guests



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 ?

> On a similar theme, Xen provides a serial console for each guest domain.
> 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 ?

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/


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