similar to: The future of blktap in Xen4CentOS

On 05/06/2015 09:27 AM, George Dunlap wrote: > On Tue, May 5, 2015 at 2:07 PM, Johnny Hughes <johnny at centos.org> wrote: >> WRT a new kernel .. the 3.18.x kernel has been selected to be maintained >> as an LTS until Jan 2017. I think we should start work on rebuilding >> this kernel and using it in the x4c projects. >> >> https://lwn.net/Articles/636289/

Hi, I''ve been working on getting a working blktap driver allowing to access ceph RBD block devices without relying on the RBD kernel driver and it finally got to a point where, it works and is testable. Some of the advantages are: - Easier to update to newer RBD version - Allows functionality only available in the userspace RBD library (write cache, layering, ...) - Less issue when

Hi, I''d like to use the blktap utils from https://github.com/xen-org/blktap because of the mirror feature, as the blktap utils comming with xen does not support this. Could anybody explain why there are two different blktap utils (one in git and one comming with xen source) and how to compile the one from git so that it works with libxl ? Any pointers greatly appreciated ;-) Thanks

Thanks to work from Johnny, linux 3.18.12 with all the x4c blktap goodness have been built and are now in the virt6-testing repo. I've also uploaded libvirt 1.2.15. As you may have seen earlier today, virt6-testing also includes an updated 4.4.2 package with the latest security update (XSA-133). The kernel has had some basic testing (by myself, Johnny, and another community member), but

On Fri, Apr 24, 2015 at 4:32 AM, Pasi K?rkk?inen <pasik at iki.fi> wrote: > On Thu, Apr 23, 2015 at 05:09:56PM +0100, George Dunlap wrote: > > I've got Xen 4.4.2 in virt6-testing. I haven't had a chance to test > > it, and won't for another week or two; but if some volunteers can put > > it through its paces, I can ask Johnny to push it to the public repo

On Sat, May 16, 2015 at 2:08 PM, Johnny Hughes <johnny at centos.org> wrote: > On 05/13/2015 01:14 PM, George Dunlap wrote: >> Thanks to work from Johnny, linux 3.18.12 with all the x4c blktap >> goodness have been built and are now in the virt6-testing repo. I've >> also uploaded libvirt 1.2.15. As you may have seen earlier today, >> virt6-testing also

All, I have compiled an experimental 3.18.12 kernel from the 3.18 LTS kernel branch from kernel.org for the Xen4Centos 6 tree. http://people.centos.org/hughesjr/xen-kernel/x86_64/ This should be considered extremely experimental at this point and is unsigned. I have tested it on 2 generic servers and it worked fine on both of those with sata and gigabit ethernet. Please test this and provide

This patch series copies the core of the tapdisk process from blktap2, with updates coming from blktap2.5. Signed-off-by: Thanos Makatos <thanos.makatos@citrix.com>

KB and I were looking at repositories to import into git.centos.org recently, and we found the e1000e package -- a rebuild of the Intel e1000 driver for the x4c kernel. Does anyone know if this externally-build module is still necesssary for Linux 3.10? Or for Linux 3.14, which we're planning on moving to at some point in the near future? -George

Package: blktap-dkms Version: 2.0.93-0.2 Severity: serious Justification: fails to build from source (but built successfully in the past) The build fails on 3.14 kernel with the following error: /var/lib/dkms/blktap/2.0.93/build/ring.c: In function ?blktap_ring_make_tr_request?: /var/lib/dkms/blktap/2.0.93/build/ring.c:314:32: error: ?struct bio? has no member named ?bi_sector?

Package: wnpp Severity: wishlist Owner: Debian Xen Team <pkg-xen-devel at lists.alioth.debian.org> * Package name : blktap-dkms Version : 2.0.90 Upstream Author : Jon Ludlam <jonathan.ludlam at eu.citrix.com> * URL : http://www.xen.org/ * License : GPL-2 Programming Lang: C Description : Xen blktap kernel component DKMS package This package

This patch series introduces the shared ring used by the front-end to pass request descriptors to tapdisk, as well as responses from tapdisk to the front-end. Requests from this ring end up in tapdisk''s standard request queue. When the tapback daemon detects that the front-end tries to connect to the back-end, it spawns a tapdisk and tells it to connect to the shared ring. The shared

Hello, I''ve recently setup a Linux Dom0 with a 3.0.17 kernel and Xen 4.1.2, and since the 3.x series doesn''t have blktap support I''m using qdisk to attach raw images. I''ve been playing with small images, something like 1GB, and everything seemed fine, speed was not fantastic but it was ok. Today I''ve set up a bigger machine, with a 20GB raw hdd and the

$ git checkout RELEASE-4.2.2 $ git clean -ffdx [do a build, install, reboot] $ xl create a0 $ xl cd-eject a0 hdc [However, the guest OS still sees the CD inserted] $ xl block-list a0 Segmentation fault $ xl cd-insert a0 hdc file:/images/xs-tools-6.0.0.iso Segmentation fault The problem seems to be that xl cd-eject is writing corrupt values to xenstore. Note that vbd/1/5632 is still there

Hi folks, I met a problem: when 6 VM reboot at the same time, 3:00 morning, the Dom0 reboot it self: Xen version is 4.0.0, VMs are windows 2003 with redhat pv, they will update and reboot itself every 3:00 AM. # last ... ... admin pts/0 10.247.1.1 Fri Jun 25 03:40 - 04:30 (00:50) reboot system boot 2.6.31.13 Fri Jun 25 11:16 (00:-3) admin pts/0

Hi folks, I met a problem: when 6 VM reboot at the same time, 3:00 morning, the Dom0 reboot it self: Xen version is 4.0.0, VMs are windows 2003 with redhat pv, they will update and reboot itself every 3:00 AM. # last ... ... admin pts/0 10.247.1.1 Fri Jun 25 03:40 - 04:30 (00:50) reboot system boot 2.6.31.13 Fri Jun 25 11:16 (00:-3) admin pts/0

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> When disk is a cdrom and the drive is empty the "params" node in xenstore might be missing completely: cope with it instead of segfaulting. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- hw/xen_disk.c | 16 +++++++++++----- 1 files changed, 11 insertions(+), 5 deletions(-) diff --git

Do we want to move the Xen4CentOS kernel to new LTS 3.10.x from the current 3.4.x Kernel? If so, can we start testing the that kernel build? Is someone from Xen.org working on porting the xen specific patches that are required in the 3.10.x kernel from the ones we have in the 3.4.x tree in Xen4CentOS? The only one I know we need is the blktap module. I have created a new spec that builds a

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Attendees: Lars, Lokesh, George, KB (eventually) Docker update: - - Docker 1.3.1 for virt7-testing Xen update: - Xen 4.4.1 in virt6-testing - Can't do a release of xen without libvirt because libvirt depends on a specific version of libxl - Plan: update to libvirt-1.2.9 before test then release Signing - C7 we want to use the CBS signing

Hey all! Just a reminder, the CentOS Virt SIG meeting is tomorrow, 2pm, on #centos-devel (freenode IRC). Agenda items I've got: * Xen 4.4.1 for C6 update (finally) - Got xen 4.4.1 w/ updated XenServer blktap working, + libvirt - Other changes to consider: xend off by default, revert "favor qdisk" change * oVirt joining SIG? * Meetings over Christmas - proposal: Cancel phone