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