La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: renaud07 le 18 septembre 2020 à 00:16:16
-
Bonsoir,
Je viens de changer de configuration pour mon serveur proxmox, passant d'une carte mère AM2 (athlon x2) à du 775 (Xeon) et je n'ai plus de réseau, uniquement sur les machine virtuelles.
J'ai bien évidemment adapté l'interface qui est passé de enp3s0 à enp2s0 dans /etc/network/interfaces et j'ai bien du réseau via proxmox et les conteneurs, mais sur les VM, rien ne passe... Les IP n'ont pas bougées et tout est bien détecté et up.
Ai-je oublié un truc ?
Merci
root@pve:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
link/ether 00:22:15:xx:xx:xx brd ff:ff:ff:ff:ff:ff
3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:22:15:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.2.2/24 brd 192.168.2.255 scope global vmbr0
valid_lft forever preferred_lft forever
inet6 fe80::222:15ff:fe8b:2b2a/64 scope link
valid_lft forever preferred_lft forever
root@pve:~# ping 192.168.2.7
PING 192.168.2.7 (192.168.2.7) 56(84) bytes of data.
From 192.168.2.2 icmp_seq=1 Destination Host Unreachable
From 192.168.2.2 icmp_seq=2 Destination Host Unreachable
From 192.168.2.2 icmp_seq=3 Destination Host Unreachable
From 192.168.2.2 icmp_seq=4 Destination Host Unreachable
From 192.168.2.2 icmp_seq=5 Destination Host Unreachable
From 192.168.2.2 icmp_seq=6 Destination Host Unreachable
From 192.168.2.2 icmp_seq=7 Destination Host Unreachable
From 192.168.2.2 icmp_seq=8 Destination Host Unreachable
From 192.168.2.2 icmp_seq=11 Destination Host Unreachable
^X^X^C
--- 192.168.2.7 ping statistics ---
15 packets transmitted, 0 received, +9 errors, 100% packet loss, time 342ms
root@pve:~# ping google.com
PING google.com (216.58.214.78) 56(84) bytes of data.
64 bytes from par10s39-in-f14.1e100.net (216.58.214.78): icmp_seq=1 ttl=114 time=30.2 ms
64 bytes from par10s39-in-f14.1e100.net (216.58.214.78): icmp_seq=2 ttl=114 time=30.3 ms
64 bytes from par10s39-in-f14.1e100.net (216.58.214.78): icmp_seq=3 ttl=114 time=29.8 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 29.755/30.078/30.310/0.235 ms
-
Normalement, quand tu changes la configuration réseau, tu dois le faire dans un fichier interfaces.new, qui sera pris en compte au redémarrage du serveur. C'est bien ce que tu as fait ?
https://pve.proxmox.com/wiki/Network_Configuration
-
Ai-je oublié un truc ?
Pour moi non... J'ai un cluster proxmox de 2 machines au hardware très différent (Mac Mini et Intel NUC) et j'ai déjà passé des VM de l'une à l'autre (ce qui revient grosso modo à changer le hardware) sans avoir de problèmes réseau dans les VM...
Question: Si tu crées une nouvelle VM, a-t-elle le même problème ?
-
Normalement, quand tu changes la configuration réseau, tu dois le faire dans un fichier interfaces.new, qui sera pris en compte au redémarrage du serveur. C'est bien ce que tu as fait ?
https://pve.proxmox.com/wiki/Network_Configuration
Je n'avais pas vu... Comme dit au début j'ai directement édité /etc/nework/interfaces.
Question: Si tu crées une nouvelle VM, a-t-elle le même problème ?
C'est la première chose que j'ai faite et oui ça bloque aussi...
-
Je n'avais pas vu... Comme dit au début j'ai directement édité /etc/nework/interfaces.
Proxmox doit répliquer entre serveurs, et j'ai peur que quand on n'a pas suivi la procédure, le changement soit écarté. Tu pourrais essayer avec le fichier new.
-
Y'a pas de réplication du fichier interfaces entre serveurs.
-
Problème d'offload TCP avec les drivers réseaux VirtIO ?
Qu'est ce que c'est le bordel ce truc d'ailleurs...
-
Je viens justement de changer de NIC (passage en E1000) et deviez quoi ? Ça remarche :)
Je n'ai pas précisé un truc mais ça vient peut-être de là : je n’ai pas réussi à activer la virtualisation matérielle (malgré qu'elle soit enabled dans le BIOS), j'ai donc du la virer dans les options de chaque VM. Et étant donné que le NIC par défaut était virtIO... y'en a peut-être besoin pour que ça fonctionne ?
-
Ah oui il faut !
-
Y'a pas de réplication du fichier interfaces entre serveurs.
Non, mais les interfaces servent à la réplication entre serveurs. D'où l'idée de ne pas arrêter le trafic, et ne faire la mise à jour qu'au moment du reboot.
-
Rien compris :)
Je dis juste que modifier le fichier interfaces n'est pas un problème dans le cas d'un cluster proxmox et ne pose aucun souci avec aucune des fonctionnalités de proxmox
Et pas besoin d'un fichier interfaces.new pour changer des params au reboot, éditer le fichier interfaces suffit.
-
Et bien pourtant, lis le lien que j'ai donné, c'est la procédure officielle. Et des paramètres (MAC...) qui sont dans les fichiers interfaces, sont bien synchronisés entre serveurs, dans d'autres fichiers. C'est pour assurer la cohérence. Bien sûr, quand on a plusieurs serveurs. Mais je me demandais si cela pouvait entrainer des problèmes même pour un si on ne suivait pas la procédure...
-
Non, tu as mal compris.
Proxmox, quand tu utilises la GUI enregistre tes changements dans un fichier interfaces.new, et ifupdown applique toutes tes modifs (dans interfaces) d'un coup au reboot. Toi, tu peux le faire directement dans interfaces si tu veux, ça ne change rien.
-
Ah oui il faut !
Maintenant y'a plus qu'à trouver comment activer tout ça... car c'est pas tout mais sans VT-x c'est assez lent (et encore j'ai de la chance que QEMU le permette, si je me servais de virtualbox je l'aurais dans l'OS...)
Y'a un truc qui me fait tiquer cependant c'est que le virtIO pour les disques ne semble pas affecté puisque ça démarre toujours.
-
C'est juste la vt-x, pas la vt-d ? En tout cas a mon sens si tu n'as pas de vt-*, ça va être difficile d'avoir des perfs :/
-
C'est bien la VT-x que je n'arrive pas à activer. Et oui c'est super lent, j'ai tenté de démarrer une netinstall de debian, je ne compte pas le temps qu'il faut entre chaque page...
Heureusement, sur les systèmes déjà installé c'est un peu plus réactif.
-
Non, tu as mal compris.
Proxmox, quand tu utilises la GUI enregistre tes changements dans un fichier interfaces.new, et ifupdown applique toutes tes modifs (dans interfaces) d'un coup au reboot. Toi, tu peux le faire directement dans interfaces si tu veux, ça ne change rien.
Non, cela ne fait pas longtemps qu'il est possible de modifier les interfaces réseau par l'interface web. Avant, c'était à la main, et il était déjà recommandé de créer un fichier interfaces.new pour cela.
Mais bon, je ne vais pas insister puisque le problème est résolu.
-
Les seuls fichiers synchronisés entre les noeuds d’un cluster sont situé dans /etc/pve
La synchronisation du fichier contenant la définition des interfaces n’a aucun sens puisque les machines peuvent avoir des configurations réseau totalement différentes.
Comme @Hugues j’ai modifié des dizaines de fois mes fichiers interface directement sans que ça ne pose aucun problème...
-
Oui, parce que la doc de Proxmox c'est une chose, mais ça reste la stack debian/iproute en dessous, et Proxmox n'agit pas vraiment dessus.
-
Et du corosync qui compte sur le réseau pour la synhronisation, et savoir si le quorum est toujours disponible. Mais c'est vrai qu'à 1 ou 2 serveurs, corosync ne sert pas vraiment.
-
Certes, mais Corosync se repose (comme tout le reste) sur la conf réseau du système, il n'agit pas dessus.
-
Bon... Je pense que mon problème sera vite résolu : cet aprem' j'étais en train de configurer 2-3 trucs dessus, puis je suis parti faire autre chose et en revenant : plus de connexion (je précise que le serveur est chez mes parents) Test de ping (des fois que la box soit en train de changer d'ip) : ça marche. SSH : rien. Scan des ports : tout est fermé.
Je demande alors un peu d'aide et qu'on me branche clavier/écran voir ce qu'il se passe : aucun affichage. Reboot forcé : toujours rien aucun signe de vie ni sur l'écran ni les LED du clavier. Mais ça démarre électriquement, ventilos et DD ok.
J'en conclu que la CM a décidé de décéder 2 jours à peine après son installation. Je dois aller le récupérer la semaine prochaine, mais je crains que ça soit bel et bien mort... à moins que ce soit une broutille que j'ai oublié mais ça m'étonnerais vu comment ça a planté d'un coup (sans compter que je l'avais bien testée avant son installation définitive). Peut-être des condos qui ont lâchés...
-
Il n'est pas mort finalement :D
J'ai rappuyé sur le bouton et il est reparti. J'ai juste trituré un peu la CG, peut-être était-ce pour ça.
Pour la virtualisation c'était tout simplement le BIOS qui n'était pas moddé (vu que j'ai mis un Xeon 771 il faut les microcodes spécifiques). Un fois flashé, tout est nickel et le virtIO refonctionne à merveille 8)
root@pve:~# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 38 bits physical, 48 bits virtual
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 23
Model name: Intel(R) Xeon(R) CPU X5460 @ 3.16GHz
Stepping: 10
CPU MHz: 2687.548
CPU max MHz: 3166.0000
CPU min MHz: 2003.0000
BogoMIPS: 6332.55
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 6144K
NUMA node0 CPU(s): 0-3
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm