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-devel

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

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: 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: Thu, 3 Nov 2011 13:38:37 -0400
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "xen-users@xxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxx>, Walter Robert Ditzler <ditwal001@xxxxxxxxx>
Delivery-date: Thu, 03 Nov 2011 10:40:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1107251748160.12963@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: <!&!AAAAAAAAAAAYAAAAAAAAAOJK0u4CH31Kl5v1RPAzyrZCgQAAEAAAAI32k8eIVQhMgLM5AGCb128BAAAAAA==@xxxxxxxxx> <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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
.. 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"

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).

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.

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.

Any suggestions, thoughts, ideas? It sounds like the xen-blkfront
support for CD-ROMs is not working right.

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]

Attachment: good.log
Description: Text document

Attachment: good.xenstore.ls
Description: Text document

Attachment: fail.xenstore.ls
Description: Text document

Attachment: fail.log
Description: Text document

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