= Intérêts de la virtualisation =
 * Création simple d'un nouveau serveur 
 * Flexibilité des ressources allouées
 * Séparation des services (facilite les màj)
 * Tolérance aux pannes matérielles
 * … À compléter !

= Au Cr@ns =

== Baie de disque ==

Au Cr@ns, les disques durs des serveurs virtuels sont centralisés sur la baie de disque. Celle-ci est à la fois connectée au vlan adm pour permettre son administration, et à un réseau dédié à l'export des volumes, grâce au protocole [[http://fr.wikipedia.org/wiki/ISCSI|iSCSI]].
L'avantage de cette architecture est de permettre le partage des volumes virtuels entre plusieurs serveurs de virtualisation, ce qui permet de virtualiser sur l'un ou l'autre des serveurs physiques tout ou partie des serveurs virtuels. Cela autorise ainsi la maintenance d'un des serveurs physique sans arrêt des services.

La baie de disque (actuellement {{{nols}}}) possède une interface web de gestion des disques autorisant de nombreuses opérations (réplication, snapshots, etc), mais aussi une interface telnet permettant de réaliser des API (voir par exemple {{{/usr/scripts/gestion/iscsi/nolslib.py}}})

Actuellement, quatre serveurs sont connectés à la baie de disque pour exporter les volumes: 
 * {{{zbee}}}, pour le partage des home et {{{/usr/scripts/}}}
 * {{{kdell}}}, {{{fz}}}, {{{ft}}} et {{{stitch}}} pour la virtualisation

L'export des volumes fournis sur chacun des serveurs fournit tout un lot de périphériques {{{/dev/sdXX}}}. Les scripts dans {{{/usr/scripts/gestion/iscsi}}} se chargent, notamment au démarrage, de créer des liens symboliques entre ces fichiers et des noms "user-friendly" du type {{{/dev/nom_de_la_partition}}} (enfin, quand ça marche bien…)

== Serveurs de virtualisation ==
Actuellement, trois serveurs de virtualisation : {{{fz}}}, {{{ft}}}, {{{kdell}}} et {{{stitch}}}.

== Recettes de cuisine Cr@nseuse ==

=== Créer un nouveau DomU ===
Cette partie n'est plus d'actualité, car on a quitté Xen, mais il y avait un tutoriel détaillé, allant de l'allocation de nouveaux volumes sur la baie de disque à la planification des sauvegardes. Il est encore disponible ici : [[/CreerUnDomu]]

=== Créer une nouvelle VM ===
Un tutoriel détaillé, allant de l'allocation de nouveaux volumes, l'installation de base de Debian et des services principaux: [[/CreerUneVM]]

=== Rattacher la console d'une VM ===

Un script dans {{{/usr/scripts/gestion/virtualisation/}}}, appelé {{{connect-qm}}} permet de rattacher les machines configurées correctement. Les VM n'ayant en effet pas d'interface de connexion par défaut, on leur fait simuler une connexion console/série.

=== Migration à chaud sous Xen ===

Sous Xen, on aurait dû pouvoir migrer les DomU à chaud, c'est-à-dire transférer l'ensemble de l'espace de la machine virtuelle vers un autre virtualiseur, sans la couper. Cependant, à cette époque, où on avait deux virtualiseurs, {{{fy}}} et {{{fz}}}, cela ne fonctionnait pas bien : la plupart des DomU envoyées de {{{fz}}} vers {{{fy}}} mourraient en route, et on devait les relancer. On a pas réussi à trouver à l'époque l'origine du problème. C'est en passant de Xen à Proxmox qu'on a trouvé la source du problème.

=== Migration à chaud sous Proxmox ===

Lorsqu'on est sur un hôte, il suffit d'utiliser la commande qm migrate en mettant l'option --online.

== Les problèmes ==
Toute technologie vient aussi avec son lot de problèmes et/ou inconvénients.

=== Les migrations foireuses ===

http://ark.intel.com/compare/75790,37103,33083 : le processeur de {{{fy}}} ne contient pas la technologie VTx with extended page table. Cela signifie que la RAM de la VM était mappée d'une façon ingérable par {{{fy}}} quand elle venait d'une machine avec ladite technologie. D'où les foirages.

=== Entrées/Sorties ===
Étant donné l'abstraction matérielle réalisée par le système de virtualisation, il y a une perte de perfs au niveau des IO. Cependant, les dernières technologies (disques VIRTIO, etc) ont permis de récupérer une partie de ces pertes.

=== Manque de place ===
En raison de la duplication des systèmes d'exploitation (chaque DomU a son propre /), on évite généralement de stocker trop de données sur le DomU. Ceci nous a donc motivé (avec la latence des entrées-sorties) [[CransTechnique/CentralisationDesLogs|à centraliser les logs]].

=== Gestion du temps ===
L'utilisation de Xen semble poser des problèmes de synchronisation d'horloge entre le Dom0 et les DomU. En particulier, celle-ci semble inefficace et on observe une dérive temporelle importante des DomU, qui doit être corrigée, sous peine de plantage des services (beaucoup sont dépendants de l'heure courante). Malheureusement, ntp semble parfois nous jouer des tours. (Les nounous s'étant penchées sur le sujet pourront compléter et préciser le problème)
Bref, il s'agit là d'un problème ouvert …  Heureusement qu'on est passés à Proxmox.

=== Gestion des sauvegardes ===
Ceci n'est pas vraiment un problème, mais la sauvegarde des DomU sollicite à la fois la machine hôte et la baie de disque. Il serait intéressant d'utiliser les fonctionnalités de snapshot de la baie de disque au lieu d'une backup traditionnelle via [[CransTechnique/ServicesMineurs/BackupPc|BackupPc]]

----
CatégoriePagePublique