Re: BLKTAP

[Shriram Rajagopalan <rshriram@cs.ubc.ca>]

[-- Attachment #1.1: Type: text/plain, Size: 3705 bytes --]

On Mon, Nov 21, 2011 at 6:04 PM, Michael A. Collins <
mike.a.collins@ark-net.org> wrote:

> *From:* Shriram Rajagopalan [mailto:rshriram@cs.ubc.ca]
> *Sent:* Monday, November 21, 2011 12:03 AM
> *To:* Michael A. Collins
> *Cc:* xen-devel@lists.xensource.com; xen-users@lists.xensource.com
> *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

[-- Attachment #1.2: Type: text/html, Size: 7960 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel