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

# HG changeset patch
# User Jim Fehlig <[email protected]>
# 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.

diff -r aee991c7723a -r b6a56d49c45c tools/python/xen/xm/create.py
@@ -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.""")
 

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Looks like it changes vncunused default rather than vncdisplay. Wouldn't the preferred default be to keep vncunused=1?

-- Keir

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

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

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

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