Je cherche à fiabiliser mon installation, notament lors de coupures de courant.
Voici la partie de mon install qui nous interresse:
Nuc Hystou (avec ESXI 6.5)
VM Home Assistant
RFXCOM
AEON Stick Z-Wave
VM Unifi Controller
VM Jeedom
Nas Synology
Onduleur eaton (sur lequel sont branchés tous les éléments de mon coffret communication
Problèmes / actions suite à coupure de courant (+onduleur vidé) pour relancer mon installation:
Allumer (manuellement) le nas
Allumer (manuellement) le nuc
Réparer la VM HA
→ Impossible de redémarrer la VM sinon
En fait après un « arret brutal » du nuc, sur cette VM j’ai l’erreur « File system specific implementation of LookupAndOpen[…] failed »
Pour résoudre le problème je dois lancer la commande suivante en ssh sur mon nuc:
vmkfstools -x repair chemin_de_la_vm_a_réparer.vmdk
Relancer les VMs
Réparer l’intégration de mon RFXCOM
→ Sinon les capteurs ne remontent plus aucune info (mais les actionneurs fonctionnent)
Pour ce faire, je suis obligé d’arrêter la VM HA, ajouter le RFXCOM à ma VM Jeedom, vérifier que je récupère des valeurs, supprimer le RFXCOM de cette VM, le rajouter à HA et redémarrer.
Si je fais juste une suppression/rajout, ça ne fonctionne pas
Si je « recharge » l’intégration, ça ne fonctionne pas
Arrêter (manuellement) l’addon Z-Wave JS qui se lance toujours automatiquement (malgré que j’ai décoché le lancement au démarrage), et qui se réinstalle meme si je le désinstalle.
Ce dernier ne peut être utilisé en meme temps que Z-Wave JS to MQTT que j’utilise
Peut être d’autres actions que j’oublie
Bref, comme vous le voyez, pas grand chose d’automatisé, et surtout je suis loin d’avoir un système qui redémarre de façon autonome si je ne suis pas sur place.
Je suppose qu’il existe peut être (je n’ai pas encore trouvé) une intégration de l’onduleur permettant de détecter la coupure de courant, et d’arrêter proprement les VMs, le nuc et le nas (et du coup les problèmes liés au RFXCOM est au VMDK à réparer), mais quid du redémarrage?
Sinon, comment automatiser les réparations RFXCOM et VM HA?
Pour l’automatisation des relances des VMs, j’ai bien tenté de l’activer dans les paramètres VMWare, mais ça ne fonctionne pas
Tu n’as pas besoin de garder l’addon ZwaveJS …Le seul impératif c’est de faire l’intégration la première fois qui active le fonctionnement en webservice
Perso je l’ai viré et ça fonctionne
Alors, après quelques heures de tentatives suite à ton post:
Version Esxi: J’ai regardé plusieurs tutos pour y arriver, mais en vain… j’ai l’impression que le problème vient du fait que je doive rajouter le driver realtek au zip (comme je l’avais fait à l’époque pour le iso de la 6.5. Je pense que je vais encore devoir y passer du temps, et débrancher le nuc pour faire cela depuis mon bureau et non en remote dans le coffret communication…
Pour l’addon ZWaveJs, je l’avais viré par le passé, puis il revenais tout seul (et se lançait seul), je l’ai reviré hier, puis après un reboot il est revenu. Aujourd’hui il n’est plus là! C’est plutôt étrange, je ne me l’explique pas, mais le principal c’est qu’il ne soit plus la :).
NUT: Je ne connaissait pas cet outil (mon onduleur servait jusqu’à présent uniquement de tampon). J’ai donc branché l’onduleur à mon NAS synology en usb, activé la prise en charges UPS, puis intégration HA (Petite vidéo intéressante sur le sujet)
Coupure des VMs depuis Esxi: j’ai tenté le tuto, mais sans je n’arrive pas encore jusqu’au bout (la commande wget n’aboutie pas, j’ai tenté l’installation, mais ça n’abouti pas encore :). Bref, je dois continuer de creuser ce point.
Configuration du hystou pour la relance automatique: Existe-il une solution pour le faire en remote, ou bien je n’ai pas le choix que de le débrancher de mon coffret comm pour le brancher sur un écran / clavier ?
Esxi 7.0: Ko a priori, il n’y a pas possibilité d’utiliser les drivers realtek a partir de la version esxi 7.0 (au max c’est la 6.7). J’ai commandé hier un nouvel ssd que je reçoit aujourd’hui (les 128gigas devenaient un peu short de toutes façon, 256 ne feront pas de mal), je lance la migration de mes VMs vers Proxmox tout à l’heure :).
Pour info, l’add on ZWave Js est à nouveau réapparu aujourd’hui dans mon supervisor, et il était démarré, c’est quand même très louche.
Pas possible ? Je suis étonné, je l’avais fait la modif de l’iso avec les drivers intel de mon nuc à tout première version de la 7.0 l’année dernière. Donc je vois pas pourquoi c’est pas possible maintenant. Un lien ?
Bon de toute façon c’est pas forcement idéal de se précipiter vers la v7.0 tant qu’elle est pas en 7.1 … C’est jamais vraiment stable avant chez Esxi.
Esxi ça fonctionne très bien sur un support bootable SD/USB …ça rends vachement plus simple les migrations
Moi, je ferai bien le test de virer les 2 add-ons zigbee et zwave, et desinstaller l’intégration zwave en laissant les entités.
Puis
réinstallation de Zigbee2mqtt, config et versificatio du webservice
réinstallation de l’intégration Zwave, en décochant la case du début. Utilisation de l’url du WS
Justement dans ce lien, ils précisent bien:
‹ Within the 7.0 releases, there are many issues with consumer network adapters, like the deprecation of VMKlinux drivers and thus the missing support for Realtek NICs, and the up and downs with the ne1000 driver. ›
J’ai commencé la migration des mes VMs vers Proxmox sur tes conseils (sur un disque tout neuf, comme ça je peux reswitcher si besoin). J’ai migré les VMs (export des *.ovf et des *.vmdk, puis recopie sous proxmox en tmp, puis import avec importovf) , pour le moment je n’arrive à ajouter au réseau qu’une seule d’entres elles, et j’ai du mal a « visualiser » les fichiers utilisés par les VMs (un peu comme le navigateur de esxi. C’est probablement que je dois encore me familiariser avec proxmox, question d’habitude, mais c’est vrai qu’après une bonne partie de la journée dessus, je patauge encore un peu :).
Synthèse du flux tel que je le comprends
Lors d’une coupure de courant:
Mon Nas (Synology), qui est branché a l’onduleur et sur lequel j’ai paramétré UPS, diffuse sur mon réseau les infos de l’onduleur, et s’éteint dès que la batterie faiblie
Proxmox va détecter la coupure via les infos reçues du NAS, va éteindre les VMs, et arrêter le NUC (tout ceci via l’installation/paramétrage de NUT sur le NUC).
Lors du retour du courant (faut-il que l’onduleur se soit totalement vidé entre les 2?):
Le Nuc va démarrer automatiquement (car paramétré dans le BIOS)
Les VMs vont se lancer automatiquement (sous réserve d’avoir coché « démarrer au boot »)
Le Nas va redémarrer automatiquement (sous réserve d’avoir coché « Redémarrer automatiquement lorsque le problème d’alimentation est résolu » dans les paramètres d’alimentation)
Sinon ça progresse pas mal:
JWave JS
Le problème de réinstallation+démarrage systématique de l’addon Zwave Js est résolu. Je n’ai pas eu à tout réinstaller, mais juste à reconfigurer l’intégration (non pas l’addon du supervisor):
Configuration → Intégration ZWave JS → Configurer → Reconfigurer le serveur, puis décocher l’utilisation de l’addon ZWave JS:
Acces réseau de certaines VMs sous Proxmox
Les VMs sont migrées sous proxmox et accessibles sur le réseau. Pour régler le problème que j’avais (en vérifiant avec ‹ ip addr ›, elles n’avaient pas d’ip réseau…), j’exécute les commandes suivantes dans les consoles des VMs qui posent problème:
sudo dhclient -r
sudo dhclient
Par contre, j’ai eu a nouveau le problème (certains VMs sans IP) à nouveau après redémarrage du nuc. Je reexecute les commandes et ça rentre dans l’ordre. Je me demande s’il y a pas un souci quelque part, sinon il faudra que j’automatise ces commandes au lancement de la VM.
Démarrage automatique du NUC lorsqu’il a du courant
La modif du Bios est faite, ça fonctionne !
Du coup, j’imagine qu’il faut obligatoirement qu’entre l’arrêt du nuc, et le retour du courant, il faut que l’onduleur se soit totalement, sinon le « trigger » du nuc « le courant est revenu » n’arrivera jamais.
Salut.
Dans la synthèse c’est ça.
Sachant que l’onduleur peut revenir online (courant de retour) n’importe quand, sans forcément avoir une coupure, il faut dans l’idéal faire les opérations dans l’autre sens. Ou annuler l’ordre d’arrêt.
J’avoue j’ai pas ça à la maison. Jusque là j’attends 15min avant de tout couper, c’est un peu moins que la durée maxi. Je jetterai un œil à l’occasion. Le premier des deux revient vers l’autre ?
Concernant les ip des vm… Personnellement je passe toutes ces petites choses en ip fixes. Ça demande un peu plus de boulot mais ça marche à tous les coups.
Yes je vais regarder ce point sur le délais (enfin, après mon retour de vacances pour maintenant :)).
Pour les IPs fixes, toute mon installation est déjà en ip fixes (65 ip fixes à la maison, déclarées au niveau de mon routeur ubiquiti USG).
Fixe dans ton cas aussi mais tu passes par un bail dhcp. Chez moi, la machine est configurée avec une ip en dur.
Donc réseau en place ou pas c’est toujours ok
Ps : j’ai scripté un truc rigolo hier… Je teste et tu me dira ton avis après les vacances
Allez un petit truc rapide (avec nut installé dans proxmox ) :
On définit les régles dans /etc/nut/upssched.conf
CMDSCRIPT /etc/nut/proxmoxmgnt.sh
AT ONBATT * EXECUTE upsonbatt
AT ONBATT * START-TIMER stopvms 600
AT LOWBATT * EXECUTE stopnuc
AT ONLINE * EXECUTE startvms
AT ONLINE * CANCEL-TIMER stopvms
Ce qui se traduit par :
En cas de panne on balance une alerte par mail et commence à compter (600 secondes) avant d’arrêter les VM
Quand on arrive au niveau de batterie critique, on arrête proxmox
Si entre-temps le courant est revenu : On relance les VM, on arrête de compter et on envoi l’info par mail
Pour traiter les actions en fonctions des états de l’onduleur :
le contenu de /etc/nut/proxmoxmgnt.sh
#!/bin/bash
case $1 in
stopvms)
for i in $(qm list | awk '{ print $1 }' | grep -v VMID); do
status=`qm status $i|awk '{ print $2 }'`
if [ "$status" = "running" ]
then
echo "Arrêt de la VM : $i"
qm shutdown $i -forceStop -skiplock
else
echo "Rien à faire sur la VM : $i, car déjà éteinte"
fi
done
;;
startvms)
for i in $(qm list | awk '{ print $1 }' | grep -v VMID); do
onboot=`qm config $i|grep onboot|awk '{ print $2 }'`
status=`qm status $i|awk '{ print $2 }'`
if [ "$onboot" = "1" ]
then
if [ "$status" = "stopped" ]
then
echo "Démarrage de la VM : $i"
qm start $i
else
echo "Rien à faire sur la VM : $i, car déjà allumée"
fi
else
echo "Rien à faire sur la VM : $i, car pas de lancement automatique"
fi
done
mail -s "Courant rétabli" your@email.com
;;
stopnuc)
shutdown -h +0
;;
upsonbatt)
mail -s "Panne de courant" your@email.com
;;
esac
Il y a encore moyen de faire mieux … mais c’est déjà un base, sachant qu’on:
arrête les VMs que si elle fonctionnent
on les relance que si elles sont en autostart et pas lancées
En complément il faut définir les mécanimes de notifications dans /etc/nut/upsmon.conf
SHUTDOWNCMD "/sbin/shutdown -h now"
HOSTSYNC 15
POWERDOWNFLAG /etc/nut/killpower
FINALDELAY 5
NOTIFYCMD /sbin/upssched
NOTIFYMSG ONBATT "%s fonctionne sur batterie"
NOTIFYMSG ONLINE "%s fonctionne de nouveau sur secteur"
NOTIFYMSG LOWBATT "%s indique une batterie faible !"
NOTIFYMSG SHUTDOWN "Le système est entrain de d'éteindre !"
NOTIFYFLAG ONLINE SYSLOG+EXEC
NOTIFYFLAG ONBATT SYSLOG+EXEC
NOTIFYFLAG LOWBATT SYSLOG+EXEC
NOTIFYFLAG FSD SYSLOG+WALL+EXEC
NOTIFYFLAG COMMOK SYSLOG+EXEC
NOTIFYFLAG COMMBAD SYSLOG+EXEC
NOTIFYFLAG SHUTDOWN SYSLOG+EXEC
NOTIFYFLAG REPLBATT SYSLOG+EXEC
NOTIFYFLAG NOCOMM SYSLOG+EXEC
#ONDULEUR
MONITOR nom@serveur 1 user password master
Voilà ce que ça donne coté service si on débranche l’onduleur
Je me permet de remonter ce topic suite à ta réponse qui me plait bien concernant la gestion de proxmox. La première question concerne ton retour sur le fonctionnement de tes scripts, es-tu satisfait ? La seconde question concerne le device sur lequel brancher mon onduleur, sur mon serveur proxmox ou plutôt sur le NAS ?
Salut.
Ça fait un moment que j’ai pas retravaillé cette partie là chez moi mais c’est surtout parce que ça fonctionne assez bien.
En ce moment j’ai quelques travaux en cours dans la maison et ça joue parfaitement son rôle.
En cas de petite interruption (démontage prise par ex) , ça continue de fonctionner. Et quand la coupure est plus longue (recablage), ça arrête tout proprement jusqu’au retour de courant.
Techniquement j’ai mis ça sur le nuc / promox. Il est configuré pour se relancer à la reprise du courant et il redémarre les VMs dans la foulée
Je l’ai mis en place et j’ai ajouté pour les lxc la commande pct ainsi q’une alerte par telegram
pour le mail j’ai ajouté -a "FROM:email@email.fr" pour permettre un envoi correcte vers le FAI
#!/bin/bash
cURL="/usr/bin/curl"
token="le token"
chat="le chatID"
case $1 in
stopvms)
for i in $(qm list | awk '{ print $1 }' | grep -v VMID); do
status=`qm status $i|awk '{ print $2 }'`
if [ "$status" = "running" ]
then
echo "Arrêt de la VM : $i"
qm shutdown $i -forceStop -skiplock
else
echo "Rien à faire sur la VM : $i, car déjà éteinte"
fi
done
for i in $(pct list | awk '{ print $1 }' | grep -v VMID); do
status=`pct status $i|awk '{ print $2 }'`
if [ "$status" = "running" ]
then
echo "Arrêt de la LXC : $i"
pct shutdown $i -forceStop -skiplock
else
echo "Rien à faire sur la LXC : $i, car déjà éteinte"
fi
done
;;
startvms)
for i in $(qm list | awk '{ print $1 }' | grep -v VMID); do
onboot=`qm config $i|grep onboot|awk '{ print $2 }'`
status=`qm status $i|awk '{ print $2 }'`
if [ "$onboot" = "1" ]
then
if [ "$status" = "stopped" ]
then
echo "Démarrage de la VM : $i"
qm start $i
else
echo "Rien à faire sur la VM : $i, car déjà allumée"
fi
else
echo "Rien à faire sur la VM : $i, car pas de lancement automatique"
fi
done
for i in $(pct list | awk '{ print $1 }' | grep -v VMID); do
onboot=`pct config $i|grep onboot|awk '{ print $2 }'`
status=`pct status $i|awk '{ print $2 }'`
if [ "$onboot" = "1" ]
then
if [ "$status" = "stopped" ]
then
echo "Démarrage de la LXC : $i"
pct start $i
else
echo "Rien à faire sur la LXC : $i, car déjà allumée"
fi
else
echo "Rien à faire sur laLXC : $i, car pas de lancement automatique"
fi
done
mail -s "Courant ok" email@email.fr -a "FROM:email@email.fr"
;;
startmail)
$cURL --data chat_id=$chat --data-urlencode "text= Courant revenu!" "https://api.telegram.org/bot"$token"/sendMessage" > /dev/null 2>&1
;;
stopnuc)
shutdown -h +0
;;
upsonbatt)
mail -s "Panne de courant" email@email.fr -a "FROM:email@email.fr"
$cURL --data chat_id=$chat --data-urlencode "text= Panne de courant" "https://api.telegram.org/bot"$token"/sendMessage" > /dev/null 2>&1
;;
esac
Voilà j’aimerai transférer ma config NUT précédemment sous proxmox vers un raspberry dédié à mon onduleur EATON PRO 650 afin de ne plus être dépendant des mises à jour proxmox.
Savez-vous s’il est possible de garder le même type de fonctionnement pour autant ? via l’API ?
Si oui est-il possible de m’aider à faire ceci ? Je peux ouvrir un sujet dédié si nécessaire.
a priori, il n’y a pas possibilité d’utiliser les drivers realtek a partir de la version esxi 7.0 (au max c’est la 6.7). J’ai commandé hier un nouvel ssd que je reçoit aujourd’hui (les 128gigas devenaient un peu short de toutes façon, 256 ne feront pas de mal), je lance la migration de mes VMs vers Proxmox tout à l’heure :).
