- dernière modification : mai 2011 -

Le moniteur d'exploitation IBM
de machines virtuelles

l'hyperviseur VM/CMS

Dans le cadre du propos, sans désir de promotion des produits que je ne connais pas et qui sont faits pour l'entreprise, seulement pour information complémentaire, vous pouvez consulter les sites VMware et Sun: ils traitent de la virtualisation.

--ooOoo--

          Le système d'exploitation VM/CMS développé par la Société IBM aura été, de mon point de vue, le système le plus avant-gardiste que j'ai pu connaître. Ce système d'exploitation avait été écrit par IBM pour ses propres équipes de développement à San Jose si j'ai bonne mémoire et mis en clientèle aux alentours des années 1972 date à laquelle j'en appris l'existence. Mais il me semble que les études étaient bien antérieures.

          Membre de l'équipe-système du Bureau d'étude de la Division Hélicoptères de la SNIAS, aujourd'hui EADS, je fus l'un des plus ardents partisans de son installation après un formidable stage d'un mois effectué chez IBM sur les "internes" de cet hyperviseur. Toute l'équipe était convaincue qu'il répondait parfaitement aux besoins scientifiques du BE grâce à ses machines CMS.

          Par ailleurs, pour la maintenance et la mise au point d'applications sensibles, nous nous privions pas de la possibilité d'avoir en permanence une machine virtuelle avec un VM généré. J'ai toujours trouvé qu'un VM sous VM était une belle performance.

          Ce système est resté opérationnel jusqu'en 2000 où il devait disparaître au profit de puissantes stations de travail Unix. Comble d'ironie, devinez qui a été chargé d'assister les utilisateurs pour la conversion des programmes de VM en Unix ?... je vous le donne en mille !... Après m'être battu avec mon équipe pour l'installer, seul rescapé, je me retrouvais à "bosser" pour sa disparition, alors qu'il n'y avait pas d'équivalent.... Les contraintes de la dite rentabilité... Bref, bien que vieux de plus de 40 années aujourd'hui - car je crois qu'il y a encore des configurations opérationnelles -, ce système d'exploitation garde toute sa modernité. C'est pourquoi je lui consacre ces quelques pages en espérant votre indulgence car je le fais de mémoire, sans brochure et j'ai oublié, en plus de dix ans, certains détails. Je m'attacherai donc plutôt à l'esprit dans l'exposé.

          C'est ce type de système que j'aimerais bien voir tourner sur PCs qui rivalisent largement en performance avec ces grosses machines de l'époque pour pouvoir passer par exemple d'un système Windows/Vista à un ou plusieurs systèmes Unix/Linux dans plusieurs fenêtres affichées ensemble.

          Quel intérêt à cela me direz-vous ? trois exemples pour illustrer le propos :

  1. En installant Linux/Ubuntu j'espérais pouvoir m'affranchir de Windows/Vista. J'ai finalement renoncé et décidé de conserver Windows/Vista car certains logiciels sous Windows que j'espérais remplacer n'ont finalement pas, de mon point de vue et à mon niveau, d'équivalents à la hauteur sous Linux (montage vidéo, gestion de site web en particulier). Comme je partage les disques entre les deux systèmes, je suis souvent appelé de passer de l'un à l'autre et, pour ce faire, il me faut rebooter la machine à chaque fois alors qu'un changement de fenêtre suffirait avec une gestion de machines virtuelles.
     

  2. Il serait plus aisé, me semble-t-il, de mettre au point des application multiplateformes.
     

  3. il serait aussi aisé d'avoir une machine virtuelle qui hébergerait un ancien système, MSDOS donc Windows 3.1 (qu'on lançait à la main) ou un autre, pour l'utilisation de programmes qui n'ont jamais été reconduits. Je constate que la spécialité des développeurs modernes est bien d'ignorer complètement la notion de compatibilité ascendante pour obliger à racheter les mêmes programmes avec des améliorations certes mais en en retirant certaines autres qui fonctionnaient sur la version précédente. Pourquoi faut-il revalider par exemple sur une version Ubuntu 8.10 des programmes qui tournaient sur des versions plus anciennes. Normalement, ils devraient pouvoir être ipso facto installables.
              J'ai toujours le souvenir d'avoir eu une machine VM tournant pendant plus d'une quinzaine d'années avec un système DOS (sans disque), le premier système des machines 360 d'IBM car une application de gestion donnait toujours satisfaction. De plus, elle ne pouvait pas être modifiée car les sources n'avaient pu être retrouvés.
              Pour ma part, j'aurais bien aimé pouvoir retrouver le logiciel AutoCad qui tournait sur mon ancien MSDOS et dont les fonctionnalités me conviendraient suffisamment aujourd'hui, même avec la présence de "microCADAM" qui ne le remplace pas complètement. C'est vrai, j'ai installé l'application "ProgeCAD 2009 Smart", une application gratuite du dernier "AutoCad" d'AutoDesk. Je regrette seulement que ce soit une "usine à gaz" et ma préférence se porte toujours sur mon antique "microCadam".

          Le lecteur sera peut-être surpris de cette position. Je ne suis pas un changeur de version assidu tant que je ne suis pas convaincu qu'elle apporte vraiment du progrès. Il faut avoir le temps de "rentabiliser" la version en cours. Pour Ubuntu par exemple, changer de version tous les 6 mois me paraît excessif, alors que tous les 12 ou 18 mois serait plus judicieux, à mon sens bien sûr. Je n'aime pas particulièrement courir systématiquement après le nouveau ou le soi-disant progrès. Par contre, j'essaie plutôt de courir, si je le peux et si j'en suis capable, après ce que je pourrais faire de nouveau si c'est indispensable. Il me semble que ce n'est pas pareil. Je ne sais combien de fois je me suis aperçu de faire des choses inutiles, souvent après coup, en pensant subitement à une idée qui ne m'était pas venue tout de suite. Par exemple en utilisant une autre application d'une certaine manière ou en la modifiant en peu, le tour était joué. A chaque fois, sans aucun état d'âme, c'était la poubelle, le "delete" irréversible  !....

          Bien sûr, j'ai connaissance de l'existence d'applications de virtualisation. Seulement, ce ne sont que des applications qui fonctionnent sous un système qui, lui, n'est pas virtualisé. Par exemple, MicroSoft propose, sous Windows 7 (!!!), son "Windows Virtual PC" à l'adresse " http://www.microsoft.com/windows/virtual-pc/ " :

          Si son "Windows Virtual PC" assurait vraiment l'émulation d'un hardware PC, il n'aurait nul besoin de proposer un mode XP puisqu'il aurait pu alors gérer un PC virtuel avec un Windows XP. Le titre me paraît néanmoins trompeur et mensonger car "Windows Virtual Windows" me semble mieux refléter la réalité.

          Il en est de même pour VMware qui tourne sous Linux alors qu'il aurait été préférable qu'il tourne en natif.

          Nous sommes à des lieues du très vieil hyperviseur de VM qui virtualise des véritables machines réelles IBM série 360/370/380. Il est vrai aussi que, dans des discussions de salon, le terme de "Virtual PC" est beaucoup plus bluffant qu'"émulateur PC", la vraie terminologie !...

Principes de fonctionnement :

          Un calculateur, c'est avant tout une unité de contrôle CPU (dite aussi une unité centrale) capable d'effectuer des opérations, c'est le cerveau. Mais ce n'est pas tout, à elle toute seule elle n'est rien. Les réactions des diverses opérations lancées sont différentes. Par exemple, une addition s'effectue plus rapidement qu'une lecture sur un disque et encore plus qu'un accès à un réseau. Il se pose alors le problème de répondre sans oubli, à toutes les requêtes : fin d'opérations, fin de lecture, fin d'écriture, touche d'arrêt, battements d'horloge, détection d'anomalies, etc... La ressource qui permet d'alerter de manière aléatoire l'unité de contrôle qu'un phénomène est apparu est tout simplement le mécanisme des INTERRUPTIONS. Quand un événement se produit, l'alerte est donnée à l'unité de contrôle qui s'interrompt pour exécuter automatiquement et en priorité, un branchement à l'adresse de la routine de traitement de l'interruption associée à l'événement. Cette adresse se trouve dans une table de la région de communication du système à un emplacement fixe.

          Sur les machine IBM série 360, 370 ,390, c'est un petit peu différent car il n'y a qu'une seule interruption pour toutes les entrées/sorties. Le traitement est asynchrone. Il y a donc gestion de files d'attente. Toutes les entrées/sorties sont gérées par des unités de contrôle qui ne sont rien d'autres que des calculateurs frontaux. C'est cette particularité qui fait qu'un très grand nombre de périphériques peut être connecté à ces machines.

          Conceptuellement le principe de la mémoire virtuelle est simple. L'utilisateur s'en sert tous les jours sans s'en rendre compte.

          Mais tout d'abord, la mémoire virtuelle : c'est quoi au juste et pourquoi ?

          J'expose ici une technique que je connais à peu près correctement utilisée sur les calculateurs IBM. Malheureusement, je ne connais pas du tout les internes de Windows ni même ceux d'Unix/Linux. Ce sont par ailleurs les seules machines sur lesquelles j'ai travaillé et dont je n'ai jamais utilisé l'assembleur. J'estimais que ce n'était pas nécessaire, le langage C n'étant pas, en réalité, un langage au sens propre du terme mais plutôt un assembleur très évolué. Il suffit d'analyser son taux d'expansion par rapport aux compilateurs courants. Tout cela pour dire que, sous Unix/Linux ou Windows, d'autres techniques ont pu être préférées mais je ne serais pas étonné que le "mode protégé" de ces PC soit au coeur de la fonctionnalité.

D'abord un petit historique :

          Avec l'augmentation des travaux effectués sur les machines, la mémoire réelle - on dit aussi mémoire vive - de l'ordinateur a été vite saturée. Par ailleurs, les performances des disques se sont accrues notablement. En faisant des statistiques, les concepteurs ont remarqué qu'une grande partie de la mémoire vive était inutilisée la plupart du temps. Une application est généralement écrite pour répondre à plusieurs traitements, plusieurs objectifs. Chacun d'entre eux est traité par un programme. Quand un programme s'exécute, les autres parties de l'application sont inertes mais tout de même résidentes en mémoire. On imaginait donc à l'époque des techniques de découpage appelée "programmation modulaire", expression qui a souvent alimenté les conversations de salon quant à sa définition - un peu comme la "programmation orientée objets" aujourd'hui -. Elles consistaient à faire faire à l'éditeur de liens, le programme qui construit l'exécutable, donc au programmeur en fin de compte, tout le découpage de l'application :

          Mais très rapidement, la méthode glissa vers une entité plus petite la "page", le "cluster" c'est à dire un découpage des programmes et des données effectué cette fois-ci par le système lui-même sans demander à l'utilisateur d'intervenir au niveau de la construction du module exécutable. C'était un plus. Ce découpage correspondait en général au découpage hardware de la mémoire sur les cartes électroniques.

Maintenant le vif du sujet :

          L'idée consiste à exécuter les instructions se trouvant dans une page correspondant au programme en laissant protégées toutes les autres pages de la mémoire réelle. Quand arrive le moment d'exécuter une instruction qui est en dehors de cette page, une interruption "violation de protection mémoire" alerte le système qui l'analyse. Si cette adresse appartient à une page virtuelle du programme, le système charge cette page virtuelle dans une page réelle libre qu'il déprotège et donne le contrôle à l'instruction qui continue le programme. Si cette adresse n'appartient pas à une page virtuelle du programme, alors c'est une véritable anomalie qui est traitée comme à l'accoutumé. Et le processus se poursuit ainsi de suite....

          La technique maintenant consiste à créer un gros fichier, 5 fois la mémoire vive, 10 fois voire davantage, appelé "swapfile" ou "fichier de pagination" dans lequel les programmes à exécuter vont être chargés dans un premier temps page par page dans un ordre aléatoire en fonction des pages disponibles.

Ce fichier héberge tout simplement la mémoire virtuelle du calculateur.

          Côté mémoire vive le système connaît parfaitement son emplacement. Elle est découpée aussi en pages de même taille à partir de laquelle les instructions du programme seront exécutées.

          Revenons un court instant sur les interruptions : il y en a une, donc, qui nous intéresse tout particulièrement ici : c'est l'interruption "violation de protection mémoire".

          Sur une machine IBM 360/370/390, la mémoire est découpée physiquement en pages de 4 Ko auxquelles est associé un registre de protection dont les deux flags les plus importants sont :

-------------------------------
          Il y en a un troisième très important, si j'ai bonne mémoire, : le bit de gel de page (bit à 1 : la page n'est pas swapable). Une page est fixée ou gelée en mémoire lors d'une opération d'entrées/sorties. En effet, une entrée/sortie est gérée par une unité de contrôle périphérique qui a accès directement à la mémoire réelle du calculateur mais qui ne connais pas la pagination. Il faut donc absolument que les pages mémoires contiguës qui doivent recevoir ou émettre les données soient présentes et de plus autorisées en lecture ou écriture.
-------------------------------

Le processus maintenant :

          On imagine aisément la fréquence des sollicitations du fichier "swap". Au moment de l'installation du système, ce fichier est crée sur un disque dédié en général. D'autres fichiers peuvent être créés sur ce disque mais on s'arrange toujours pour choisir des fichiers très très peu sollicités tout en étant indispensables.

          Conceptuellement le principe de la machine virtuelle est tout aussi simple que celui de la mémoire virtuelle. Evidemment, c'est plus aisé à dire qu'à expliquer et en plus qu'à faire !....

          Mais tout d'abord, la machine virtuelle : c'est quoi au juste ?

          Une machine, un calculateur qu'est-ce que c'est ?

Le contexte est fixé, maintenant le vif du sujet :

          La technique de gestion de machines virtuelles consiste donc à faire fonctionner plusieurs machines, vues de l'utilisateur, avec leur propre système d'exploitation, dans une seule machine réelle. Il va de soi que toutes les machines virtuelles, fonctionnellement parlant, doivent être des "clones" de la machine réelle. Elles doivent avoir tout ce qui vient d'être décrit précédemment.

          Mais si on regarde bien les choses, quelle différence y-a-t-il entre une machine réelle ayant un système d'exploitation habituel en charge de programmes d'application et un hyperviseur de virtualisation en charge de machines virtuelles.

Hyperviseur, système d'exploitation ou applications, c'est du code de même nature.
Il n'y a donc aucune différence.

          Seul le contexte distingue le système des applications. Un système d'exploitation ou un hyperviseur est une application qui gère des environnements pour applications. Sauf cas spéciaux, une application tourne toujours en mode programme et le système ou l'hyperviseur en mode système. D'ailleurs, dans le fichier de pagination d'un hyperviseur de virtualisation, on ne fait pas aisément la différence entre une page virtuelle d'une machine virtuelle et une page virtuelle d'une application gérée par une machine virtuelle différente.

Dans une machine virtuelle, tout est virtuel, même les entrées/sorties par exemple.
Dans ce cas, c'est l'hyperviseur qui va les effectuer à sa place.

          L'idée consiste à placer toutes les machine virtuelle en mode programme, un mode nonprivilégié. L'hyperviseur donne le contrôle à une machine virtuelle. Tant qu'elle exécute des instructions nonprivilégiée, il laisse faire. Mais quand une machine virtuelle exécute une instruction privilégiée comme le lancement d'une entrée/sortie par exemple, il est alerté par une interruption "violation du mode privilégié" qu'il analyse. Si l'instruction privilégiée est exécutée dans le mode privilégié de la machine virtuelle puisqu'il connaît le registre d'état de chacune d'elles, il exécute l'opération à la place de la machine virtuelle en tenant compte de tout le contexte. Si l'instruction privilégiée est exécutée dans le mode nonprivilégié de la machine virtuelle, alors il y a effectivement anomalie et le système reproduit à la machine virtuelle tout l'environnement pour lui permettre de traiter l'anomalie dans les strictes mêmes conditions qu'elle le ferait si elle était réelle.

          Revenons un court instant sur les interruptions : c'est donc l'interruption "violation du mode privilégié" qui nous intéresse particulièrement ici.

          Sur une machine IBM 360/370/390, le passage du mode privilégié dit mode système vers le mode nonprivilégié dit mode programme se fait à l'aide d'une instruction qui positionne l'indicateur du mode système/programme du PSW.

          L'exemple de la figure ci-dessus montre une configuration du système VM assez typique que nous avions eu à une certaine période :

Le principe de fonctionnement :

          L'hyperviseur VM est le maître de la machine réelle. Son noyau est donc en mode privilégié. Par conséquent, tous les systèmes qu'il est susceptible de charger sont tous sous son contrôle total. Leurs noyaux sont donc en mode nonprivilégié, pour lui bien sûr car ils sont en mode privilégié dans leurs environnements respectifs. Toutes ces machines virtuelles ne demandent qu'à travailler. Comme c'est lui qui gère la mémoire virtuelle, il va agi de la même manière que celle qui a été expliquée avec les programmes. La seule particularité, il exécutera les instructions privilégiées à la place des machines virtuelles et reproduira le contexte pour permettre à la machine virtuelle d'agir comme si c'était une machine réelle.

          A un moment choisi par lui seul, en fonction de ses impératifs et de ses contraintes, le système d'exploitation va donner la main à une machine virtuelle.

          Comment s'y prend-il ?

          Il connaît parfaitement la topographie des machines virtuelles puisqu'elles sont une réplique de la machine réelle. La machine virtuelle est, une fois chargée, tout à fait prête à fonctionner comme elle le serait si elle était réelle. Pour ce faire, un certain nombre de pages virtuelles de la machine virtuelle sont chargées, en particulier, celles qui contiennent la zone fixe du noyau. Il se branche donc à l'adresse se trouvant dans le PSW et, aussitôt, la machine virtuelle démarre.
 
          Deux cas peuvent se présenter :

          Il y a une autre fonction de l'hyperviseur dont je ne parlerait pas mais dont on peut pressentir le besoin. Les machines virtuelles ont leur propre système d'exploitation. Elle possèdent un système d'adressage absolu débutant pour chacune à zéro, tout comme l'hyperviseur, mais leurs adresses d'implantations sont à un endroit quelconque de l'espace d'adressage de l'hyperviseur. Il existe donc une interface fondamentale : le Translateur d'adresses qui, dans un premier temps, était un composant en mémoire de l'hyperviseur et qui, par la suite, devint un composant microprogrammé.

En résumé :

          Je disais que, CONCEPTUELLEMENT, les principes étaient simples :

la notion de mémoire virtuelle est étroitement liée à la "violation de protection mémoire" .

la notion de machine virtuelle est étroitement liée à la "violation de mode privilégié"

--ooOoo--