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
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 ? >> >> >> shriramI 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
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 workThat''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)
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) > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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