Reprise du message précédent :
Hello.
Dites, vous me confirmez que pour passer d'un bridge "de base" sans VLAN à un bridge qui permet de gérer les VLAN pour chaque VM/LXC, il suffit de rendre le bridge "VLAN aware" et de passer le port du switch sur lequel proxmox est connecté en trunk ? Et sans rien changer à la configuration des VM/LXC qui tournent actuellement (donc sans leur affecter de VLAN) alors elles sont toutes sur le VLAN untagged (ID 1) ?
Il faut que je gère une VM ou LXC qui doit apparaître sur un autre VLAN et je n'avais encore jamais pris le temps de configurer ça sur proxmox ...

Normalement oui.
Ensuite tu config le VLAN dans l'nterface du LXC/VM. Bon par contre faut bien config les ports de ton switch pour dire lesquels laissent passer le trafic dudit VLAN

Ca roule. Je teste ça rapidement. Merci !

Je reviens sur ce point, quelqu'un a de l'expérience à ce sujet là?
Ps je parle bien "juste" de retrouver un proxmox fonctionnel, je sais que je devrais revoir la partie réseau vu que les interfaces changeront (rien de grave) mais côté stockage il retrouvera ses petits tout seul (les pools zfs) à partir du moment ou je booterais sur le bon ssd?

Merci d'avance.

Bonjour,
 
Il y a des personnes qui ont utiliser le multipath en iscsi ?
 
j'ai juste une question basique.

Bonjour,
J'ai un dédié OVH avec proxmox sur 2 disques SSD
RAID 1 (mdadm) pour /boot, /, et les VG
par contre le swap est en 2 partitions (1 sur chaque disque) de 16go soit 32G de swap au global (donc comme un RAID0 mais c'en est pas un)

Un des SSD a lâché vendredi matin, ce qui a fait crasher l'hôte (qui a perdu une partie de son swap brutalement => normal)

redémarrage de l'hôte sur le SSD restant, ça marche mais avec 50% de swap en moins (=> normal aussi)

n'ayant pas besoin de 32Go de swap, je me demande si ça serait une bonne idée de faire un RAID1 sur les 2 partoches actuelles et de mettre le swap sur le RAID.

le but est bien sûr que l'hôte ne se vautre pas si un des disque revenait à planter
la question est "y a-t-il une contre indication à faire ça ?"

Merci

L'install par Debian par défaut ne le fait jamais et fait depuis toujours 2 partitions séparées. Mais j'avoue ne jamais avoir compris pourquoi et ne vois a priori pas de contre indication.
 
Une vieille doc explique bien l'intérêt potentiel:
https://tldp.org/HOWTO/html_single/ [...] WTO/#ss2.3
 
Par contre dans ta description, 32Go de swap c'est énorme. Sachant que le débat chez certains est de savoir si c'est encore utile avec les quantités de RAM qu'on a et sachant que si on a un système qui remplit plusieurs gigas de swap, ce n'est pas bon signe et, même en NVMe, les performances vont s'effondrer.

J'ai mon proxmox qui plante à répétition depuis quelques semaines. Je regarde dans quel log pour espérer trouver la cause svp ?

Si tu as des fichiers log et pas juste journal, dans syslog ou debug et il faut regarder ce qui précède le crash ou le reboot. Tu n'as rien à l'écran?

 
Suivant ce que tu fais ça ne l'est pas forcément tant que ça ^^".
 
Sur mon ancien laptop j'ai 16 de ram et 32 de swap et j'arrivais à tout saturer...   .
 
Là sur mon proxmox avec 128 de ram pour le moment mon swap est à 0... .

Ou journal aussi, je n'ai rien paramétré de spécifique à vrai dire

Je n'ai rien à l'écran. Mon hôte (serveur sans écran) devient inaccessible (interface web également). Je suis obligé de hard reset sur le boîtier lui même

Quel chipset réseau?

4x Intel 2.5gbps mais ça ne le faisait pas. Le serveur tourne depuis des mois sans aucun problème. Le seul événement récent est le clonage du disque système pour passer d'un nvme à un sata

ok j'avais eu le même soucis avec un e1000, là je sais pas

La sortie console de DMESG

dans ton lien, ils répondent pas vraiment à la question.
ils disent que pour du HA c'est mieux (oui, merci, sinon ça crash) mais que sinon faut laisse le swap sur différentes partoches des disques vu que la répartition est gérée par le kernel depuis la nuit des temps.
nulle part ça dit fais toi plaisir, ya pas de contre indication (que ce soit stabilité, perf etc...)
 
pour les 32Go de swap, je fais ce que je veux d'abord    
plus sérieusement, je n'ai que 32Go de RAM et il arrive que je fasse un peu d'overprovisionning temporairement.
du coup ça déborde. il me faut du swap. et j'aime pas m'apercevoir trop tard que j'ai pas alloué assez au départ. du coup je vois large a l'install des machines.
et dans le cas ici, heureusement que j'ai vu large au départ vu que je vais certainement passer de 32 à 16....

 
Ils répondent à la question puisqu'ils précisent que c'est utile dans le cas qui t'occupe, ne donnent pas de contre indication et disent que c'était stable il y a 15 ans.
Ok, ils précisent que tu peux faire des stress tests pour t'assurer de la stabilité mais ça je m'en foutrais vu les autres remarques... et vu que ça a du progresser depuis 15 ans.  
De toutes façons, ça rejoint ce qu'on peut lire par ailleurs.

bon bah c'est parti !
vais faire ça a chaud.
un petit coup de swapoff, creation du raid, mkswap, et swapon.
dans la théorie, ça se passe bien

tester c'est douter !!
c'est passé les doigts dans le nez (avec la PROD sur la bécane sinon c'est pas drôle)

edit: ne pas oublier de mettre à jour mdadm.conf

Oui en prod au boulot.

hello,

problème depuis ce matin.
suite à mise à jour/reboot d'un routeur, cluster HS
j'ai 2 hôtes (oui, je sais pas bien, mais le sujet n'est pas la)

chaque hôte ne voit pas le second
ils se pinguent
il y a du trafic UDP entre les 2 hôtes sur le port 5405 (corosync) j'ai vérifié avec wireshark

pourtant cluster HS: chacun indique la même chose "Cluster not ready - no quorum"

j'ai déjà testé le reboot dans un peu tous les sens
forcer le quorum de chacun à 1

d'autres idées d'où ça peut venir ?
vous savez ou sont les logs de corosync ?

Pourtant le problème peut tout à fait provenir du fait que justement tu as 2 hotes.
Aucun des deux ne sait qui a raison.
C'est pour ça qu'en général il y a 3 hotes pour statuer sur qui est le bon.
Vérifie au cas ou aussi que tout le monde est bien à la bonne heure.

Dans la doc il est fait mention que si on ne veut pas un 3ème hôte on peut rajouter un "qdevice" qui va servir à cette décision là:
https://pve.proxmox.com/wiki/Cluster_Manager

Voir:
Corosync External Vote Support

Sur chaque hote si tu fais:
pvecm status

Tu as quoi?

Je suppose que tu as donc déjà fait:
pvecm expected 1

Mais si tu le fais sur les 2, ça ne règle pas le soucis puisque tu as toujours le conflit ou chacun vote pour soit. :')

EDIT: je dirais que pour t'en sortir il faudrait bricoler comme ça:
https://www.jm.technology/post/prox [...] pril_2019/

du coup je dirais qu'il faudrait que les deux votes pour le 1 par exemple avec:
pvecm --votes 2 sur l'hote que tu veux comme ok et pvecm --votes 0 sur le deuxième?

je sais que 2 nœuds c'est pas optimal mais vu la config osef (1 principal 1 failover, ya pas de HA, et c'est pas de la prod non plus)
 

 
 
et oui, testé "pvecm expected 1" sur l'un / l'autre / les 2 ça ne résous rien
si je le fais sur les 2 l'état du cluster passe à OK mais ils ne se voient toujours pas.
 
en fait, je m'en fout que ça marche pas, c'est du test.
mais je veux comprendre ce qui se passe.
j'ai déjà rebooté plein de fois les hôtes avant ça sans soucis, idem avec les MAJ de switch/routeur ou même coupure WAN (oui les 2 hôtes sont sur les sites différents, ça passe par du VPN entre les 2), mais j'aimerai comprendre ce qui s'est passé ce matin et pourquoi ça reviens pas.

j'en viens a me demander si je ferais pas un nouveau reboot du routeur vu que c'est le seul truc que j'ai modifié ce matin.
pourtant, le trafic passe bien.... donc à mon avis ça changera rien.

Donc, tu as ta réponse qui est exactement celle que je t'ai évoquée.
Chaque hote attend 2 votes et n'en a qu'un seul.
 
Solution, sur un et bien UN SEUL des hotes fait:
pvecm --votes 2, ça devrait le faire passer comme principal.
 
 
Ce n'est pas juste "pas optimal", c'est justement problématique, tu es justement dans le cas ou aucune décision ne peut être prise puis qu’aucun des deux ne sait qui a raison..

t'es en train de me dire que la coupure réseau de ce matin était trop longue/tombée au mauvais moment et que ça a flingué le truc ?
 
la commande marche pas mais j'ai compris le principe

 
vais regarder la doc

"pvecm votes 2" peut être ? Faut trouver la syntaxe.

Non ça ne veut pas dire que quelque chose est flingué, tu n'as que 2 noeuds, donc pas assez pour prendre une décision ( quorum )
Ta cmd status te le dit un noeud a besoin de 2 votes pour être maitre, mais en l'absence d'un 3 ême pour voter et donc trancher chaque noeud se croit le bon noeud ( coupure réseau survenue en même temps).

Donc il faut "tricher" et dire à un noeud qu'il a 2 votes pour devenir le maitre et tout débloquer.

Edit :
https://pve.proxmox.com/pve-docs/pvecm.1.html

Donc c'est ko la commande c'est avec add ou autre, c'était avant qu'il fallait le faire visiblement.

Bon tu peux tester ça :
1) éteindre 1 noeud.
2) redémarrer le noeud restant.
Sur ce noeud faire : pvecm expected 1
Ce noeud remarche ?
 
Si oui alors rallumer le dernier noeud et voir ce qu'il en est.

déjà testé ça plusieurs fois.
les noeud fonctionnent indépendamment l'un de l'autre avec pvecm expected 1

en modifiant le fichier de conf corosync j'ai réussi a passer le vote a 2 pour un des noeud.

pvecm status me donne bien 2 pour le quorum, 3 pour le nombre max, dont 2 votes pour un noeud.

donc le quorum est OK sur un des noeud mais j'ai toujours un noeud offline (l'autre)
(alors qu'il ping et que les corosync se parlent)

à partir de l'autre noeud, c'est l'inverse. quorum KO (1 vote et quorum à 2) et le premier noeud offline

pour moi c'est pas un problème de vote/quorum:
avec pvecm expeted 1 ça permettait le démarrage des VM etc... (normal)
mais les noeud sont invisibles l'un de l'autre.

edit: de toutes façons, en dehors du nombre total de vote/quorum, ya forcement un moment ou quand tu redémarre un noeud il se retrouve sans quorum et donc "bloqué".
cependant il attend de "voir" les autres et récupérer les infos du cluster (sinon tu pourrais pas redémarrer un noeud sans qu'il soit définitivement éjecté du cluster)
c'est justement cette étape qui doit planter dans mon cas. il voit pas le copain d'en face donc arrive pas à se synchro (vote ou pas vote osef, ils ne se voeint de toute façon pas)

Et question bête leurs ip étaient bien fixées et pas en dhcp ayant pu bouger depuis le reboot du router ?

les IP sont en fixe et n'ont pas changées

je pense que je commence à comprendre ce qui s'est passé (et c'est pas une bonne nouvelle du tout)

/etc/pve/authkey.pub est régénéré périodiquement
/etc/pve/priv/authkey.key aussi du coup (et potentiellement authorized_keys et known_hosts)

l'heure à laquelle c'est régénéré correspond à l'heure à laquelle j'ai eu ma coupure réseau à cause du reboot de routeur.

du coup ça s'est retrouvé désynchronisé !

j'ai recopié à la main ces différents fichiers (et au passage le corosync.conf pour être sur), j'ai récupéré la visu des différents hôtes sur l'IHM (plus d'erreur 401 quand je clique sur l'hôte distant)

pour autant, les hôtes distants sont toujours vu comme offline l'un par rapport à l'autre.

donc j'ai récupéré une partie du truc, mais pas tout.

donc mes soucis ne sont pas liés au quorum/votes, mais à la régénération des clefs entre machines qui ne se sont pas propagées à cause d'un hôte offline.

et c'est la que ça fait mal !
un hôte est isolé du cluster suffisamment longtemps (coupure réseau, intervention matériel etc...) et c'est mort, il reviendra pas....

si qqn a une idée pour resync tout ça, je prend
edit: j'ai bien sur fait un reboot de tout le monde après la copie des fichiers, sans succès.

Bonjour !
 
c'était bien les clefs !!!!
il suffisait d'attendre plus longtemps, le cluster est a nouveau en état OK et stable depuis mardi.
 
donc ça confirme que:
-- rien à voir avec le nombre d'hôtes/votes
-- qu'il ne faut surtout pas avoir une coupure (réseau ou hôte power off) pendant le renouvellement de clef !

J'ai un truc complètement dingue qui se produit depuis quelques temps, et je crois que je commence à isoler l'origine du problème.
 
J'ai l'organisation suivante (je vais simplifier un micro poil) :
- sur un switch 1G non géré : du matos en filaire (pc, ampli, ...)
- sur un second switch 2.5G, POE lui aussi non géré : d'autre matos en filaire + mes 2 points d'accès wifi ubiquiti + un uplink vers le switch 1G
- un pont de ce switch 2.5G vers une carte réseau 10G dans mon serveur proxmox
- une seconde carte réseau (1G intégrée) dans ce serveur qui me sert de WAN pour la partie routeur (voir plus bas).
 
Sur le serveur proxmox j'ai divers LXC/VM, dont une VM OPNSense qui fait office de routeur, DNS (adguard) et DHCP (Kea intégré à OPNSense). Je sors donc vers une livebox via la carte réseau 1G (déclarée en DMZ sur la livebox).
- la partie réseau "lan" est le vmbr0 passé en virtIO à la VM
- la partie "wan" est carrément le port pci de la carte réseau 1G.
 
Historiquement tout ça fonctionnait très bien. En pratique j'ai même plutôt une troisième carte réseau 1G sur laquelle je branchais le switch 1G (pour splitter le trafic et avoir 3.5G de bande passante possible côté LAN), mais j'ai dégagé cette partie pour essayer d'isoler le problème.
 
Depuis quelques semaines mon Macbook pro a du mal à récupérer une IP auprès du DHCP. Au début je pensais à un problème wifi car je voyais juste que l'ordi essayait de se connecter sans jamais réussir, mais j'ai fini par comprendre qu'il n'obtenait juste pas d'IP et finissait donc par s'attribuer une ip en 169.XXX. Si je force une IP en 192.168.1.X et la passerelle en dur, miracle tout fonctionne nickel.
 
Là où c'est dingue c'est que par exemple mes ESP32 qui me servent pour la domotique arrivent sans souci à avoir une ip, de même que tous mes périphériques filaires, notamment le dock sur lequel je branche le macbook 95% du temps !
J'ai aussi constaté que le problème était identique pour mon smartphone, qui depuis toujours était en ip fixe (on peut le faire "par réseau wifi" donc ça n'est pas dérangeant, alors que pour le mac c'est par interface, donc dès que je veux me connecter à un autre réseau ailleurs que chez moi il faut que je rebascule manuellement en dhcp si j'ai forcé une ip fixe).
 
J'ai donc creusé et essayé de voir ce qu'il se passait au niveau des trames DHCP (tcpdump).
Bilan :
- en filaire / pour mes autres périphériques, les trames arrivent bien sur l'hôte proxmox ET à la VM
- pour mon mac et smartphone, les trament arrivent sur l'hôte proxmox mais PAS la VM !!!
 
Quelques trames OK (un esp qui veut une IP) :

ou encore (mon point d'accès wifi qui quémande une IP) :

 
La trame typique KO :

Et celle là n'arrive jamais sur la VM OPNSense, et le mac n'a jamais de réponse, donc répète, répète et finit par s'attribuer une ip à la con.
 
Si je désactive le DHCP Kea et que je lance un lxc avec pihole et active son DHCP à lui, ça marche instantanément, mon mac et smartphone ont des ip sans souci (mais ça me fait ch**r de faire tourner un conteneur juste pour un dhcp alors que c'est quand même la base d'un routeur).
 
Alors mon stagiaire préféré m'a parlé d'hardware offloading à désactiver (fait, sans résultat), de passer la carte réseau en Intel E100 plutôt que virtIO (ça fout à plat la VM, probablement parce que l'interface change de nom dans opnsense ensuite) ainsi que de manière différente de procéder : unicast, broadcast, ... selon les périphériques. J'ai aussi bricolé les options de mes points d'accès qui ont des trucs du genre "Multicast to unicast", sans succès. Donc là je sèche un peu.
 
Des pistes ?

 
Alors, ce que je vais dire est peut-être débile (je préviens   )
 
J'ai eu un truc très similaire (en fait complètement similaire) sauf que le DHCP est attribué par le routeur et non par Kea intégré à OPNSense.  
Ce qui se passait avec mes devices Apple, surtout iPhone, iPad, c'est que comme toi, ils finissaient par se retrouver avec une IP en 169.x.x.x.  
La raison : saturation de la table d'IP DHCP parce que par défaut tu as ça quand ils se connectent au wifi : Limit IP Address Tracking  
Ils changent d'IP constamment et finissent par foutre la merde.
Depuis que j'ai passé tous les iBidules de la famille en IP fixe et que j'ai désactivé cette merde, plus aucun soucis (j'ai réinitialisé le routeur avant)
Pas sûr que ça te serve, mais on se sait jamais

J'ai des baux statiques pour quasiment tout le monde.
Le Mac a une adresse MAC fixe pour ce réseau.
Et le smartphone (Samsung) a le même souci.
 
J'ai exploré la piste des régles de firewall aussi, mais aucune raison que ça passe pour certains périphériques et pas d'autres.
 
J'ai tenté de changer de carte réseau, en passant par la 3è carte 1G du serveur plutôt que la carte 10G, les 2 sont agrégées dans vmbr0 -> ça ne change rien.
J'ai aussi tenté de ne plus agréger les 2 cartes, ça ne change rien.
 
J'ai tenté de remettre l'ancien DHCP d'OPNSense plutôt que Kea, ça ne change rien. Idem pour celui d'adguard (qui tourne sur la VM OPNSense).
 
Je suis à 2 doigts d'acheter un routeur séparé, genre un petit ubiquiti, ce qui me retient c'est que j'utilise HAproxy, et adguard, le premier pour filtrer des accès à des services web et serveurs minecraft (qui ne fonctionnent que si on passe par le nom de domaine + des règles de pays, donc un scan d'ip ne montre aucun port ouvert), donc s'il faut que je fasse tourner des conteneurs/VM pour ça malgré tout, autant faire tourner un conteneur pour un DHCP...
 
Je pourrai tenter de passer la carte réseau entière à la VM plutôt que le vmbr0, mais j'ai un peu peur que ça mette la zone, du genre ralentisse les transferts du lan (ou augmente la charge CPU/conso) car ils seront filtrés par OPNSense alors qu'en pratique je m'en fous, c'est du LAN.

Bon je reviens à la charge.
J'ai donc fait ce que j'évoquais à au dessus.
Tout mon trafic LAN et wifi passe désormais par mon switch 2.5GBPS branché sur la carte réseau 10G du serveur. Elle est associée à vmbr0 dans proxmox.
J'ai passé les 2 autres cartes 1G en PCI direct à ma VM OPNSense (lan et wan). La carte Lan est sur un port de mon switch.  
J'ai donc la première carte avec une ip (192.168.1.253) qui est celle de la passerelle pour tout le monde.
En théorie c'est un peu comme si mon OPNSense était sur une machine différente avec ses 2 cartes réseau dédiées.
 
J'ai réactivé le DHCP d'OPNSense et désactivé celui de mon LXC pihole.
 
Et ben c'est la même merde.
- Mes interfaces filaires arrivent à avoir une ip
- Mes trucs de domotique (esp32...) wifi arrivent à avoir une ip
- Mon Mac et mon smartphone n'obtiennent pas d'ip, le paquet DHCP n'a jamais l'air d'arriver à la carte réseau LAN de la VM OPNSense (alors que les autres paquets passent bien, je les vois avec tcpdump)
 
Les paquets DHCP "Discover" de tout le monde apparaissent bien sur une machine au pif (j'ai pris l'interface LAN 10G de mon serveur proxmox par ex) sauf ceux de mon mac et smartphone qui n'arrivent pas sur la carte réseau LAN d'OPNSense.
W T F ? ? ?  

Salut  
J’ai un soucis similaire avec mon Mac ou l’iMac de ma femme : il n’arrivait pas à avoir une adresse ip.
Pour l’un c’était un câble réseau qui était foireux et pour l’autre c’était le switch.
 
Tu passes par un adaptateur usb pour le réseau sur ton Mac ?
 
Essaie de changer le/les câble(s) et de changer le port sur le switch.

Hum, vraiment étrange comme souci
 
De mon coté j'ai ENFIN configuré PBS pour mes backups et sah quel plaisir. Je vais enfin pouvoir avoir plusieurs semaines/mois de rétention et faire du file-level restore. Et aussi ne plus uploader 1To/j de full backups...
 
Bon j'ai pas encore fait l'externalisation du folder qui contient les chunks, je vais tester aujourd'hui. Ca fera 1.3To d'upload mais normalement ensuite seulement qques Go de differentiel quotidien.
 
Par contre je songe à passer d'un container à une VM pour Nextcloud parce qu'en mode CT le backup est plus long qu'une VM en mode block.

Bon j'ai quand même une solution à défaut de comprendre :
 
visiblement il y a un troisième DHCP (ils foutent quoi opnsense ???) intégré à dnsmasq. C'est natif opnsense (comme Kea désormais), c'est pas un truc que j'ai rajouté. Il n'était pas activé.
 
J'ai désactivé Kea et activé le dhcp de dnsmasq et... ça marche !!!
Bon point au passage : on peut exporter les baux statiques de kea et les importer dans dnsmasq
 
N'empêche, ça n'explique rien de pourquoi ça bloquait avec Kea, sachant que Kea a une case à cocher pour ajouter automatiquement les règles dans le firewall pour s'assurer que tout le trafic dhcp passe bien !
 
Reste à savoir si je reste avec mon install bizarre à base de 3 cartes réseaux ou pas. Dans l'absolu c'est pas con de passer 2 cartes à la VM routeur et qu'elle soit totalement isolée, de l'autre ça n'est absolument pas nécessaire.

Pour en revenir a mes déboire de Proxmox qui ne démarrait plus après la MAJ en version 9, j'ai pin un kernel plus ancien pour que ce soit ok.
 
L'explication de la version des drivers nvidia qui sont sur le repo de Debian 13.
 
Ce sont les 550 et ils sont incompatibles avec tous les kernel >=6.17
 
Il faut passer au mini aux 580, manuellement donc... si on veut profiter des derniers kernel.
 
C'est quand meme bizarre qu'il y ait des drivers sur le repo officiel qui ne fonctionnent pas avec la version du systeme...