From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: [PATCH] [xm] Fix vncdisplay for hvm guests Date: Thu, 31 May 2007 16:26:38 -0600 Message-ID: <465F4B9E.7020302@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: References: C27B6060.F751%keir@xensource.com List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > > On 16/5/07 00:14, "Jim Fehlig" 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//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//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