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