WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: Is: Xen 4.1.1, xend, HVM, 3.1 kernel; Was:Re: [Xen-devel] xen 4.2 un

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: 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
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Mon, 7 Nov 2011 16:26:19 -0500
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "xen-users@xxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxx>, Walter Robert Ditzler <ditwal001@xxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Delivery-date: Mon, 07 Nov 2011 13:27:44 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1111071646210.3519@kaball-desktop>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <alpine.DEB.2.00.1107181242270.12963@kaball-desktop> <!&!AAAAAAAAAAAYAAAAAAAAAOJK0u4CH31Kl5v1RPAzyrZCgQAAEAAAAE0cphS4zTVFjzXOjWNB7uwBAAAAAA==@xxxxxxxxx> <alpine.DEB.2.00.1107201238440.12963@kaball-desktop> <!&!AAAAAAAAAAAYAAAAAAAAAOJK0u4CH31Kl5v1RPAzyrZCgQAAEAAAAIMchHuG/6dIqtJ7GgPrsOEBAAAAAA==@xxxxxxxxx> <!&!AAAAAAAAAAAYAAAAAAAAAOJK0u4CH31Kl5v1RPAzyrZCgQAAEAAAAAKIP0TTIelKl7OMHw7/aSQBAAAAAA==@xxxxxxxxx> <alpine.DEB.2.00.1107251142270.12963@kaball-desktop> <!&!AAAAAAAAAAAYAAAAAAAAAOJK0u4CH31Kl5v1RPAzyrZCgQAAEAAAAICr5HMuz3FOpEbmgui+XxgBAAAAAA==@xxxxxxxxx> <alpine.DEB.2.00.1107251748160.12963@kaball-desktop> <20111103173837.GA21554@xxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1111071646210.3519@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
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