Introduction
La virtualisation n’est pas une idée nouvelle. En fait, elle remonte aux débuts de l’informatique. On peut ainsi citer les travaux de Popek et Goldberg en 1974, qui ont analysé les différents types de solutions de virtualisation possible, leurs inconvénients respectifs et ont jeté les bases des développements futurs.
Pour rappel, la virtualisation consiste à exécuter un système d’exploitation dans une machine virtuelle, ce qui permet d’utiliser plusieurs systèmes sur la même machine, soit pour utiliser un système d’exploitation différent de l’hôte soit pour compartimenter de façon efficace les différents services d’une machine. Historiquement, la virtualisation est devenue à la mode en 2006, quand des logiciels permettant de lancer Windows dans Mac OS X sont apparus. Depuis, la technologie a été intégrée à Windows 7, est très utilisée dans les entreprises et a été intégrée dans le coeur même des ordinateurs : d’abord au niveau du processeur et ensuite, récemment, au niveau des périphériques d’entrées/sorties. Malgré tout, cela reste une technologie assez mystérieuse pour le grand public. Il nous est donc apparu utile de faire un tour d’horizon des solutions de virtualisation disponibles actuellement et de leurs développements futurs.
La virtualisation : définition
Virtualisation, c’est un joli mot certes, mais pas très explicite. Précisons tout d’abord que nous aborderons ici la virtualisation matérielle. Il s’agit de pouvoir faire fonctionner sur une seule machine, plusieurs systèmes d’exploitation. En quoi cela pose-t-il problème ? Parce que le système d’exploitation est le programme en charge de gérer les ressources matérielles de l’ordinateur (CPU, mémoire vive, périphériques, etc.). Les éventuelles applications n’ont aucun lien direct avec le matériel, elles passent toutes par l’intermédiaire de l’OS. De par sa conception, un système d’exploitation s’attend donc à avoir seul la gestion de toutes les ressources matérielles de l’ordinateur et à pouvoir dialoguer directement avec le CPU.
Les logiciels de virtualisation doivent donc tromper les multiples systèmes d’exploitation fonctionnant en parallèle pour leur faire croire qu’ils sont installés seuls sur une machine, alors qu’en fait ils sont plusieurs à se partager les mêmes ressources. Pour ce faire, il faut que le logiciel de virtualisation simule autant de « machines virtuelles » que d’OS. Chaque OS ne voit alors que sa propre machine virtuelle et fonctionne sans souci.
Glossaire
Avant d’aller plus loin, prenons un moment pour définir précisément les termes employés couramment dans le domaine.
VM : acronyme de Virtual Machine, soit Machine Virtuelle. Il s’agit de l’ensemble des ressources matérielles (processeur, mémoire, disque dur, périphériques, etc.) simulées par le logiciel de virtualisation et vues par les systèmes d’exploitation invités. Plus précisément, on parle ici de HVM (Hardware Virtual Machine), machine virtuelle matérielle.
VMM : Virtual Machine Monitor, ou gestionnaire de machine virtuelle. C’est le logiciel de virtualisation à proprement parler. Il en existe de nombreux sur le marché (VMware, Virtual PC, Parallels Workstation etc…). Deux types existent, le premier s’installe comme une application sur un système hôte (Linux, Mac OS X, Windows, etc.) et le second, qu’on appelle couramment un hyperviseur, est un fait un système d’exploitation très simple (Linux ou Windows) contenant le programme de virtualisation. La différence est importante dans le cas des applications critiques : utiliser le second type de VMM permet d’éviter de gaspiller des ressources avec un système hôte.
Quels en sont les usages ?
Les machines virtuelles ont de très nombreuses applications, souvent dans le domaine professionnel où beaucoup d’applications ne nécessitent pas la puissance d’un serveur, mais où la segmentation des services oblige pourtant les administrateurs à en dédier un à chaque tâche.
La première est de pouvoir profiter d’autant de systèmes d’exploitation qu’on le souhaite, beaucoup plus facilement qu’avec un multi-boot. On peut ainsi envisager d’avoir Windows sur un Macintosh, Windows, Mac OS X et Linux sur une même machine, etc. Au-delà du simple gadget, c’est un avantage pour tous les développeurs de logiciels qui doivent tester leur code sous chaque plateforme, sous chaque navigateur internet, etc. Notez que, pour le moment, sans doute par la volonté d’Apple, aucun logiciel de virtualisation ne permet d’installer la version client de Mac OS X sur un PC. L’inverse est par contre tout à fait possible.
Cela permet aussi de faire tourner sur un PC récent des applications anciennes. Par exemple, des logiciels ou jeux développés pour Windows 95 et incompatibles avec Windows 7. Cette situation est très fréquente aussi chez les grandes entreprises, qui ne peuvent pas changer de logiciels à chaque renouvellement de matériel. Microsoft a d’ailleurs pensé à ce problème en intégrant un Windows XP virtuel dans Windows 7.
Un autre avantage de l’utilisation de machines virtuelles est une stabilité et une sécurité accrue : un plantage d’une machine virtuelle ne bloque pas les autres. De même, un virus contaminant une VM ne touchera pas les autres.
Par ailleurs, chaque VM est encapsulée dans un fichier. Il est donc très facile de réaliser une sauvegarde de son système à un instant donné. En cas de contamination virale, de plantage à répétition suite à l’installation d’un logiciel hasardeux, il suffit de supprimer le fichier de la VM en cours et de le remplacer par la sauvegarde réalisée un jour plus tôt.
Ce fichier est aussi très facilement transférable d’un ordinateur à un autre. Une aubaine pour les administrateurs systèmes et tous ceux qui changent de PC régulièrement. Il est même possible de convertir une VM créée avec un logiciel de virtualisation pour l’utiliser sur un autre. Certains logiciels permettent de transférer des machines virtuelles « à chaud » : un programme gérant le paiement des salaires est par exemple placé sur un serveur de faible puissance en temps normal et déplacé, sans coupures de service, sur une machine plus puissante au moment où les salaires doivent être envoyés.
Enfin, et surtout, la virtualisation permet aux entreprises d’optimiser l’utilisation de leurs ressources matérielles. Grâce à la virtualisation, il est possible de faire fonctionner plusieurs machines virtuelles sur un seul ordinateur, les ressources matérielles sont donc utilisées au mieux en fonction de la charge.
Emulation, virtualisation, etc…
Pour créer des machines virtuelles, différentes solutions existent :
- l’émulation
- la virtualisation par traduction binaire
Les deux techniques reposent sur le même concept de base : intercepter à la volée les requêtes des systèmes d’exploitation vers la machine virtuelle et les traduire pour qu’elles puissent être exécutées par la machine réelle.
Cette description succincte est suffisante pour mettre en évidence le principal problème lié à la virtualisation : la perte de performances. En effet, une instruction est remplacée par des dizaines d’autres, et le temps de calcul résultant est bien plus long.
L’émulateur est un cas spécifique : il consiste à utiliser un système d’exploitation (ou un programme) sur un système qui n’utilise pas la même architecture. Par exemple, l’émulation consiste par exemple à lancer un jeu Mégadrive (machine basée sur un processeur 68000) sur un PC classique (en x86). Les émulateurs sont généralement lents, car toutes les instructions doivent être adaptées et — outre le décodage — certaines architectures sont plus efficaces que d’autres. Globalement, la différence de puissance entre les deux machines (hôte et client) doit être importante () la faveur de l’hôte) pour une émulation efficace. Les émulateurs sont soit externes (des programmes) soit intégrés au système : les Mac récents disposent d’un émulateur de code PowerPC (performant pour la bonne et simple raison qu’une partie du code ne change pas, les appels aux fonctions du système restant identiques).
La virtualisation est un peu différente : elle se base sur des systèmes hôtes et clients basés sur la même architecture (x86, par exemple). Concrètement, les instructions sont exécutées nativement par le processeur de l’hôte, le logiciel de virtualisation se « contentant » de modifier les instructions qui pourraient affecter l’hôte (par exemple en écrivant directement dans la mémoire d’un périphérique). Les performances sont souvent proches d’une implémentation native sur des calculs classiques, une perte se faisant par contre sentir dès qu’il y a des appels au matériel (comme une carte graphique), les logiciels de virtualisation n’ayant pas réellement la possibilité d’y accéder directement.
Dans la pratique, et en laissant tomber des cas particuliers comme Rosetta sous Mac OS X, on voit bien que la virtualisation est bien plus efficace. Dans un système émulé, toutes les instructions doivent être analysées, transformées et ensuite exécutées, et le sous-système entier (accès à la mémoire, aux périphériques, etc.) aussi, alors qu’un système virtualisé se contente d’émuler une partie des périphériques et de modifier certaines instructions ainsi que l’accès à la mémoire, mais la majorité des instructions sont exécutées en l’état.
Notons enfin qu’il existe quelques solutions intermédiaires, mais elles sont rares et spécifiques : certains processeurs (Godson 3, par exemple) intègrent des fonctions qui permettent d’accélérer l’émulation du code x86, d’autres intègrent directement des composants matériels pour une émulation très efficace (cas de beaucoup de consoles), etc.
Les défis de la virtualisation
Un processeur n’est capable d’exécuter qu’un nombre réduit d’instructions élémentaires. Cet ensemble, appelé ISA (Instruction Set Architecture), est codé dans le processeur et n’est pas modifiable. Il définit les capacités d’un processeur, dont l’architecture matérielle est ensuite optimisée pour exécuter les instructions de l’ISA le plus efficacement possible. Plusieurs ISA existent. Le plus connu dans le monde PC est le x86, utilisé depuis l’origine par les processeurs Intel et repris par les puces d’AMD. On peut aussi citer le PowerPC, l’ARM, le MIPS, etc.
Très répandu, voire même omniprésent, le x86 n’est pour autant pas exempt de défauts. Mais comme il est hors de question de le remplacer, il fallait trouver des solutions de contournement. C’est ce qu’ont développé Intel et AMD avec respectivement VT-x et AMD-V.
Si le x86 se prête mal à la virtualisation c’est à cause de 17 instructions critiques, mais non privilégiées. Si vous n’avez rien compris à la phrase précédente lisez ce qui suit :
Toutes les instructions de l’ISA x86 ne sont pas sur un pied d’égalité. Parmi elles, certaines peuvent modifier la configuration des ressources du processeur ; elles sont dites critiques. Pour protéger la stabilité de la machine, ces instructions ne peuvent pas être exécutées par tous les logiciels. Du point de vue du CPU, les logiciels appartiennent à 4 catégories, ou niveaux d’abstraction : les anneaux 0, 1, 2, 3. Chaque anneau définit un niveau de privilège décroissant. Les instructions les plus critiques réclament les privilèges les plus élevés, d’ordre 0. Malheureusement, sur un processeur x86, 17 de ces instructions critiques peuvent être exécutées même par des logiciels de rang 1, 2, ou 3.
Cela constitue un gros problème pour les logiciels de virtualisation. Un système d’exploitation est en effet prévu pour fonctionner en anneau 0 et utiliser des instructions critiques afin de répartir les ressources du processeur entre les différentes applications. Mais lorsqu’il est en situation d’invité, sur une machine virtuelle, le même OS ne doit pas pouvoir modifier les ressources matérielles, sous peine de faire planter tout le système. Seul l’hyperviseur doit avoir ces droits. Il faut donc que toutes les instructions critiques soient interceptées.
C’est très facile pour toutes les instructions privilégiées. L’OS est alors exécuté en ring 3, comme les applications, et toutes les requêtes d’instructions privilégiées déclenchent une erreur qui est traitée par le VMM. C’est beaucoup plus compliqué pour les 17 instructions dangereuses et non privilégiées. Celles-ci ne déclenchant pas d’erreur automatique, elles doivent être détectées au coup par coup par le VMM, puis réinterprétées. Il en résulte une surcharge en calcul importante, et une grande complexité du logiciel hyperviseur.
Les autres coupables
Au-delà des défauts du x86, la virtualisation du matériel pose d’autres soucis. Par exemple, l’OS invité suppose qu’il a accès à la totalité de la mémoire de la machine. Or ce n’est pas le cas puisqu’il la partage avec les autres OS et le VMM. Ce dernier doit donc surveiller et intercepter les tentatives d’accès de l’OS invité à des adresses mémoires non disponibles, et les détourner. Autre exemple, le fait que l’OS invité fonctionne au même niveau (anneau 3) que les applications invitées met en danger sa stabilité. Enfin, l’OS invité ne doit jamais découvrir qu’il tourne en réalité en anneau 3, sous peine de plantage. Le VMM doit donc là encore intercepter les instructions susceptibles de révéler l’état des privilèges de l’invité.
Dernier souci, la gestion des périphériques : générant des accès en mémoire et des interruptions, les périphériques doivent être gérés par le VMM qui doit ensuite les émuler pour chaque OS invité. Une source supplémentaire de ralentissement, et surtout une perte énorme en termes de fonctionnalités.
Les solutions
Afin de simplifier tout cela, Intel a conçu VT-x et AMD a proposé AMD-V. Ces deux technologies sont très similaire, au point que nous n’allons pas les différencier dans la description suivante. Intel VT-x et AMD-V se composent toutes deux de trois volets, chacun visant à résoudre de façon les difficultés à la virtualisation du CPU, à la virtualisation de la mémoire, et à la virtualisation des périphériques.
La virtualisation du CPU : Intel VT-x et AMD-V
Afin de faciliter la virtualisation du CPU, Intel et AMD ont cherché à supprimer la nécessité de surveillance et de traduction des instructions. Pour ce faire, de nouvelles instructions ont été ajoutées. Une nouvelle structure de contrôle fait aussi son apparition, baptisée VMCS (Virtual Machine Control Structure) chez Intel.
Parmi les nouvelles instructions, l’une d’elles (VM entry chez Intel) permet de basculer le processeur dans un nouveau mode d’exécution, dédié aux systèmes invités. Ce mode possède aussi quatre niveaux de privilèges différents. Ainsi sont supprimés les problèmes liés à l’exécution de l’OS invité en anneau 3 : l’OS invité peut s’exécuter en anneau 3 du mode VM. Quand le contexte l’exige, le processeur bascule du mode invité au mode normal. Cette bascule est décidée par des conditions fixées par le VMM à l’aide des bits de contrôle stockées dans la VMCS.
Au moment de basculer, l’état du processeur dans le mode invité est stocké dans la VMCS et l’état du processeur en mode hôte est rechargé à partir de la VMCS. Les instructions nécessaires sont alors exécutées, puis le VMM fait ressortir le processeur du mode hôte pour repasser en mode invité, en stockant l’état du processeur hôte dans la VMCS et en rechargeant l’état invité précédemment stocké. Il n’y a donc plus aucune traduction d’instructions, les instructions critiques provoquant le passage du mode invité au mode hôte. Passage automatique grâce aux règles fixées dans la VMCS.
Avec ces technologies, Intel et AMD ont considérablement accélérés les programmes de virtualusations et le traitement de ce type d’instructions, lent au départ, s’améliore de plus en plus avec la sortie des nouveaux processeurs (comme on le voit dans le tableau). Par ailleurs, la mise en place des instructions en question a permis la dispartition d’un type de virtualisation, la « paravirtualisation ». Cette technologie consistait à modifier le système d’exploitation client pour qu’il n’utilise plus les instructions posant problèmes (en simplifiant), ce qui permettait de gagner en performances, au détriment de l’universalité (un OS en open source étant nécessaire). L’intégration d’AMD-V et de VT-x a signé l’arrêt de mort de cette technologie.
Dans la pratique, et même si les gains ne sont pas toujours aussi important qu’attendus, VT-x et AMD-V sont maintenant des prérequis pour installer des programmes de virtualisation (comme avec Windows 7) et les (rares) processeurs ne disposant pas encore de ces technologies sont peu à peu mis à l’écart de la virtualisation.
Virtualisation mémoire et E/S
La virtualisation mémoire
Lorsqu’il est seul installé sur une machine, un OS s’occupe de l’adressage de la totalité de la mémoire vive. En d’autres termes, il décide d’en allouer une certaine quantité à chaque application, quantité qui sera comprise entre le bit d’adresse x et celui d’adresse y. Cet adressage est réalisé sur une mémoire virtuelle, dite linéaire, qui représente la totalité de la mémoire vive disponible, qu’elle soit répartie sur une ou deux barrettes, ou sur le disque dur. La correspondance entre cette mémoire linéaire et la mémoire physique est réalisée par une unité du CPU, la MMU (Memory Management Unit). La MMU maintient à jour le tableau de correspondance entre les adresses physiques et les adresses linéaires demandées par l’OS, ce qui est appelé la page de table (page table ou PT en anglais).
Sur un ordinateur où tournent plusieurs systèmes d’exploitation, chacun ne peut utiliser qu’une portion de la mémoire vive totale. Le partage est décidé par le VMM lors de la création de chaque VM. Par exemple, l’OS 1 doit utiliser les bits zéro à x, et l’OS 2 les bits x+1 à y. Malheureusement, un OS débute toujours son adressage à zéro. Pour éviter les conflits entre différents OS fonctionnant simultanément, il faut donc que l’hyperviseur bloque tous les accès des OS vers la MMU et les réinterprète. Le VMM construit alors, pour chaque OS, une fausse page de table faisant correspondre les adresses linéaires réclamées par l’OS à celles qui lui sont réservées. Ce tableau de correspondance intermédiaire est appelé Shadow Page Table (SPT). Au final, un simple accès mémoire devient une opération complexe, la machine virtuelle devant s’occuper de la gestion de la mémoire du système client, ce qui — en cas d’accès fréquents à la mémoire — ralentit fortement le système hôte dans ses propres accès.
Pour réduire le travail du VMM, Intel et AMD ont inventé les Extended Page Tables (EPT) et Rapid Virtualization Indexing (RVI) respectivement. Il s’agit dans les deux cas d’implanter les SPT en hardware. En plus de la PT de la MMU, il y a donc une EPT ou RVI par OS invité. Ces tableaux permettent en fait de dédier une partie des adresses physiques de la mémoire à chaque OS. Ceux-ci peuvent alors accéder librement à leur propre domaine d’adresses réservé, sans provoquer l’intervention du VMM. L’ensemble des adresses mémoires physiques des OS invités est ensuite recompilé dans l’EPT et la gestion de la mémoire du système client est entièrement prise en charge par le matériel, ce qui est évidemment plus rapide qu’une implémentation logicielle.
Les deux technologies sont intégrées dans les processeurs haut de gamme chez les deux constructeurs : les Opteron Barcelona (et plus) chez AMD et les processeurs basés sur Nehalem (Core i7, par exemple) chez Intel.
La virtualisation des périphériques
Dernier point à prendre en charge, la virtualisation des E/S (entrées/sorties). En effet, même si l’accès au processeur est transparent avec VT-x et AMD-V, l’accès aux périphériques reste du ressort du programme de virtualisation : chaque logiciel doit créer ses propres périphériques virtuels, des pilotes adaptées à ces derniers doivent être dévellopés et les performances sont évidemment loin d’être mirobolantes (le problème se pose essentiellement pour les cartes graphiques). De plus, les logiciels de virtualisation doivent reproduire la gestion de la mémoire des périphériques et ce n’est pas toujours suffisant : si un programme de la machine virtuelle essaye d’accéder directement au matériel, il risque tout simplement de ne pas fonctionner. Pour régler le problème, les constructeurs ont donc proposé une nouvelle technologie, connue sous le nom d’IOMMU.
VT-d et AMD-Vi, les deux technologies d’Intel et AMD, permettent donc de créer un accès virtuel aux périphériques d’E/S. Le fonctionnement est un peu différent des instructions de virtualisations : au lieu de partager un périphérique entre deux systèmes (hôte et client), la technologie permet en fait de donner un accès direct à un périphérique depuis une machine virtuelle. Il n’y a pas ici de notion de partage en tant que tel, mais bien un accès direct et exclusif : si la machine virtuelle accède à un périphérique comme une carte graphique, la machine hôte perd son accès, ce qui suppose (dans le meilleur des mondes) qu’une carte graphique dédiée à la machine virtuelle soit installée. Il est possible de partager la majorité des périphériques, des ports USB aux connecteurs PCI-Express (et donc les cartes installées), tout en gardant bien à l’esprit que l’accès est exclusif.
Contrairement à VT-x et AMD-V, qui dépendent du processeur, ces deux technologies dépendent du chipset (ou du processeur, dans le cas des modèles Intel intégrant le contrôleur PCI-Express). Actuellement, VT-d et AMD-Vi sont peu utilisés et les logiciels capables de tirer parti des technologies sont rares. De plus, certains périphériques demandent des pilotes spécifiques pour être utilisés avec VT-d ou AMD-Vi.
Dans les faits, la virtualisation des périphériques est essentiellement utilisée pour deux usages : offrir des capacités vidéo correctes à une machine virtuelle (en dédiant une carte graphique) ou — plus courant — permettre à une machine virtuelle présente sur un serveur de disposer de sa propre carte réseau. Des cartes mères dédiées à ce type d’installation (et disposant donc de plusieurs cartes réseau) existent d’ailleurs.
Pour ce qui est de la compatibilité, les chipsets de la famille Q d’Intel ainsi que les puces dédiées aux Nehalem sont généralement compatibles alors qu’AMD ne propose AMD-Vi que sur les chipsets de la famille 8xx (pas encore disponibles).
Le matériel compatible
Chez AMD, les processeurs sont compatibles depuis les Athlon 64 en socket AM2, les versions précédentes ne le sont pas (Socket 939, etc.). Pour les Turion (mobile), les versions en Socket 754 ne sont pas compatibles. Les Sempron n’ont généralement pas la technologie AMD-V, sauf quelques modèles. Enfin, certains Opteron ont la technologie AMD-V mais aussi la technologie RVI (pour les accès mémoire). Voici la liste complète.
| AMD | ||
| Athlon 64 (AM2) | Depuis la révision F (Orleans, 90 nm) | 3000+, 3200+, 3500+, 3800+, 4000+, LE-1600, LE-1620, LE-1640, 2650e, LE-1640B, LE-1660, 2000+ (65 nm), 2600+ (65 nm) et 3100+ (65 nm) |
| Athlon 64 X2 (AM2) | Depuis la révision F (Windsor, 90 nm) | 3800+, 4000+, 4200+, 4400+, 4600+, 4800+, 5000+, 5200+, 5400+, 5600+, 6000+, 6400+, 3600+ EE, 3800+ EE, 4000+ EE, 4200+ EE, 4400+ EE, 4600+ EE, 4800+ EE, 5000+ EE, 5200+ EE, 3600+ EE SFF, 3600+ (65 nm), 4000+ (65 nm), 4200+ (65 nm), 4400+ (65 nm), 4600+ (65 nm), 4800+ (65 nm), 5000+ (65 nm), 5200+ (65 nm), 5400+ (65 nm), 5600+ (65 nm), 5800+ (65 nm) et 6000+ (65 nm) |
| Athlon 64 FX (AM2) | Depuis la révision F (Windsor, 90 nm) | FX-62 |
| Athlon 64 FX (Socket F) | Depuis la révision F (Windsor, 90 nm) | FX-70, FX-72 et FX-74 |
| Athlon Neo | Tous | MV-40 et TF-20 |
| Athlon X2 (K8) AM2 | Tous | BE-2300, BE-2350, BE-2400, 3250e, 4050e, 4450e, 4850e, 5050e, 4450B, 4850B, 5050B, 5200B, 5400B et 5600B |
| Athlon X2 (K10) AM2+ | Tous | 6500, 7450, 7550, 7750 et 7850 |
| Athlon II X2 (AM3) | Tous | 250u, 260u, 215, 235e, 240, 240e, 245, 250, 255, B22 et B24 |
| Athlon II X3 (AM3) | Tous | 400e, 405e, 425, 435 et 440 |
| Athlon II X4 (AM3) | Tous | 600e, 605e, 620, 630 et 635 |
| Phenom X3 (AM2+) | Tous | 8250e, 8400, 8450, 8450e, 8550, 8600, 8650, 8750, 8850, 8600B et 8750B |
| Phenom X4 (AM2+) | Tous | 9100e, 9150e, 9350e, 9450e, 9500, 9550, 9600, 9650, 9750, 9850, 9950, 9600B et 9750B |
| Phenom II X2 (AM3) | Tous | 545, 550, 555, B53 et B55 |
| Phenom II X3 (AM3) | Tous | 700e, 705e, 710, 720, B73 et B75 |
| Phenom II X4 (AM3) | Tous | 805, 810, 820, 900E, 905e, 910, 910e, 920, 925, 940, 945, 955, 965, B93 et B95 |
| Turion 64 (S1) | Tous | MK-36 et MK-38 |
| Turion 64 X2 (S1) | Tous | TL-50, TL-52, TL-56, TL-60, TL-64, TK-42, TK-53, TK-55, TK-57, TL-56 (65 nm), TL-58, TL-60 (65 nm), TL-62, TL-64, TL-66 et TL-68 |
| Turion X2 Ultra (S1G2) | Tous | ZM-80, ZM-82, ZM-84, ZM-85, ZM-86, ZM-87, ZM-88, RM-70, RM-72, RM-74, RM-75, RM-76, RM-77 et Neo L625 |
| Athlon X2 Mobile (S1G2) | Tous | QL-60, QL-62, QL-64, Ql-65, QL-66, QL-67, Neo L325, Neo L335 et Neo L510 |
| Turion II (S1G3) | Tous | M500, M520, M540, M600, M620, M640 et M660 |
| Athlon II Mobile (S1G3) | Tous | M300, M320 et M340 |
| Sempron (AM3) | Tous | 140 |
| Mobile Sempron (S1) | Tous | SL-40, SL-42, 200U et 210U |
| Mobile Sempron (S1G3) | Tous | M100 et M120 |
| Opteron (AM2) | Depuis la révision F (Santa Ana, 90 nm) | 1210, 1212, 1214, 1216, 1218, 1220, 1222, 1220 SE, 1222 SE, 1224 SE, 1210 HE, 1212 HE, 1214 HE, 1216 HE et 1218 HE |
| Opteron (Socket F) | Depuis la révision F (Santa Rosa, 90 nm) | 2210, 2212, 2214, 2216, 2218, 2220, 2222, 2220 SE, 2222 SE, 2224 SE, 2210 HE, 2212 HE, 2214 HE, 2216 HE, 2218 HE, 8212, 8214, 8216, 8218, 8220, 8222, 8220 SE, 8222 SE, 8224 SE, 8212 HE, 8214 HE, 8216 HE et 8218 HE |
| Opteron (AM2+) | Tous (avec RVI) | 1352, 1354 et 1356 |
| Opteron (AM3) | Tous (avec RVI) | 1381, 1385 et 1389 |
| Opteron (Socket F) | Tous (avec RVI) | 2347, 2350, 2352, 2354, 2356, 2358 SE, 2360 SE, 2344 HE, 2346 HE, 2347 HE, 2350 HE, 2376, 2378, 2380, 2382, 2384, 2386 SE, 2387, 2389, 2393 SE, 2372 HE, 2374 HE, 2376 HE, 2379 HE, 2381 HE, 2373 EE, 2377 EE, 8347, 8350, 8350, 8354, 8356, 8358 SE, 8360 SE, 8346 HE, 8347 HE, 8350 HE, 8378, 8380, 8382, 8384, 8386 SE, 8387, 8389, 8393 SE, 8374 HE, 8376 HE, 8379 HE, 8381 HE, 2427, 2431, 2435, 2439 SE, 2423 HE, 2425 HE, 2419 EE, 8431, 8435, 8439 SE et 8425 HE |
Chez Intel, c’est compliqué. La liste est longue, et certaines gammes ont des modèles compatibles, alors que d’autres, non. Dans les Atom, les séries N, D et x30 ne sont pas compatibles, alors que certains Z5xx le sont. Dans les Celeron, c’est assez inégal : les modèles « D » (basés sur le Pentium 4) ne sont pas compatibles et la majorité des Celeron ne le sont pas, sauf les Celeron E « Penryn ». Aucun Celeron M n’est compatible et les Celeron Mobile oublient aussi VT-x, sauf le SU2300. Dans les Core Duo et Core Solo, la compatibilité dépend du modèle. Dans les Core 2 Duo, les séries 4xxx ne sont pas compatibles, les séries 6xxx le sont, certains 7xxx le sont et la majorité des 8xxx sont compatibles. Dans les versions mobiles, ça dépend du processeur, tout comme dans les Core 2 Quad. Les Core 2 Quad Mobile et les Core 2 Solo sont tous compatibles. Les Core i3 supportent VT-x mais pas VT-d alors que tous les Core i5 ont VT-x et certains ont VT-d. Les Core i7 dotés d’un contrôleur PCI-Express ont VT-d, les modèles classiques ne l’ont pas. Les versions Mobile sont parfois compatibles, en fonction du processeur. Dans les anciennes puces, seuls quelques rares Pentium 4 supportent la technologie, ainsi que quelques Pentium et Pentium Mobile. Enfin, tous les Xeon sont au moins VT-x sauf un.
| Intel | ||
| Atom | Z5xx (certains), VT-x | Z550, Z540, Z530P, Z530, Z520PT et Z520 |
| Celeron (LGA775) | Uniquement les modèles en 45 nm, VT-x | E3200, E3300 et E3400 |
| Celeron Mobile | Uniquement un modèle en 45 nm, VT-x | SU2300 |
| Core Duo | Certains modèles, VT-x | L2300, L2400, L2500, T2300, T2400, T2500, T2600, T2700, U2400 et U2500 |
| Core Solo | Certains modèles, VT-x | U1300, U1400 et U1500 |
| Core 2 Duo (LGA775) | Certains modèles, VT-x | E6300, E6320, E6400, E6420, E6650, E6600, E6700n E6750, E6850, E7400 (rev. SLGW3), E7500 (rev. SLGTE), E7600, E8200, E8300, E8400, E8500, E8600 et X8600 |
| Core 2 Duo Mobile | Certains modèles, VT-x | L7200, L7300, L7400, L7500, L7700, P7370, P7570, P8400, P8600, P8700, P8800, P9500, P9600, P9700, SL9300, SL9380, SL9400, SL9600, SP9300, SP9400, SP9600, SU9300, SU9400, SU9600, T5500, T5600, T6670, T7100, T7200, T7250, T7300, T7400, T7500, T7600, T7700, T7800, T8100, T8300, T9300, T9400, T9500, T9600n T9800, T9900, U7500, U7600, U7700, X9000, X9100, X7800 et X7900 |
| Core 2 Quad (LGA775) | Certains modèles, VT-x | Q6600, Q6700, Q8300 (rev. SLGUR), Q8400, Q8400S, Q9300, Q9400, Q9400S, Q9450, Q9505, Q9505S, Q9550, Q9550S, Q9650, QX6700, QX6800, QX6850, QX9650, QX9770 et QX9775 |
| Core 2 Quad Mobile | Tous, VT-x | QX9300, Q9000 et Q9100 |
| Core 2 Solo Mobile | Tous, VT-x | SU3300, SU3500, U2100 et U2200 |
| Core i3 | Tous, VT-x | 530, 540, 330M et 350M |
| Core i5 | Certains modèles, VT-x | 661, 750, 750S et 430M |
| Core i5 | Certains modèles, VT-x et VT-d | 650, 660, 670, 520E, 520M, 520UM et 540M |
| Core i7 (LGA1156) | Tous, VT-x et VT-d | 860, 860S, 870 |
| Core i7 (LGA1366) | Tous, VT-x | 920, 940, 950, 960, 965, 975 |
| Core i7 Mobile | Certains, VT-x | 820QM, 720QM et 920XM |
| Core i7 Mobile | Certains, VT-x et VT-d | 610E, 620LE, 620LM, 620M, 620UE, 620UM, 640LM et 640UM |
| Pentium 4 (LGA775) | Certains, VT-x | 662 et 672 |
| Pentium D (LGA775) | Certains, VT-x | 920, 930, 940, 950, 960, 955 et 965 |
| Pentium (LGA775) | Certains, VT-x | E5300 (rev. SLGTL), E5400 (rev. SLGTK), E6300, E6500 et E6600 |
| Pentium (LGA1156) | Tous, VT-x | G6950 |
| Pentium Mobile | Certains, VT-x | T2060, T2080, T2130 |
| Xeon | Certains, VT-x | 3040, 3050, 3060, 3065, 3070, 5030, 5050, 5060, 5063, 5080, 5110, 5113, 5120, 5128, 5130, 5133, 5138, 5140, 5148, 5150, 5160, 7020, 7030, 7040, 7041, 7110M, 7110N, 7120M, 7120N, 7130M, 7130N, 7140M, 7140N, 7150N, E3110, E3120, L3110, E5205, E5220, E5240, L5215, L5238, L5240, L5248, X5260, X5270, X5272, E5310, E5320, E5335, E5345, L5310, L5318, L5320, L5335, X5355, X5365, E5405, E5410, E5420, E5430, E5440, E5450, E5462, E5472, L5408, L5410, L5420, L5430, X5450, X5460, X5470, X5472, X5482, X5492, E5502, E5504, E5506, E5520, E5530, E5540, L5506, L5508, L5518, L5520, L5530, W5580, W5590, X5550, X5560, X5570, E7210, E7220, E7310, E7320, E7330, E7340, L7345, X7350, E7420, E7430, E7440, E7450, L7445, L7455, X7460, L3360, X3320, X3330, X3350, X3360, X3370, X3380, W3505, W3520, W3540, W3550, W3565, W3570, W3580, X3210, X3220 et X3230 |
| Xeon | Certains, VT-x et VT-d | L3426, X3430, X3440, X3450, X3460 et X3470 |
Enfin, certains chipsets (quand le northbridge n’est pas intégré au CPU) supportent VT-d : Q35, X38, X48, B43, Q43, Q45 et X58 (ainsi que les versions serveux 5500 et 5520).
Au final, comme on le voit, il est nécessaire de bien choisir son processeur et sa carte mère si on veut profiter des possibilités matérielles de la virtualisation.
Conclusion
Voilà qui conclu notre rapide tour d’horizon de la virtualisation. Si vous désirez approfondir le sujet, de nombreuses ressources sont disponibles sur Internet et notamment sur le site d’Intel. Si, par contre, vous n’êtes toujours pas convaincus de l’utilité de ce principe, sachez néanmoins qu’il va constituer un des axes de développement majeurs des prochains CPU Intel, et AMD pour les années à venir. Sous cette poussée, et grâce à la multiplication du nombre des coeurs au sein des processeurs, on peut même imaginer que la virtualisation devienne une des tendances principales de l’informatique personnelle dans le futur proche. Sécurité, stabilité, polyvalence, interopérabilité, les avantages que tout un chacun pourrait en retirer sont nombreux. Mais uniquement quand les performances offertes par les optimisations matérielles implantées par les fondeurs seront vraiment efficaces, suffisamment pour rendre l’utilisation des machines virtuelles aussi confortables que celles de machines réelles. Un combat pas gagné d’avance, dont vous pourrez suivre la chronique dans nos colonnes…
