BLKTAP

BLKTAP

[Michael A. Collins]

I noticed recently that there is no real easy way to get the kernel driver
for blktap working in mainline.  I've pulled down the source from Daniel
Stodden's linux git tree on xensource, but it looks like it's for debian and
I'm running Fedora 14, so I'm trying to sort it out.  I run the 3.1.x kernel
and don't want to go back to the 2.6.32 that Jeremy has, which has the
blktap driver in it.  Is there anything out there that will patch a 3.1.x
mainline kernel to include the blktap driver?  I want to try out drbd/remus,
but it's not going anywhere at the moment.  Thanks.
Mike

Re: BLKTAP

[Shriram Rajagopalan]

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

On Sun, Nov 20, 2011 at 4:45 PM, Michael A. Collins <
mike.a.collins@ark-net.org> wrote:

> I noticed recently that there is no real easy way to get the kernel driver
> for blktap working in mainline.  I've pulled down the source from Daniel
> Stodden's linux git tree on xensource, but it looks like it's for debian
> and
> I'm running Fedora 14, so I'm trying to sort it out.  I run the 3.1.x
> kernel
> and don't want to go back to the 2.6.32 that Jeremy has, which has the
> blktap driver in it.  Is there anything out there that will patch a 3.1.x
> mainline kernel to include the blktap driver?  I want to try out
> drbd/remus,
>

drbd/remus - why  do you need blktap ?

shriram

> but it's not going anywhere at the moment.  Thanks.
> Mike
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

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

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

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

Re: BLKTAP

[Michael A. Collins]

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

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|

 

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.  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.  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. 

 

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


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

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

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

Re: BLKTAP

[Shriram Rajagopalan]

[-- 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

Re: BLKTAP

[Michael A. Collins]

On 22.11.2011 01:56, Shriram Rajagopalan wrote:

> 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.]>

The drbd:<resource> syntax works for xm, but not for xl.  I'll have to 
work on that.  Below is what xl spits out trying to create the domain.

dc.xl: config parsing error in disk specification: unknown value for 
format: near `xvda' in `drbd:dc,xvda,w'

> 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
> [5], 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
>
>>
>> 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 ?
>>  
>>
>> shriram

I am interested in running the latest drbd changes with remus.  But I 
am interested in getting this to work through the xl interface more than 
anything.



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

Re: [Xen-users] BLKTAP

[Florian Heigl]

2011/11/22 Michael A. Collins <mike.a.collins@ark-net.org>:
> On 22.11.2011 01:56, Shriram Rajagopalan wrote:
>
>> 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:...).
> The drbd:<resource> syntax works for xm, but not for xl.  I'll have to work

That's what I ended up with, too

>> 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.

wasn't there something in remus that demands you have a drbd: device
if you're not using blktap?

>> I see that there is a nice howto for debian on remusha.wikidot.com
>> [5], 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
>>
>>>
>>> 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 ?
>>>
>>>
>>> shriram
>
> I am interested in running the latest drbd changes with remus.  But I am
> interested in getting this to work through the xl interface more than
> anything.

Currently there's no alternate reality available in which one can run Remus?
blktap - not really there (and it would have other nice features)
dr:bd - doesn't play with xl
xm - not supposed to use that any more
older distros - will not take remus patches i guess
older howtos - broken since Remus is already part of Xen by now

(And I don't think it will get better by pointing at a workaround else
if one thing that should work isn't working.
Instead, soon, it will no longer work at all)

Re: [Xen-users] BLKTAP

[Shriram Rajagopalan]

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

On Tue, Nov 22, 2011 at 7:29 AM, Florian Heigl <florian.heigl@gmail.com>wrote:

> 2011/11/22 Michael A. Collins <mike.a.collins@ark-net.org>:
> > On 22.11.2011 01:56, Shriram Rajagopalan wrote:
> >
> >> 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:...).
> > The drbd:<resource> syntax works for xm, but not for xl.  I'll have to
> work
>
> That's what I ended up with, too
>
> >> 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.
>
> wasn't there something in remus that demands you have a drbd: device
> if you're not using blktap?
>
> >> I see that there is a nice howto for debian on remusha.wikidot.com
> >> [5], 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
> >>
> >>>
> >>> 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 ?
> >>>
> >>>
> >>> shriram
> >
> > I am interested in running the latest drbd changes with remus.  But I am
> > interested in getting this to work through the xl interface more than
> > anything.
>
>
Well, there is no xl support for remus as of yet. The main barrier being
the disk specification issue (mentioned below) and libnetlink interface to
manipulate
the VM's network interface. Am working on that.


> Currently there's no alternate reality available in which one can run
> Remus?
> blktap - not really there (and it would have other nice features)
> dr:bd - doesn't play with xl
>

its drbd btw :).
can u just start a domain with drbd backend disk? (no remus) or anything.
I mean using the drbd:<resourceName> syntax (as described in the DRBD
website)
or using the "script=drbd,backendtype=phy,format=raw,target=resourceName"
syntax in xl.

 I have tried and it doesnt work. xl defaults (hardcoded?) to tap backend.
doing a grep in the tools/libxl directory, I can see that there is no
implementation
for invoking the script supplied as part of disk spec.

if (disk->script) {
        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts"
                   " not yet supported, sorry");
        rc = ERROR_INVAL;
        goto out_free;
    }




> xm - not supposed to use that any more
> older distros - will not take remus patches i guess
> older howtos - broken since Remus is already part of Xen by now
>
> (And I don't think it will get better by pointing at a workaround else
> if one thing that should work isn't working.
> Instead, soon, it will no longer work at all)
>
>

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

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

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

Re: [Xen-users] BLKTAP

[Michael A. Collins]

On 22.11.2011 12:27, Shriram Rajagopalan wrote:
>
> its drbd btw :).
> can u just start a domain with drbd backend disk? (no remus) or
> anything.
> I mean using the drbd: syntax (as described in the DRBD website)
>  or using the
> "script=drbd,backendtype=phy,format=raw,target=resourceName" syntax 
> in
> xl.
>  
>  I have tried and it doesnt work. xl defaults (hardcoded?) to tap
> backend.
> doing a grep in the tools/libxl directory, I can see that there is no
> implementation
>  for invoking the script supplied as part of disk spec.
>
> if (disk->script) {
>         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block
> scripts"
>                    " not yet supported, sorry");
>          rc = ERROR_INVAL;
>         goto out_free;
>     }
>
>  


That's cool, and explains alot.  I had not figured that libxl didn't 
have the capability of executing block scripts.  I will wait patiently 
and try to assist in any way to test any changes needed to provide libxl 
support to remus.
Mike

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