On Wed, 2010-07-21 at 20:11 -0400, Dante Cinco wrote:
> Daniel,
>
> I'm using 2.6.32 pv-ops dom0 kernel. How do I check if it's using
> blktap2 instead of blktap1? If I look at /dev and /dev/xen, here's
> what I see?
With pvops the formula is pretty simple.
Blktap1 doesn't exist, you have to run blktap2.
> kaan-11:/boot# ls -l /dev/blktap-control
> crw-rw---- 1 root root 10, 60 Jul 21 16:45 /dev/blktap-control
> kaan-11:/boot# ls -l /dev/xen/
> total 0
> crw-rw---- 1 root root 10, 54 Jul 21 16:45 evtchn
> crw-rw---- 1 root root 10, 61 Jul 21 16:45 gntdev
>
> Here's part of my "xm info"
>
> release : 2.6.32
> version : #1 SMP Tue Jul 20 11:33:27 PDT 2010
> machine : x86_64
> xen_major : 4
> xen_minor : 1
> xen_extra : -unstable
> xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> hvm-3.0-x86_32p hvm-3.0-x86_64
>
> Some additional info: When I tried bringing up an HVM win2k8 from VHD,
> I see the following in qemu-dm-svm.log
>
> Using xvda for guest's hda
> Strip off blktap sub-type prefix to vhd:/mnt/win2008sp2.vhd (drv 'tapdisk')
Uhm. Looks like common image locator madness.
I think this stuff has seen changes again.
So vhd:/mnt/win2008.vhd is ends up as the path, and tapdisk the driver?\
That won't work.
What does you cfg look like?
Guessing, do you have a :tapdisk: substring in there? I used to have
one.
Could you try stripping it, down to "tap:vhd:/mnt/win2008sp2.vhd"?
Thanks,
Daniel
> qemu: type (image format) 'tapdisk' unknown for vbd
> '/local/domain/0/backend/tap/1/51712/type' or image
> 'vhd:/mnt/win2008sp2.vhd'
>
> Does this look like it's related to blktap1 vs blktap2?
>
> Thanks.
>
> Dante
>
>
> On Mon, Jul 19, 2010 at 7:30 PM, Daniel Stodden
> <daniel.stodden@xxxxxxxxxx> wrote:
> > On Mon, 2010-07-19 at 17:27 -0400, Dante Cinco wrote:
> >> I'm getting this message (subject line) in daemon.log every time I
> >> start or restart xend. I'm not sure if this is related to the fact
> >> that I cannot boot up my Windows domU from a VHD file. The Windows
> >> domU was working fine with Xen 4.0.0 (with 2.6.32.14 dom0 kernel).
> >> When I upgraded to Xen 4.0.1-rc4 (with 2.6.32.16 dom0 kernel), I can
> >> no long boot the Windows domU from VHD. The VNC console for the
> >> Windows HVM has this message:
> >>
> >> Booting from Hard Disk ...
> >> Boot from Hard Disk failed; could not read the boot disk
> >>
> >> No bootable device.
> >> Powering off in 30 seconds.
> >>
> >> Here's the disk setting in my Windows domU config file: disk =
> >> ['tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w']
> >>
> >> Here's the other BLKTAPCTRL messages in daemon.log:
> >>
> >> BLKTAPCTRL[2444]: blktapctrl.c:790: blktapctrl: v1.0.0
> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [raw image (aio)]
> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [raw image (sync)]
> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [vmware image (vmdk)]
> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [ramdisk image (ram)]
> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [qcow disk (qcow)]
> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [qcow2 disk (qcow2)]
> >> BLKTAPCTRL[2444]: blktapctrl_linux.c:86: blktap0 open failed
> >> BLKTAPCTRL[2444]: blktapctrl.c:859: couldn't open blktap interface
> >> BLKTAPCTRL[2444]: blktapctrl.c:922: Unable to start blktapctrl
> >
> > Let's kill the beast.
> >
> > Blktapctrl is a residual from blktap1 nobody ever bothered to reliably
> > prevent from trying to start on pvops, unfortunately.
> >
> > I had a bit of an aha-experience today trying to repro your issue,
> > before I figured out that you're just running 2.6.3x. It seems to be the
> > case that the chrdev majors assignment, both dynamically allocated by
> > blktap1 and -2, tend to be identical when moving from a xen kernel with
> > blktap1 enabled, to pvops, which only has blktap2.
> >
> > Which means if somebody starts blktapctrl, it may happily try to open
> > the kernel link of the first blktap2 (/dev/xen/blktap-2/blktap0) device
> > as the control node for blktap1 (/dev/xen/blktap0).
> >
> > In really unfortunate cases, that code around blktapctrl.c:859 above
> > will suceed, even managing to provoke a stacktrace. Normally wouldn't
> > happen, in this case I happened to have some somewhat wedged trainwreck
> > minor number 0 set up, which wasn't aquired by a real tapdisk already.
> >
> > Should drop blktapctrl from xend start altogether, to avoid confusion in
> > in both software and users.
> >
> > Or maybe at least do an environment check and fail with a more friendly
> > last word on blktap1 matters.
> >
> > That, of course, nowhere explains your w2k8 problem, right?
> >
> > Daniel
> >
> >
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home