Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed

[Dante Cinco <dantecinco@xxxxxxxxx>]

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?

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