Re: [Xen-devel] [PATCH] [xm] Fix vncdisplay for hvm guests

[jd <jdsw2002@xxxxxxxxx>]

I am running in to the following problem. In versions
prev to xen 3.1, when vncunused=0, xm create used to
use the domid as display number. 

This seems to be broken in 3.1. Do we have a patch for
this ? 


Thanks
/Jd


--- Jim Fehlig <jfehlig@xxxxxxxxxx> wrote:

> Keir Fraser wrote:
> >
> > On 16/5/07 00:14, "Jim Fehlig"
> <jfehlig@xxxxxxxxxx> wrote:
> >
> >   
> >> results in '-vncunused' being passed to qemu-dm. 
> There are several
> >> approaches
> >> for a fix - this patch defaults vncdisplay to
> None in xm options.  It
> >> currently defaults to 1 and is always included in
> the image config
> >> created by configure_hvm() in
> tools/python/xen/xm/create.py.  In xend
> >> (tools/python/xen/xend/image.py -
> parseDeviceModelArgs), vncunused takes
> >> precedence over vncdisplay.
> >>     
> >
> > Looks like it changes vncunused default rather
> than vncdisplay. Wouldn't the
> > preferred default be to keep vncunused=1?
> >   
> 
> After looking at this closer I thing the original
> patch applies. 
> Setting a default in xm tool doesn't seem right. 
> E.g. with hvm config
> 
> vnc=1
> vncdisplay=5
> 
> I get two different versions of xend's internal
> config for vfb device -
> depending on client I use to define the domain. 
> Using 'xm new config', 
> /var/lib/xend/domains/<uuid>/config.sxp has
> 
>         (vfb
>             (vncunused 1)
>             (vncdisplay 5)
>             (uuid
> 499604ae-f8c5-81a6-3600-9444322e2bfc)
>         )
> 
> Using XenAPI c-bindings I get
> 
>        (vfb
>             (type vnc)
>             (protocol rfb)
>             (uuid
> 66c18754-3207-5e45-31db-28df050bff4f)
>             (vndisplay 5)
>        )
> 
> So if we want a default it should be in xend for
> consistency.
> 
> Now as for default I found some interesting behavior
> using vncdisplay on
> c/s 15080.  For hvm domains created with xm
> (containing above config),
> the following qemu-dm cmdline is assembled
> 
> -vnc 127.0.0.1:5 -vncunused
> 
> If another domain is using 5905 the new domain will
> bind to 5906 due to
> the -vncunsued also being present on cmdline,
> otherwise it will bind to
> 5905 as expected.
> 
> The story is a little different for pv domains.  A
> pv domain 'xm new'ed'
> with config
> 
> vfb=["type=vnc,vncdisplay=5"]
> 
> results in /var/lib/xend/domains/<uuid>/config.sxp
> 
>         (vfb
>             (xauthority /root/.Xauthority)
>             (vncdisplay 5)
>             (type vnc)
>             (display localhost:10.0)
>             (uuid
> 5741017b-f0fc-0447-c613-aa558f6e582c)
>         )
> 
> Notice there is no vncunused=1 in this config as
> there was in the
> internal hvm config.  xen-vncfb is invoked with
> "--vncport 5905 --listen
> 127.0.0.1".  If another domain is already using
> 5905, too bad -
> xen-vncfb won't be able to bind and no graphics.
> 
> Which of these behaviors is preferred default?  I
> can put together a
> patch that provides consistency between hvm and pv
> domains once default
> is chosen.  Personally I'm torn.  If user specifies
> a port she should be
> able to reach the display at that port.  On the
> other hand, having a
> functional vm in the event of a conflict is nice too
> :-).
>  
> Regards,
> Jim
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 



       
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the 
tools to get online.
http://smallbusiness.yahoo.com/webhosting 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel