Elle apporte notamment le support des "Bind Mount Extensions"[1], une meilleure prise en charge du système de fichier JFS, une amélioration du "kernel helper"[2] et nombre d'autres petites améliorations. Cette nouvelle version corrige également beaucoup de bogues (Voir annonce complète et en anglais dans les liens ci-dessous).
Parallèlement, le projet a également annoncé le lancement d'un nouveau site web. Celui-ci est maintenant basé sur MediaWiki et son design a été entièrement refait. Il a remplacé l'ancien wiki le 5 septembre et la migration de la documentation est en cours d'achèvement . En outre, un FTP anonyme, des archives, un dépôt subversion et l'espace web des utilisateurs ont été ajoutés à l'infrastructure publique. Notes :
[1] Bind Mount Extensions : Ajout au noyau de code permettant de réaliser des "bind mounts" avec des options différentes du point de montage d'origine, par exemple "mount -o bind,ro ...". En d'autres termes, il est donc maintenant possible de passer des options "normales" à un "mount -o bind ".
[2] Kernel helper : Dispositif permettant de gérer en espace utilisateur des événements spécifiques à un contexte, sans devoir implémenter de gestion de politique de sécurité particulière dans le noyau. Cas d'école : La commande "reboot" (ou "halt") est tapée dans un système invité, on ne doit bien sûr rebooter que celui-ci, et pas le serveur hôte ni un autre invité. L'appel est donc intercepté par le noyau, redirigé en espace utilisateur vers Vshelper qui se charge des actions à entreprendre. C'est semblable au fonctionnement de Hotplug.
Qu'est-ce que Linux-VServer ?
Linux-VServer est une solution de virtualisation pour GNU/Linux. Contrairement à d'autres solutions, la séparation est ici accomplie par l'isolement au niveau du kernel; ainsi, les machines virtuelles (aussi appelées "contextes") partagent le même noyau, économisant les ressources tout en garantissant un niveau de sécurité élevé. Les processus virtualisés ont bel et bien l'impression de tourner dans leur propres machine réelle, et il est possible d'installer une distribution différente pour chaque système invité.
Gestion de "fermes" de vservers
Il existe quelques projets d'interfaces d'administration de vservers. Hasard du calendrier, le projet OpenVCP a publié, le 4 septembre, une release-candidate de la version 0.2.
OpenVCP (Open-Source VServer Control Panel) qui propose une interface web de gestion de ferme de vservers.
On peut, de celle-ci, construire (installer) et contrôler les serveurs virtuels, surveiller le trafic, etc... Cette dernière version corrige bien sûr quelques bugs et rajoute des fonctionnalités (gestion des utilisateurs/réseaux, support de TLS...)
Aller plus loin
- Linux-VServer (5 clics)
- Linux-VServer sur Wikipédia (EN) (1 clic)
- Linux-VServer sur Wikipédia (FR) (7 clics)
- Texte complet de l'annonce en anglais (0 clic)
- Ancien wiki (0 clic)
- OpenVCP (1 clic)
# Gains par rapport a Xen/qemu/etc.
Posté par Pierre Carrier . Évalué à 7.
Y a-t-il par exemple partage "dynamique" de la mémoire ? Les performances sont meilleures ? Qu'en est-il des possibilités en matière de réseaux ? (je ne connais que le fonctionnement de vmware sur le sujet)
De plus, comment les droits sont-ils gérés ? (je pense à des machines virtuelles dont on voudrait par exemple interdire l'accès à des disques ou ports)
Cette news n'était sûrement pas le meilleur lieu pour poser ce genre de questions, mais au passage...
[^] # Re: Gains par rapport a Xen/qemu/etc.
Posté par Prae . Évalué à 9.
Pour te donner un bonne exemple, j'arrive à installer une bonne dizaine de vserver en activité sur un portable P75 sans problème et sans encore latence.
Après tout dépend de l'activité, mais jusqu'à maintenant, les performances sont au rendez-vous car l'interconnexion et l'activité au sein du kernel a été réduit à une idée simple: le context_id.
Chaque process/file/handler possède un ctx_id qui (le) spécifie dans un monde parralèle.
Le main possède le ctx_id 0 et les autres, comme tu veux (ID random ou fixe)
La gestion de ce ctx_id ne demande presque rien au kenrel et apporte beaucoup en terme de perf et d'évolution future.
Je résume à mort, bien entendu.
Après, il y a aussi les features que je te laisse le soin d'appréhender.
En tout cas, c'est un beau projet je trouve, et la coreteam est toujours dispo pour aider voire débugger si besoin ait. (notamment bertl :)
[^] # Re: Gains par rapport a Xen/qemu/etc.
Posté par etham (site web personnel) . Évalué à 1.
[^] # Re: Gains par rapport a Xen/qemu/etc.
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
« Par rapport à la virtualisation de la machine, c'est mieux parce qu'il y a très peu d'overhead avec vserver »
;-)
[^] # Re: Gains par rapport a Xen/qemu/etc.
Posté par Prae . Évalué à 4.
Il fallait lire (entre les fautes de syntaxe et d'orthographe) :
"Par rapport à une virtualisation de machine, [vserver ajoute] très peu d'overhead."
[^] # Re: Gains par rapport a Xen/qemu/etc.
Posté par Prae . Évalué à 4.
LinuxFr est sous Vserver ;-)
[^] # Re: Gains par rapport a Xen/qemu/etc.
Posté par atmaniak (site web personnel) . Évalué à 0.
[^] # Re: Gains par rapport a Xen/qemu/etc.
Posté par Yann Droneaud (site web personnel) . Évalué à 2.
# Bind mount extensions
Posté par ben (site web personnel) . Évalué à 3.
cf http://wiki.alionet.org/doku.php?id=partitionnementsimple
Voilà, parcequ'à moi, ça ne me disait rien du tout...
Merci pour cette dépêche forte interressante
Benjamin
[^] # Re: Bind mount extensions
Posté par Sylvain Briole (site web personnel) . Évalué à 2.
Est-ce que par hasard quelqu'un saurait si ce genre d'option ou de technique est disponible sous xBSD (x={Net,Open,Free})?
[^] # Re: Bind mount extensions
Posté par manu_fred . Évalué à 1.
[^] # Re: Bind mount extensions
Posté par Antoine Jacoutot (site web personnel) . Évalué à 1.
[^] # Re: Bind mount extensions
Posté par Yth (Mastodon) . Évalué à 2.
C'est juste qu'il faut le refaire (dans fstab par exemple) à chaque redémarrage, et que ça peut se faire entre deux partitions différentes, ou via NFS etc...
Yth.
[^] # Re: Bind mount extensions
Posté par inico (site web personnel) . Évalué à 2.
[^] # Re: Bind mount extensions
Posté par ribwund . Évalué à 3.
mount -t proc none /proc
[^] # Re: Bind mount extensions
Posté par Florent Rougon (site web personnel) . Évalué à 1.
Par exemple, j'ai un chroot contenant Debian unstable dans le répertoire /usr/local/sid-root. Il arrive que je souhaite travailler sur des images qui sont dans /home/flo/images avec un logiciel qui est installé dans ce chroot (soit parce que le logiciel n'existe pas dans Debian stable, soit parce que je veux utiliser une version assez récente dudit logiciel). Il suffit de faire un :
# mount --bind /home/flo/images /usr/local/sid-root/home/flo/images
pour rendre les images accessibles dans /home/flo/images à l'intérieur du chroot. C'est nettement plus pratique (et rapide) que l'alternative consistant à copier les images dans le chroot, travailler dessus, puis les copier à nouveau hors du chroot en écrasant les anciennes versions.
# LinuxFR
Posté par ナイコ (site web personnel) . Évalué à 3.
On pourrait aussi parler d'une université française qui utilise quelques centaines de vservers répartis sur quelques dizaines de machines physiques, mais je laisse les intéressés se manifester au besoin ;-).
[^] # Re: LinuxFR
Posté par Jérôme BENOIS . Évalué à 2.
[^] # Re: LinuxFR
Posté par Prae . Évalué à 2.
A noter cependant que - par défaut - un process qui prend 100% de (faux) CPU dans un vserver ne floodera pas le serveur en lui-même ni même ses petits copains.
Si tu souhaites constater les performances, y'a Lycos Hebergement Mutualisé France (seulement?) qui à l'ensemble de ces "jails" pro-clients en vserver sous Linux. Ainsi qu'Ikse, une boite française qui gère (et développe) dotNode.org, la version libre d'Orkut-Google; JeuxLibre.net, etc...
Pour les autres : http://linux-vserver.org/VServer_Hosting :-)
[^] # Re: LinuxFR
Posté par didbaba . Évalué à 1.
[^] # Re: LinuxFR
Posté par ナイコ (site web personnel) . Évalué à 2.
# Interface loopback ?
Posté par N-Mi . Évalué à 2.
Le problème c'est que beaucoup de ces logiciels lancent des connexions vers "127.0.0.1" (pour la base de données, pour tester la machine sur laquelle il tourne, pour communiquer entre les composants). Comme il n'y a pas d'interface loopback séparée de la machine hôte, on est obligés de changer partout dans la configuration l'adresse loopback par l'adresse sur l'interface réseau. Là où ça se corse c'est pour les logiciels avec "127.0.0.1" codé en dur dans le source.
Du coup je viens de virer les Vservers de cette machine de tests et je commence à regarder du côté de Xen. Quelqu'un sait s'il est prévu un jour de rajouter une interface loopback par serveur virtuel ?
Question subsidiaire : y'en a qui ont réussi a faire de l'unification avec des vservers ? Si oui, et faire en sorte que lorsqu'on upgrade l'arborescence "de référence" ça fasse un upgrade de tous les vservers ? (le but étant qu'un nouveau vserver prenne le moins possible d'espace disque)
[^] # Re: Interface loopback ?
Posté par Prae . Évalué à 5.
Tu vas dans /etc/vservers/ton_vserver/
Dans "interfaces", tu crées un répertoire, disons "mon_loopback_cheri"
à l'interieur, tu crées tout plein de fichier :
bcast dev ip mask name prefix scope
Dans le premier (bcast), tu met le broadcast, exemple : 127.255.255.255
Dans le second (dev), tu met "lo" bien entendu :-)
Dans le troisième (ip), ... l'adresse ip 127.0.0.1 (ou autres si tu veux)
Dans le mask, le netmask : 255.0.0.0
Dans le name, tu places ce que tu veux, généralement le nom du vserver
Le prefix, c'est générale soit 8, 16, 24 (ou autres suivant votre topologie réseau)
Et en enfin dans le scope, tu met "host"
Tu restart le tout, Tadaaaaaaa !
# vserver monvserveur enter
# socket -sl 1234
Sur le main:
$ telnet localhost 1234
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
[^] # Re: Interface loopback ?
Posté par Amand Tihon (site web personnel) . Évalué à 5.
Je ne connais strictement rien à vserver, mais si j'ai bien compris, il désire avoir dans chaque vserver une appli qui puisse écouter sur 127.0.0.1:1234 et que ce loopback soit propre au vserver où il a été créé/configuré.
Mais je me trompe peut-être...
[^] # Re: Interface loopback ?
Posté par Prae . Évalué à 4.
En effet, il n'y a pas de "jailing" de ce type pour l'interface loopback par défaut,
Cependant, la feature a été codé par la coreteam, mais elle n'a pas été intégré à la version courante du patch principal.
Voici ce patch : http://vserver.13thfloor.at/Experimental/delta-lo0.05.1.diff
Il sera intégré dans les versions 2.2 voire 2.3 si tout se passe bien
[^] # Re: Interface loopback ?
Posté par N-Mi . Évalué à 2.
Bon, vais essayer le patch pour voir s'il fonctionne correctement, ou sinon attendre la première version de développement qui l'incluera.
[plussoiement]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.