[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


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

            (vncunused 1)
            (vncdisplay 5)
            (uuid 499604ae-f8c5-81a6-3600-9444322e2bfc)

Using XenAPI c-bindings I get

            (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 -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


results in /var/lib/xend/domains/<uuid>/config.sxp

            (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".  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 :-).

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.