The error message "Host 192.168.0.11 is not in 'Peer in Cluster' state" typically occurs when the initiating node doesn't recognize itself as part of the trusted storage pool. While your gluster peer status shows all nodes are properly connected from each other's perspective, the volume creation command fails because the initiating node's self-perception is incorrect.

First, let's confirm the cluster status from all nodes. Run this on each server:

gluster peer status
gluster pool list

You should see consistent output across all nodes. If any node shows discrepancies, it indicates communication issues.

Here are the most likely reasons and solutions:

1. Firewall or Network Connectivity

Ensure all required ports are open (24007-24008 by default) between all nodes. Test connectivity:

for host in 192.168.0.{11..14}; do
    nc -zv $host 24007
    nc -zv $host 24008
done

2. Hostname Resolution

GlusterFS is particular about hostnames. Verify that:

hostname -f

returns the same name across all nodes and matches what's in /etc/hosts.

3. Glusterd Service Issues

Restart the glusterd service on all nodes:

systemctl restart glusterd
systemctl status glusterd

After troubleshooting, here's how to properly create your distributed replicated volume:

# From any node (not necessarily 192.168.0.11)
gluster volume create gv0 replica 2 \
  192.168.0.11:/export/brick1 \
  192.168.0.12:/export/brick1 \
  192.168.0.13:/export/brick1 \
  192.168.0.14:/export/brick1

gluster volume start gv0

After volume creation, verify with:

gluster volume info gv0
gluster volume status gv0

You should see all bricks participating and the replica pairs properly formed.

• Always use fully qualified domain names (FQDNs) in production
• Consider using force option only when absolutely necessary
• For production environments, use at least GlusterFS 7.x or newer

---

When setting up a GlusterFS 3.4 cluster with four nodes (192.168.0.11-14), you might encounter this puzzling error during volume creation:

volume create: gv0: failed: Host 192.168.0.11 is not in 'Peer in Cluster' state

This occurs despite successfully probing all peers and verifying connectivity through gluster peer status.

GlusterFS requires bidirectional peer relationships for volume creation. While you've probed from 192.168.0.11 to others, the local host (192.168.0.11) needs to recognize itself as a peer too.

Here's how to verify the complete peer status:

# On each node, check peer status
gluster peer status

# Check pool list for comprehensive view
gluster pool list

The correct approach involves establishing complete peer relationships before volume creation:

# From each node, probe all other nodes (including itself)
for node in 192.168.0.{11..14}; do
    gluster peer probe $node
done

# Verify full connectivity
gluster pool list

Once all nodes are properly peered, create your volume from any node:

gluster volume create gv0 replica 2 \
    192.168.0.11:/export/brick1 \
    192.168.0.12:/export/brick1 \
    192.168.0.13:/export/brick1 \
    192.168.0.14:/export/brick1

gluster volume start gv0

For thorough cluster health checking:

# Check volume info
gluster volume info

# Examine brick status
gluster volume status gv0 detail

# Verify self-heal status (for replicated volumes)
gluster volume heal gv0 info

• Firewall blocking ports 24007-24009/tcp
• Inconsistent hostname resolution across nodes
• Missing reverse DNS entries
• Clock synchronization issues (NTP not configured)

For production environments, consider adding these checks to your deployment scripts:

#!/bin/bash
# Verify NTP synchronization
ntpstat || echo "Warning: NTP not synchronized"

# Check firewall rules
iptables -L | grep 24007 || echo "Warning: GlusterFS ports might be blocked"

# Validate DNS resolution
for node in 192.168.0.{11..14}; do
    host $node || echo "DNS resolution failed for $node"
done