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

[Jim Fehlig <jfehlig@novell.com>]

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