Merci d’avance.

Rien de surprenant, donc, à ce que tu aies un peu de mal. C’est d’autant plus courageux.

Pourquoi pas Xen ?
J’aurai du mal à répondre précisément car je ne connais que dans les grandes lignes.

Xen permet la para-virtualisation (la machine virtuelle contient système d’exploitation complet mais adapté pour être virtualisé) ou, sur des processeurs avec le jeu d’instructions adéquat, la virtualisation complète (la machine virtuelle contient un système d’exploitation complet qui n’a pas « conscience » d’être virtualisé).

OpenVZ permet de cloisonner le système hôte en subdivisions qui se comportent comme des machines virtuelles. Ces subdivisions contiennent un système d’exploitation incomplet car le noyau est partagé par toutes les subdivisions et le système hôte.

De ces fondements découlent naturellement plusieurs conséquences directes :
- Xen offre plus de neutralité pour les système hébergés, leur virtualisation sera peu ou pas perceptible par ces derniers, alors que certaines limitations se feront sentir dans les machines virtuelles OpenVZ, en particulier si une application nécessite de charger des modules noyau (puisque ce dernier est partagé)
- Xen permet d’héberger des machines virtuelles avec des systèmes d’exploitation différents, mixer des windows et des linux, ou des linux avec des noyaux spécifiques, alors qu’OpenVZ n’héberge que des distributions linux, éventuellement différentes, mais qui auront forcément toutes le même noyau
- Xen est plus lourd car chaque machine virtuelle a une empreinte mémoire plus importante (du fait que le système hébergé est complet) et consomme davantage de ressources ; la densité (nbre de machines virtuelles / hôte) potentielle est nécessairement moindre qu’avec OpenVZ
- la pénalité de performance due à la virtualisation est nécessairement plus importante avec Xen qu’avec OpenVZ, car pour « atteindre le matériel » les serveurs virtuels doivent « traverser » deux noyaux au lieu d’un

Voila pour les grands principes. Après je n’ai pas administré de serveurs xen, je n’ai donc pas d’avis sur le degré de complexité (ou de facilité) que cela représente. Je suis parti sur OpenVZ car, partant des principes ci-dessus, c’était ce qui correspondait le mieux à mes besoins :
- je ne cherche qu’à virtualiser des serveurs linux
- ces serveurs hébergent majoritairement des applications de gestion qui peuvent s’accommoder sans difficulté d’un noyau commun
- je cherche une performance optimale et une densité maximale pour des serveurs virtuels aussi petits et indépendants que possible (j’ai prévu d’expliquer pourquoi dans un article)

Mais tout le monde n’a pas les mêmes besoins, et dans d’autres circonstances, OpenVZ ne sera pas le meilleur choix.

En tout cas, si, dans un autre contexte je devais me tourner vers une solution de virtualisation complète, j’examinerais de près KVM. Certes, Xen est plus ancien et supporté par une société, mais d’une part la para-virtualisation ne présente plus, aujourd’hui, aucun intérêt à mon avis, et d’autre part, pour la virtualisation complète KVM me parait plus prometteur et mieux soutenu par la communauté du libre. C’est en tout cas le sentiment que m’ont laissé les quelques articles que j’ai lu sur le sujet.

Et pour répondre à la dernier question, oui j’ai l’intention de faire un article sur la sauvegarde des machines virtuelles. Je l’ai commencé il y a peu mais pas encore achevé.

Bon courage !

Je connais une personne qui fait comme vous dans le cadre professionnel:
http://howto.landure.fr/gnu-linux/debian-4-0-etch
pour quoi ne pas faire du xen?
http://howto.landure.fr/gnu-linux/debian-4-0-etch/installer-et-configurer-xen-sur-debian-4-0-etch

Pour le moment j’installe openvz chez moi et quand j’aurai à peu prés compris je mettrai ça « en production » à la maison pour terminer au lycée dans quelques temps.

Je vais un peu plus « manger » de la doc de openvz histoire d’approfondire tout ça et attendre la nouvelle feuille de calcul

Par avance merci!

Une remarque: est il envisagé de faire un article sur la sauvegarde des ve?

Essaie avec la nouvelle version de la feuille de calcul lorsque je l’aurai mise en ligne.

Si ce tampon de mémoire est momentanément saturé, cela signifie que des paquets peuvent être perdus. S’agissant de paquets TCP, ils seront réémis, mais si cela se produit trop souvent, les « performances » de ta machine virtuelle ne seront pas au top.

J’ai modifié la feuille de calcul pour les besoins de mon travail, et la nouvelle version doit ne plus provoquer de warning, au moins sur le paramètre dgramrcvbuf.

Cette feuille de calcul constitue une aide pour avoir un ensemble de paramètres UCB à peu près cohérents, mais il faut quand même savoir ce que fera la machine virtuelle pour tailler ces valeurs. J’ai aussi agrémenté la nouvelle mouture de la feuille de quelques commentaires qui vont dans ce sens.

Je vais la récupérer pour la mettre en ligne, et je le signalerai quand ce sera fait.

Le paramètre dgramrcvbuf permet de contrôler les tampons de mémoire alloués à la gestion des sockets UDP.
Le paramètre othersockbuf permet de contrôler les tampons de mémoire alloués à la gestion des sockets unix.

Pour répondre à ta question sur la maintenance de cette doc… Dans le cadre de mon travail je suis souvent amené à mettre en place des solutions techniques et je m’efforce pour cela d’utiliser au maximum des logiciels libres. Le nombre et la diversité de nos installations implique que ces solutions soient accompagnées d’une documentation adaptée à notre contexte (plus ciblée) afin que notre équipe d’administrateurs systèmes puisse réaliser leur travail d’exploitation correctement.

J’estime que c’est un juste retour pour la communauté d’utilisateurs de logiciels libres que d’adapter cette documentation pour la sortir de notre contexte et la rendre plus « généraliste ». C’est l’idée qui est à l’origine de ce site.

Aussi, tant que nous utiliserons OpenVZ (et c’est partir pour durer) j’essaierai de maintenir cette doc (ou plutôt ces articles) à jour.

petites précisions:

cat /proc/user_beancounters
Version: 2.5
uid resource held maxheld barrier limit failcnt
1: kmemsize 317037 907673 1474560 1622016 0
lockedpages 0 0 16 16 0
privvmpages 724 7250 24576 27034 0
shmpages 0 0 8192 8192 0
dummy 0 0 0 0 0
numproc 4 13 30 30 0
physpages 469 5570 0 2147483647 0
vmguarpages 0 0 8192 2147483647 0
oomguarpages 469 5570 8192 2147483647 0
numtcpsock 1 2 30 30 0
numflock 1 6 30 33 0
numpty 0 1 16 16 0
numsiginfo 0 2 256 256 0
tcpsndbuf 0 6696 122880 199680 0
tcprcvbuf 0 190968 122880 199680 4
othersockbuf 2232 5160 46080 122880 0
dgramrcvbuf 0 2232 3600 3600 0
numothersock 1 4 30 30 0
dcachesize 0 0 442368 486605 0
numfile 105 293 750 750 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
numiptent 10 10 128 128 0
0: kmemsize 2184929 2740641 2147483647 2147483647 0
lockedpages 0 0 2147483647 2147483647 0
privvmpages 4465 5238 2147483647 2147483647 0
shmpages 649 649 2147483647 2147483647 0
dummy 0 0 2147483647 2147483647 0
numproc 50 60 2147483647 2147483647 0
physpages 2244 2584 2147483647 2147483647 0
vmguarpages 0 0 2147483647 2147483647 0
oomguarpages 2244 2584 2147483647 2147483647 0
numtcpsock 6 6 2147483647 2147483647 0
numflock 2 2 2147483647 2147483647 0
numpty 1 1 2147483647 2147483647 0
numsiginfo 0 2 2147483647 2147483647 0
tcpsndbuf 64728 64728 2147483647 2147483647 0
tcprcvbuf 98304 98304 2147483647 2147483647 0
othersockbuf 20088 23016 2147483647 2147483647 0
dgramrcvbuf 0 4280 2147483647 2147483647 0
numothersock 27 31 2147483647 2147483647 0
dcachesize 0 0 2147483647 2147483647 0
numfile 981 1145 2147483647 2147483647 0
dummy 0 0 2147483647 2147483647 0
dummy 0 0 2147483647 2147483647 0
dummy 0 0 2147483647 2147483647 0
numiptent 10 10 2147483647 2147483647 0
############################

J’ai juste fait une installation de irsii et de screen et fait tourné irssi dans cette ve…

J’ai définit une machine avec 64Mo de ram 1go de disque dur et 20 processus.

Quand je fais une vérification ça donne:

vzcfgvalidate /etc/vz/conf/1.conf
Warning: dgramrcvbuf.bar should be > 32768 (currently, 3600)
Recommendation: othersockbuf.bar should be > 132096 (currently, 46080)

C’est le premier warning qui m’inquiète de plus je n’arrive pas trop à comprendre sur quoi ses paramétres joues…

Les lignes de commandes:
##############################
vzctl set 1 –diskspace 943718:1048576 –diskinodes 58982:65536 –save
vzctl set 1 –avnumproc 20:20 –numproc 30:30 –numtcpsock 30:30 –numothersock 30:30 –vmguarpages 8192:2147483647 –kmemsize 1474560:1622016 –tcpsndbuf 122880:199680 –tcprcvbuf 122880:199680 –othersockbuf 46080:122880 –dgramrcvbuf 3600:3600 –oomguarpages 8192:2147483647 –privvmpages 24576:27034 –lockedpages 16:16 –shmpages 8192:8192 –numfile 750:750 –numflock 30:33 –dcachesize 442368:486605 –save
##############################

Une autre question un peu hors-sujet: es que la doc va suivre petit à petit les évolutions de openvz? les petites modifications par exemples, les nouveautés majeur etc?

Par avance merci pour cette doc!

merci pour ces articles d’une grande qualité je vais enfin pouvoir mettre et exploiter un openvz sur le serveur de mon lycée!!

J’aurai bien une centaines de questions vu que je ne connais pas openvz mais je vai me retenir

Bravo pour ce travail ça va nous servir par ici! ;o)