similar to: How many block device in domU supports?

Hi: Recently I have some study on linux container(lxc), which is a light weight OS level virtualization. With the previous knowledge of tapdisk, I have an assumption that, I may could use the vhd for each container to seperate the storage of all containers, or even in later days, vhd is stored in distributed storage, container could be migrated. Build filesystem on tapdev

# HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1316609964 -3600 # Node ID b43fd821d1aebc8671e684bfc285cda7a6002ff1 # Parent 206afa070919e3fe0b13a03f870ca2da44ab604a libxl: attempt to cleanup tapdisk processes on disk backend destroy. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 206afa070919 -r b43fd821d1ae

Changes: tools/blktap: remove unneeded pointer dereferencing in convert_dev_name_to_num tools/blktap: constify string arrays in convert_dev_name_to_num tools/blktap: fix params and physical-device parsing tools/blktap: remove unneeded pointer dereferencing from img2qcow.c tools/blktap: remove unneeded pointer dereferencing from qcow2raw.c tools/blktap2: fix build errors caused by Werror in

--------------------------------------------------------------------------- Backport of the following patch from development: # User Ian Campbell <[hidden email]> # Date 1309968705 -3600 # Node ID e4781aedf817c5ab36f6f3077e44c43c566a2812 # Parent 700d0f03d50aa6619d313c1ff6aea7fd429d28a7 libxl: attempt to cleanup tapdisk processes on disk backend destroy. This patch properly terminates the

blktap2: fix makefile of vhd for parallel make With parallel make, libvhd might not be created before link resulting in link error. This patch guarantees it. Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp> diff --git a/tools/blktap2/vhd/Makefile b/tools/blktap2/vhd/Makefile --- a/tools/blktap2/vhd/Makefile +++ b/tools/blktap2/vhd/Makefile @@ -12,6 +12,9 @@ CFLAGS +=

Hi sahil: I think the reason why you cannot get page shared is due to the gref you got. Gref is responsible for a page allocated from domU, in my understanding it should not be 0, that is a gref 0 can not be shared, that''s why I skip gref 0 to be nominated. The gref is nominated to Xen and later used to find a corrspond MFN, so it shall not always be the same.

We''ve been working on getting XEN 4.1.2 validated for internal use and have run into what appears to be a livelock induced failure in properly freeing a blktap2 device. We ported the blktap2 driver from Dan Stodden''s GIT tree into 3.2.x which is a reasonably straight forward process. We are also running the toolchain with a patch which Ian Campbell posted in order to get xl to

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

Package: xcp-xapi Version: 1.3.2-6 Severity: normal Tags: upstream Normally (in 'iso-based' XCP) is possible to attach VDI to dom0. That operation usually looks like: xe vbd-create vdi-uuid=... vm-uuid=(dom0 uuid) device=N xe vbd-plug I done those steps in xcp-xapi and got success (no error), but no xvd* device found. Here operations log: # xe vbd-create

Hi all, I had met with a question about vhd format when i install xen 4.2.0 source code on suse11_x86_64_sp2. execute steps: 1)Install fully suse 11 sp2 to host pc 2)Boot from Xen kernel menu 3)Download xen 4.2.0 source code from http://xen.org/download/index_4.2.0.html 4)Download bin86-0.16.19.tar.gz cmake-2.8.9.tar.gz Dev86src-0.16.19.tar.gz gettext-0.18.1.1.tar.gz

For those wanting to know how to mount filesystems through blktap2 here is how you do it, as I couldn''t find it fully documented. The instructions on the blktap2 readme file are rather out of date. You can mount them under Dom0 like so. e.g. to mount a vhd file, sudo xm block-attach 0 tap2:vhd:/home/xen/xenwin7-persist.vhd xvdb w 0 Now the device should appear under /dev ls

Guys, I'm trying to compile the Xen 4.0.0 via debian/rules makefile but I got this: administrativo at sid01:~/xen/xen-4/xen-4.0.0$ make -f debian/rules build-tools ..... make -C lib all make[7]: Entering directory `/home/administrativo/xen/xen-4/xen-4.0.0/debian/build/build-tools/tools/blktap2/vhd/lib' make[7]: Nothing to be done for `all'. make[7]: Leaving directory

Hi. I make xen and xen-tools from source (xen-testing.hg). I tried to use tap:tapdisk:vhd, but blktap2 driver not available (in xend.log: WARNING: using deprecated blktap module) How i can install this driver ? My kernel "2.6.32-4-xen-amd64" from Debian Sid. Thanks. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com

Hi, I''ve been testing Xen 4.0.1 with kernel 2.6.34.5 + http://gentoo-xen-kernel.googlecode.com/files/xen-patches-2.6.34-4.tar.bz2, and one of the things that I noticed immediately is there are two problems with tapdisk and this combination. First, the syntax "disk = [''tap:tapdisk:aio: ..." no longer works. When tested with HVM domU, it boots, but there was no disk

Hello, I have a problem with storage over NFS (NFS server is running on Open Solaris 10 with NFS version client/server/min/max=3) cat /var/log/messages from cnode1 (XCP 1.0 beta) during instalation new VM: an 18 22:57:37 cnode1 tapdisk[9661]: ERROR: errno -88 at vhd_complete: /var/run/sr-mount/2d5ed3ca-7e4d-bceb-f959-542d3bade15e/3d69f4a6-743d-486e-8a65-1734e6ef0b67.vhd: op: 2, lsec:

Hi, I''m currently trying xen 4.1.1 with the 3.0.0-rc5 (heard that it now contains the xen code to run as front or back xen domain). Everything seems to run fine, except that I am trying since a few hours to mount a .vhd file in the dom0. What I tried so far: to create a blank vhd file (this is working): host# vhd-util create -n /storage/test.vhd -s 20G Then i try to mount the file

Add ''-C'' (nocow) option to vhd-util create. Btrfs has terrible performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files (since having copy on write for this kind of data is not useful). According to ''chattr'' manpage, NOCOW

Package: src:blktap Version: 2.0.90-3 Severity: normal Tags: sid stretch User: debian-gcc at lists.debian.org Usertags: ftbfs-gcc-5 Please keep this issue open in the bug tracker for the package it was filed for. If a fix in another package is required, please file a bug for the other package (or clone), and add a block in this package. Please keep the issue open until the package can be built

# HG changeset patch # User Brendan Cully <brendan@cs.ubc.ca> # Date 1252699253 25200 # Node ID 92b42ec8a5677679e5841033544bf82606c3cfd3 # Parent d2a32e24fe504b9626e6732b4f213c7cb1bc8b57 blktap2: Fix off-by-one error in driver lookup diff --git a/tools/blktap2/drivers/tapdisk-server.c b/tools/blktap2/drivers/tapdisk-server.c --- a/tools/blktap2/drivers/tapdisk-server.c +++

uname -a:Linux DC26 2.6.30.10 #1 SMP Wed Jun 2 04:34:53 PDT 2010 i686 i686 i386 GNU/Linux OS:CentOS5.5 build xen #make all Errors: include -I../../../tools/libxc -I../../../tools/include -I ../../../tools/libaio/src -I ../../../tools/memshr -D_GNU_SOURCE -DUSE_NFS_LOCKS -DUSE_GCRYPT -c -o tapdisk-queue.o tapdisk-queue.c In file included from tapdisk-queue.c:44: libaio-compat.h:82:3: