I''m running SLES10 SP1 and have been using file:/ for my file-backed domUs. The domUs sit on a shared OCFS2 SAN-backed filesystem and are run on my three or four XEN servers. I''m having issues with the loopback devices not being released when the domUs shutdown or migrate, so I decided to switch over to tap:aio for my file-backed domUs. This isn''t working, either. Whereas the domUs with file: at least boot and run, the domUs with tap:aio: fail with this error: Error: Device 51952 (vbd) could not be connected. Hotplug scripts not working. I''ve searched the mailing lists and been through all the udev issues, and none of those seem to apply - my loop devices and vifs are connecting perfectly fine, just these tap:aio devices that won''t work. I''ve also verified that blktap and xenblk are loaded as modules. I used udevmonitor to track what happens when I start domUs with tap:aio vs. file (loop) disks. Here''s file method: UEVENT[1209507940.668013] add@/block/dm-30 UEVENT[1209507940.668040] offline@/block/dm-30 UEVENT[1209507940.668049] online@/block/dm-30 UEVENT[1209507940.668059] add@/block/dm-31 UEVENT[1209507940.668067] offline@/block/dm-31 UEVENT[1209507940.668074] online@/block/dm-31 UDEV [1209507940.895265] add@/block/dm-31 UDEV [1209507940.896125] offline@/block/dm-31 UDEV [1209507940.949818] online@/block/dm-31 UDEV [1209507940.951980] add@/block/dm-30 UDEV [1209507940.952814] offline@/block/dm-30 UEVENT[1209507940.962962] mount@/block/dm-30 UDEV [1209507940.979895] online@/block/dm-30 UDEV [1209507940.980777] mount@/block/dm-30 UEVENT[1209507941.415122] umount@/block/dm-30 UDEV [1209507941.415413] umount@/block/dm-30 UEVENT[1209507941.421063] remove@/block/dm-30 UEVENT[1209507941.422222] remove@/block/dm-31 UDEV [1209507941.422598] remove@/block/dm-30 UDEV [1209507941.423304] remove@/block/dm-31 UEVENT[1209507942.248473] add@/devices/xen-backend/vkbd-15-0 UDEV [1209507942.248767] add@/devices/xen-backend/vkbd-15-0 UEVENT[1209507942.255938] add@/devices/xen-backend/vfb-15-0 UDEV [1209507942.256133] add@/devices/xen-backend/vfb-15-0 UEVENT[1209507942.272675] add@/devices/xen-backend/vbd-15-51712 UEVENT[1209507942.297785] add@/devices/xen-backend/vif-15-0 UDEV [1209507942.298036] add@/devices/xen-backend/vif-15-0 UEVENT[1209507942.301038] add@/class/net/vif15.0 UEVENT[1209507942.301052] online@/devices/xen-backend/vif-15-0 UEVENT[1209507942.374108] add@/devices/xen-backend/console-15-0 UDEV [1209507942.374558] add@/devices/xen-backend/console-15-0 UDEV [1209507942.404498] online@/devices/xen-backend/vif-15-0 UDEV [1209507942.459501] add@/class/net/vif15.0 UDEV [1209507942.616792] add@/devices/xen-backend/vbd-15-51712 and here''s tap:aio method: UEVENT[1209507805.006622] add@/devices/xen-backend/vbd-0-51952 UEVENT[1209507805.007163] add@/devices/xen/vbd-51952 UDEV [1209507805.007937] add@/devices/xen/vbd-51952 UDEV [1209507805.042766] add@/devices/xen-backend/vbd-0-51952 UEVENT[1209507905.016513] remove@/devices/xen-backend/vbd-0-51952 UEVENT[1209507905.067583] remove@/devices/xen/vbd-51952 UDEV [1209507905.067852] remove@/devices/xen/vbd-51952 UDEV [1209507905.078662] remove@/devices/xen-backend/vbd-0-51952 syslog messages are unhelpful - here''s the output when I try with tap:aio: Apr 29 16:55:02 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) Apr 29 16:55:02 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) Apr 29 16:55:02 xen02 logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/0/51952 Apr 29 16:56:42 xen02 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/0/51952 Apr 29 16:56:43 xen02 logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vbd/0/51952 Anyone have any hints as to what might be going on here? Any possible solutions? Thanks, Nick P.S. - FWIW, it doesn''t seem to make a difference whether the files are local vs. SAN as to whether tap:aio works or not. This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nick Couchman schrieb:> I''m running SLES10 SP1 and have been using file:/ for my file-backed domUs. The domUs sit on a shared OCFS2 SAN-backed filesystem and are run on my three or four XEN servers. I''m having issues with the loopback devices not being released when the domUs shutdown or migrate, so I decided to switch over to tap:aio for my file-backed domUs. This isn''t working, either. Whereas the domUs with file: at least boot and run, the domUs with tap:aio: fail with this error: > >Hi Nick, we''re running quite some Xen machines on SLES 10 SP1 here, too. I tried to switch from file:/ to tap:aio:/ (as xen documentation recommends), without success. As far as I can see the creation itself works, but it locks down the machine shortly after accessing it. For now I do my testing on Dom0 (it''s easier to see what''s happening there). So here''s what I tried: # Create 2 TB sparse file linux # dd if=/dev/zero of=/proj.stand/xen/disk2 bs=1M count=1 seek=2048000 1+0 records in 1+0 records out 1048576 bytes (1,0 MB) copied, 0,018314 seconds, 57,3 MB/s # Attach it to dom0 as /dev/hdb linux # xm block-attach 0 tap:aio:/proj.stand/xen/disk2 /dev/hdb w 0 linux # cat /proc/partitions ... 3 64 2097153024 hdb ... Now fdisk/mount this device - whatever you like. During my test the machine froze quite fast, however the same tests with file:/ work quite well - no idea why. Someone on the list, where this works? Bye, Marcel> Error: Device 51952 (vbd) could not be connected. Hotplug scripts not working. > > I''ve searched the mailing lists and been through all the udev issues, and none of those seem to apply - my loop devices and vifs are connecting perfectly fine, just these tap:aio devices that won''t work. I''ve also verified that blktap and xenblk are loaded as modules. I > used udevmonitor to track what happens when I start domUs with tap:aio vs. file (loop) disks. Here''s file method: > > UEVENT[1209507940.668013] add@/block/dm-30 > UEVENT[1209507940.668040] offline@/block/dm-30 > UEVENT[1209507940.668049] online@/block/dm-30 > UEVENT[1209507940.668059] add@/block/dm-31 > UEVENT[1209507940.668067] offline@/block/dm-31 > UEVENT[1209507940.668074] online@/block/dm-31 > UDEV [1209507940.895265] add@/block/dm-31 > UDEV [1209507940.896125] offline@/block/dm-31 > UDEV [1209507940.949818] online@/block/dm-31 > UDEV [1209507940.951980] add@/block/dm-30 > UDEV [1209507940.952814] offline@/block/dm-30 > UEVENT[1209507940.962962] mount@/block/dm-30 > UDEV [1209507940.979895] online@/block/dm-30 > UDEV [1209507940.980777] mount@/block/dm-30 > UEVENT[1209507941.415122] umount@/block/dm-30 > UDEV [1209507941.415413] umount@/block/dm-30 > UEVENT[1209507941.421063] remove@/block/dm-30 > UEVENT[1209507941.422222] remove@/block/dm-31 > UDEV [1209507941.422598] remove@/block/dm-30 > UDEV [1209507941.423304] remove@/block/dm-31 > UEVENT[1209507942.248473] add@/devices/xen-backend/vkbd-15-0 > UDEV [1209507942.248767] add@/devices/xen-backend/vkbd-15-0 > UEVENT[1209507942.255938] add@/devices/xen-backend/vfb-15-0 > UDEV [1209507942.256133] add@/devices/xen-backend/vfb-15-0 > UEVENT[1209507942.272675] add@/devices/xen-backend/vbd-15-51712 > UEVENT[1209507942.297785] add@/devices/xen-backend/vif-15-0 > UDEV [1209507942.298036] add@/devices/xen-backend/vif-15-0 > UEVENT[1209507942.301038] add@/class/net/vif15.0 > UEVENT[1209507942.301052] online@/devices/xen-backend/vif-15-0 > UEVENT[1209507942.374108] add@/devices/xen-backend/console-15-0 > UDEV [1209507942.374558] add@/devices/xen-backend/console-15-0 > UDEV [1209507942.404498] online@/devices/xen-backend/vif-15-0 > UDEV [1209507942.459501] add@/class/net/vif15.0 > UDEV [1209507942.616792] add@/devices/xen-backend/vbd-15-51712 > and here''s tap:aio method: > UEVENT[1209507805.006622] add@/devices/xen-backend/vbd-0-51952 > UEVENT[1209507805.007163] add@/devices/xen/vbd-51952 > UDEV [1209507805.007937] add@/devices/xen/vbd-51952 > UDEV [1209507805.042766] add@/devices/xen-backend/vbd-0-51952 > UEVENT[1209507905.016513] remove@/devices/xen-backend/vbd-0-51952 > UEVENT[1209507905.067583] remove@/devices/xen/vbd-51952 > UDEV [1209507905.067852] remove@/devices/xen/vbd-51952 > UDEV [1209507905.078662] remove@/devices/xen-backend/vbd-0-51952 > > syslog messages are unhelpful - here''s the output when I try with tap:aio: > Apr 29 16:55:02 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) > Apr 29 16:55:02 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) > Apr 29 16:55:02 xen02 logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/0/51952 > Apr 29 16:56:42 xen02 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/0/51952 > Apr 29 16:56:43 xen02 logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vbd/0/51952 > > Anyone have any hints as to what might be going on here? Any possible solutions? > > Thanks, > Nick > > P.S. - FWIW, it doesn''t seem to make a difference whether the files are local vs. SAN as to whether tap:aio works or not. > > > > This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi!> Nick Couchman schrieb: >> > I''m running SLES10 SP1 and have been using file:/ for my file-backed domUs. The domUs sit on a shared OCFS2 SAN-backed filesystem and are run on my three or four XEN servers. I''m having issues with the loopback devices not being released when the domUs shutdown or migrate, so I decided to switch over to tap:aio for my file-backed domUs. This isn''t working, either. Whereas the domUs with file: at least boot and run, the domUs with tap:aio: fail with this error: >> > >> > > Hi Nick, > > we''re running quite some Xen machines on SLES 10 SP1 here, too. > I tried to switch from file:/ to tap:aio:/ (as xen documentation > recommends), > without success. As far as I can see the creation itself works, but it locks > down the machine shortly after accessing it. > > For now I do my testing on Dom0 (it''s easier to see what''s happening there). > So here''s what I tried: > > # Create 2 TB sparse file > linux # dd if=/dev/zero of=/proj.stand/xen/disk2 bs=1M count=1 seek=2048000 > 1+0 records in > 1+0 records out > 1048576 bytes (1,0 MB) copied, 0,018314 seconds, 57,3 MB/s > > # Attach it to dom0 as /dev/hdb > linux # xm block-attach 0 tap:aio:/proj.stand/xen/disk2 /dev/hdb w 0 > linux # cat /proc/partitions > ... > 3 64 2097153024 hdb > ... > > Now fdisk/mount this device - whatever you like. > > During my test the machine froze quite fast, however the same tests with > file:/ > work quite well - no idea why. > > Someone on the list, where this works?Have you checked that the process "blktapctrl" is running on dom0 (ps ax | grep blktapctrl)? If not, than your Kernel might be compiled without blktap support. I''m using Xen with Debian-Etch in dom0 and the debian xen-kernel has blktap-support disabled by default so I had to build a custom kernel. Greetings, Gernot Kieseritzky _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Gernot Kieseritzky schrieb:> Hi! > > >> Nick Couchman schrieb: >> >>>> I''m running SLES10 SP1 and have been using file:/ for my file-backed domUs. The domUs sit on a shared OCFS2 SAN-backed filesystem and are run on my three or four XEN servers. I''m having issues with the loopback devices not being released when the domUs shutdown or migrate, so I decided to switch over to tap:aio for my file-backed domUs. This isn''t working, either. Whereas the domUs with file: at least boot and run, the domUs with tap:aio: fail with this error: >>>> >>>> >>>> >> Hi Nick, >> >> we''re running quite some Xen machines on SLES 10 SP1 here, too. >> I tried to switch from file:/ to tap:aio:/ (as xen documentation >> recommends), >> without success. As far as I can see the creation itself works, but it locks >> down the machine shortly after accessing it. >> >> For now I do my testing on Dom0 (it''s easier to see what''s happening there). >> So here''s what I tried: >> >> # Create 2 TB sparse file >> linux # dd if=/dev/zero of=/proj.stand/xen/disk2 bs=1M count=1 seek=2048000 >> 1+0 records in >> 1+0 records out >> 1048576 bytes (1,0 MB) copied, 0,018314 seconds, 57,3 MB/s >> >> # Attach it to dom0 as /dev/hdb >> linux # xm block-attach 0 tap:aio:/proj.stand/xen/disk2 /dev/hdb w 0 >> linux # cat /proc/partitions >> ... >> 3 64 2097153024 hdb >> ... >> >> Now fdisk/mount this device - whatever you like. >> >> During my test the machine froze quite fast, however the same tests with >> file:/ >> work quite well - no idea why. >> >> Someone on the list, where this works? >> > > Have you checked that the process "blktapctrl" is running on dom0 (ps ax > | grep blktapctrl)? If not, than your Kernel might be compiled without > blktap support. I''m using Xen with Debian-Etch in dom0 and the debian > xen-kernel has blktap-support disabled by default so I had to build a > custom kernel. > >Yepp, should be compiled in: process is running, modules loaded: linux7:~ # ps -ef | grep blkta root 3735 1 0 Apr23 ? 00:00:00 blktapctrl root 15395 15326 0 13:34 pts/9 00:00:00 grep blkta linux7:~ # lsmod | grep blktap blktap 124804 2 [permanent] xenbus_be 8576 3 netbk,blkbk,blktap> Greetings, > Gernot Kieseritzky >Bye, Marcel _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nick Couchman schrieb:> I''m running SLES10 SP1 and have been using file:/ for my file-backed domUs. The domUs sit on a shared OCFS2 SAN-backed filesystem and are run on my three or four XEN servers. I''m having issues with the loopback devices not being released when the domUs shutdown or migrate, so I decided to switch over to tap:aio for my file-backed domUs. This isn''t working, either. Whereas the domUs with file: at least boot and run, the domUs with tap:aio: fail with this error: > > syslog messages are unhelpful - here''s the output when I try with tap:aio: > Apr 29 16:55:02 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) > Apr 29 16:55:02 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) > Apr 29 16:55:02 xen02 logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/0/51952 > Apr 29 16:56:42 xen02 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/0/51952 > Apr 29 16:56:43 xen02 logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vbd/0/51952 > > Anyone have any hints as to what might be going on here? Any possible solutions?You should have some BLKTAPCTRL and TAPDISK lines in your /var/log/messages which could give you some hints. If these lines are missing you most probably don''t have loaded the kernel modules (they aren''t loaded by default, IIRC) or blktapctrl isn''t running. Kevin _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Kevin, Well, here''s the output from lsmod and ps: xen02:~ # lsmod | grep -i tap blktap 121604 2 [permanent] xenbus_be 8832 3 netbk,blkbk,blktap xen02:~ # ps -ef | grep blk root 7060 1 0 Apr28 ? 00:00:00 blktapctrl root 31500 31466 0 06:59 pts/0 00:00:00 grep blk Clearly the blktap module is loaded (is there another one I need??) and the control daemon is running. The only messages that I get with BLKTAP or TAPDISK occur when I manually do an "xm block-attach" to dom0 to test out the tap:aio method. If I try to start a domU with tap:aio, the only log file messages I get are these: Apr 30 07:01:57 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) Apr 30 07:01:57 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) Apr 30 07:01:57 xen02 logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/0/51952 Maybe the /etc/xen/scripts/block script is not handling the tap:aio stuff correctly, since that''s the last message? Or maybe something else is failing to occur. -Nick>>> On Wed, Apr 30, 2008 at 5:58 AM, Kevin Wolf <kwolf@suse.de> wrote:Nick Couchman schrieb:> I''m running SLES10 SP1 and have been using file:/ for my file-backed domUs. The domUs sit on a shared OCFS2 SAN-backed filesystem and are run on my three or four XEN servers. I''m having issues with the loopback devices not being released when the domUs shutdown or migrate, so I decided to switch over to tap:aio for my file-backed domUs. This isn''t working, either. Whereas the domUs with file: at least boot and run, the domUs with tap:aio: fail with this error: > > syslog messages are unhelpful - here''s the output when I try with tap:aio: > Apr 29 16:55:02 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) > Apr 29 16:55:02 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) > Apr 29 16:55:02 xen02 logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/0/51952 > Apr 29 16:56:42 xen02 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/0/51952 > Apr 29 16:56:43 xen02 logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vbd/0/51952 > > Anyone have any hints as to what might be going on here? Any possible solutions?You should have some BLKTAPCTRL and TAPDISK lines in your /var/log/messages which could give you some hints. If these lines are missing you most probably don''t have loaded the kernel modules (they aren''t loaded by default, IIRC) or blktapctrl isn''t running. Kevin This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Well, my machine doesn''t freeze, it just sits for a while trying to start the domU and then gives up because it cannot connect the tap:aio block device. I see some of the udev events, the modules appear to be loaded, and I can do the same thing you did - manually attaching the tap:aio file to dom0, mount it, fdisk it, etc., but it doesn''t seem to want to work in domU. -Nick>>> On Wed, Apr 30, 2008 at 4:35 AM, Marcel Ritter <Marcel.Ritter@rrze.uni-erlangen.de> wrote:Nick Couchman schrieb:> I''m running SLES10 SP1 and have been using file:/ for my file-backed domUs. The domUs sit on a shared OCFS2 SAN-backed filesystem and are run on my three or four XEN servers. I''m having issues with the loopback devices not being released when the domUs shutdown or migrate, so I decided to switch over to tap:aio for my file-backed domUs. This isn''t working, either. Whereas the domUs with file: at least boot and run, the domUs with tap:aio: fail with this error: > >Hi Nick, we''re running quite some Xen machines on SLES 10 SP1 here, too. I tried to switch from file:/ to tap:aio:/ (as xen documentation recommends), without success. As far as I can see the creation itself works, but it locks down the machine shortly after accessing it. For now I do my testing on Dom0 (it''s easier to see what''s happening there). So here''s what I tried: # Create 2 TB sparse file linux # dd if=/dev/zero of=/proj.stand/xen/disk2 bs=1M count=1 seek=2048000 1+0 records in 1+0 records out 1048576 bytes (1,0 MB) copied, 0,018314 seconds, 57,3 MB/s # Attach it to dom0 as /dev/hdb linux # xm block-attach 0 tap:aio:/proj.stand/xen/disk2 /dev/hdb w 0 linux # cat /proc/partitions ... 3 64 2097153024 hdb ... Now fdisk/mount this device - whatever you like. During my test the machine froze quite fast, however the same tests with file:/ work quite well - no idea why. Someone on the list, where this works? Bye, Marcel> Error: Device 51952 (vbd) could not be connected. Hotplug scripts not working. > > I''ve searched the mailing lists and been through all the udev issues, and none of those seem to apply - my loop devices and vifs are connecting perfectly fine, just these tap:aio devices that won''t work. I''ve also verified that blktap and xenblk are loaded as modules. I > used udevmonitor to track what happens when I start domUs with tap:aio vs. file (loop) disks. Here''s file method: > > UEVENT[1209507940.668013] add@/block/dm-30 > UEVENT[1209507940.668040] offline@/block/dm-30 > UEVENT[1209507940.668049] online@/block/dm-30 > UEVENT[1209507940.668059] add@/block/dm-31 > UEVENT[1209507940.668067] offline@/block/dm-31 > UEVENT[1209507940.668074] online@/block/dm-31 > UDEV [1209507940.895265] add@/block/dm-31 > UDEV [1209507940.896125] offline@/block/dm-31 > UDEV [1209507940.949818] online@/block/dm-31 > UDEV [1209507940.951980] add@/block/dm-30 > UDEV [1209507940.952814] offline@/block/dm-30 > UEVENT[1209507940.962962] mount@/block/dm-30 > UDEV [1209507940.979895] online@/block/dm-30 > UDEV [1209507940.980777] mount@/block/dm-30 > UEVENT[1209507941.415122] umount@/block/dm-30 > UDEV [1209507941.415413] umount@/block/dm-30 > UEVENT[1209507941.421063] remove@/block/dm-30 > UEVENT[1209507941.422222] remove@/block/dm-31 > UDEV [1209507941.422598] remove@/block/dm-30 > UDEV [1209507941.423304] remove@/block/dm-31 > UEVENT[1209507942.248473] add@/devices/xen-backend/vkbd-15-0 > UDEV [1209507942.248767] add@/devices/xen-backend/vkbd-15-0 > UEVENT[1209507942.255938] add@/devices/xen-backend/vfb-15-0 > UDEV [1209507942.256133] add@/devices/xen-backend/vfb-15-0 > UEVENT[1209507942.272675] add@/devices/xen-backend/vbd-15-51712 > UEVENT[1209507942.297785] add@/devices/xen-backend/vif-15-0 > UDEV [1209507942.298036] add@/devices/xen-backend/vif-15-0 > UEVENT[1209507942.301038] add@/class/net/vif15.0 > UEVENT[1209507942.301052] online@/devices/xen-backend/vif-15-0 > UEVENT[1209507942.374108] add@/devices/xen-backend/console-15-0 > UDEV [1209507942.374558] add@/devices/xen-backend/console-15-0 > UDEV [1209507942.404498] online@/devices/xen-backend/vif-15-0 > UDEV [1209507942.459501] add@/class/net/vif15.0 > UDEV [1209507942.616792] add@/devices/xen-backend/vbd-15-51712 > and here''s tap:aio method: > UEVENT[1209507805.006622] add@/devices/xen-backend/vbd-0-51952 > UEVENT[1209507805.007163] add@/devices/xen/vbd-51952 > UDEV [1209507805.007937] add@/devices/xen/vbd-51952 > UDEV [1209507805.042766] add@/devices/xen-backend/vbd-0-51952 > UEVENT[1209507905.016513] remove@/devices/xen-backend/vbd-0-51952 > UEVENT[1209507905.067583] remove@/devices/xen/vbd-51952 > UDEV [1209507905.067852] remove@/devices/xen/vbd-51952 > UDEV [1209507905.078662] remove@/devices/xen-backend/vbd-0-51952 > > syslog messages are unhelpful - here''s the output when I try with tap:aio: > Apr 29 16:55:02 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) > Apr 29 16:55:02 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) > Apr 29 16:55:02 xen02 logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/0/51952 > Apr 29 16:56:42 xen02 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/0/51952 > Apr 29 16:56:43 xen02 logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vbd/0/51952 > > Anyone have any hints as to what might be going on here? Any possible solutions? > > Thanks, > Nick > > P.S. - FWIW, it doesn''t seem to make a difference whether the files are local vs. SAN as to whether tap:aio works or not. > > > > This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Have also located and attached the xen-hotplug.log file. I''m trying to figure out how to interpret it, but if anyone sees anything obvious... -Nick>>> On Wed, Apr 30, 2008 at 5:58 AM, Kevin Wolf <kwolf@suse.de> wrote:Nick Couchman schrieb:> I''m running SLES10 SP1 and have been using file:/ for my file-backed domUs. The domUs sit on a shared OCFS2 SAN-backed filesystem and are run on my three or four XEN servers. I''m having issues with the loopback devices not being released when the domUs shutdown or migrate, so I decided to switch over to tap:aio for my file-backed domUs. This isn''t working, either. Whereas the domUs with file: at least boot and run, the domUs with tap:aio: fail with this error: > > syslog messages are unhelpful - here''s the output when I try with tap:aio: > Apr 29 16:55:02 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) > Apr 29 16:55:02 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) > Apr 29 16:55:02 xen02 logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/0/51952 > Apr 29 16:56:42 xen02 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/0/51952 > Apr 29 16:56:43 xen02 logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vbd/0/51952 > > Anyone have any hints as to what might be going on here? Any possible solutions?You should have some BLKTAPCTRL and TAPDISK lines in your /var/log/messages which could give you some hints. If these lines are missing you most probably don''t have loaded the kernel modules (they aren''t loaded by default, IIRC) or blktapctrl isn''t running. Kevin This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Kevin, Well, here''s the output from lsmod and ps: xen02:~ # lsmod | grep -i tap blktap 121604 2 [permanent] xenbus_be 8832 3 netbk,blkbk,blktap xen02:~ # ps -ef | grep blk root 7060 1 0 Apr28 ? 00:00:00 blktapctrl root 31500 31466 0 06:59 pts/0 00:00:00 grep blk Clearly the blktap module is loaded (is there another one I need??) and the control daemon is running. The only messages that I get with BLKTAP or TAPDISK occur when I manually do an "xm block-attach" to dom0 to test out the tap:aio method. If I try to start a domU with tap:aio, the only log file messages I get are these: Apr 30 07:01:57 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) Apr 30 07:01:57 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) Apr 30 07:01:57 xen02 logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/0/51952 Maybe the /etc/xen/scripts/block script is not handling the tap:aio stuff correctly, since that''s the last message? Or maybe something else is failing to occur. -Nick>>> On Wed, Apr 30, 2008 at 5:58 AM, Kevin Wolf <kwolf@suse.de> wrote:Nick Couchman schrieb:> I''m running SLES10 SP1 and have been using file:/ for my file-backed domUs. The domUs sit on a shared OCFS2 SAN-backed filesystem and are run on my three or four XEN servers. I''m having issues with the loopback devices not being released when the domUs shutdown or migrate, so I decided to switch over to tap:aio for my file-backed domUs. This isn''t working, either. Whereas the domUs with file: at least boot and run, the domUs with tap:aio: fail with this error: > > syslog messages are unhelpful - here''s the output when I try with tap:aio: > Apr 29 16:55:02 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) > Apr 29 16:55:02 xen02 kernel: blkback: ring-ref 8, event-channel 38, protocol 1 (x86_64-abi) > Apr 29 16:55:02 xen02 logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/0/51952 > Apr 29 16:56:42 xen02 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/0/51952 > Apr 29 16:56:43 xen02 logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vbd/0/51952 > > Anyone have any hints as to what might be going on here? Any possible solutions?You should have some BLKTAPCTRL and TAPDISK lines in your /var/log/messages which could give you some hints. If these lines are missing you most probably don''t have loaded the kernel modules (they aren''t loaded by default, IIRC) or blktapctrl isn''t running. Kevin This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nick Couchman schrieb:> xen02:~ # lsmod | grep -i tap > blktap 121604 2 [permanent] > xenbus_be 8832 3 netbk,blkbk,blktap > xen02:~ # ps -ef | grep blk > root 7060 1 0 Apr28 ? 00:00:00 blktapctrl > root 31500 31466 0 06:59 pts/0 00:00:00 grep blk > > Clearly the blktap module is loaded (is there another one I need??) and the control daemon is running.Looks right so far.> The only messages that I get with BLKTAP or TAPDISK occur when I manually do an "xm block-attach" to dom0 to test out the tap:aio method.So if you try to block-attach the image to Dom0 it works and the problem is only with DomU? Unfortunately I currently don''t have a machine installed with SP1 here, it''s all the SP2 RCs now. Looking at my own logfiles I found that I get this "blkback: ring-ref" lines only when I use file. With blktap it doesn''t show up at all. So the information that you wanted blktap might have been lost somewhere in the middle of the domain startup. This would also explain the missing BLKTAP and TAPDISK lines. Kevin _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Well, I''ve actually experienced mixed results with attaching a tap:aio device to dom0. Sometimes it works and sometimes it doesn''t, and I''m having trouble tracking down a pattern to it. When it fails in dom0, instead of the error message about hotplug scripts not working, I get a "Backend device not found" message. I''ll be moving to SP2 as soon as you release it, but I''m wary of doing that on these production machines until it''s officially released. Any other hints on what I may be able to look at would be much appreciated. I''ve also got a support case open on my Novell support contract for this issue. -Nick>>> On Mon, May 5, 2008 at 6:12 AM, Kevin Wolf <kwolf@suse.de> wrote: > Nick Couchman schrieb: >> xen02:~ # lsmod | grep -i tap >> blktap 121604 2 [permanent] >> xenbus_be 8832 3 netbk,blkbk,blktap >> xen02:~ # ps -ef | grep blk >> root 7060 1 0 Apr28 ? 00:00:00 blktapctrl >> root 31500 31466 0 06:59 pts/0 00:00:00 grep blk >> >> Clearly the blktap module is loaded (is there another one I need??) and the > control daemon is running. > > Looks right so far. > >> The only messages that I get with BLKTAP or TAPDISK occur when I manually do > an "xm block-attach" to dom0 to test out the tap:aio method. > > So if you try to block-attach the image to Dom0 it works and the problem > is only with DomU? Unfortunately I currently don''t have a machine > installed with SP1 here, it''s all the SP2 RCs now. > > Looking at my own logfiles I found that I get this "blkback: ring-ref" > lines only when I use file. With blktap it doesn''t show up at all. So > the information that you wanted blktap might have been lost somewhere in > the middle of the domain startup. This would also explain the missing > BLKTAP and TAPDISK lines. > > KevinThis e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nick Couchman schrieb:> I''ll be moving to SP2 as soon as you release it, but I''m wary of doing that on these production machines until it''s officially released. Any other hints on what I may be able to look at would be much appreciated. I''ve also got a support case open on my Novell support contract for this issue.Even though I''ve been into the blktapcrtl/tapdisk code recently, the problem isn''t exactly obvious to me. So best let''s handle this through our support. After all, it''s their job, I''m just a random developer. ;-) Kevin _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wednesday April 30 2008 12:53:13 pm Nick Couchman wrote:> Have also located and attached the xen-hotplug.log file. I''m trying to > figure out how to interpret it, but if anyone sees anything obvious...This part of the output is curious: + p=aio:/xenstore/xenvol1/Projects/disk0 ++ xenstore_read backend/vbd/0/51952/mode +++ xenstore-read backend/vbd/0/51952/mode ++ local v=w ++ ''['' w ''!='' '''' '']'' ++ echo w + mode=w + case $t in + ''['' -x /etc/xen/scripts/block-tap '']'' <-------------------------?? +++ export PATH=/sbin:/bin:/usr/bin:/usr/sbin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:. +++ PATH=/sbin:/bin:/usr/bin:/usr/sbin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:. +++ export LANG=POSIX +++ LANG=POSIX ++++ set ++++ grep ''^LC_'' ++++ cut -d= -f1 +++ unset +++ trap sigerr ERR +++ log debug remove XENBUS_PATH=backend/vbd/0/51952 The marked line tests if block-tap is executable, and then suddenly jumps to another script, which is doing a remove. 1) Is block-tap indeed marked as executable? My SuSE 10.3 system doesn''t even have a block-tap, so I''m not sure what package that comes from. What is the output of ''rpm -q --whatprovides /etc/xen/scripts/block-tap''? If you don''t have it either, try ''yum install /etc/xen/scripts/block-tap''. 2) Can you verify what script the rest of the output after the flagged line is coming from? _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
My SLES10 install also does not have a block-tap script. I traced this down, though, and this is a standard line in the block script (I think) that just looks for any custom script for a particular device type. If uses a variable that has the device type and looks for block-$DEVICE just in case there are customer scripts. Don''t think this is the issue. Not sure about what script is generating that output, but I''ll try to track it down. I have another issue, now, after upgrading to SLES10 SP2 GMC (Beta, just before release) and that''s that my Windows HVM domUs hang at boot time, now. That, and they''ve changed the OCFS2 version from 1.2.8 to 1.4.0, which means that I have to upgrade ALL Of my servers to get them to see my SAN volume. -Sigh- how annoying... -Nick>>> On 2008/05/09 at 20:13, jim burns <jim_burn@bellsouth.net> wrote:On Wednesday April 30 2008 12:53:13 pm Nick Couchman wrote:> Have also located and attached the xen-hotplug.log file. I''m trying to > figure out how to interpret it, but if anyone sees anything obvious...This part of the output is curious: + p=aio:/xenstore/xenvol1/Projects/disk0 ++ xenstore_read backend/vbd/0/51952/mode +++ xenstore-read backend/vbd/0/51952/mode ++ local v=w ++ ''['' w ''!='' '''' '']'' ++ echo w + mode=w + case $t in + ''['' -x /etc/xen/scripts/block-tap '']'' <-------------------------?? +++ export PATH=/sbin:/bin:/usr/bin:/usr/sbin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:. +++ PATH=/sbin:/bin:/usr/bin:/usr/sbin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:. +++ export LANG=POSIX +++ LANG=POSIX ++++ set ++++ grep ''^LC_'' ++++ cut -d= -f1 +++ unset +++ trap sigerr ERR +++ log debug remove XENBUS_PATH=backend/vbd/0/51952 The marked line tests if block-tap is executable, and then suddenly jumps to another script, which is doing a remove. 1) Is block-tap indeed marked as executable? My SuSE 10.3 system doesn''t even have a block-tap, so I''m not sure what package that comes from. What is the output of ''rpm -q --whatprovides /etc/xen/scripts/block-tap''? If you don''t have it either, try ''yum install /etc/xen/scripts/block-tap''. 2) Can you verify what script the rest of the output after the flagged line is coming from? This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sat, May 10, 2008 at 11:25 AM, Nick Couchman <Nick.Couchman@seakr.com> wrote:> My SLES10 install also does not have a block-tap script. I traced this > down, though, and this is a standard line in the block script (I think) that > just looks for any custom script for a particular device type. If uses a > variable that has the device type and looks for block-$DEVICE just in case > there are customer scripts. Don''t think this is the issue. > > Not sure about what script is generating that output, but I''ll try to track > it down. > > I have another issue, now, after upgrading to SLES10 SP2 GMC (Beta, just > before release) and that''s that my Windows HVM domUs hang at boot time, > now. That, and they''ve changed the OCFS2 version from 1.2.8 to 1.4.0, which > means that I have to upgrade ALL Of my servers to get them to see my SAN > volume. -Sigh- how annoying... >What messages do you see in the /var/log/xen/qemu* log file when the domU hangs at boot?> > -Nick > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Attached is one of the qemu-dm-*.log files from an attempt to start a Windows HVM. -Nick>>> On Sat, May 10, 2008 at 9:33 AM, "Todd Deshane" <deshantm@gmail.com> wrote:On Sat, May 10, 2008 at 11:25 AM, Nick Couchman <Nick.Couchman@seakr.com> wrote: My SLES10 install also does not have a block-tap script. I traced this down, though, and this is a standard line in the block script (I think) that just looks for any custom script for a particular device type. If uses a variable that has the device type and looks for block-$DEVICE just in case there are customer scripts. Don''t think this is the issue. Not sure about what script is generating that output, but I''ll try to track it down. I have another issue, now, after upgrading to SLES10 SP2 GMC (Beta, just before release) and that''s that my Windows HVM domUs hang at boot time, now. That, and they''ve changed the OCFS2 version from 1.2.8 to 1.4.0, which means that I have to upgrade ALL Of my servers to get them to see my SAN volume. -Sigh- how annoying... What messages do you see in the /var/log/xen/qemu* log file when the domU hangs at boot? -Nick This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi again, I finally found some time to have a deeper look into my tap:aio:/tap:qcow: troubles: Once again how I tested things: mkdir /proj.stand/mnt dd if=/dev/zero of=/proj.stand/dummy bs=1M count=40960 xm block-attach 0 tap:aio:/proj.stand/dummy xvda w 0 fdisk /dev/xvda # create 1 primary partition here mkreisers /dev/xvda1 mount /dev/xvda1 /proj.stand/mnt while true; do time dd if=/dev/zero of=/proj.stand/mnt/file bs=1M count=20480; done ... This works quite well (as ''file:/proj.stand/dummy'' worked before). However if I replace the "disk image file" with a sparse file (which is created quite fast, and saves lots of disk space for the moment) dd if=/dev/zero of=/proj.stand/dummy bs=1M seek=40959 count=1 and run the same test, the process will hang just a few minutes later (or maybe it''s just getting so slow, that no progress can be observed, I can''t say for sure). If also found this behaviour when using sparse qcow files: qcow-create -r 20480 /proj.stand/image.qcow xm block-attach 0 tap:qcow:/proj.stand/image.qcow xvda w 0 ... <insert test above here> ... works fine, but without "-r (reserve)" flag, it fails miserably: qcow-create 20480 /proj.stand/image.qcow xm block-attach 0 tap:qcow:/proj.stand/image.qcow xvda w 0 ... <insert test above here> ... .... < this takes hours ... or more? Never finished for me) So this is (in short) what works (and what not): type: sparse: works: file:/ no yes file:/ yes yes tap:aio:/ no yes tap:aio:/ yes no tap:qcow:/ no yes tap:qcow:/ yes no So for me it looks like blktap (or some other component) gets into trouble when sparse files are used... Any idea what''s the cause of that? BTW: The system I''m currently testing on is SLES 10 SP2. Bye, Marcel -- ---- Dipl.-Inf. Marcel Ritter Linux/Novell Regionales Rechenzentrum Erlangen Tel: 09131 / 85-27808 E-Mail: Marcel.Ritter@rrze.uni-erlangen.de ---- Unix _IS_ user friendly... It''s just selective about who its friends are. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Marcel Ritter schrieb:> Hi again, > >...> If also found this behaviour when using sparse qcow files: > > qcow-create -r 20480 /proj.stand/image.qcow > xm block-attach 0 tap:qcow:/proj.stand/image.qcow xvda w 0 > ... <insert test above here> ... > > works fine, but without "-r (reserve)" flag, it fails miserably: > > qcow-create 20480 /proj.stand/image.qcow > xm block-attach 0 tap:qcow:/proj.stand/image.qcow xvda w 0 > ... <insert test above here> ... > .... < this takes hours ... or more? Never finished for me)Update on that (qcow, without reserve): I was too impatient on that, after waiting quite some time I got this: while true; do time dd if=/dev/zero of=dummy bs=1M count=10240; done 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 3851,42 seconds, 2,8 MB/s real 64m11.684s <- took over 1 hour!!! user 0m0.032s sys 0m12.569s 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 3928,04 seconds, 2,7 MB/s real 69m0.305s user 0m0.040s sys 0m14.485s 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 336,601 seconds, 31,9 MB/s real 5m44.421s user 0m0.012s sys 0m14.021s 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 111,804 seconds, 96,0 MB/s real 1m54.282s <- now, less than 2 minutes user 0m0.032s sys 0m13.189s 10240+0 records in 10240+0 records out Looks like expanding the qcow file the first time takes *very* long, after that it speeds up considerably (2,8 MB/s -> 96 MB/s), so my next try will be to run that test again on tap:aio: with sparse file .... Currently running the same test for tap:aio: again ... running for more than 3 hours now ...> So this is (in short) what works (and what not): > > type: sparse: works: > file:/ no yes > file:/ yes yes > tap:aio:/ no yes > tap:aio:/ yes no > tap:qcow:/ no yesSo this should read: - tap:qcow:/ yes no +tap:qcow:/ yes yes> So for me it looks like blktap (or some other component) gets into > trouble when > sparse files are used... > > Any idea what''s the cause of that? > > BTW: The system I''m currently testing on is SLES 10 SP2.Bye, Marcel -- ---- Dipl.-Inf. Marcel Ritter Linux/Novell Regionales Rechenzentrum Erlangen Tel: 09131 / 85-27808 E-Mail: Marcel.Ritter@rrze.uni-erlangen.de ---- Unix _IS_ user friendly... It''s just selective about who its friends are. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Marcel Ritter schrieb:> Marcel Ritter schrieb:...> Looks like expanding the qcow file the first time takes *very* long, > after > that it speeds up considerably (2,8 MB/s -> 96 MB/s), so my next try > will be > to run that test again on tap:aio: with sparse file .... > > Currently running the same test for tap:aio: again ... running for > more than 3 hours now ...Test is running for > 20 hours now - dom0 only partially works: local login possible, ssh login accepts connection, asks for password but hangs afterwards. Looking at /proc/diskstats for the tap:aio: device xvbd: Fields 1-8: no changes Field 9: is constantly at 160 Fields 10/11: increase steadily Field 1 -- # of reads issued Field 2 -- # of reads merged, field 6 -- # of writes merged Field 3 -- # of sectors read Field 4 -- # of milliseconds spent reading Field 5 -- # of writes completed Field 7 -- # of sectors written Field 8 -- # of milliseconds spent writing Field 9 -- # of I/Os currently in progress Field 10 -- # of milliseconds spent doing I/Os Field 11 -- weighted # of milliseconds spent doing I/Os Looks to me like a lot of time is spent to process I/Os that never finish. Any comments on that? But at least the problem seems to be a tap:aio: sparse file issue only ... Bye, Marcel -- ---- Dipl.-Inf. Marcel Ritter Linux/Novell Regionales Rechenzentrum Erlangen Tel: 09131 / 85-27808 E-Mail: Marcel.Ritter@rrze.uni-erlangen.de ---- Unix _IS_ user friendly... It''s just selective about who its friends are. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users