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