Re: Is: Xen 4.1.1, xend, HVM, 3.1 kernel; Was:Re: [Xen-devel] xen 4.2 unstable; HVM; 2.6.39.3; HD/Network card error

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Mon, Nov 07, 2011 at 05:15:08PM +0000, Stefano Stabellini wrote:
> On Thu, 3 Nov 2011, Konrad Rzeszutek Wilk wrote:
> > .. snip..
> > > I need the output of the guest kernel stuck during boot in order to
> > > understand the problem. It shouldn't be difficult to get if you enable
> > > logging over the serial in the guest kernel.
> > 
> > Hey Stefano,
> > 
> > Looks like I can reproduce this as well. This is using Fedora Core 16,
> > and with the Fedora Core 16 HVM install.
> > 
> > The interesting thing is that while 'xl' works, the 'xm' (which is what
> > virt-install and all of that uses), does not. And I think it is related
> > just to how we handle the hdc:cdrom,r case. Read below.
> > 
> > Just to make sure it is not SELinux related, I've called 'setenforce=0'.
> > The guest config is easy:
> > 
> > kernel = "/usr/lib/xen/boot/hvmloader"
> > builder='hvm'
> > memory=1024
> > #maxmem=1024
> > maxvcpus = 2
> > serial='pty'
> > vcpus = 2
> > disk = [ 'file:/mnt/iso/Fedora-16-x86_64-DVD.iso,hdc:cdrom,r', 
> > 'phy:/dev/vg_guest/f16_64,hda,w']
> > boot="dn"
> > vif = [ 'type=ioemu,model=e1000,mac=00:0F:4B:00:00:71, bridge=switch' ]
> > vfb = [ 'vnc=1, vnclisten=0.0.0.0 ,vncunused=1']
> > vnclisten="0.0.0.0"
> 
> BTW the vfb setting is wrong for an hvm domain.
> The correct way of configuring vnc is the following:
> 
> vnc=1
> vnclisten="0.0.0.0"
> vncunused=1
> 
> it just happened to work with xm but it was never supposed to.
> 
> 
> > Attached are the serial logs from good and bad, and as well the xenstore-ls 
> > from ..
> > you guessed it - good and bad. The interesting part is:
> > 
> > (this works)
> >    backend = ""
> >     qdisk = ""
> >      24 = ""
> >       5632 = ""
> >        frontend = "/local/domain/24/device/vbd/5632"
> >        params = "aio:/mnt/iso/Fedora-16-x86_64-DVD.iso"
> >        frontend-id = "24"
> >        online = "1"
> >        removable = "1"
> >        bootable = "1"
> >        state = "6"
> >        dev = "hdc"
> >        type = "tap"
> >        mode = "r"
> >        feature-barrier = "1"
> >        info = "4"
> >        sector-size = "512"
> >        sectors = "7337984"
> >        hotplug-status = "connected"
> > 
> > (this fails)
> >     vbd = ""
> >      10 = ""
> >       768 = ""
> >        domain = "test"
> >        frontend = "/local/domain/10/device/vbd/768"
> >        uuid = "ee7800e1-fae0-dfe2-9345-96fda7d7851f"
> >        bootable = "1"
> >        dev = "hda"
> >        state = "4"
> >        params = "/var/lib/xen/images/test.img"
> >        mode = "w"
> >        online = "1"
> >        frontend-id = "10"
> >        type = "file"
> >        node = "/dev/loop0"
> >        physical-device = "7:0"
> >        hotplug-status = "connected"
> >        feature-flush-cache = "1"
> >        sectors = "41943040"
> >        info = "0"
> >        sector-size = "512"
> > 
> > Which would imply that for the CD-ROM when we use 'xm' it is setup
> > as a PV disk (and we try to load the driver for it but fail)
> > while for the 'xl' it is as a QEMU qdisk (so emulated).
> 
> There is always a PV disk associated with CD-ROMs even though the guest
> is not going to use it. Linux blkfront would explicitly avoid to setup
> a PV interface for CD-ROMs.
> 
> 
> > First I *thought* it was that blkback is failing to do its
> > stuff when using /dev/loop0, but after doing this:
> > 
> > disk = [ 'phy:/dev/loop0,hda,w']
> > 
> > I still got it to boot.
> 
> Let me get this straight:
> 
> disk = [ 'phy:/dev/loop0,hda,w'] works
> disk = [ 'file:/mnt/iso/Fedora-16-x86_64-DVD.iso,hdc:cdrom,r' ] does NOT work
> 
> that is very strange considering that if I recall correctly xm/xend
> would setup a loop device when the disk config is 'file:', so the two
> should be equivalent.

<nods> It might have been me getting tired by this point. The timeout seems
to be .. well, I think that the 'file' works as well - it is just that the
timeout takes forever, and then there might be another timeout before the
anaconda windows pops up. So it could be that in the normal case it works - it
just that you have to be patient.

> 
> 
> > So it really seams that xen-blkback (or xen-blkfront) can't deal
> > with CD-ROMs very well. So I did it:
> > 
> > disk = [ 'phy:/dev/loop1,hdc:cdrom,r', 'phy:/dev/loop0,hda,w']
> > [root@phenom ~]# losetup -a
> > /dev/loop0: [0005]:1353 (/dev/mapper/vg_guest-f16_64)
> > /dev/loop1: [002a]:45613764 (/mnt/iso/Fedora-16-x86_64-DVD.iso)
> > 
> > Which is pretty much exactly what the 'file:/'.. would, and I got this
> >  vbd = ""
> >      34 = ""
> >       5632 = ""
> >        domain = "hvm.xm"
> >        frontend = "/local/domain/34/device/vbd/5632"
> >        uuid = "e30da140-7ef9-9c1f-8e45-1e5e63f798e0"
> >        bootable = "1"
> >        dev = "hdc"
> >        state = "6"
> >        params = "/dev/loop1"
> >        mode = "r"
> >        online = "1"
> >        frontend-id = "34"
> >        type = "phy"
> >        physical-device = "7:1"
> >        hotplug-status = "connected"
> > 
> > And after waiting for the timeout.. (can't load and then some more, the 
> > installer
> > came up and I could 'Test' the ISO image. The CD-ROM image was
> > emulated, which sounds right - the vbd/34/5632 just did not work out
> > and it timed out, but it still had the QEMU disk (/dev/sr0) and it used
> > that instead.
> 
> What is the guest kernel? As I said before blkfront should avoid loading
> a PV disk for CD-ROMs, see:

F16 DomU. So 3.1

> 
> commit b98a409b80ac510c95b4f1bafdef28edaeabd3e7
> Author: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> Date:   Thu Jul 29 14:53:16 2010 +0100
> 
>     blkfront: do not create a PV cdrom device if xen_hvm_guest
>     
>     It is not possible to unplug emulated cdrom devices, and PV cdroms don't
>     handle media insert, eject and stream, so we are better off disabling PV
>     cdroms when running as a Xen HVM guest.
>     
>     Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> 
> 
> > Any suggestions, thoughts, ideas? It sounds like the xen-blkfront
> > support for CD-ROMs is not working right.
> 
> it shouldn't work at all :)

HA!
> 
> 
> > Or maybe there are multiple issues and the error from xen-blkfront is
> > red heering. I seem to see other things too:
> > 
> > vif vif-0: 2 parsing device/vif/0/mac
> > 
> > [Ugh, looks like MAC is 00:00:00:0.. in the guest], but it probably got the 
> > right
> > MAC on the emulated device]
> > 
> > 
> > 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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel