Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Mon, Jun 02, 2014 at 11:07:56AM +1000, Igor Cicimov wrote: > On 02/06/2014 6:14 AM, "Lars Ellenberg" <lars.ellenberg at linbit.com> wrote: > > > > On Sat, May 31, 2014 at 10:48:09PM +1000, Igor Cicimov wrote: > > > Hi all, > > > > > > I've been searching for a solution about this but couldn't find anything > > > but couple of threads ending without any outcome. > > > > > > I have drbd-8.4.4 installed in Ubuntu-12.04 container running on > > > Ubuntu-12.04 host. I can only create the metadata and then the try to > bring > > > the resource up fails with the following message: > > > > > > root at lxc01:~# drbdadm up r0 > > > Could not connect to 'drbd' generic netlink family > > > > > > The kernel module loads fine and /proc/drbd directory exists. For sure > this > > > is not related to apparmor since I get the same issue with the service > > > stopped on the host and rules teardown. > > > > > > Has there been any solution for this or DRBD can't run inside linux > > > container at all? > > > > Possibly could be made to work. > > Or not. > > I don't know. > > > > There is a lot of things that would need to be abstracted > > into per container namespaces. I'm not even sure if all > > the infrastructure to abstract device numbers is there yet, > > even in recent kernels. > > > > *IF* it can be made to work, > > properly isolating different containers against each other would > > require ... let's say "code changes" ... in the module > > (there is only one kernel, so just one instance of this kernel module, > > there are many containers, > > it would likely need to become "container aware" on various levels). > > > > Appart from that: I don't see the use case. > > Having DRBD on the host, outside the containers, > > and replicate the containers state and content > > is a known working use case. > > > > But what for would you want DRBD *inside* the container? > > > > Why not? Its working inside vm's why not inside containers too? They are > becoming more popular as light virtualization solution so for sure this > will become necessity down the road. Are you saying this should not be > available on user level in case lets say someone wants to try a cluster of > two containers with drbd replicated device? Each VM has its own "kernel", its own "drbd" module. => works. But even there, usually you put the VM image on top of DRBD, not some DRBD inside the VM (even though that is possible). Container: does not work. Possibly could be made to work. Probably would not only require changes in DRBD module code, but in generic kernel as well. I don't know. I do not see that happening anytime soon. Maybe find someone who knows, and get them to explain to me what would be necessary to do in DRBD to make it play nice from within containers... But I really don't see why. If you create a container, you tell it what "storage" to use. Put that on top of DRBD. Done. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com