Bernard Ourghanlian, Directeur Technique et Sécurité de Microsoft France (2)
Il faut complètement repenser le déploiement du poste de travail
HL : Ce que vous décrivez représente une vision à moyen terme qui nécessite des niveaux de performances beaucoup plus important que ceux dont on dispose aujourd'hui, pour que l'ensemble puisse fonctionner de façon fluide. MED-V va arriver dans le courant de ce semestre et j'imagine que pour faire tourner aisément dans un système d'exploitation une machine virtuelle et des applications intégrées, il doit falloir une configuration musclée.
BO : En fait aujourd'hui cela ne marche pas si mal : j'ai une machine virtuelle Windows 7 sur mon PC et honnêtement les performances sont plutôt bonnes. Mais il faut de la mémoire si on veut une machine virtuelle « qui respire ». C'est un sujet sur lequel on travaille beaucoup sur Hyper-V ; dans Hyper-V V2 qui sera intégré à Windows Server 2008 R2, il y aura une fonction d'allocation intelligente de mémoire en cours de préparation et qui va probablement arriver dans une mise à jour d'Hyper-V V2, avant l'arrivée d'Hyper-V V3.
Les solutions proposées par Microsoft ou VMware (qui fait un petit mieux que nous mais avec quelques frustrations autour de la notion d'overcommitment), ne nous paraissent pas être la bonne voie. Nous visions une solution permettant d'allouer de la mémoire dynamiquement aux machines virtuelles, autrement dit faire en sorte que, à n'importe quel instant, on puisse réallouer de la mémoire en plus ou en moins, à l'ensemble des machines virtuelles existantes.
Autrement dit, on va définir pour chaque machine virtuelle à travers une politique ou un fichier de configuration une mémoire minimale, une mémoire moyenne et une mémoire maximum et, sur la base de ces paramètres, on va avoir la possibilité de faire en sorte que l'on puisse retirer de la mémoire et rajouter de la mémoire dynamiquement à chacune des machines virtuelles.
Cela nécessite bien sûr que le système d'exploitation le supporte et donc, en fait, on aura la nécessité de recourir à la paravirtualisation et donc ce que l'on a appelé dans le cas d'Hyper-V, les enlightments, de telle façon que le système d'exploitation accepte qu'on puisse ajouter ou retirer de la mémoire à la demande pour bénéficier d'un genre d'équilibrage dynamique entre les différentes machines virtuelles.
Il s'agit d'utiliser le maximum de mémoire à chaque instant mais, si on rajoute une machine virtuelle, il faudra en enlever sur celles qui tournent déjà et en rajouter à la nouvelle machine virtuelle (une fonctionnalité qui va arriver dans l'Hyper-V V2.x). C'est une fonctionnalité qui va normalement arriver juste après la sortie d'Hyper-V v2 (intégrée avec Windows Server 2008 R2) mais qui va jouer sur le poste de travail un rôle fondamental parce que le goulot d'étranglement sur le poste de travail aujourd'hui, c'est moins le processeur que la mémoire. Cela fait partie des éléments qui joueront un rôle très fondamental dans la virtualisation du poste de travail.
HL : En termes de caractéristique mémoire, quelles sont les recommandations de Microsoft pour justement tirer partie de ces technologies ?
BO : Cela dépend vraiment de l'environnement applicatif que l'on a dans ces machines virtuelles. Il est possible de tailler une machine virtuelle Vista avec 256 MO de mémoire, on peut le faire mais cela va « ramer » et on ne pourra pas y installer beaucoup d'applications.
Aujourd'hui, si on prend une machine virtuelle Windows 7, on respire vraiment sans problèmes avec 1 Go de mémoire. Avec Windows 8 on peut raisonnablement penser qu'on respirera encore mieux parce qu'on bénéficiera de MinWin et donc des seules briques dont on a besoin sur son poste et aussi sur son serveur. Cela fait partie des éléments qui vont contribuer à rendre beaucoup plus simple l'utilisation d'un PC sur lequel on aura certes de la mémoire mais pas dans des quantités gigantesques.
HL : D'une façon générale, pour une entreprise qui doit procéder à un appel d'offres pour renouveler une partie de son parc PC, sur quelle capacité mémoire doit elle tabler pour pouvoir mettre en œuvre ces différents technologies ?
BO : A terme, je pense que 4 Go est un bon chiffre. Mais en sachant que la virtualisation est un sujet qui est « en devenir », pour de nombreuses raisons. Il y a aussi le fait que le matériel évolue. Au niveau du matériel il y a un certain nombre de fonctionnalités qui arrivent dans les nouvelles générations de processeurs qui ne sont pas encore intégrées dans les machines d'aujourd'hui, comme par exemple les fonctions VT-d chez Intel et IOMMU chez AMD qui vont permettre au niveau de la virtualisation de pouvoir faire des entrées sortie « directes » depuis les machines virtuelles.
Quand on regarde la façon dont cela fonctionne sur Hyper-V, on fait une entrée-sortie, mais on a besoin de passer à travers le bus mémoire qui va sous-traiter tout le travail à la machine virtuelle parente qui effectue le travail.
On a besoin de faire des échanges mémoire à mémoire entre deux machines virtuelles qui, au final, vont aboutir à un disque ou à un périphérique d'entrée sortie. L'idée avec VT-d (« d » comme Direct IO) c'est d'avoir simplement un message service qui dise au matériel : « prépare ta fenêtre de DMA, je vais ‘tirer' à cet endroit là », et à ce moment là on va faire en sorte que la machine virtuelle, une fois que l'on a préparé le buffer au bon endroit, puisse directement insérer le contenu de l'entrée sortie dans le buffer sans avoir à faire de la recopie.
C'est un énorme plus en termes de performances parce que cela va permettre de pouvoir consommer énormément moins de CPU que ce l'on fait aujourd'hui. Et d'une manière générale, c'est ce qui va permettre, dans un environnement qui riche en entrées / sorties comme le poste de travail, d'avoir de bien meilleures performances.
HL : Ce que vous décrivez là se situe dans un horizon d'environ 3 ans. Quid de l'arrivée beaucoup plus tôt, si on en croit Citrix, d'une solution qui leur soit propre ?
BO : Il est encore un peu tôt pour se prononcer sur une telle solution : Il faut voir comment sera déployée et quelles seront réellement ses performances et ses capacités, la virtualisation sur le poste de travail est possible à travers Virtual PC (ou son équivalent chez VMware). Virtual PC n'est pas un Hyperviseur, ce qui présente un certain nombre d'inconvénients, mais est parfaitement utilisable. Ce qui reste problématique au niveau de toutes les machines virtuelles du marché, c'est d'abord leur performance et leur niveau d'intégration avec le système.
Quand on parle d'une solution comme MED-V, sa justification essentielle c'est que, pour un utilisateur, il est extrêmement perturbant d'avoir n machines virtuelles : il n'y comprend plus rien. Il passe son temps à passer d'une machine virtuelle à une autre, il ne sait ce qu'il peut faire entre elles, il peut à certains moments faire du copier coller. L'expérience utilisateur n'est pas très simple.
Dernier point fondamental, c'est la problématique de la gestion de ces machines virtuelles. Une machine virtuelle a un cycle de vie, ca naît, ça meurt et entre temps accomplit de nombreuses tâches en particulier se patcher. Un des sujets majeurs au niveau des machines virtuelles est de savoir les patcher offline.
Quand je reçois un patch sur le poste de travail, il faut que l'on sache patcher toutes les machines virtuelles qui sont installées dessus. Sans que la machine virtuelle soit démarrée. C'est un sujet sur lequel on travaille et qui est relativement occulté. Mais quand il faut patcher 25, 30, 50 machines virtuelles et qu'il faut toutes les démarrer pour être capable de les patcher, c'est un vrai cauchemar !
Actuellement si je démarre une machine virtuelle non patchée et que j'ai trois ou quatre virus qui se baladent sur le réseau, j'y « ai droit » immédiatement. C'est un point sur lequel des progrès doivent être réalisés. Ce point est encore plus important sur les serveurs, car en général on a moins de serveurs physiques, moins de machines virtuelles et on gère cet environnement a peu près de manière professionnelle. Par contre il est très hasardeux de confier de nombreuses machines virtuelles à des utilisateurs qui n'ont pas la moindre idée de ce qu'il faut faire en termes de patchs.
Concernant ces solutions de virtualisation, il y a même des fabricants comme Phoenix qui essayent de mettre en œuvre un hyperviseur intégré en standard avec n'importe quel PC. Pourquoi pas si l'on accepte de se restreindre à faire peu de choses. Car dès qu'on entre dans un environnement opérationnel nécessitant un véritable système, savoir comment on va patcher l'hyperviseur concerné si on a des problèmes est un vrai sujet.
On travaille sur la preuve mathématique d'Hyper-V en partenariat avec l'université de Sarrebruck et Microsoft Research parce que l'on sait que c'est un élément fondamental. Il va falloir être capable de prouver mathématiquement les machines virtuelles car on ne peut pas se permettre d'avoir à supporter un bug sur le moniteur de machine virtuel lui-même.
Et c'est l'une des raisons pour laquelle l'architecture d'Hyper-V me semble préférable parce que c'est un micro noyau de petite taille (moins de 1 Mo, environ 50 000 lignes de code) qu'une architecture d'hyperviseur « à la VMware » dans lequel on va rajouter nombre de drivers de périphériques, etc. Une des raisons pour lesquelles on veut garder à l'hyperviseur une taille absolument minimaliste c'est qu'on veut le prouver mais aussi à en limiter au maximum la surface d'attaque. C'est essentiel.
HL : Pour rassurer les directions informatiques ?
BO : Oui mais pas seulement : il n'est pas possible qu'on ait des bugs dans ce qui va devenir une composante fondamentale de tous les postes de travail et de tous les serveurs de demain. L'objectif est de ne jamais à patcher, jamais, sauf pour ajouter des fonctionnalités.
C'est exactement la même chose que si on disait : « désolé mais il faut changer le Bios sur toutes vos machines ». J'ai souvenir de virus il y a quelques années qui endommageait gravement le Bios quand il s'exécutait et c'était une catastrophe. Les utilisateurs ne pouvaient plus rien faire.
Là c'est pareil, si l'hyperviseur à un bug et que, par exemple, on a mis là dedans ce que l'on appelle un « hyper rootkit », qui va attaquer l'hyperviseur lui-même, c'est l'enfer. Il faut imaginer des milliers de serveurs et des dizaines ou des centaines de milliers d'ordinateur à patcher, c'est à devenir fou. On ne peut pas se le permettre.
L'autre évolution importante au niveau matériel concerne l'arrivée de TXT (Trusted Execution Technology) chez Intel (cela s'appelle SVM chez AMD) qui va permettre de faire en sorte qu'on puisse disposer de la signature d'hyperviseur dans le TPM pour être sûr que l'hyperviseur ne soit pas frelaté avant de le démarrer.
Ce sont des briques qui deviennent nécessaires pour construire les systèmes d'information demain.
HL : Et justement ce n'était pas une des ambitions de l'annonce de Citrix et d'Intel que d'expliquer que des composants compatibles avec les extensions processeur d'Intel puissent être patchés à distance même s'ils ne sont pas opérationnels ?
BO : Si bien sûr, cela fait partie des objectifs de vPro, etc. La fréquence de patch d'un Bios est fréquente, par exemple tous les deux ou trois mois (c'est le cas sur la mienne). Il est logique de le faire le plus simplement possible. Le fait qu'on puisse le faire c'est bien, mais ne pas avoir à le faire c'est encore mieux.
HL : Ne pourrait-on imaginer, avec ce genre d'outils, de pouvoir patcher Hyper-V sans que cela devienne incommensurable ?
BO : Oui, mais ce que l'on constate et que nous disent tous nos clients, une des raisons pour lesquelles ils patchent avec si peu de bonne volonté (quand on voit ce qu'il est en train de se passer avec Conficker et tous les problèmes qu'il y a chez de très nombreux clients qui ont fait le choix de ne pas patcher) c'est que sur 100 PC, il y a toujours un ou deux pour lesquels il y a un problème.
Et on ne sait pas pourquoi.
Ce qui est très difficile c'est d'atteindre le 100 %. Même si on a la possibilité de patcher sans avoir à démarrer le PC, c'est très bien, ce qui est ensuite compliqué ce sont les divers cas où PC n'a pas été patché. Un bon patch c'est un patch qu'on n'a pas besoin d'appliquer parce que l'hyperviseur aura été assez solide pour ne pas nécessiter de correction...
De même, un bon déploiement c'est un déploiement qu'on n'a pas besoin de faire. C'est la raison pour laquelle la virtualisation est si importante, l'idéal étant qu'un jour il n'y ait plus de déploiement du tout.
Il suffit pour s'en convaincre de voir les difficultés qu'ont nos clients avec le déploiement des postes de travail. La virtualisation est une vraie révolution car elle change complètement la donne. Déployer les postes de travail, patcher les postes de travail a été toujours une vrai « galère ». Cela doit cesser.
HL : Entre la situation actuelle que vous décriviez avec moins d'un % des postes de travail qui utilisent la virtualisation et la vision à moyen terme reposant sur Hyper-V V3, comment la transition va-t-elle ?
BO : Cette transition va s'opérer à travers la généralisation d'App-V et de MED-V et avec la volonté de faire en sorte que, petit à petit, les gens comprennent l'intérêt de la virtualisation. Par ailleurs, l'un des intérêts majeurs de MED-V est que les utilisateurs auront une machine virtuelle en plus de leur machine habituelle et ce de manière transparente.
HL : Et cela va tourner sur des machines actuelles ? J'ai cru comprendre que sur un PC ou un portable standard cela risquait de « ramer ».
BO : Tout dépend de ce que l'on appelle un portable standard. Windows 7 consomme beaucoup moins de mémoire que Vista. On peut parfaitement utiliser Windows 7 avec 1Go de mémoire, par exemple sur un Netbook, ce qui était assez difficile avec Vista. C'est un progrès important.
Si j'ai des machines virtuelles, par exemple une machine virtuelle XP qui correspond à des scénarios très réels dans les entreprises qui ne peuvent pas migrer vers Vista parce que leurs applications ne tournent pas ; la virtualisation pour ces entreprises est une solution, je dirais même que c'est probablement la solution. Avoir une machine virtuelle XP sur laquelle j'ai mon patrimoine applicatif, que je n'ai pas envie de migrer, représente une solution tout à fait envisageable, au moins pendant quelques années le temps que les choses se résolvent.
Aujourd'hui, une machine Windows XP avec 512 Mo tourne sans grande difficulté ; il est envisageable de pouvoir faire tourner à la fois Windows 7 et une image virtualisée de Windows XP sur la même machine avec 2 Go, cela ne devrait pas poser le moindre problème.
HL : Une machine avec 1 Go de RAM sous Windows 7 serait suffisamment configurée pour faire tourner et Windows 7 et une machine virtuelle sous XP ?
BO : Probablement pas. Il faudrait disposer de 2 Go pour faire tourner à la fois Windows 7 et une machine XP, voire même en plus une machine Vista. Tous les PC vendus aujourd'hui (même dans la grande distribution) disposent de 2 Go de mémoire. C'est la seul voie car la course au GHz est finie.
HL : Quid du parc existant ?
BO : Il faut voir à quelle vitesse les choses évoluent, mais dans les entreprises aujourd'hui, on a souvent un taux de renouvellement d'environ un tiers chaque année, ce qui veut dire qu'on renouvelle 100 % du parc tous les 3 ans ; une telle approche est donc loin d'être invraisemblable.
HL : Les rythmes de renouvellement vont peut être s'allonger compte tenu du contexte économique.
BO : C'est probable mais nécessité fait loi. Rien n'empêche d'imaginer des modèles totalement différents de la façon dont on utilise les postes de travail aujourd'hui dans les entreprises.
On pourrait imaginer des entreprises proposant à leurs salariés d'utiliser leurs propres PC moyennant une allocation forfaitaire annuelle. Certaines entreprises sont lancées dans cette direction, comme Shell, moyennant une allocation annuelle d'environ 2000 euros.
Elles payent quelque chose comme 2000 $ ou 2000 € à leurs collaborateurs et leur disent : « vous achetez la machine que vous voulez mais, par contre, vous en assurez la maintenance, je ne veux pas en entendre parler ». Il n'y a donc pas de call center sur autre chose que les applications. « Tout ce qui est système d'exploitation etc., est géré par les utilisateurs ; L'entreprise se limite à donner une machine virtuelle avec l'environnement corporate nécessaire pour travailler.
HL : C'est l'idée de Med-V ?
BO : C'est MED-V plus Virtual PC/Hyper-V V3 en l'occurrence sur le poste de travail à terme. Et oui c'est effectivement ca l'idée.
HL : Si la machine qui supporte l'OS hôte des machines virtuelles à des problèmes, que se passe-t-il si la machine n'est pas sécurisée ?
BO : On a exactement les mêmes problèmes qu'aujourd'hui dans la virtualisation dans les data centers. Quand on a une machine dans un data center qui supporte quatre, cinq, dix ou vingt machines virtuelles, si jamais l'on a un problème au niveau du matériel ou au niveau de l'hyperviseur ou de la partition maitresse, malheureusement on perd tout.
On travaille sur la possibilité d'avoir plusieurs partitions parentes qui soient capables d'être en redondance (je ne suis pas très certain que ce soit très réaliste sur un poste de travail).
HL : Pour prendre le relais en cas de défaillance de la partition principale... Je suppose que l'ensemble des partitions parentes doivent être patchées, ça devient compliqué !
BO : La virtualisation sans gestion du cycle de vie d'une machine virtuelle c'est insupportable. Il faut absolument gérer son cycle de vie de machines virtuelles et c'est la raison pour laquelle on a tant insisté sur System Center Virtual Machine Manager : c'est obligatoire, il faut être capable de gérer à la fois les machines physique et les bibliothèques de machines virtuelles de la façon la plus intelligente possible et être capable de faire en sorte que les mises à jours de ces machines virtuelles se fassent dès que c'est possible et le plus rapidement possible.
Ce qui nécessite ensuite de savoir, par exemple, utiliser des protocoles différentiels pour pouvoir ne recopier que ce qui a changé. Par exemple, si je mets en place un changement au niveau central, je vais faire en sorte que les machines virtuelles et l'ensemble du parc puissent être patchés sans recopier les quelques Go que représente la machine virtuelle à chaque fois.
C'est une des raisons aussi pour laquelle utiliser App-V et Hyper-V fait beaucoup de sens car cela permet d'avoir des machines virtuelles en petit nombre en fonction des profils d'utilisation et ensuite de streamer le reste du patrimoine applicatif à la demande ; cela évite d'avoir les situations fréquentes où l'on a des centaines et des centaines de machines virtuelles différentes en fonction des applications. A chaque fois, il faut en patcher autant.
C'est un cauchemar. Alors que si, en central, j'ai un patch à appliquer au niveau App-V, je patche en central mon application et puis à partir du moment où il y a une différence sur le poste de travail, je télécharge la différence et puis c'est tout. C'est comme même un énorme avantage. (Source IT Channel)