Bonjour à tous
Cela fait la 2ème fois que mon proxmox perd les pédalles en un an.
La 1ère fois, les VM étaient plantées alors que les containers fonctionnaient.
Après un reboot de proxmox via l’interface proxmox, tout est rentré dans l’ordre.
Depuis ce matin, j’ai un phénomène un peu similaire mais mêmes les containers semblent HS.
Pourtant certaines VM ping, mon proxmox ping aussi.
En revanche aucune réponse sur l’intrerface ni en SSH sur le proxmox.
j’ai l’impression que c’est plutôt la carte réseau du NUC de planté mais sans certitudes.
Il est à jour en 7.2
Avez vous déjà ce genre de souci ?
Je me demande si il ne fait pas trop chaud ou est le NUC. Il est dans mon garage et avec les fortes chaleurs il peut faire facilement 30 ou 35°.
Je n’ai pas eu le problème cet hiver
Du coup, ça fait un peu flipper car je vois pas d’autres solutions qu’un reboot hardware
Salut,
ça me fait un peu penser à ce que j’ai décris ici :
je pense pas que ça soit similaire. Car dans mon cas j’ai toutes les VM/LXC de plantées.
C’est plus un problème proxmox je pense.
Mon proxmox ping mais pas joignable ni en SSH ni en web,…
qinon j’ai effectivement un hub alimenté et qu’une seule petite rallonge d’1 m pour la clé conbee2
Et coté espace disque restant ?
Bonjour
Alors je ne sais pas ce que tu as en VM mais j’ai eu le même genre de soucis ces derniers temps (depuis 1 an je pense) avec un fréquence plus ou moins importante.
J’ai même acheté une prise Shelly Plus S non mise sur Jeedom pour éteindre et relancer mon NUC à distance. de cette manière Proxmox redevenait joignable via l’interface web via VPN par exemple ou reverse proxy.
Je ne sais pas si c’est lié mais à chaque fois j’avais un VM MotionEye qui tournait 32Go SSD et 8Go de Ram j’ai donc arrêter la VM pas uniquement pour ça mais car je n’avais pas le temps de m’occuper de la config.
Et ces dernières semaines j’ai décidé de me remettre dans le sujet et j’ai par contre installé un container LXC car plus léger en ressources etc… et bien même résultat on va dire Crash de proxmox !!
J’ai coupé le container et bien plus de crash !!
Donc pour mon cas cela semble ciblé sur MotionEye qui à mon sens doit avoir son système indépendant du reste
Je suis preneur de la source de ton crash pour ne pas avoir la même surprise un jour
J’ai bien une VM motion été…
Ça fait chier de l’arrêter de mon côté je m en sers pour streamer mes flux car l’app est pas mal !
Je comprends pas pourquoi pendant ces 6 mois d’hiver pas eu de crash…
A suivre…
Bon j’ai redémarré mon NUC.
Tout est reparti même si c’est toujours un peu scabreux les redémarrage hardware…
J’ai regardé dans différents logs.
en fait les jeedom et autre ont continués de fonctionner mais sans réseau.
Je pense qu’il y a un souci au niveau du réseau soit sur le NUC (hardware donc) soit au niveau de la couche basse de Debian.
Mon NUC pinguait bien mais SSH HS.
Je ne sais pas comment diagnostiquer plus en détail
Dans kern.err j’ai des logs de ce type sur le réseau. Il y a peut etre un sujet la dessus ?
Jun 12 00:00:20 pve kernel: [1040497.549802] fwbr100i0: port 1(fwln100i0) entered disabled state
Jun 12 00:00:20 pve kernel: [1040497.549963] vmbr0: port 10(fwpr100p0) entered disabled state
Jun 12 00:00:20 pve kernel: [1040497.599510] device fwpr100p0 left promiscuous mode
Jun 12 00:00:20 pve kernel: [1040497.599513] vmbr0: port 10(fwpr100p0) entered disabled state
Jun 12 00:01:02 pve kernel: [1040539.818988] device eth0 entered promiscuous mode
Jun 12 00:01:13 pve kernel: [1040550.978798] device eth0 left promiscuous mode
Jun 12 00:02:43 pve kernel: [1040640.751860] vmbr0: port 10(fwpr102p0) entered blocking state
Jun 12 00:02:43 pve kernel: [1040640.751864] vmbr0: port 10(fwpr102p0) entered disabled state
Jun 12 00:02:43 pve kernel: [1040640.751913] device fwpr102p0 entered promiscuous mode
Jun 12 00:02:43 pve kernel: [1040640.754013] vmbr0: port 10(fwpr102p0) entered blocking state
Jun 12 00:02:43 pve kernel: [1040640.799026] fwbr102i0: port 1(fwln102i0) entered blocking state
Jun 12 00:02:43 pve kernel: [1040640.799029] fwbr102i0: port 1(fwln102i0) entered disabled state
Jun 12 00:02:43 pve kernel: [1040640.799074] device fwln102i0 entered promiscuous mode
Jun 12 00:02:43 pve kernel: [1040640.799103] fwbr102i0: port 1(fwln102i0) entered blocking state
Jun 12 00:02:43 pve kernel: [1040640.799105] fwbr102i0: port 1(fwln102i0) entered forwarding state
Jun 12 00:02:43 pve kernel: [1040640.801882] fwbr102i0: port 2(tap102i0) entered blocking state
Jun 12 00:02:43 pve kernel: [1040640.801884] fwbr102i0: port 2(tap102i0) entered disabled state
Jun 12 00:02:43 pve kernel: [1040640.801933] fwbr102i0: port 2(tap102i0) entered blocking state
Jun 12 00:02:43 pve kernel: [1040640.801935] fwbr102i0: port 2(tap102i0) entered forwarding state
Jun 12 00:02:57 pve kernel: [1040654.436168] fwbr102i0: port 2(tap102i0) entered disabled state
Jun 12 00:02:57 pve kernel: [1040654.463868] vmbr0: port 10(fwpr102p0) entered disabled state
Jun 12 00:02:57 pve kernel: [1040654.466106] device fwln102i0 left promiscuous mode
Jun 12 00:02:57 pve kernel: [1040654.501733] vmbr0: port 10(fwpr102p0) entered disabled state
Jun 12 00:03:09 pve kernel: [1040666.741977] device tap104i0 entered promiscuous mode
Jun 12 00:03:09 pve kernel: [1040666.813029] fwbr104i0: port 1(fwln104i0) entered blocking state
Jun 12 00:03:09 pve kernel: [1040666.813032] fwbr104i0: port 1(fwln104i0) entered disabled state
Jun 12 00:03:09 pve kernel: [1040666.813104] fwbr104i0: port 1(fwln104i0) entered blocking state
Jun 12 00:03:09 pve kernel: [1040666.813106] fwbr104i0: port 1(fwln104i0) entered forwarding state
Jun 12 00:03:13 pve kernel: [1040670.926999] device eth0 left promiscuous mode
Jun 12 00:03:19 pve kernel: [1040676.555848] fwbr104i0: port 2(tap104i0) entered disabled state
Jun 12 00:03:19 pve kernel: [1040676.575268] fwbr104i0: port 1(fwln104i0) entered disabled state
Jun 12 00:03:19 pve kernel: [1040676.575413] vmbr0: port 10(fwpr104p0) entered disabled state
Jun 12 00:03:19 pve kernel: [1040676.578163] device fwln104i0 left promiscuous mode
Jun 12 00:03:19 pve kernel: [1040676.613450] device fwpr104p0 left promiscuous mode
Jun 12 00:03:19 pve kernel: [1040676.613453] vmbr0: port 10(fwpr104p0) entered disabled state
Jun 12 00:03:22 pve kernel: [1040679.908156] EXT4-fs (dm-23): mounted filesystem without journal. Opts: noload. Quota mode: none.
Jun 12 00:04:05 pve kernel: [1040722.767685] EXT4-fs (dm-21): mounted filesystem without journal. Opts: noload. Quota mode: none.
Jun 12 00:04:21 pve kernel: [1040738.287759] EXT4-fs (dm-23): write access unavailable, skipping orphan cleanup
Jun 12 00:06:02 pve kernel: [1040839.327490] device eth0 entered promiscuous mode
Jun 12 00:06:13 pve kernel: [1040850.488510] device eth0 left promiscuous mode
Jun 12 00:07:02 pve kernel: [1040899.766771] device eth0 entered promiscuous mode
Jun 12 00:07:13 pve kernel: [1040910.943516] device eth0 left promiscuous mode
Jun 12 00:08:13 pve kernel: [1040970.278202] device eth0 left promiscuous mode
Jun 12 00:09:13 pve kernel: [1041030.733335] device eth0 left promiscuous mode
Jun 12 00:12:13 pve kernel: [1041210.629446] device eth0 left promiscuous mode
Jun 12 00:13:12 pve kernel: [1041269.968761] device eth0 left promiscuous mode
Jun 12 00:16:13 pve kernel: [1041450.654525] device eth0 left promiscuous mode
Jun 12 00:17:12 pve kernel: [1041509.977005] device eth0 left promiscuous mode
Jun 12 00:19:13 pve kernel: [1041630.698819] device eth0 left promiscuous mode
Jun 12 00:23:13 pve kernel: [1041870.967512] device eth0 left promiscuous mode
Jun 12 00:24:02 pve kernel: [1041919.111131] device eth0 entered promiscuous mode
Etonnant car j’ai pas de port eth0…
La carte réseau de base s’appele eno1
ca m’est arrivé 2 fois sur mon vieux nuc i3 (gen5) en 3-4ans : ne répond plus du tout, obligé de reboot via le bouton
Je n’ai jamais trouvé la raison. Pas de conteneur LXC de mon coté, que des VMs
Avez vous fait toutes les maj du bios du nuc ?
Au niveau du bios j’ai une petite maj a faire. Difficile de dire ce qu’elle corrige, la note n’est pas très explicite… Mise a jour du microcode CPU…
Ça me fait rebondir sur le fait suebj’ai pas d écran donc tout un bazar pour faire la MAJ (d’ou l’intérêt quand même d’avoir un mini pc avec une carte réseau ipmi, mini serveur plutôt du coup…).
Est ce que vous avez connaissance d’un petit kvm IP de façon à pouvoir voir la sortie écran dans une page web et pouvoir piloter clavier a minimum ?
J’arrive pas à trouver une ref
les kvm ip coutent cher car matos plutot pro. Et encore, ca doit plus trop se vendre avec les bios ipmi&co des serveurs.
Concernant mon crash, je pense à un genre de kernel panic, mais sans écran branché sur le nuc au moment du crash, c’est impossible de savoir.
Le plus embêtant c’est que mon « pseudo cluster 2 noeuds » (ok c’est pas bien) était complètement inaccessible bien que le 2e noeud était OK. Il a fallu jouer du SSH pour avoir un qorum avec 1 noeud pour que l’interface web refonctionne (je n’étais pas sur place).
J’ai remonté des backups des VM du noeud 1 sur le noeud 2 en attendant de pouvoir être sur place et de hard reboot. Sans les périfs USB pour jeedom, autant dire qu’il n’y a pas grand chose qui marchait.
Il faudrait un genre de switch USB pour piloter sur quel noeud ils sont branché!
Ouep les kvm gateway coûte cher…
Du coup j’avais hésité à acheter un Intel nuc i7 ou l’équivalent en histou ou je ne sais plus quelle marque avec une carte réseau ipmi…
Ça prend tout son sens sinon veut pas être enmerdé 
Du coup tu as un mini pc avec ipmi ?
les trucs genre histou ca sera bien moins stable que les nuc.
J’ai un nuc 5i3 et un 8i5
Ils vont bientot être a la retraite, remplacés par 4 optiplex micro i7 toujours sous cluster proxmox.
Reste a trouver une solution pour basculer les périfs USB d’un noeud à l’autre 
Reste a trouver une solution pour basculer les périfs USB d’un noeud à l’autre
bon en fait ca va être compliqué car proxmox ne permet pas la migration d’une VM (changement de noeud) ayant des « local resources » (les ports USB en l’occurrence)
Pour mes autres VM, le HA avec stockage distant (en NFS chez moi) c’est vraiment super. J’attends la livraison de mes 4 SSD pour tester la fonction « replication » qui permet de stocker les VM sur les noeuds plutôt qu’a distance et les répliquer entre les noeuds (avec ZFS)
Bonjour,
Il y a moyen de déporter les clés ailleurs et de les utiliser via usbip ou similaire.
Évidemment ça ajoute un spof pour ces clés mais la migration des vm sera grandement facilité.
oui j’avais vu cela, mais les déporter sur quel matériel ?
Je ne suis pas sûr qu’un rpi sur carte-sd soit plus fiable que mes noeuds proxmox.
En mettant un RPI par clé usb, ca limiterait la casse en cas de panne d’un des RPI
J’ai eu un nouveau plantage aujourd’hui.
J’ai posé un écran avant de rebooté et je n’avais rien.
Je pense que c’est un problème de température.
J’ai fait la MAJ en 056 et fixé la vitesse du ventilo en FIXED à 65%.
De votre coté comment régler vous les paramètres de cooling de vos NAS ?
J’étais par défaut en BALANCED. J’ai tenté le cool mais ça na pas bien changé la vitesse après reboot. J’ai l’impression que les valeurs de reglage dans le BIOS de limite de temperature sont farfelues… 65° par exemple alors que au redémarrage dans mon garage à 35°, le CPU frolait les 50°…
J’aimerai bien trouver les bonnes valeurs CUSTOM car l’hiver ça va ventiler pour rien (j’ai 10° dans le garage).
Avez vous donc des réglages custom ou êtes vous sur les valeurs par défaut ?
Bonjour,
Pour ce qu’un ventilo consomme, la règle en informatique est de toujours ventiler au max.
La contrainte qui peut faire diminuer la vitesse est le bruit. Ce qui n’est pas un problème ici car ton NUC est dans ton garage.
Le radiateur sur le CPU n’est pas plein de poussière ?
il faudrait l’écran branché et allumé h24 pour chopper l’erreur.
Sur le proxmox, installer « lm-sensors » puis taper la commande « sensors » pour voir les températures système
ouep mais en oneshot c’est pas génial. Il faudrait que j’arrive à pouvoir les remonter et historiser qq part.
Non pas de poussière