à propos de chroot évolués ... Quel ne fut pas ma surprise de découvrir LXC suite à l'annonce de la suppression d'openvz dans les paquetages officiels de Debian. Ok j'avais entendu parler de cgroup, et d'une volonté de mutualiser les ressources (en code source) utilisées pour tous les systèmes de virtualisation. Mais jamais je n'ai entendu parler de LXC lorsque mon choix c'est porté il y a 4ans sur le merveilleux openvz
LXC ne supporte pas les quota de disques, tout est root à l'intérieur et pas de migration à chaud, et pas d'ultra granularité des beancounters
Aucune doc sur XLC ou presque site miteux de branleur de garage : lxc.sourceforge.net à comparer avec http://wiki.openvz.org/
Quelqu'un à une explication, à part ok c'est mieux les cgroup et c'était l'avenir. Pourquoi ne pas avoir intégré les cgroup (un peu comme kde passe à DBus par exemple) Y a t il eu intégration des techno d'openvz dans LXC ? Les dev d'openvz sont ils dégoutés ? Peut-on migrer automatiquement openvz vers lxc ? Le retard va t il est rattrapé ?
par avance merci !
# c'est passé ya quelques jours
Posté par Glorf . Évalué à 2.
cadeau :
https://linuxfr.org/users/jyes/journaux/mauvaise-surprise-virtuelle%E2%80%A6
[^] # Re: c'est passé ya quelques jours
Posté par Jean . Évalué à 1.
merci intéressant, mais ça ne répond pas à mes questions sur openvz ...
[^] # Re: c'est passé ya quelques jours
Posté par geb . Évalué à 2.
Il faut dire qu'il y a 4 ans LXC n'existait pas (ou en était à ses prémices), je ne connais pas les dates exactes.
Openvz a toujours eu du mal à suivre les différentes versions de linux. Cela tient sans doute un peu au code, mais aussi sans à la volonté des développeurs de faire un produit entreprise, et donc de se concentrer sur le support des kernels LTS, typiquement ceux utilisés par red hat.
[^] # Re: c'est passé ya quelques jours
Posté par RB . Évalué à 3.
Je me range un peu à cette opinion:
http://blog.gauner.org/blog/tag/linux-vserver-lxc-container-virtualization-contextualization/
J'ai bien aimé openvz, simplement le fait que ce soit pas mainline m'a parfois empêché de prendre les kernel que je voulais au profit de ceux avec openvz.
L'avenir à l'air d'être pour LXC maintenant même s'il lui manque quelques features.
[^] # Re: c'est passé ya quelques jours
Posté par RB . Évalué à 1.
Ah oui pour les quotas disques, là aussi il y a un remplacement très efficace et mainline, utiliser lvm pour des partitions à la demande, avec le cow (copy on write) y a même manière d'instancier beaucoup de vm en un minimum de temps...
[^] # Re: c'est passé ya quelques jours
Posté par geb . Évalué à 4.
Je suis curieux de savoir comment tu fais ton cow.
Et dans tous les cas ça n'est pas la même chose. Avec vserver et openvz, tu peux donner des quotas sur une partition. Avec LXC tu es obligé de creer une partition. La différence pourra paraitre minime, mais un exemple simple illustrera la différence.
Prends un disque de 500 Go. Mets 50 VMs dessus.
Si tu dois creer des partions pour chaque VM, tu peux leur donner 10Go max.
Si tu peux partager la même partition. Rien n'empêche de donner un peu plus , en gageant sur le faite que tout le monde n'utilisera pas ses 15 ou 20Go.
C'est d'ailleurs exactement la même différence entre la gestion de la mémoire avec lxc,vserver, openvz et kvm,qemu,xen:
Dans un cas tu peux légèrement surbooker: Si tu as une VM a qui tu alloues 256mo mais qui en utilise 128mo, le kernel verra une utilisation de 128mo.
Dans l'autre si tu alloues 256mo à une VM, tu vas utiliser 256mo.
(A titre d'exercice je te laisse le soin de trouver à quelle technologie correspond quel comportement :) )
[^] # Re: c'est passé ya quelques jours
Posté par RB . Évalué à -5.
Merci de tes explications, j'aime bien ce ton pédant que tu prends.
J'ai mis où que c'était exactement la même chose ? J'ai parlé de lvm comme d'un outil qui peut dans certains cas palier à l'absence des quotas de par sa souplesse (y compris les possibilités de redimensionnement à chaud avec certains fs).
Pour le cow faut regarder du côté des lvm snapshots...
[^] # Re: c'est passé ya quelques jours
Posté par geb . Évalué à 1.
Pardon pour le ton c'était pas volontaire.
Mais justement, pour moi, c'est pas aussi bien, le hack à coup de LVM (que tu peux utiliser avec openvz et vserver). Par contre, si il y a moyen de passer outre, et d'avoir le même genre de comportement qu'avec vserver ou openvz, je suis vraiment curieux de savoir comment :-)
[^] # Re: c'est passé ya quelques jours
Posté par barmic . Évalué à 2.
Je regarde tout ça d'un oeuil intéressé mais pas expert. Pourquoi tu ne peux pas utiliser les quotas classiques ? Tout les processus ont le même utilisateur ?
Il y a pas moyen de corriger ça avec un LSM style AppArmor ou SELinux ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: c'est passé ya quelques jours
Posté par geb . Évalué à 2.
Non, mais tu peux avoir plusieurs utilisateurs ayant le même uid sur les différentes VMs.
Par contre, le fonctionnement de ces quotas par VM est fortement inspiré du fonctionnement des quotas classiques, avec des IDs rajoutés en plus (voir http://linux-vserver.org/Paper#Filesystem_XID_Tagging pour vserver, cela doit être semblable avec openvz).
Honnêtement, je ne sais pas. Par contre:
cela ne semble par être le "coeur de métier" de ces outils. Je ne suis pas du tout sûr qu'ils proposent de quoi faire des quotas.
il est possible que certaines choses rentrent en conflits. Typiquement pour utiliser openvz ou vserver, il faut avoir désactivé SELinux. A priori, seul grsecurity est utilisable avec lxc et vserver (mais pas openvz), et il ne permet pas ce genre de choses.
[^] # Re: c'est passé ya quelques jours
Posté par barmic . Évalué à 0.
Si tu as vraiment besoin de machines virtuelles, pourquoi tu n'en utilise pas ?
C'est quoi leur cœur de métier si ce n'est contraindre les utilisateurs/groupes/processus y compris sur leur droits au système de fichier ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Manque de doc...
Posté par Corentin Chary (site web personnel) . Évalué à 3.
En fait, LXC c'est juste le nom du projet global, et accessoirement des outils userspaces qui permettent de manipuler les conteneurs (--help + man t'aiderons à leur sujet).
Pour tout le reste de la conf, il faut plutôt que tu regarde directement chacun des éléments qui composent l'infra LXC. Par exemple beaucoup de choses peuvent être faites avec cgroup et dans ce cas, c'est la doc cgroup directement qu'il faut chercher.
Tu peux aussi lire les différents articles de l'excellent Lwn sur ces différents composants: http://lxc.sourceforge.net/index.php/about/kernel-namespaces/
LXC étant upstream, et surtout maintenu et développé par IBM, ça me semble une très bonne solution à long terme. Ce qui n'est pas forcément le cas d'OpenVZ qui semble être bloqué au 2.6.32, et semble se trainner pas mal de bugs (en tout cas j'en ai recontré pas mal de moches sur la version d'ubuntu 8.04 LTS).
[^] # Re: Manque de doc...
Posté par geb . Évalué à 3.
J'avais commencé à troller sur https://linuxfr.org/users/jyes/journaux/mauvaise-surprise-virtuelle%E2%80%A6 mais le journal commençant à mourir, je n'ai pas continué :)
Il y a clairement des manques dans les cgroups. Par exemple au niveau de la limitation de la mémoire:
Avec vserver, il y a moyen de limiter la mémoire en terme de mémoire virtuelle (mem + swap). C'est le kernel qui globalement, décidera si cela vaut le coup de swapper ou non. Et, si tu dépasses le quota, tu ne peux plus allouer de mémoire (logique non?)
Avec les cgroups, tu dois configurer une limite en terme de mémoire + une limite en terme de swap. Cela pose un premier problème, cela force à swapper, quand l'hôte à encore de la mémoire disponible ! De plus, et c'est là le plus drôle, l'allocation n'est pas bloquée. Donc un process essayant d'allouer plus que son quota va pouvoir allouer (dans le swap), mais va se faire killé par l'oomkiller. Donc, il va écrire dans le swap, puis le kernel va vider le swap. Imagines que cela arrive à un processus apache (+ mod_php), aussitôt killé, le master va chercher à le relancer. Cela fait une très jolie forkbomb qui en plus va faire plein d'aller et retour dans le swap et peut finir facilement par écrouler l'hôte. L'oom-killer de la version 2.6.37 devrait diminuer un peu le problème, mais ... avoir une vrai limite en terme de mémoire virtuelle, et des allocations bloquées quand le quota est dépassé serait un poil mieux.
Bref, les cgroups c'est pas encore ça. Vserver permet de les utiliser, mais, je suis en train de voir comment repasser sur l'ancien comportement, lui au moins ne faisait pas monter le load de la machine à 500.
# KVM
Posté par bubar🦥 (Mastodon) . Évalué à -6.
[^] # Re: KVM
Posté par geb . Évalué à 3.
ça n'a rien à voir. Ce serait comme comparer un PC et une carte graphique.
# Parefeu
Posté par Spack . Évalué à 1.
D'ailleurs, concernant la mise en place d'un pare-feu sur une machine hébergeant plusieurs conteneur LXC, ça se passe comment ?
Il faut en mettre un pour chaque conteneur ou un sur la machine hôte suffit ? Car bon au final il n'y a qu'un seul noyau qui tourne et tout fini par sortir sur la même interface.
[^] # Re: Parefeu
Posté par geb . Évalué à 2.
Cela dépend ... de comment tu configures tes VMs.
Si toutes tes VMs écoutent directement sur les interfaces. Il faut configurer le firewall sur chacune.
Si à l'inverse, l'hôte tient rôle de routeur, tu peux commencer à filtrer sur l'hôte, et éventuellement sur les VMs.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.