Dante Cinco
2010-Jul-19 21:27 UTC
[Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed
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 I''ve also attached the output from /var/log/xen/xend.log when attempting to bringup the Windows domU. When the Windows domU VHD file was booting under Xen 4.0.0, I would get these messages in syslog: tapdisk2[4833]: Created /dev/xen/blktap-2/control device tapdisk2[4833]: Created /dev/xen/blktap-2/blktap0 device tapdisk2[4833]: Created /dev/xen/blktap-2/tapdev0 device tapdisk2[4833]: new interface: ring: 253, device: 253, minor: 0 tapdisk2[4833]: I/O queue driver: lio tapdisk2[4833]: /mnt/win2008sp2.vhd version: tap 0x00010003, b: 12800, a: 6903, f: 6087, n: 28330016 tapdisk2[4833]: opened image /mnt/win2008sp2.vhd (1 users, state: 0x00000001, type: 4) tapdisk2[4833]: VBD CHAIN: tapdisk2[4833]: /mnt/win2008sp2.vhd: 4 I appreciate any insight or recommendation. Thanks. - Dante _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel Stodden
2010-Jul-20 02:30 UTC
Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed
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 blktapctrlLet''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@lists.xensource.com http://lists.xensource.com/xen-devel
Dante Cinco
2010-Jul-22 00:11 UTC
Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed
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@citrix.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel Stodden
2010-Jul-22 02:02 UTC
Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed
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@citrix.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
Dante Cinco
2010-Jul-22 16:59 UTC
Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed
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@citrix.com> 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@citrix.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel Stodden
2010-Jul-22 20:11 UTC
Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed
On Thu, 2010-07-22 at 12:59 -0400, Dante Cinco wrote:> 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 tapdev0No. These will be generated by udev in the future, in which case this would be indication, too. But right now the toolstack mknods them if they don''t exist. You should see a /sys/class/blktap2 directory and ''tapdev'' and ''blktap2'' device entries in /proc/devices.> 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=yYep. Problem is I''m not very good with xen-stable, as you might have already guessed. There''s a lot of ''tap'' vs. ''tap2'' stuff in the python sources. How about tap2:tapdisk:...? :> Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Dante Cinco
2010-Jul-22 20:46 UTC
Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed
Daniel, You got it right with tap2 (instead of tap). That''s the key. So with Xen 4.0.0 and 2.6.32.14 it''s: disk = [ ''tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w'' ] and with Xen 4.0.1-rc4 and 2.6.32.16 it''s: disk = [ ''tap2:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w'' ] Very subtle change but makes a world of difference. My Windows 2008 domU is now booting from a VHD file. Here''s what I see in /sys/devices/virtual/blktap2/blktap0/debug: vhd:/mnt/win2008sp2.vhd (253:0), refcnt: 0, dev_inuse: 0x0000001e capacity: 0x3200000, sector size: 0x200, device users: 2 pending requests: 0 And in /var/log/xen/ qemu-dm-svm.log: Using xvda for guest''s hda Using file /dev/xen/blktap-2/tapdev0 in read-write mode Thanks a lot for your help. Dante On Thu, Jul 22, 2010 at 1:11 PM, Daniel Stodden <daniel.stodden@citrix.com> wrote:> On Thu, 2010-07-22 at 12:59 -0400, Dante Cinco wrote: >> 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 > > No. These will be generated by udev in the future, in which case this > would be indication, too. But right now the toolstack mknods them if > they don''t exist. > > You should see a /sys/class/blktap2 directory and ''tapdev'' and ''blktap2'' > device entries in /proc/devices. > >> 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 > > Yep. > > Problem is I''m not very good with xen-stable, as you might have already > guessed. > > There''s a lot of ''tap'' vs. ''tap2'' stuff in the python sources. > > How about tap2:tapdisk:...? > > :> > > Daniel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2010-Jul-22 21:10 UTC
Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed
On Thu, Jul 22, 2010 at 01:46:35PM -0700, Dante Cinco wrote:> Daniel, > > You got it right with tap2 (instead of tap). That''s the key. > > So with Xen 4.0.0 and 2.6.32.14 it''s: disk = [ > ''tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w'' ] > > and with Xen 4.0.1-rc4 and 2.6.32.16 it''s: disk = [ > ''tap2:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w'' ] > > Very subtle change but makes a world of difference. My Windows 2008 > domU is now booting from a VHD file. >Uhm.. is this change intentional? -- Pasi> Here''s what I see in /sys/devices/virtual/blktap2/blktap0/debug: > vhd:/mnt/win2008sp2.vhd (253:0), refcnt: 0, dev_inuse: 0x0000001e > capacity: 0x3200000, sector size: 0x200, device users: 2 > pending requests: 0 > > And in /var/log/xen/ qemu-dm-svm.log: > Using xvda for guest''s hda > Using file /dev/xen/blktap-2/tapdev0 in read-write mode > > Thanks a lot for your help. > > Dante > > > On Thu, Jul 22, 2010 at 1:11 PM, Daniel Stodden > <daniel.stodden@citrix.com> wrote: > > On Thu, 2010-07-22 at 12:59 -0400, Dante Cinco wrote: > >> 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 > > > > No. These will be generated by udev in the future, in which case this > > would be indication, too. But right now the toolstack mknods them if > > they don''t exist. > > > > You should see a /sys/class/blktap2 directory and ''tapdev'' and ''blktap2'' > > device entries in /proc/devices. > > > >> 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 > > > > Yep. > > > > Problem is I''m not very good with xen-stable, as you might have already > > guessed. > > > > There''s a lot of ''tap'' vs. ''tap2'' stuff in the python sources. > > > > How about tap2:tapdisk:...? > > > > :> > > > > Daniel > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-Jul-23 07:07 UTC
Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed
On 22/07/2010 22:10, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:>> You got it right with tap2 (instead of tap). That''s the key. >> >> So with Xen 4.0.0 and 2.6.32.14 it''s: disk = [ >> ''tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w'' ] >> >> and with Xen 4.0.1-rc4 and 2.6.32.16 it''s: disk = [ >> ''tap2:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w'' ] >> >> Very subtle change but makes a world of difference. My Windows 2008 >> domU is now booting from a VHD file. >> > > Uhm.. is this change intentional?xen-unstable:21338 and xen-4.0-testing:21140. So yes. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel Stodden
2010-Jul-25 09:27 UTC
Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed
On Fri, 2010-07-23 at 03:07 -0400, Keir Fraser wrote:> On 22/07/2010 22:10, "Pasi Kärkkäinen" <pasik@iki.fi> wrote: > > >> You got it right with tap2 (instead of tap). That''s the key. > >> > >> So with Xen 4.0.0 and 2.6.32.14 it''s: disk = [ > >> ''tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w'' ] > >> > >> and with Xen 4.0.1-rc4 and 2.6.32.16 it''s: disk = [ > >> ''tap2:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w'' ] > >> > >> Very subtle change but makes a world of difference. My Windows 2008 > >> domU is now booting from a VHD file. > >> > > > > Uhm.. is this change intentional? > > xen-unstable:21338 and xen-4.0-testing:21140. So yes.That sounds like a lot of fallout on xen-users. Especially for people who just want their guests to boot. Maybe the whole notation should have rather been some _optional_ blktap = {1|2} cfg key, only for those who actually care? [As much as the whole disk notation should probably always just have been <type>:<path>, with a separately configurable <type> -> <backend> mapping for people who want to override backend choices (such file->loopback vs file->aio).] I guess the latter cannot be fixed. But maybe the former? Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-Jul-25 09:42 UTC
Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed
On 25/07/2010 10:27, "Daniel Stodden" <daniel.stodden@citrix.com> wrote:>>> Uhm.. is this change intentional? >> >> xen-unstable:21338 and xen-4.0-testing:21140. So yes. > > That sounds like a lot of fallout on xen-users. > Especially for people who just want their guests to boot. > > Maybe the whole notation should have rather been some _optional_ blktap > = {1|2} cfg key, only for those who actually care? > > [As much as the whole disk notation should probably always just have > been <type>:<path>, with a separately configurable <type> -> <backend> > mapping for people who want to override backend choices (such > file->loopback vs file->aio).] > > I guess the latter cannot be fixed. But maybe the former?I don''t personally have an opinion on it. I''m pretty sure Jim was having other problems if this distinction wasn''t made in the config file. But perhaps it was rash to backport it to 4.0-testing, all the same. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2010-Jul-26 10:36 UTC
Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed
On Sun, 2010-07-25 at 10:27 +0100, Daniel Stodden wrote:> On Fri, 2010-07-23 at 03:07 -0400, Keir Fraser wrote: > > On 22/07/2010 22:10, "Pasi Kärkkäinen" <pasik@iki.fi> wrote: > > > > >> You got it right with tap2 (instead of tap). That''s the key. > > >> > > >> So with Xen 4.0.0 and 2.6.32.14 it''s: disk = [ > > >> ''tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w'' ] > > >> > > >> and with Xen 4.0.1-rc4 and 2.6.32.16 it''s: disk = [ > > >> ''tap2:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w'' ] > > >> > > >> Very subtle change but makes a world of difference. My Windows 2008 > > >> domU is now booting from a VHD file. > > >> > > > > > > Uhm.. is this change intentional? > > > > xen-unstable:21338 and xen-4.0-testing:21140. So yes. > > That sounds like a lot of fallout on xen-users. > Especially for people who just want their guests to boot. > > Maybe the whole notation should have rather been some _optional_ blktap > = {1|2} cfg key, only for those who actually care?FWIW, I completely agree with this.> > [As much as the whole disk notation should probably always just have > been <type>:<path>, with a separately configurable <type> -> <backend> > mapping for people who want to override backend choices (such > file->loopback vs file->aio).] > > I guess the latter cannot be fixed. But maybe the former? > > Daniel > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2010-Jul-27 06:21 UTC
Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed, tap: vs. tap2:
On Mon, Jul 26, 2010 at 11:36:24AM +0100, Ian Campbell wrote:> On Sun, 2010-07-25 at 10:27 +0100, Daniel Stodden wrote: > > On Fri, 2010-07-23 at 03:07 -0400, Keir Fraser wrote: > > > On 22/07/2010 22:10, "Pasi Kärkkäinen" <pasik@iki.fi> wrote: > > > > > > >> You got it right with tap2 (instead of tap). That''s the key. > > > >> > > > >> So with Xen 4.0.0 and 2.6.32.14 it''s: disk = [ > > > >> ''tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w'' ] > > > >> > > > >> and with Xen 4.0.1-rc4 and 2.6.32.16 it''s: disk = [ > > > >> ''tap2:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w'' ] > > > >> > > > >> Very subtle change but makes a world of difference. My Windows 2008 > > > >> domU is now booting from a VHD file. > > > >> > > > > > > > > Uhm.. is this change intentional? > > > > > > xen-unstable:21338 and xen-4.0-testing:21140. So yes. > > > > That sounds like a lot of fallout on xen-users. > > Especially for people who just want their guests to boot. > > > > Maybe the whole notation should have rather been some _optional_ blktap > > = {1|2} cfg key, only for those who actually care? > > FWIW, I completely agree with this. >Yeah, especially when blktap2 is the only available on in pvops dom0 kernels.. All the users have tap:something in their cfgfiles currently.. -- Pasi> > > > [As much as the whole disk notation should probably always just have > > been <type>:<path>, with a separately configurable <type> -> <backend> > > mapping for people who want to override backend choices (such > > file->loopback vs file->aio).] > > > > I guess the latter cannot be fixed. But maybe the former? > > > > Daniel > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-Jul-27 06:48 UTC
Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed, tap: vs. tap2:
On 27/07/2010 07:21, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:>>> That sounds like a lot of fallout on xen-users. >>> Especially for people who just want their guests to boot. >>> >>> Maybe the whole notation should have rather been some _optional_ blktap >>> = {1|2} cfg key, only for those who actually care? >> >> FWIW, I completely agree with this. >> > > Yeah, especially when blktap2 is the only available on in pvops dom0 kernels.. > All the users have tap:something in their cfgfiles currently..Well the patch to make the distinction is currently in xen-unstable and xen-4.0. Should it be reverted from one or both? Actually it is up to IanJ or Stefano to decide on that now. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2010-Aug-02 12:11 UTC
Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed, tap: vs. tap2:
On Tue, Jul 27, 2010 at 07:48:39AM +0100, Keir Fraser wrote:> On 27/07/2010 07:21, "Pasi Kärkkäinen" <pasik@iki.fi> wrote: > > >>> That sounds like a lot of fallout on xen-users. > >>> Especially for people who just want their guests to boot. > >>> > >>> Maybe the whole notation should have rather been some _optional_ blktap > >>> = {1|2} cfg key, only for those who actually care? > >> > >> FWIW, I completely agree with this. > >> > > > > Yeah, especially when blktap2 is the only available on in pvops dom0 kernels.. > > All the users have tap:something in their cfgfiles currently.. > > Well the patch to make the distinction is currently in xen-unstable and > xen-4.0. Should it be reverted from one or both? Actually it is up to IanJ > or Stefano to decide on that now. >Now when Xen 4.0.1-rc5 is out I guess this should be decided shortly.. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Aug 02, 2010 at 03:11:52PM +0300, Pasi Kärkkäinen wrote:> On Tue, Jul 27, 2010 at 07:48:39AM +0100, Keir Fraser wrote: > > On 27/07/2010 07:21, "Pasi Kärkkäinen" <pasik@iki.fi> wrote: > > > > >>> That sounds like a lot of fallout on xen-users. > > >>> Especially for people who just want their guests to boot. > > >>> > > >>> Maybe the whole notation should have rather been some _optional_ blktap > > >>> = {1|2} cfg key, only for those who actually care? > > >> > > >> FWIW, I completely agree with this. > > >> > > > > > > Yeah, especially when blktap2 is the only available on in pvops dom0 kernels.. > > > All the users have tap:something in their cfgfiles currently.. > > > > Well the patch to make the distinction is currently in xen-unstable and > > xen-4.0. Should it be reverted from one or both? Actually it is up to IanJ > > or Stefano to decide on that now. > > > > Now when Xen 4.0.1-rc5 is out I guess this should be decided shortly.. >Ping? -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2010-Aug-13 15:18 UTC
Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed, tap: vs. tap2:
Pasi Kärkkäinen writes ("Re: [Xen-devel] BLKTAPCTRL[2375]:
blktapctrl_linux.c:86: blktap0 open failed, tap: vs.
tap2:"):> On Tue, Jul 27, 2010 at 07:48:39AM +0100, Keir Fraser wrote:
> > Well the patch to make the distinction is currently in xen-unstable
and
> > xen-4.0. Should it be reverted from one or both? Actually it is up to
IanJ
> > or Stefano to decide on that now.
>
> Now when Xen 4.0.1-rc5 is out I guess this should be decided shortly..
I think the behaviour should be that you write "tap:" in your file and
get either blktap or blktap2 depend on which is available. You should
be able to override this with a seperate config option.
(Perhaps this is another thing we need a global xl config file for.)
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2010-Aug-15 14:46 UTC
Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed, tap: vs. tap2:
On Fri, Aug 13, 2010 at 04:18:38PM +0100, Ian Jackson wrote:> Pasi Kärkkäinen writes ("Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed, tap: vs. tap2:"): > > On Tue, Jul 27, 2010 at 07:48:39AM +0100, Keir Fraser wrote: > > > Well the patch to make the distinction is currently in xen-unstable and > > > xen-4.0. Should it be reverted from one or both? Actually it is up to IanJ > > > or Stefano to decide on that now. > > > > Now when Xen 4.0.1-rc5 is out I guess this should be decided shortly.. > > I think the behaviour should be that you write "tap:" in your file and > get either blktap or blktap2 depend on which is available. You should > be able to override this with a seperate config option. >Yeah, this sounds good to me. I''ve updated http://wiki.xensource.com/xenwiki/blktap2 wiki page to reflect the Xen 4.0.1 current state, aka you need tap2: there.. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Maybe Matching Threads
- [PATCH 00 of 18] [v2] tools: fix bugs and build errors triggered by -O2 -Wall -Werror
- [PATCH] blktap2: fix makefile of vhd for parallel make
- [Q] VmError: Disk isn''t accessible with tap2:tapdisk:vhd
- Third release candidate for Xen 4.0.1
- blktapctrl not running