|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
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.
> 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:
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 :)
> 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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |