RPCEnvironment init request failed

Pomyślałem o dodaniu kolejnego węzła Proxmox do klastra. Zamiast trzymać PBS na osobnej fizycznej maszynie, chciałem go zwirtualizować, tak jak w każdym innym środowisku, które stawiam. Zainstalowałem więc świeżą kopię tej samej wersji Proxmox VE i spróbowałem dołączyć do klastra. I wtedy pojawił się ten komunikat:

Connection error 500: RPCEnvironment init request failed: Unable to load access control list: Connection refused

Oraz mnóstwo innych dotyczących nazwy hosta, kluczy SSH, kworum itp. W końcu interfejs Proxmoxa przestał działać, bo nie mogłem się zalogować. Restart usług klastra kończył się jakimiś bezużytecznymi informacjami. Byłem więc trochę zaniepokojony sytuacją. Oczywiście miałem kopię zapasową wszystkiego, co działało na tej maszynie, ale przywracanie z backupu byłoby uciążliwe.

Rozwiązaniem, a raczej prowizoryczną łatką (monkey-patch), jest wyłączenie nowego węzła. Na dowolnym innym działającym węźle (najlepiej na liderze) wykonaj:

umount -l /etc/pve
systemctl restart pve-cluster

To polecenie odmontowuje i ponownie montuje system plików FUSE, a następnie restartuje usługę klastra PVE. Co było przyczyną źródłową? Właściwie nie wiem na pewno, ale podejrzewam problem z siecią albo z systemem plików, powodujący rozbieżności w rozproszonej konfiguracji. Dodałem nawet domeny wszystkich węzłów do lokalnego resolvera w pfSense, żeby mieć pewność, że to nie problem z DNS. Inna możliwość jest taka, że 2 z 4 węzłów mają dodatkowy interfejs sieciowy z bridge'em. Problemem mogą być różne systemy plików (ZFS vs XFS), ale już tak nie sądzę, bo 2 węzły mają już ZFS, a dodanie ich do klastra w przeszłości przebiegło bez żadnych problemów.

Postanowiłem nie restartować żadnych węzłów ani ich nie rozłączać, bo mogłoby to spowodować trwałą awarię. Pozostaje to więc zagadką, z prowizoryczną łatką, dzięki której wszystko znowu działa.