This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Remus blktap2 issue

To: Xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Remus blktap2 issue
From: Jonathan Kirsch <kirsch.jonathan@xxxxxxxxx>
Date: Wed, 8 Sep 2010 11:33:18 -0700
Delivery-date: Wed, 08 Sep 2010 11:34:08 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=xoCrv6b8iYS5Gqp183UUu0ZgzlqufRPAvRU6PXgcNvk=; b=Zd40X1YkX3PrToquR77DXrwqAABapcZkWHgbut6u3QDvDsfmiV2jmZIZIbOEW0c3xT 5E9uNDGrsHXMpcKu3qS0TDXMxSLXgPry399Sy1ftB77H/KpGZotBm//FV1mUCHvpdu1Z YeaqxTCqb3GibE0aIXMuGygzg/ORRv+AYGaXQ=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=B+9znfERYhZr7up3KoVeL1q1HQz3Vo1Rq2ADLHneKkcPSYiCUpsV5lLbpeL1ddNeMJ MpBlRJplzpKYneKPNcQ/K1SnWZtqOcznU3PST2Y584yKiqx6e9AKH7nvMirO4QNqhYUR 9VKXM5QHO3X8AEXdCUrh4OcL/GjUKDh9htUlA=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTinK4M86N2_aTQ-J0ctDRQZqgfodx8b6z_JB73HR@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AANLkTinCyWjaSwGQT7bWL7=tkF_xQe3ABeosAusr+mjg@xxxxxxxxxxxxxx> <20100908060101.GE2804@xxxxxxxxxxx> <AANLkTinK4M86N2_aTQ-J0ctDRQZqgfodx8b6z_JB73HR@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

Thanks a lot for the patch.  Unfortunately, this did not solve the problem for me (after applying the patch on both primary and backup, rebuilding and installing xen/tools/stubdom, and then rebooting both hosts).  The backup is still unable to create the disk device when the fail-over occurs.  Thus, although I see checkpoint traffic flowing from primary to backup, the state of the backup's disk image is never modified (as judged by the image's last-modified time).  The backup does switch from "paused" to "running," but it consumes 100% CPU and when I connect to its vnc console it is as if the VM is frozen.  So *something* is being transferred, because I do see the screen from the primary, but obviously all is not right, because I can't interact with it at all.

Out of curiosity, in your working Remus deployment, which dom0 kernel are you running (and which version of Xen)?  I'm running Xen 4.0.1 and the pvops dom0 kernel.  My understanding was that Remus supported pvops dom0 2.6.31.x. 

Any other ideas regarding what this might be a symptom of?  My naive interpretation is that it is not a networking configuration problem (since state is being transferred), but that it has something to do with setting up the tapdisk via tapdisk2.


On Wed, Sep 8, 2010 at 1:50 AM, Shriram Rajagopalan <rshriram@xxxxxxxxx> wrote:
Its not just the tap2:remus:....

there is a bug lurking in the in tools/python/xen/remus/device.py in ReplicatedDisk class. The regular _expression_ scans the domU config for only tap:tapdisk:remus... or tap:remus.. disk types only. I was able to get it working by fixing that regexp.
This applies for xen 4.0.1 only. Am not sure about xen unstable.
 Here is a patch that might be of help to you (its rather crude but heck I was too lazy :) )
diff -r b536ebfba183 tools/python/xen/remus/device.py
--- a/tools/python/xen/remus/device.py  Wed Aug 25 09:22:42 2010 +0100
+++ b/tools/python/xen/remus/device.py  Fri Sep 03 08:47:13 2010 -0700
@@ -36,10 +36,13 @@
         # to request commits.
         self.ctlfd = None
-        if not disk.uname.startswith('tap:remus:') and not disk.uname.startswith('tap:tapdisk:remus:'):
+        if not disk.uname.startswith('tap2:remus:') and not disk.uname.startswith('tap:remus:') and not disk.uname.startswith('tap:tapdisk:remus:'):
             raise ReplicatedDiskException('Disk is not replicated: %s' %
-        fifo = re.match("tap:.*(remus.*)\|", disk.uname).group(1).replace(':', '_')
+        if disk.uname.startswith('tap2:remus:'):           
+            fifo = re.match("tap2:.*(remus.*)\|", disk.uname).group(1).replace(':', '_')
+        else:
+            fifo = re.match("tap:.*(remus.*)\|", disk.uname).group(1).replace(':', '_')
         absfifo = os.path.join(self.FIFODIR, fifo)
         absmsgfifo = absfifo + '.msg'

On Tue, Sep 7, 2010 at 11:01 PM, Pasi Kärkkäinen <pasik@xxxxxx> wrote:
On Tue, Sep 07, 2010 at 03:28:32PM -0700, Jonathan Kirsch wrote:
>    Hello,
>    I have been playing around with Remus on Xen 4.0.1, attempting to
>    fail-over for an HVM domU.
>    I've run into some problems that I think could be related to tapdisk2 and
>    its interaction with how one sets up Remus disk replication in the domU
>    config file.
>    A few things I've noticed:
>    -The tap:remus:backupHostIP:port|aio:imagePath notation does not work for
>    me, although this is what is written in the Remus documentation.  However,
>    I have found the following to work (i.e., not complain when starting
>    domU), so this is what I've been using:
>    tap2:remus:backupHostIP:port|aio:imagePath...

Yeah, this stuff was changed in Xen 4.0.1:

I guess someone should update the remus wiki page.

-- Pasi

Xen-devel mailing list

perception is but an offspring of its own self

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>