Daniel,
My cfg has this: disk = [ 'tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w' ]
If I remove tapdisk, I get this error:
Error: need more than 1 value to unpack
Here's a more basic question: How do I check if my dom0 kernel has
blktap2? Is the presence of /dev/xen/blktap-2 (such as below) a
necessary indicator?
kaan-20:~# ls -l /dev/xen/blktap-2
crw------- 1 root root 253, 0 Jul 21 20:29 blktap0
crw------- 1 root root 10, 59 Jul 21 20:29 control
brw------- 1 root root 253, 0 Jul 21 20:29 tapdev0
The system with Xen 4.0.1-rc4 and 2.6.32.16 where VHD does not work
does not have any blktap in /dev/xen:
kaan-11:~# ls -l /dev/xen
crw-rw---- 1 root root 10, 54 Jul 22 01:57 evtchn
crw-rw---- 1 root root 10, 61 Jul 22 01:57 gntdev
Does this mean this dom0 kernel does not have the blktap driver?
The kernel config file for the system where VHD does not work contains
the following. Is this correct?
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_XEN_BLKDEV_TAP=y
CONFIG_XEN_BLKBACK_PAGEMAP=y
Thanks.
Dante
On Wed, Jul 21, 2010 at 7:02 PM, Daniel Stodden
<daniel.stodden@xxxxxxxxxx> wrote:
> 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