Xen devel - May 2007 - [PATCH] [xm] Fix vncdisplay for hvm guests

''vncdisplay=N'' in hvm config file is ignored when building
qemu-dm
arguments.

xm create or xm new -> xm start with hvm config file containing
vnc=1
vncdisplay=5

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.

This patch is against 3.1.0-testing but looks like problem exists in
unstable as well - even with recent changes to
tools/python/xen/xend/image.py when moving to qemu 0.9.0

Regards,
Jim





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

On 16/5/07 00:14, "Jim Fehlig" <jfehlig@novell.com> 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?

 -- Keir


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

Keir Fraser wrote:
>
> On 16/5/07 00:14, "Jim Fehlig" <jfehlig@novell.com> 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?
>   
Sorry, the wording was a little off in the original post.  Right, it 
does change vncunused to None - not vncdisplay.  But the patch was 
against 3.1.0 and the logic in parseDeviceModelArgs has changed between 
3.1.0 and current unstable.  In unstable it looks as though vncunused 
will not be default if it _and_ vncdisplay are not set - which is the 
case in 3.1.0.

Further, I did not verify the default behavior for pv domains if neither 
vncunused or vncdisplay is set :-/.  I will verify behavior of vncunused 
vs vncdisplay in unstable and repost patch if necessary.

Regards,
Jim


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

Keir Fraser wrote:
>
> On 16/5/07 00:14, "Jim Fehlig" <jfehlig@novell.com> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

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@novell.com> wrote:
> Keir Fraser wrote:
> >
> > On 16/5/07 00:14, "Jim Fehlig"
> <jfehlig@novell.com> 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@lists.xensource.com
> 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@lists.xensource.com
http://lists.xensource.com/xen-devel