[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] GNBD: cannot connect to cluster manager ...Operation not permitted



On Mon, Jul 19, 2004 at 05:40:40PM +0200, Christian Zoffoli wrote:
> 
> Hi to all.
> I have compiled and installed all the stuff in cvs on a vanilla 2.6.7, 
> but I have a big problem when I try to export a device with GNBD:
> 
> 
> ...I've done all the steps in 
> https://open.datacore.ch/DCwiki.open/Wiki.jsp?page=GFS.GNBD.Usage
> 
> 
> ...but when I try
> 
> gnbd_export -v -e export1 -d /dev/sdb1
> 
> it fails with:
> 
> ---
> receiver: ERROR cannot connect to cluster manager : Operation not permitted
> gnbd_export: ERROR gnbd_clusterd failed
> ---
> 
> looking at the log I have found this message:
> ---
> Jul 19 20:28:13 gfs1 receiver[22551]: ERROR [gnbd_clusterd.c:53] cannot 
> connect to cluster manager : Operation not permitted

There have been a lot of people who have had this same problem.  In general
there is no reason for gnbd to have any relation to clustering.  This begs the
question, why is there a "gnbd_cluster" thread trying to talk with a cluster
manager?  IMO it's unfortunate that gnbd is doing this at all, much more so by
default, causing unnecessary problems for so many people.

AFAIK, the only way to prevent gnbd from doing this is to use the "-c Enable
caching" flag for gnbd_export.  Try using that flag and see if it helps.

Now a feeble attempt to answer the question above.  When you do a "non-caching"
export (don't use -c), gnbd assumes that it also needs to talk with a cluster
manager because it assumes that you are going to use two gnbd servers to export
the same (shared) underlying block device.  This also assumes that the clients
are using some form of multi-pathing in their volume manager.  I may be wrong
on some of that, but it's clearly not the way most people use gnbd -- people
usually have SAN's precisely to avoid using gnbd, not to do gnbd multi-pathing.

[If anything, people want to do mirroring between gnbd servers, not fail-over.
Fail-over may be useful for some people, but I'd hope it could be done without
making gnbd itself impossibly convoluted.]

-- 
Dave Teigland  <teigland redhat com>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]