[PATCH] [xm] Fix vncdisplay for hvm guests

[PATCH] [xm] Fix vncdisplay for hvm guests

[Jim Fehlig]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

'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




[-- Attachment #2: xm-vncunused.patch --]
[-- Type: text/x-patch, Size: 1066 bytes --]

# HG changeset patch
# User Jim Fehlig <jfehlig@novell.com>
# Date 1179270277 21600
# Node ID b6a56d49c45c7ae82851e04e6322f18aa6e2c481
# Parent  aee991c7723a0c2fb88811c7c8b3cbdcb89f2bb9
'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.

Signed-off-by: Jim Fehlig <jfehlig@novell.com>

diff -r aee991c7723a -r b6a56d49c45c tools/python/xen/xm/create.py
--- a/tools/python/xen/xm/create.py	Wed May 09 16:34:47 2007 +0100
+++ b/tools/python/xen/xm/create.py	Tue May 15 17:04:37 2007 -0600
@@ -474,7 +474,7 @@ gopts.var('vnclisten', val='',
           use="""Address for VNC server to listen on.""")
 
 gopts.var('vncunused', val='',
-          fn=set_bool, default=1,
+          fn=set_bool, default=None,
           use="""Try to find an unused port for the VNC server.
           Only valid when vnc=1.""")
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH] [xm] Fix vncdisplay for hvm guests

[Keir Fraser]

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

Re: [PATCH] [xm] Fix vncdisplay for hvm guests

[Jim Fehlig]

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

Re: [PATCH] [xm] Fix vncdisplay for hvm guests

[Jim Fehlig]

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

Re: [PATCH] [xm] Fix vncdisplay for hvm guests

[jd]

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