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

[Stefano Stabellini <stefano.stabellini@eu.citrix.com>]

On Thu, 10 Nov 2011, Konrad Rzeszutek Wilk wrote:
> 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?
> 

Have you noticed that the vnc parameters inside vfb look very similar to
the normal vnc parameters outside vfb?
Xend happens to store both set of vnc parameters the same way, using
the same internal variables. That is why it happened to work in the
past. It was working by pure chance, I have no idea what changed.
Windows doesn't take advance of vfb or vkbd at all.