search for: blktap1

...d the current pkg-xen SVN tree. The following made it work for me... Cheers, Ian. commit e9a08d8d5afa92da73ab09b3ed53dc9f1f084381 Author: Ian Campbell <ijc at hellion.org.uk> Date: Thu Aug 15 17:14:56 2013 +0100 * debian/patches/series: Add new patch * debian/patches/qemu-without-blktap1.patch: Backport upstream patch to build qemu-traditional without blktap1, slightly modified to force this behaviour without backporting all the autoconf bits. * debian/patches/tools-disable.diff: Don't try and download qemu-xen.git tree. We get this from the system. diff...

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

...this version of Xen does not include the blktap2 backend (tapdisk2) and associated utilities (vhd-util, etc.). The decision was made to disable the blktap v1 kernel module (the default is now blktap2). As a result we can't use any tap devices which means worse performance than previousl. Since blktap1 was available in lenny this could be looked on as a regression. Please consider either adding blktap2 or reinstating the blktap1 kernel module. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux...

The kernel patch queue used by the Xen Cloud Platform domain 0 has been published at: http://xenbits.xen.org/XCP/linux-2.6.27.pq.hg This kernel has been the recipient of extensive testing and performance optimization and is actively maintained with the latest stable drivers. There is ongoing work to merge patches which are not currently upstream into the paravirtops tree or to remove the

The kernel patch queue used by the Xen Cloud Platform domain 0 has been published at: http://xenbits.xen.org/XCP/linux-2.6.27.pq.hg This kernel has been the recipient of extensive testing and performance optimization and is actively maintained with the latest stable drivers. There is ongoing work to merge patches which are not currently upstream into the paravirtops tree or to remove the

...he DISK_BACKEND_TAP case can fall through, but only if !libxl__blktap_enabled. I''m not sure I understand the intention of this code to actually remove the fall-through case though. I''m not convinced DEVICE_TAP is even valid -- it seems to create a tap entry in xenstore (e.g. is a blktap1 thing). The usage in libxl_device_disk_del seems particularly dubious to me. diff -r 403080639e20 -r 281207ed3fb3 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Tue Apr 05 17:26:32 2011 +0100 +++ b/tools/libxl/libxl.c Tue Apr 05 17:34:07 2011 +0100 @@ -1015,12 +1015,7 @@ int libxl_device_disk_add(l...

...binaries. (closes: #737905) - pygrub searches for extlinux.conf in the expected places. (closes: #697407) - Update scripts to use correct syntax for ip command. (closes: #705659) * Fix install of xend configs to not break compatibility. . [ Ian Campbell ] * Disable blktap1 support using new configure option instead of by patching. * Disable qemu-traditional and rombios support using new configure option instead of by patching. No need to build-depend on ipxe any more. * Use system qemu-xen via new configure option instead of patching. * Use system seabi...

The domU is using pygrub to boot its own 2.6.18.8-xen kernel. It can be booted successfully under 2.6.18.8-xen dom0 and xen 3.3.1. However when upgrade dom0 to 2.6.32.15 and xen 4.0.1-rc3-pre, the domU can not boot with tapdisk. I am wondering it is something related to the blktap driver. *When using tap:aio:* PATH/disk.img in domU disk configuration, the boot process hanged at a prompt: XENBUS:

The domU is using pygrub to boot its own 2.6.18.8-xen kernel. It can be booted successfully under 2.6.18.8-xen dom0 and xen 3.3.1. However when upgrade dom0 to 2.6.32.15 and xen 4.0.1-rc3-pre, the domU can not boot with tapdisk. I am wondering it is something related to the blktap driver. *When using tap:aio:* PATH/disk.img in domU disk configuration, the boot process hanged at a prompt: XENBUS:

Package: blktap-dkms Version: 2.0.93-0.10 Severity: serious User: debian-qa at lists.debian.org Usertags: piuparts Hi, blktap-dkms fails to build a module for Linux 4.12: Selecting previously unselected package blktap-dkms. (Reading database ... 34976 files and directories currently installed.) Preparing to unpack .../blktap-dkms_2.0.93-0.10_amd64.deb ... Unpacking blktap-dkms (2.0.93-0.10) ...

Hello, I''m currently trying to understand some problems I had in the past with mixing look-back with blktap(2) for HV and PV domains. I''m stuck reading the source code, so I''d like to get some help from the list. Interrupt me if I got something fundamentally wrong in my understanding so far: 1. With pure-HV the domU gets an emulated IDE (or whatever) disk. The

...akes some other things which are on their way out configurable at build time with a default depending on how far down the slope I judge them to be. * nuke in tree copy of libaio * nuke obsolete tools: xsview, miniterm, lomount & sv * make xend optional, still on by default (for now!) * disable blktap1 by default (needs qemu patch, just posted) * some cleanup of .*ignore Ian.

The contents are the wip.testme branch currently on salsa. I combined the wip.initscript and wip.oxenstored into this and added more things today. I think this is pretty gtg and it's smoke tested (in several cases by scping files around instead of doing package build), so it needs a final extra review and test round before putting it in master branch (which I don't want to force push). I

The following patches shave some rough edges off the tools build system to allow cross compiling for at least arm32 and arm64 based on the Debian/Ubuntu multiarch infrastructure. They also add the necessary fixes to build for arm64 (which I have only tried cross, not native). I have posted some instructions on how to compile with these patches on the wiki:

What are the outstanding things to do before we think we can start on the 4.2 -rc''s? Does anyone have a timetable in mind? hypervisor: * ??? - Keir, Tim, Jan? tools: * libxl stable API -- we would like 4.2 to define a stable API which downstream''s can start to rely on not changing. Aspects of this are: * event handling (IanJ working

This patch series adds support for network buffering in the Remus codebase in libxl. Changes in V3: [1/5] Fix redundant checks in configure scripts (based on Ian Campbell''s suggestions) [2/5] Introduce locking in the script, during IFB setup. Add xenstore paths used by netbuf scripts to xenstore-paths.markdown [3/5] Hotplug scripts setup/teardown invocations are now