[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] [xm] Fix vncdisplay for hvm guests
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 --- Jim Fehlig <jfehlig@xxxxxxxxxx> wrote: > 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 > > 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 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel > ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |