Isso é menos preocupante do que parece à primeira vista.
Primeiro, quando especificar um IP do host do Gluster durante a montagem do cliente (seja com FUSE ou libgfapi), você estará usando apenas para análise de pares. Uma vez completada essa análise, a libfgapi trata da comunicação entre todos os pares investigados, no (s) IP (s) que eles fornecem quando sondados.
Tudo isso é ótimo até o host que seu teste por IP explícito é desativado. Existem algumas coisas que você pode fazer para evitar que isso aconteça. Keepalived ou ctdb podem fornecer um IP flutuante que você usaria apenas para análise de cliente para servidor. Alternativamente, um round-robin de DNS fará isso com nomes.
Esse nome ou IP flutuante não será usado para enviar dados para os volumes do Gluster, mas será apenas para garantir que o rastreamento sempre aconteça, mesmo em um ambiente degradado.
Com o libvirt, isso acaba ficando assim:
<driver name='qemu' type='qcow2' cache='none'/>
<source protocol='gluster' name='kvm/test.img'>
<host name='gluster-probe' port='24007'/>
</source>
<target dev='vda' bus='virtio'/>
</disk>
Neste caso, eu implementei um round-robin de DNS fora do libvirt para que eu possa ter certeza de que esse nome sempre será resolvido para um host no conjunto de peers do gluster, contanto que pelo menos um esteja ativo. Depois de entrar em contato com um, ele obtém a lista completa, conecta-se aos hosts dessa lista por meio do IP e, em seguida, se movimenta com alegria.