Bonsoir
J'ai un ancien dédié (HD classique) avec Proxmox 5.
Je ne suis pas sûr que ce soit la dernière version de décembre.
En tout cas, je n'ai pas modifié les sources.list manuellement.
Jusqu'à hier, tout allait bien.
J'ai fait une màj : apt dist-upgrade … comme je l'ai déjà souvent fait !
Maintenant, mes conteneurs ne tournent plus correctement !
Dans 4 conteneurs, il ne reste que l' IP localhost 127.0.0.1
L'autre IP, qui est pourtant dans la config réseau dans l'interface graphique Proxmox, a disparu !
Bizarrement 2 conteneurs ont toujours leurs IP corrects (1 conteneur a 2 IP, l'autre 1 IP)
Mais pourquoi les IP de mes 4 autres conteneurs ont disparu ?
root@ct104-d6 :~# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Plus de eth0 ?
Pourtant eth0 existe bien dans l'interface graphique Proxmox.
J'ai fait des stop / start des conteneurs, et un reboot du Proxmox : non, ça ne revient pas !
4 conteneurs sur 6 n'ont plus d' IP …
Merci. Bonne soirée. Didier
Problème à la c.n et toutes mes condoléances…
Mais plus sérieusement, une idée qui me vient comme ça, as tu tenté de supprimer la carte rzo dans l'interface graphique et de la recréer ?
Peut être que ça remettra les choses en place… En croisant les doigts et en allumant un cierge qui sait ?
Pas encore essayé.
C'était bien une de mes prochaines pistes !
Mais pfffff… je n'avais JAMAIS eu le moindre problème avec Proxmox 3 basé sur OpenVZ…
ok, c'est pas la peine de pleurer, ils sont passés à LXC. Pas le choix.
j'ai fait un halt du conteneur 104
- j'ai noté les paramètres de eth0 (MAC OVH etc)
- delete eth0
- add eth0 avec les mêmes paramètres
- start conteneur 104
et… m… il n'y a encore que l0
Pas d'interface eth0
pffffff
Hum, et si tu recrées une VM toute neuve ?
Ne pas supprimer l'ancienne pour le moment, juste créer une nouvelle, pour voir si la carte rzo fonctionne bien.
Et si oui tenter la chose suivante :
- Backup d'une VM qui merde (en incluant une copie du disque via dd)
- Suppression de la dite VM.
- Recréer une VM totalement identique.
- Une fois la VM crée, l'arrêter, recopier le disque du backup sur la nouvelle vm avec la commande dd
- redémarrer la nouvelle VM…
Ou comment oqp ses soirées autour d'un bug !
Idéalement il faudrait comprendre ce qui merde pour réparer le problème, mais j'avoue que je n'ai pas d'idée… Du coup à part bricoler j'ai pas d'idée 
EDIT : ne pas supprimer la vm qui merde, juste l'arrêter… Sait on jamais…
j'ai fait presque ça :
backup de ct104, un backup d'il y a quelques jours, càd quand ça fonctionnait bien.
pct stop 104
restore backup sur un nouveau ct105.
pct start 105
et … niet ! Toujours pas de eth0 !
Mais ok, je n'ai pas deleté l'ancien conteneur 104 (unprivilege… car venant de OpenVZ) …
ça m'inquiète car j'ai un conteneur qui foire aussi sur un AUTRE dédié Proxmox…
BINGO c'est le même problème sur mon 2ème Proxmox (serveur avec SSD) …
p…
J'ose plus arrêter et redémarrer des conteneurs maintenant !
Ce 2ème Proxmox a certains conteneurs qd mm critiques avec des clients web ou mails…
m…
pq tu crées une VM ou un conteneur neuf, et ensuite DD pour recopier ?
et pas faire un simple restore du backup en changeant évidemment le numéro de conteneur ?
si ça continue, je vais supprimer les Proxmox et tout passer en VPS…
mais pffff… pour Drupal avec Composer, faut 4 GB de RAM. ça monte le prix.
Et on perd qd mm en souplesse (pas facile de faire des copies de vps, backup, etc)
même si je gagnerais en stabilité.
J'ai suggéré de faire une copie du disque via dd pour ne pas toucher à la config de la VM, juste récupérer les données sur le disque.
Mais déjà faut voir si en créant une nouvelle VM elle sera affectée par ce bug…
Parce que restaurer un backup ça restore le disque mais aussi la config de la vm.
Je vais créer un tout nouveau conteneur !
ça fonctionne !
Un nouveau conteneur Unpriviledge (car les autres sont aussi "unpriviledge" car venant de OpenVZ) :
ct318 : Ubuntu 18.04
root@ct318:~# ip addr show
1: lo: 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
25: eth0@if26: mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 02:00:00:88:ac:6d brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 5.135.44.129/32 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::ff:fe88:ac6d/64 scope link
valid_lft forever preferred_lft forever
le ping 5.135.44.129 répond depuis mon PC !
ouf…
Je vais essayer maintenant la copie DD du conteneur existant.
zut
copy du conteneur 104 vers le nouveau 318 :
J'ai copié
/vz/images/104/vm-104-disk-1.raw
–>
/vz/images/318/vm-318-disk-0.raw
root@ct318 :~# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
root@ct318 :~#
ça ne va pas !
Pas d' eth0e supprime eth0
je recrée eth1 (pour changer de nom) : ça ne va pas !
Toujours que la loopback l0 …
ok, je devais absolument refaire ces Conteneurs, car pas à jour, "unpriviledge" etc
mais pas tous quand même !
Et si je dois les recréer (ok, 18.04), copier les sites ça peut aller,
mais j'ai qques conteneurs avec des boites emails (… pffff… les confix Postfix), ça va être la cata.
J'espère que les autres conteners ne vont pas se dégrader de la même façon, car ça me prend du temps de les refaire
et aussi …
POURQUOI ?
Et quelle garantie que ça ne va pas encore merder autre part ?
Proxmox 5 LXC me pose énormément de problèmes, alors qu'il était magnifiquement facile et stable en version 3 OpenVZ…
Pour les configs mails suffit de copier / coller les configs… Tt l'avantage de linux…
Sous réserve d'avoir des backups… Perso je backup mon dossier /etc toutes les nuits…
Et si tu récupères la même IP pas besoin de retoucher aux dns ni aux clients.
Mais oui c'est pénible…
Après pour tes soucis aucune idée, perso j'utilise des VM et non pas des CT histoire de mieux séparer les VMs de l'Host… Aucune idée si ça évite ce genre de soucis…
ah, ça je ne fais plus, les backups de /etc …
où se trouvent les conf de Proxmox (VM, conteneurs, IPs) ?
J'ai toujours travaillé avec des conteneurs.
ça fonctionnait très bien en OpenVZ ; très bonne isolation.
Puis, lors de la migration Proxmox 3 OpenVZ vers Proxmox 4 LXC… c'était la cata !
En plus des énormes problèmes que j'ai eu, les conteneurs venant de OpenVZ se retrouvaient en Conteneurs "unpriviledge" en LXC, càd très mal isolés !
Par ex, on voit les charges de 8 cpu (mm si j'ai donné 2 cpu au conteneur), la charge totale du serveur, etc etc… pffff…
L'intérêt des conteneurs, c'était une plus faible charge et moins de place occupée qu'avec les VM.
Mais maintenant en Proxmox 5 ? Faut-il que je crée des VM et plus des conteneurs ?
L'isolation des conteneurs est moins bonne, même avec des "unpriviledge" (je dois vérifié si je ne mélange pas "Priviledge" et "Unpriviledge"… je doute maintenant.
En tout cas, hier, je n'ai pas su faire une copie fonctionnelle de l'ancien conteneur 104.
Soit pas d' IP, soit une IP qui répond mais plein de problème de droits, d'autorisations, et de users / groups inexistants !
Merci pour ton aide.
Bonne journée.
Oui les VM ça consomme +, mais en même temps c'est mieux isolé et je peux migrer d'un host à l'autre sans crainte.
Dsl de pas pouvoir t'aider mieux que ça, n'ayant jamais bossé avec les CT je n'ai pas vraiment de retour d'expérience.
Je vais tester les VM…
Vraiment, je n'ai jamais retrouvé le confort et la souplesse de Proxmox 3 en OpenVZ.
Là, TOUT fonctionnait bien. Jamais aléatoire. Resize des disques, IP etc … sans devoir arrêter le conteneur.
Bon, ok. Merci
ha pour resizer un disque faut arrêter la VM qd même… Enfin la redémarrer à minima.
Ensuite il faut adapter la taille de la partition… Comme un upgrade de VPS chez OVH…
pas dans l'ancien Proxmox 3 OpenVZ !
Je pouvais augmenter la taille disque SANS arrêter le conteneur
J'arrêtais le conteneur quand je voulais RÉDUIRE la taille disque ! … car oui, on pouvait réduire la taille d'un conteneur …
décidément Proxmox c'est … pénible !
Pas moyen de remettre correctement une IP sur ces conteneurs.
Je refais des backups des sites Drupal.
Il suffit de faire "scp" vers mon serveur de backup ?
et ensuite de restorer dans des conteneurs à jour 18.04 / PHP 7.2 …
ah non !
Comment fait-on un SCP au départ d'un conteneur sans IP extérieure ?
… pffffff
Bon, j'ai un bricolage possible :
Je crée un nouveau conteneur avec "unpriviledge"
Je copie le fichier RAW du conteneur "standard càd pas isolé avec unprivièdge" vers le nouveau conteneur.
ça ne tourne pas car toutes les permissons sont foireuses…
mais je devrais avoir accès à mes backups TGZ.
PÉNIBLE !