[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] BLKTAP
On Mon, Nov 21, 2011 at 6:04 PM, Michael A. Collins <mike.a.collins@xxxxxxxxxxx> wrote:
From: Shriram Rajagopalan [mailto:rshriram@xxxxxxxxx]
Sent: Monday, November 21, 2011 12:03 AM To: Michael A. Collins Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] BLKTAP …
drbd/remus - why do you need blktap ?
shriram
From my readings, I have found only a few examples of using remus. Most of them refer to using the following stanza in the disk section of a VM’s cfg file:
tap2:remus:backuphost:anyfreeport|
Not sure if tap2 is the right syntax.. there was some issue a while ago, between tap & tap2 syntaxes.
That doesn’t work for xl, but even using it with xm causes issues, since there isn’t a tap device without the kernel module.
correct - so far/
So I also found out that drbd uses a tap device to handle the hook in with Xen, so if you want to have automagic working with block-drbd xen scripts then you have to use tap.
eh? I dont think so. with drbd based backend for xen VMs (with or without remus), you just use the drbd:<resourceName> syntax (much like phy:...). And then the block-drbd script in /etc/xen/scripts/ takes care of the rest of the magic.
There is no tapdisk involved in this procedure.
In essence, the block-drbd script just 1. parses the drbd:<resourceName> syntax to determine which one of the /dev/drbd[X] devices belong to the <resourceName>,
2. does some sanity checks 3. promotes <resourceName> in the host to "Primary" and then
the rest of the control flow happens akin to a phy device, with /dev/drbd[X] being supplied as the path to the disk backend.
You could do this manually too in two simple steps. 1. On the host where you want to launch the VM, promote the drbd disk to Primary (ensure that the other end is in secondary state) 2. change the VM's disk config to
phy:/dev/drbd/by-res/<resourceName> and you are good to go. [Though with remus, you ll have to hack the tools/python/xen/remus/device.py script to recognize the /dev/drbd/* URI.]
With all that said and done, I’m currently running drbd 8.3.11 since that’s the version of the kernel module included with Linux 3.1, but I’m just using Xen’s phy handler for the disk section of my VM’s cfg file.
I see that there is a nice howto for debian on remusha.wikidot.com, but again it uses a 2.6.32 kernel from Jeremy’s git repo, which has the tap kernel module. I again assert that currently there is very little out there that would help to get someone started using remus with drbd in the linux 3.1.x world. I run remus at work, but it’s using shared storage and have no need to use it with drbd, but at home I don’t really want to set that up, so I thought drbd would be a nice start.
I’ve started diffing the 8.3.9 branch of drbd with your changes for remus and will see how hard it is to get that in the 8.3.11 version I’m using.
Is the remusified drbd (8.3.9) not compiling under the 3.1.x kernel anymore or are you interested in
the latest version of DRBD + the remus stuff ?
With that being said, I mostly use xl for everything at home, I don’t even have the xend service running, which makes matters worse, since I’m sure that most of remus uses the xend service and not the API to do the magic. I am willing to document my steps and post to the wiki, so that others could benefit from it!
Mike
shriram
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|