From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Is: Xen 4.1.1, xend, HVM, 3.1 kernel; Was:Re: xen 4.2 unstable; HVM; 2.6.39.3; HD/Network card error Date: Thu, 10 Nov 2011 12:14:35 -0500 Message-ID: <20111110171435.GA6616@phenom.dumpdata.com> References: <20111103173837.GA21554@phenom.dumpdata.com> <20111107212619.GA24889@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" , Ian Campbell , Walter Robert Ditzler , "xen-users@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Tue, Nov 08, 2011 at 11:09:11AM +0000, Stefano Stabellini wrote: > On Mon, 7 Nov 2011, Konrad Rzeszutek Wilk wrote: > > > > XENBUS: Timeout connecting to device: device/vkbd/0 (local state 3, remote state 1) > > > > [which seems odds as the vkb from VNC looks to be working] > > > > > > Thanks for pointing this out: I enabled vkbd in upstream qemu but I > > > forgot to do the same in qemu-xen so as a result you would get failures > > > of this kind. > > > > Oh boy. Seems that there are a couple of issues here. It might be that the > > timeout I had experienced was _only_ related to this and the other were red-herrings. > > > > You might want to make sure M A Young and Stefan Bader are CC-ed on your Xen 4.1.1 > > patch so they can pull it in. > > Actually I have just realized that the vkbd feature couldn't possibly > have been backported to xen 4.1.1. In fact I didn't even add any vkbd > devices for HVM guests in XL in xen-unstable yet. > Of course this was to avoid situations like this one. > > So my guess is that when you use "vfb" in an HVM guest config file > you cause xend to create a vkbd device that is without backend. > A PV on HVM guest would try to connect to it but it wouldn't get any > response back so it would timeout. > > The solution to this problem is to avoid using vfb in the config file. I > strongly hope that the config file you showed us before is not generated > by libvirt somehow. If it is we need to file a bug against libvirt. And sure enough, if I modify the xm file libvirt creates to be: [root@phenom ~]# diff /tmp/b.autogenerated /tmp/b 8c8 < boot = "c" --- > boot = "dc" 20c20,21 < vfb = [ "type=vnc,vncunused=1" ] --- > #vfb = [ "type=vnc,vncunused=1,keymap=en-us" ] > vnc=1 It bootes right up. Is this a new behavior with xend? I would think not - it just seems that the 'vfb' for HVM guests worked in the past - as Windows boots just fine? And I think the accelerated drivers for Windows take advantage of that?