similar to: tap:aio support Xen Debian lenny

Package: xen-utils-3.2-1 Version: 3.2.1-2 Severity: important /usr/lib/xen-3.2-1/bin/blktapctrl searches for tapdisk executable in /usr/bin while is in /usr/lib/xen-3.2-1/bin this makes tap:aio unusable I've linked to /usr/bin and everything went fine perhaps the idea is to patch sources to pick executable from the right directory Regards -- System Information: Debian Release: 5.0

I have never been able to get tap:aio devices running. When I try it in a Linux PV domain, it says: XENBUS: Waiting for devices to initialise: 295s... And they don''t work in my GPLPV drivers, which is the problem I am trying to solve, but I''d like to see them work under Linux first. Is there anything extra I need to do? I have loaded the xenblktap module (forgot to do this

Package: xen-utils-3.4 Version: 3.4.3~rc6-1 Severity: important blktapctrl doesn't start. This means that none of the tap: disks work (eg tap:aio). It produces this in the log BLKTAPCTRL[6569]: blktapctrl.c:788: blktapctrl: v1.0.0 BLKTAPCTRL[6569]: blktapctrl.c:790: Found driver: [raw image (aio)] BLKTAPCTRL[6569]: blktapctrl.c:790: Found driver: [raw image (sync)]

Hi All I am using xen 3.3.0 version and I want to start network virtual interface on Dom U by using the following command # xend start *************************************************************** *************************************************************** ** WARNING: Currently emulating unsupported memory accesses ** ** in /lib/tls glibc libraries. The emulation is

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

Hi! When I try to compile xen-unstable on Sarge, I get this error and I don''t know how to solve it: make[3]: Entering directory `/root/xen-unstable/tools/blktap/drivers'' gcc -O2 -fomit-frame-pointer -DNDEBUG -m32 -march=i686 -Wall -Wstrict-prototypes -D__XEN_TOOLS__ -fPIC -Wall -Werror -Wno-unused -g3 -fno-strict-aliasing -I ../../../tools/libxc -I ../../libaio/src -I..

Package: xen-utils-3.4 Version: 3.4.3~rc6-1 Severity: important blktapctrl isn't started by default. If blktapctrl isn't started then none of the tap: disks (eg tap:aio) work. This functionality has been removed in tools-misc-xend-startup.diff @@ -120,24 +86,14 @@ if not sys.argv[1:]: print 'usage: %s {start|stop|reload|restart}' % sys.argv[0] elif

a clean new FC6 system downloading xen src tar ball I get make[3]: Entering directory `/opt/xen-3.0.4_1-src/tools/blktap/drivers'' gcc -O2 -fomit-frame-pointer -m64 -DNDEBUG -std=gnu99 -Wall -Wstrict- prototypes -Wno-unused-value -Wdeclaration-after-statement - D__XEN_TOOLS__ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Werror - Wno-unused -fno-strict-aliasing -I

Processing commands for control at bugs.debian.org: > close 421825 4.4.0-1 Bug #421825 [src:xen] xen-utils-3.0.3-1: blktap is missing Bug #442380 [src:xen] xen-utils-3.1-1: reenabled blktap support unusable Bug #517007 [src:xen] xen-utils-3.2-1: tap:aio on disk image files is not usable Bug #582363 [src:xen] xen-utils-3.4: blktapctrl not started by default Bug #582364 [src:xen] xen-utils-3.4:

Hi, I am running XEN 4.1 on Debian 6 and I cannot find blktapctrl process running. xend is started. I installed XEN from 4.1 source following instructions here: http://wiki.xensource.com/xenwiki/XenParavirtOps http://wiki.xensource.com/xenwiki/Xen4.0 Should there be a blktapctrl process running in this version? The problem I have encountered is that I can create a domain on a raw disk image but

Andrew, I think bug 709 is caused by blktapctrl not daemonizing itself correctly and holding open a file descriptor that the xm-test python code is reading from. I''m not really very familiar with blktapctrl. If you''d like to pick up the bug or outline how you''d like it fixed---for example by copying the daemonize implementation from xenconsoled---that would be

[PATCH 3/4] (Refactored) Add error checking in blktapctrl blktap-fixes.patch Add some additional error checking to blktapctrl during mkfifo Signed-off-by: Boris Ostrovsky <bostrovsky@virtualiron.com> Signed-off-by: Ben Guthro <bguthro@virtualiron.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

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.

Hi all I was reading through Xen 3 user manual and saw this tap:aio should be used instead of loopback... Then I came to do that, but I can get it working with replacing `file'' URI''s with `tap:aio''. My OS: Debian Lenny 2.6.26-2-xen-amd64 DomU Xen configuration file: kernel = ''/boot/vmlinuz-2.6.26-2-xen-amd64'' ramdisk =

Processing commands for control at bugs.debian.org: > forcemerge 582363 582364 421825 442380 517007 Bug #582363 [src:xen] xen-utils-3.4: blktapctrl not started by default Bug #582363 [src:xen] xen-utils-3.4: blktapctrl not started by default The source xen and version 3.0.3-0-2 do not appear to match any binary packages The source xen and version 3.1.0-2 do not appear to match any binary

Hi there I am analyzing disk performance. I'm testing raw (tap: aio) and lvm (phy :). The tests I'm doing on a SLES11SP3, cpu I7, 4GBRam, disco-SATAII 7200rpm. With phy: lvm achievement 70-80MiB / s (an acceptable value) With tap: aio: file.raw achievement 5-9MiB / s, which is very low ... 10MiB / s is what you should expect access to a tap: aio: file.raw? or I have something

Hello! First, I must mention that I am not too experienced with virtual machines, so please be gentle :-) It''s my first experiment, and I''ve been working on getting things to work during the past weeks. I''m getting close, but now it seems I''m completely stuck. I''m in the process of testing Xen with Open Nebula, but I have run into some problems.

Hello, I''m running Xen 3.0.4 on a test server and I''ve been having several file system corruption problems using the tap:aio driver. This message shows up in dmesg on different machines. EXT2-fs error (device sda1): ext2_check_page: bad entry in directory #114914: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0 EXT2-fs error (device sda1):

Hi, xen-3.0.3-41.el5 on RHEL5.1 I''m trying to use tap:aio thusly: disk = [ ''file:/var/lib/xen/images/webmail.golden.net.img,hda,w'' _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

Can anyone explain to me why tap:aio sucks so badly? We''ve got numerous CentOS 5 dom0s running file-backed domUs with tap:aio. The moment any one of them starts doing something disk-intensive, idle CPU in dom0 decreases, iowait increases, and disk IO for every other domU on the system suffers. Where lies the problem, and what to do about it? Sincerely, Ray Barnes