La sécurité de la virtualisation : suite et fin

Cet article complète le précédent sur le sujet de la sécurité de la virtualisation en abordant l’aspect réseau de stockage et essaye de présenter les risques réels de sécurité des plateformes de virtualisation. Il s’agira également du dernier billet sur ce sujet bien que je compte revenir sur ce sujet par la suite.

La sécurisation du stockage

La virtualisation n’ajoute pas de risque particulier à partir du moment où l’on suppose que l’attaquant dispose d’un accès physique aux données. Ce type d’exploit est donc uniquement inhérent au stockage sur disque.

Les réseaux de stockage en Fibrechannel n’ajoutent également pas de risque particulier. Seul les hyperviseurs ont accès aux supports de stockage distribués par le réseau de stockage. De plus, il est possible de gérer finement les accès aux différents supports de disque par les biais des techniques de « zoning ». Le zoning est une technique équivalente aux « Private VLAN » de Cisco dans le cas des réseaux Ethernet.

Contrairement à ce qui a été présenté Samedi dernier, la connexion des équipements Fibrechannel au réseau Ethernet n’ouvre pas de faille supplémentaire. Il n’est pas possible d’utiliser cette interface pour accéder aux données transitant sur le réseau de stockage. L’interface Ethernet permet uniquement d’accéder aux informations de configuration du commutateur.

Supposons qu’il soit possible d’accéder aux données transitant sur le réseau Fibrechannel par le biais de cette interface Ethernet. Toute tentative de spoofing d’adresse MAC serait parfaitement inutile car les réseaux Fibrechannel n’utilisent pas d’adresses MAC mais des WWN qui n’ont rien à voir. Les protocoles de communication sont différents et ne sont pas compatibles.

Cette problématique est cependant intéressante dans le cas des réseaux iSCSI qui n’ont même pas été mentionnés. Il n’est absolument pas souhaitable que les LAN iSCSI soient routables vers d’autres réseaux. Il est même recommandé d’avoir des équipements uniquement dédiés aux fonctionnalités iSCSI dans la mesure du possible.

Récapitulons…

Les potentielles interfaces d’attaque vers les hyperviseurs sont très peu nombreuses. Dans le cas de la virtualisation totale et de la virtualisation matérielle assistée, ces interfaces sont même inexistantes. Dans le cas des interfaces de paravirtualisation, leur utilisation est standardisée par le biais d’API mais la découverte de failles reste envisageable bien qu’aucune n’ait été trouvée à ce jour.

Les mécanismes de DoS sont régulés voire supprimés par les mécanismes classiques d’ordonnancement présents dans toutes les solutions de virtualisation.

Quels sont les risques ?

Les risques réels de sécurité inhérents aux plateformes de virtualisation se situent, d’une part, au niveau des interface de gestion. Les interfaces de gestion ne sont pas propres à la virtualisation mais leur utilisation dans ce cas particulier est généralisé.

L’accès aux interfaces de gestion doivent être sécurisés par les mécanismes réseau traditionnels ainsi que par le biais de méthodes d’authentification. Dans le cas d’une compromission de ces interfaces, les données et l’accès aux machines virtuelles reste indemne. Les interfaces ne disposent généralement pas d’accès particulier aux données, elles disposent uniquement d’une vue globale permettant la configuration des supports de stockage. En ce qui concerne l’accès aux VM, il reste protégé par les protections classiques telles que le couple login et mot de passe. Le passage dans des modes plus privilégiés attireraient inévitablement l’attention car cela nécessiterait des redémarrages non planifiés.

Conclusion

Traditionnellement, on considère qu’une technologie est sécurisée jusqu’à preuve du contraire. Il n’est pas utile de céder au sensationnalisme en décriant des potentielles failles qui n’ont pas été découvertes et qui n’ont jamais été exploitées (dans le cas de Xen).

Si nous suivons cette supposition traditionnelle, nous pouvons affirmer que la virtualisation est une technologie sécurisée. Comme toute technologie informatique, il est nécessaire d’être vigilant lors de son implémentation en suivant quelques règles de bon sens.

Pour revenir au sujet de la présentation effectué lors de la nuit du hack, j’ai été largement déçu par cette présentation aux conclusions au mieux hâtives et des nombreuses autres imprécisions que je n’ai pas évoqué ici.

La sécurité de la virtualisation

Ce weekend avait lieu la Nuit du Hack 2010. Il s’agit d’un événement orienté vers tous les types de hacking. De nombreuses conférences étaient proposées au public venu pour l’occasion avec notamment une présentation du hacking de l’iPhone et de la PS3.

Une présentation a particulièrement attiré mon attention mais pas pour de bonnes raisons. En fin de soirée avait lieu une conférence intitulé « Virtualisation et sécurité ». J’attendais donc avec impatience cette conférence. Autant dire que cela a été une grande déception. Le sujet était traité d’un point de vue beaucoup trop global mais, surtout, les informations soutenues étaient plus que discutables.

Je vais donc profiter de cette espace pour tenter d’éclaircir certains points par rapport à la sécurité de la virtualisation.

Classification

Avant de plonger dans l’étude à proprement dit de la sécurité dans la virtualisation, il est intéressant de se replonger dans la classification des solutions. Lors de la présentation, il avait été différencié les types de virtualisation suivants : « full virtualisation », « paravirtualisation » et « hyperviseurs ».

Un hyperviseur n’est pas un type de virtualisation mais une application qui peut effectuer de la virtualisation. Il est possible de les classifier selon deux catégories bien que cette division ne me plaise pas particulièrement.

La sécurisation de l’hyperviseur : DoS & DDoS

Lors de la présentation, le DoS (Denial of Service) et le DDoS (Distributed Denial of Service) ont été désignés comme des solutions simples et efficaces de neutraliser une plateforme de virtualisation.

Dans le cas de Xen, il est pratiquement impossible de communiquer avec l’hyperviseur. Il ne faut bien sur par confondre hyperviseur et domaine 0 (ou console de gestion dans le cas de VMWare). L’attaque DoS est donc difficile à imaginer dès le départ. L’interface de communication avec l’hyperviseur dont nous disposons est l’API des hypercalls, remplaçants des appels systèmes classiques dans le cas de la paravirtualisation.

L’utilisation des ces hypercalls est limitée par les algorithmes d’ordonnancement système ce qui empêche une utilisation abusive. Il s’agit du même mécanisme que celui utilisé pour le partage des ressources physiques. Le DoS semble donc impossible par ce biais.

Les outils d’administration sont également un potentiel point d’entrée supplémentaire. Ces outils ne sont accessibles qu’à partir du domaine 0 qui peut difficilement être considéré en tant que VM comme les autres. Un attaque DoS sur le domaine 0 rendrait les mêmes résultats qu’une attaque DoS sur les autres machines virtuelles étant donné les mécanismes d’ordonnancement.

La communication avec l’hyperviseur n’étant possible que par ces interfaces, il parait impossible d’y effectuer une attaque DoS capable d’atteindre toutes les machines virtuelles de la plateforme.

La sécurisation de l’hyperviseur : cloisonnement

Le cloisonnement des machines virtuelles est bien sûr une caractéristique élémentaire d’une plateforme de virtualisation. Contrairement à ce qui a été dit, l’hyperviseur n’a pas « la main » sur les machines virtuelles. Il a simplement la possibilité de les éteindre, de les démarrer ou de les mettre en pause. Ni plus, ni moins.

Le cloisonnement est géré par la restriction des accès mémoire. Les hyperviseurs ont été spécifiquement prévus afin d’éviter un débordement des accès vers la mémoire. Le seul vecteur d’exploitation de ce type de faille est les hypercalls dans le cas de Xen. A ce jour aucune faille connu permet d’accéder à des zones mémoires non autorisées.

De plus dans le cas de la virtualisation totale et de la virtualisation matérielle assistée, les machines virtuelles ne disposent même pas d’interface spécifique avec l’hyperviseur ce qui rend pratiquement impraticable de ce type de vulnérabilité.

Les risques d’erreur de cloisonnement ne sont pas inexistants bien entendu cependant il ne faut pas perdre de vue qu’il s’agit de l’objectif même de la conception de l’hyperviseur et que les machines virtuelles disposent de très peu ou aucune interface de communication avec l’hyperviseur afin de l’induire en erreur.

Dans le prochain (et dernier épisode), nous étudierons les autres points abordés lors de la présentation et les risques réels associés à la virtualisation. Loin de moi l’idée de prêcher la sécurisation totale de la virtualisation, je pense cependant qu’il est très facile et réducteur d’agiter des menaces sans fondement pratique.

Installation de Xen 4.0 sur Debian Lenny

Les tutoriels d’installation ne sont pas forcément les plus intéressants à blogger et j’en ai fait très peu pour cette raison. J’avais déjà parlé de l’installation de Xen 3.2.1 sur Debian Lenny. Au moment où j’ai écrit ce billet, cette version commençait à être relativement vieillissante. Je vais donc traiter aujourd’hui de l’installation de Xen 4.0.

Petit historique

Vous savez peut être que Xen a été quelque peu obscurcit par l’introduction de KVM dans le noyau Linux. Cette inclusion de KVM a conduit des distributions telles que Red Hat et Ubuntu à supprimer Xen de leurs distributions ou de ne laisser qu’un support pour le moins minimal. A l’époque de ces faits, Xen n’était compatible qu’avec un ou deux noyaux Linux patchés par l’équipe de Xen. Cette époque est révolue car Xen a évolué vers les noyaux dits « Paravirt Ops » ce qui signifie que la compatibilité d’un noyau Linux avec Xen ne tient plus qu’à un module de ce même noyau.

La version Xen 4.0 est particulièrement intéressante car il s’agit de la première version qui fonctionne par défaut avec les noyaux Paravirt Ops. L’installation de versions antérieures vous assurera la douleur de devoir éventuellement passer vers une version supérieure à la 4.0 lorsque vous voudrez mettre à jour vos noyaux Linux.

Installation

Nous pouvons désormais passer aux choses sérieuses. Nous allons effectuer une installation à partir des sources car il n’existe pas encore de paquets. Et puis de toute façon, une petite compilation ne vous fait pas peur !

Nous allons tout d’abord récupérer l’archive sur le site de Xen et on la dézippe :

wget http://bits.xensource.com/oss-xen/release/4.0.0/xen-4.0.0.tar.gz

tar zxvf xen-4.0.0.tar.gz

Nous allons ensuite installer tous les pré-requis et ils sont nombreux.

apt-get install bcc bin86 gawk bridge-utils iproute libcurl3 libcurl4-openssl-dev bzip2 module-init-tools transfig tgif texinfo texlive-latex-base texlive-latex-recommended texlive-fonts-extra texlive-fonts-recommended pciutils-dev mercurial build-essential make gcc libc6-dev zlib1g-dev python python-dev python-twisted libncurses5-dev patch libvncserver-dev libsdl-dev libjpeg62-dev iasl libbz2-dev e2fslibs-dev git-core uuid-dev gcc-multilib

Passons désormais à la compilation. Si vous avez une machine dotée de plusieurs cœurs / processeurs, n’hésitez surtout pas à utiliser l’option -jX où X est le nombre de cœurs que vous avez. Cette option permet de répartir la compilation sur tous les cœurs et ainsi de la finir plus rapidement. J’avais un BiQuad Core, donc ce sera 8 pour cet exemple.

make -j8 xen

make -j8 tools

make -j8 stubdom

Ensuite, on installe tout ca.

make -j8 install-xen

make -j8 install-tools

make -j8 stubdom

Grâce à toutes ces commandes, nous avons installé Xen ainsi que tous les outils associés. Il nous manque plus que le noyau Linux pour les domaines. A partir de là, vous pouvez soit créer votre propre noyau soit utiliser un noyau proposé par Xen. J’ai choisi de faire cela car c’était plus simple, plus rapide et plus pratique.

On va donc exécuter la commande qui va nous permettre de récupérer et de compiler le noyau qui va bien pour notre installation de Xen.

make -j8 world

Pour installer le noyau que vous avons compilé, il ne manque qu’à exécuter la commande suivante. On crée au passage l’initrd qui va bien.

make install

mkinitramfs -o /boot/initrd-2.6.31.13.img 2.6.31.13

Vous devez ensuite modifier Grub afin qu’il s’adapte à Xen. La configuration suivante fonctionne sur l’hyperviseur que j’ai eu l’occasion d’installer. Il faut adapter le root en fonction de votre serveur. Ici, il s’agissait d’un contrôleur RAID HP.

title           Xen 4.0.0 / Debian GNU/Linux, kernel 2.6.31.13
root            (hd0,1)
kernel          /boot/xen-4.0.0.gz
module          /boot/vmlinuz-2.6.31.13 root=/dev/cciss/c0d0p2 ro console=tty0
module          /boot/initrd-2.6.31.13.img

Vous pouvez ensuite rebooter sur votre nouvelle installation de Xen 4.0 avec votre noyau Paravirt Ops. Si vous souhaitez modifier des options à la compilation du noyau, il faut se placer dans le bon répertoire et activer les bons paramètres dans le menu.

cd build-linux-2.6-pvops_x86_64

make menuconfig

Il faut activer le support TUN/TAP si vous souhaitez exécuter des domaines HVM ainsi que le support du 802.1Q si vous souhaitez placer vos domaines sur différents VLAN. Ces deux options ne sont pas activées par défaut.

Au final, j’espère que ce tutoriel vous sera utile et que j’ai été clair. Le passage vers les noyaux en Paravirt Ops est une évolution majeure dans l’histoire de Xen et permettra une adoption nettement plus large.

Les différents types de nuages

Après avoir tenté de définir le cloud computing et avoir évoqué les différentes technologies associés, nous allons nous intéresser aux différentes offres. Nous nous intéresserons à toutes les offres de la nature qui revendiquent un caractère de « cloud computing ».

Nous distinguerons trois types de nuages. Le premier type, également le premier à être apparu sous la dénomination « cloud », est le nuage public. Le second type est le nuage privé. Le dernier type est un mélange des deux, c’est à dire, un nuage privé-public.

Le nuage public

La dénomination de « cloud computing » est arrivée en même temps que les grands nuages publics. Ces grands systèmes informatiques ont été rendus viables grâce à une forte automatisation et une grande efficacité des couches de virtualisation.

Dans ce type de nuage, chaque client se voit attribuer plus ou moins aléatoirement une machine virtuelle dans laquelle il pourra faire ce qu’il souhaite. Ces machines virtuelles sont soumises aux contraintes définies par l’hébergeur en fonction de ses conditions générales de vente. Chaque machine virtuelle est sensée être l’égale d’une autre et le client n’a que très peu d’amplitude pour la construction d’une véritable architecture.

Les nuages publics existant aujourd’hui ont essentiellement vocation à être des plateformes d’hébergement grand public à la manière d’OVH sur le marché des serveurs dédiés. Pour que cette comparaison soit valable, il est nécessaire d’exclure la diversification des offres d’OVH avec notamment la possibilité d’obtenir un firewall Cisco ASA. Il est peu probable qu’il soit possible d’insérer un Cisco ASA dans un grand nuage public.

La présence de l’open source dans les nuages public est très forte, surtout à travers de Xen. Amazon, Gandi, 1&1 et Rackspace sont tous basés sur Xen. Le marché des grand nuages public a peu de chance de voir une réelle présence de VMWare à cause de sa tarification. Je vous laisse imaginer le prix d’un cloud public VMWare…

Le nuage privé

Les nuages privés sont clairement orientés vers les entreprises. Il parait particulièrement improbable de voir une quelconque entreprise confier la totalité de ses données et de l’infrastructure informatique à une nébuleuse telle qu’Amazon.

Il me semble que la notion de nuage privé est quasiment équivalente à la notion de plateforme de virtualisation interne à une société. Dans ce type de nuage, la notion de « cloud computing » semble floue et la distinction avec une plateforme de virtualisation semble mince voire inexistante.

L’open source a un rôle à jouer sur ce type de nuages mais l’état actuel des choses ne le facilite pas. L’automatisation d’une plateforme Xen ou KVM nécessite un travail de développement conséquent même si des outils tels que le Xen Cloud Platform vont dans le bon sens. VMWare est désormais très présent sur le marché avec ses produits d’administration et d’automatisation VSphere et Virtual Center.

Le nuage privé-public

Le nuage privé-public est un nuage privé inséré dans une plateforme public. Ce type d’offre est encore relativement rare car le concept est plutôt récent.

Cette notion semble relativement équivalente à la notion de nuage privé placé dans le cadre d’une offre d’infogérance. Bien que les offres placées sous la dénomination « nuage privé-public » sont rares, les plateformes de virtualisation infogérées sont monnaie courante aujourd’hui.

Au final, je pense avoir fait le tour des différentes configurations de « cloud computing » que l’on peut retrouver aujourd’hui. Je pense également que toutes ces offres ne sont pas réellement révolutionnaires contrairement à ce que bon nombre de commerciaux souhaiteraient nous faire croire.

Les technologies du Cloud Computing

Les vacances sont finies et les affaires reprennent avec plus d’open source et de cloud computing. Lors d’un précédent article, nous avons essayé de trouver une définition à peu près convenable du cloud computing de manière générale. Ceci s’est avéré relativement complexe et hasardeux. J’ai finalement choisi de conserver la définition proposée par Wikipedia en Anglais.

A défaut de réussir à définir conceptuellement le cloud computing, nous allons essayer de le définir technologiquement. Cet exercice devrait être largement plus simple que le précédent car les ressources abondent sur ce plan. Comme vous vous en doutez déjà, il existe de nombreux types d’infrastructures physiques et applicatives placées sous la dénomination de cloud computing. Nous essayerons de faire une sélection des technologies réccurentes.

La virtualisation

Lorsqu’est évoqué la notion de cloud computing, la notion de virtualisation n’est pas bien loin. La montée en popularité du cloud computing coïncide largement avec la monte en popularité des plate-formes de virtualisation. Bien qu’il existe de nombreux types de virtualisation, la virtualisation de systèmes d’exploitation est la plus fréquente, de loin. Nous pouvons affirmer de manière relativement sûre que la base essentielle du cloud computing est la virtualisation de systèmes d’exploitation.

La virtualisation de système d’exploitation n’est cependant pas un phénomène récent. Les premières applications de VMWare datent de 1998. L’amélioration des processeurs x86 n’est certainement pas étranger à ce phénomène avec la multiplication et la densification des coeurs de calcul. La montée du cloud computing est sans aucun doute liée avec la montée en puissance des applications d’automatisation des plate-formes de virtualisation. Cette automatisation permet une flexibilité exceptionnelle et une réactivité dans l’évolution du cloud.

La place de l’open source

Alors que l’on pourrait croire que l’acteur le plus populaire dans ce domaine est VMWare, la réalité ne confirme pas cette intuition. L’open source joue un rôle essentiel dans le domaine du cloud computing à travers l’hyperviseur Xen. Le cloud publique d’Amazon est basé sur le projet Xen tout comme l’offre de serveur virtuel privé de Gandi. Cette adoption massive peut probablement s’expliquer par la nature open source de l’hyperviseur ayant permis le développement des outils d’automatisation mais aussi par la faible perte de performance. Bien que le projet KVM ait été intégré dans le noyau Linux et choisi par différentes distributions, ceci signifie en aucun cas la fin du projet Xen.

Dans le cas du déploiement de grands clouds publiques, l’utilisation des plate-formes de virtualisation propriétaires telles que VMWare ou Hyper-V ne semblent pas viables financièrement. Les licences VMWare sont exceptionnellement coûteuses, de même pour les licences Windows 2008 Server. Un grand cloud public basé sur ces technologies rendrait l’offre particulièrement peu compétitive. De plus, l’hébergeur dépendrait totalement de l’éditeur pour les fonctionnalités qu’il peut implémenter et n’aura que peu de marge pour innover. L’utilisation des outils propriétaires peut être viable financièrement dans le cadre de clouds privés de taille modeste bien que la gratuité de XenServer de Citrix ne facilite pas l’adoption.

La mise en réseau du stockage

Tandis que les deux premières technologies sont visibles par les utilisateurs des clouds, le troisième l’est nettement moins. Traditionnellement, les unités de stockage de masse sont connectées directement sur les serveurs. Concrètement, cela se traduit par la connexion des disques dur directement sur le bus ATA ou SCSI de chaque serveur. Cette forme de stockage a comme avantage d’être particulièrement simple mais a comme désavantage d’être très peu flexible.

La mise en réseau des éléments de stockage à travers le SAN (Storage Area Network) a permis de s’affranchir de nombreuses contraintes. Cette flexibilité exceptionnelle a permis aux clouds de pouvoir s’automatiser rapidement avec notament l’utilisation des techniques de snapshots ou de déduplication. De plus, le réseau de stockage a permis d’augmenter massivement les performances des IO permettant de pouvoir centraliser les données. Cette centralisation a rendu possible les techniques de migration automatique à chaud et de répartition de charge dynamique entre différents hyerviseurs.

Au final, les technologies du cloud computing sont plus simples à cibler que le concept global. J’aurais l’occasion d’évoquer et de traiter les réseaux de stockage en détail ultérieurement. Ces trois technologies sont des technologies « centrales » autour desquelles peuvent en orbiter de nombreuses autres.

Les domaines Xen : les domaines non privilégiés

Aller hop on se motive ! Pour mon avant-dernier jour de stage chez Orange Business Services, je vais faire la suite du précédent article sur les domaines Xen. J’avais eu l’occasion de détailler les spécificités du domaine privilégié, plus communément connu sous le nom de dom0.

Si vous n’êtes pas familier avec le vocabulaire spécifique à Xen, je vous renvois vers l’article traitant de la terminologie Xen. Si vous ne connaissez pas bien le projet Xen, je vous renvois vers la présentation de ce projet.

Domaine non privilégié : domU

Les domaines non privilégiés sont communément appelés « domU » (U comme unprivileged). Les domU sont l’équivalent des systèmes d’exploitation invités sur les plateformes de virtualisation classiques. Concrètement, ce sont les machines virtuelles qui s’exécuteront sur votre plateforme Xen. Ces systèmes d’exploitation s’installent une fois que vous avez un hyperviseur et un dom0 fonctionnel. Il existe de nombreux outils vous permettant d’installer des domU de manière plus ou moins simple et rapide.

Comme vous le savez surement, Xen est capable de faire de la paravirtualisation mais aussi de la virtualisation matérielle assistée. A chacun de ces types de virtualisation correspond un type de domaine non privilégié. Les domU de paravirtualisation sont appelés « domU standards » et les domU de virtualisation matérielle assistée sont appelés « domU HVM ». L’acronyme HVM signifie « Hardware-Assisted Virtual Machine ».

domU de paravirtualisation : domU standard

Nous allons tout d’abord nous intéresser aux domU dits « standards ». Les domU de paravirtualisation sont considérés standards car il s’agit des premiers domU qui ont été disponibles pour Xen et les seuls jusqu’à la version 3.0. Ceci s’explique par le fait que la paravirtualisation est la raison d’être du projet Xen et ce qui en a fait un projet inédit.

Du fait qu’il s’agisse de domU de paravirtualisation, il est nécessaire que l’OS de chaque domU standard ait été adapté pour l’hyperviseur Xen. Ceci se fait par le biais d’API spécifiques supportant les hypercalls. De très nombreux systèmes d’exploitation peuvent être placés en tant que domU par dessus Xen. Tous les Linux sont compatibles ainsi que certains BSD et OpenSolaris.

domU de virtualisation matérielle assistée : domU HVM

Lorsqu’un système d’exploitation n’a pas été adapté pour Xen, il est nécessaire de recourir à une technique de virtualisation plus classique. Il s’agit bien évidemment de la virtualisation matérielle assistée. Ce type de domU permet à Xen de supporter la quasi totalité des systèmes d’exploitation existants pour l’architecture x86.

Le module utilisé par Xen pour effectuer les opérations de virtualisation matérielle assistée est le module QEMU. La contre partie des domU HVM est une perte de performances plus importante que dans le cas d’un domU standard. Ceci s’explique par le fait qu’il est nécessaire d’effectuer beaucoup plus d’opérations d’émulation.

Rôle des domU et délégation de périphériques

Les domU n’ont pas de rôle spécifique au niveau de la plateforme de virtualisation. Ils servent juste à exécuter les diverses applications qui sont contenues dans leurs systèmes d’exploitation. Il ne leur est accordé, par défaut, aucun privilège au niveau des ressources physiques. L’hyperviseur leur attribue une partie des ressources dynamiquement et les domU les utilisent ou pas en fonction de leurs besoins.

De plus, il est tout de même possible d’accorder quelques priviléges spécifiques aux domU. Ces privilèges spécifiques se matérialisent par la délégation de périphériques. Par exemple, il est possible de donner accès exclusif à un port USB ou PCI à un domU. Ceci va lui permettre de pouvoir utiliser un composant physique comme il le souhaite. Il y a eu des exemples de cartes graphiques déléguées à un domU permettant de jouer à un jeu 3D dans le domU. Notons tout de même que la délégation de périphérique à un domU restreint totalement sa mobilité entre plusieurs hyperviseurs ce qui peut être handicapant.

Au final, cette article présente les spécificités des domU. J’espère avoir été clair et compréhensible. Si ce n’est pas le cas, vous avez toujours la possibilité de laisser un commentaire pour me le signaler. En ce qui concerne la suite des événements, je suis encore indécis sur les sujets que je vais traiter. Cela devrait varier en fonction de mon prochain emploi. De toute manière, je souhaiterais parler plus des réseaux de stockage et du stockage en général.