This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] [xm] Fix vncdisplay for hvm guests
From: Jim Fehlig <jfehlig@xxxxxxxxxx>
Date: Thu, 31 May 2007 16:26:38 -0600
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 31 May 2007 15:25:01 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: C27B6060.F751%keir@xxxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20060911)
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

<Prev in Thread] Current Thread [Next in Thread>