Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

  • État Nouveau
  • Pourcentage achevé
    0%
  • Type Anomalie
  • Catégorie Services locaux → VM
  • Assignée à Personne
  • Système d'exploitation Freebox Server V7 (Delta)
  • Sévérité Moyenne
  • Priorité Très Basse
  • Basée sur la version 4.7.3
  • Due pour la version Non décidée
  • Échéance Non décidée
  • Votes
  • Privée

FS#37575 - Crash du server suite à VM

Bonjour,

j’ai créé une VM sur mon serveur V7

Les caractéristiques de cette dernière :
- Ubuntu 22.04.1 LTS
- Disque QCow2 128Go que j’ai upgradé à 256Go (sur HDD réel de 1To, celui qu’on peut commander avec la box à l’achat chez Free)
- CPUs: 2
- RAM : 1024Mo (je n’ai pas ajouté de barrette dans mon server)
- Pas d’écran virtuel
- Cloud-init activé avec aucune modification sur la config par défaut
- Apache2, Docker, K8s, Transmission, Plex, Sonarr d’installé sur la VM

Au lancement de ma VM, parfois (et je n’ai malheureusement pas identifié d’actions reproductibles), le server V7 va crash et reboot, comme si j’avais demandé le reboot du server.
Une fois le server rebooté, ma VM est bien allumée et j’y ai accès sans problème…

De plus, en laissant la VM tourner, de nombreux crash de la freebox ont lieu tout au long de la journée :
https://i.imgur.com/4h6M5YW.png

À dispo si besoins de debug
Merci et bonne journée

1 GO pour la box… sincèrement je pense que c'est ric rac.

On a tous été surpris d'ailleurs qu'ils proposent une VM avec si peu de mémoire physique à la base, donc la majorité des gens ont illico upgradé leur mémoire.

En fait, c'est aussi ric rac pour la VM elle même. Les systèmes Linux modernes, du moins avec le noyau standard, demandent 4GO et idéalement 8 GO pour les OS 64 bit. Ca peut toujours fonctionner avec moins, mais ça peut aussi ramer et planter plus que de raison.

La Freebox a un noyau spécifique customisé pour tourner sous faibles ressources, on parle pas tout à fait des mêmes noyaux.

Avant upgrade… ma VM (opensuse tumbleweed) était très lente

Après upgrade soit RAM de 16 GO, 30 à 40% de rapiditié en plus
J'ai effectué les optimisation suivantes :

- 12 GO alloués à la VM
- tmpfs en ram
- activation de la ZRAM pour créer un SWAP en mémoire
- le système est paramétré pour utiliser le moins possible le SWAP et sans doute qu'en l'état le disque n'est plus du tout sollicité sur des opérations de SWAP

La VM tournent depuis deux ans. Pas de soucis sur l'hôte. La VM crashe parfois si le noyau est mal fagotté puisqu'il s'agit d'une Rolling Release, mais pas de soucis sur l'hôte.

L'upgrade conseillé est de 8 GO. Vous pouvez allouer 6 GO à votre VM, et laisser intact 2 GO pour la box, et l'ensemble marchera nettement mieux.

On est d'accord que sur le principe, le plantage d'une VM ne doit pas avoir d'impact sur l'hôte. Donc si l'hôte plante ce ne peut-être :

- qu'un problème de défaillance matérielle
- un problème d'allocation de mémoire insuffisante au niveau de l'hôte, donc on en revient au fait que 1 GO c'est sans nul doute ric rac pour la Freebox.

Notez aussi que de nombreuses personnes on soit placé un SSD, soit un pool de disque mécanique en RAID 0 afin d'augmenter la bande passante du disque et améliorer la performance de l'ensemble puisque à la base il y a déjà une ENORME perte de performance lorsque l'on passe sur un fichier virtuel de type qcow ou raw.

La Freebox en elle-même n'utilise quasiment pas le disque interne, elle ne l'utilise que lorsque vous visionnez la TV pour générer un cache de flux temporaire et bien entendu lorsque l'on paramètre un NAS

VickeS a commenté le 09.01.2023 21:33

Salut,

J'ai le même problème que toi, j'ai dû réduire la quantité de ram alloué à la VM malgré que j'ai acheté une barette de 4Go exprès.
L'OS de la freebox doit prendre plus qu'1Go à un moment et donc ça fait tout crash.
Tu peux voir mon retour sur le sujet que j'ai créé ici : https://dev.freebox.fr/bugs/index.php?do=details&task_id=37570

Et puis j'ajoute que vous avez chargé votre VM comme une mule.

Je sais que les linuxiens se sont pris de passion pour Docker (un truc que les utilisateurs FreeBSD connaissaient depuis de nombreuses années à travers les FreeBSD Jails à ne pas confondre avec le jail chroot de base, pendant que les trolleurs Linuxens regardaient cela en considérant "si ça n'existe pas sous Linux c'est que ça sert à rien"), mais il faut remettre les pieds sur terre.

La VM tourne sur un hôte limité en ressources, je ne suis pas certains que Docker soit vraiment raisonnable puisque en gros Docker revient à créer une seconde couche de virtualisation dans un environnement déjà virtualisé (oui Docker ce n'est pas à proprement parler de la virtualisation).

Si Docker n'absorbe pas forcément beaucoup plus de ressources processeurs qu'un service géré directement (du fait que ce n'est pas à proprement parler de la virtualisation mais plutôt un chroot plus sophistiqué), de façon incontestable ça exige plus de ressources en RAM, donc dans cette configuration n'allouer que 1GO à votre VM, c'est totalement inadapté.

Votre VM doit avoir minimum 4GO de mémoire allouée… En l'état, elle doit copieusement ramer.

Ajoutons qu'une des sources d'instabilité peut venir de l'interface réseau virtuelle utilisée par Docker ou tout autre système de conteneur. Sur des tests précédents j'avais constaté que ces interfaces réseaux virtuelles pouvaient générer des soucis sur des systèmes à faibles ressources, pour cette raison je n'opterai jamais pour des services contenarisés dans une VM Freebox.

Autre source possible de problèmes… si vous optez pour une configuration "bridge" au lieu de NAT sur cette interface virtuelle, on est dans un cas type où cela peut directement déstabiliser l'OS hôte car il peut y avoir des collisions dans la gestion de l'interface réseau matérielle niveau hôte.
J'ai constaté ça sur KVM, sur Virtualbox… où on vous conseille par défaut d'opter pour le NAT (sachant que l'IPv6 résout en fait la question car il n'a pas besoin de NAT). Les configurations bridges mènent souvent à des problèmes sur l'hôte.

Sur un hôte bien plus puissant… oui tout cela peut "éventuellement" fonctionner, ici il faut prendre en compte les ressources limitées.

VickeS a commenté le 10.01.2023 21:33

Bonjour,

1Go de ram peut suffire, suivant le nombre et le type de services allumés.
Le problème vient bien de l'allocation autorisée trop grande pour la VM. J'ai eu le même problème et j'ai fais plein de test et cela vient bien de là.

Pour ma part j'ai réduit l'allocation de ram à la VM à 2.5Go de ram sur les 4Go (3Go faisait crash). J'ai commandé une barette de 8Go pour pouvoir allouer plus sans faire crash la freebox. Je renverrais celle de 4Go.

tJulianB a commenté le 11.01.2023 21:02

Bien évidemment tous les services dont j'ai parlé dans ma VM n'étaient pas en execution en même temps. Mais je vais faire l'upgrade.

Cependant, c'est tout de même une anomalie que le server Freebox crash plutôt que la VM, non ? C'est plus ça que je souhaitais remonter.

VickeS a commenté le 11.01.2023 21:48

Pour moi c'est bien un problème. Mais l'administrateur n'est pas du même avis et d'après lui c'est la faute de l'utilisateur s'il alloue trop de RAM. Je ne suis pas de son avis mais c'est ce qu'il a écrit sur mon post.

tJulianB a commenté le 12.01.2023 20:02

Ah oui en effet… je trouve pas ça très logique non plus.

Si c'est la faute de l'utilisateur pourquoi une limite est placée à GOmax - 1 dans ce cas ?
Si il y a une limite existante il faut juste l'adapter.

Un utilisateur qui débute ne sait pas forcément combien la Delta va/peut consommer …

Chargement...

Activer les raccourcis clavier

Liste des tâches

Détails de la tâche

Édition de la tâche