[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.