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