<html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;" data-mce-style="border-left: 2px solid #1010FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div>I'm starting some gluster development and having to deal with virtual machines for test/debug seems a little bit to tedious. I was wondering if there is a way to start two (or more) servers in the same machine using different ports. Using something like that:</div><div><br></div><div> # glusterfsd -f simple-server-0.vol</div><div> # glusterfsd -f simple-server-1.vol<br clear="all"><div> # glusterfs -f simple-client.vol /mnt/data</div><div><br></div><div>where simple-server-0.vol simple-server-1.vol use different TCP ports?</div></div></div></blockquote><div><br></div><div>For translator development, I usually find it's most convenient to start glusterfsd etc. by hand with hand-crafted volfiles as you suggest. The key is to set the following options:</div><div><br></div><div> protocol/server: option transport.socket.listen-port XXXX</div><div> protocol/client: option remote-port XXXX</div><div><br></div><div>The other alternative is to do what some of our regression tests do, and start multiple glusterds bound to different addresses within the 127.x.x.x address space. See tests/cluster.rc for an example. The key command-line pieces to avoid conflicts in this case are:</div><div><br></div><div> --xlator-option management.transport.socket.bind-address=xxx</div><div> --xlator-option management.glusterd-sockfile=xxx</div><div> --xlator-option management.working-directory=xxx</div><div> --log-file=xxx</div><div> --pid-file=xxx</div><div><br></div><div>Then you can use the --remote-host option on the CLI to direct normal commands to one member of the (pseudo-)cluster. Y<span style="font-size: 12pt;">ou can also use docker/vagrant/LXC as James suggests. It's sort of a personal preference. For myself, I usually stick with the hacked-volfile approach, or (if I've added the code to generate the right volfiles) just start multiple bricks on the same machine and attach to them with gdb as needed. The other approaches are mostly useful for debugging glusterd itself, or for testing specific failure scenarios.</span></div><div><span style="font-size: 12pt;"><br></span></div></div></body></html>