Dans le cadre d'un projet en fin d'année dernière, j'ai dû installer des Linux (SLES 9) sur des MS Virtual Server au-dessus de Win2003.
Les problèmes majeurs rencontrés :
- désynchronisation énorme des horloges (et donc dysfontionnements lourds pour toutes les applications qui en dépendent... c'est à dire beaucoup)
- bug apparent de l'émulation SCSI
Microsoft promet de corriger précisément ces défauts là (voir lien de l'article). Bien joué Bill.
En revanche, sauf pour ceux qui voudraient faire tourner un seul Linux au milieu d'une horde de Windows tous exécutés sous Virtual Server, je ne vois guère l'intérêt de s'appuyer sur Win2003 + Virtual server, sauf si les versions prochaines sont vraiment très, très, très perfomantes. Est-ce probable ?
Entre autre, en première approche, Virtual Server suppose l'installation d'IIS sur la machine hôte, et probablement de tout un tas d'autres "services". La surface d'exposition aux véroles du système hôte est donc importante. Puisque c'est un Windows sur le réseau, il va lui falloir... un anti-virus (et les problèmes qui l'accompagnent). Il va falloir mettre tout ça à jour régulièrement et, sauf à ce que Vista soit vraiment un Windows révolutionnaire, rebooter assez souvent, vérifier que certains services ne se sont pas réactivés durant l'application des services packs, etc... L'interface graphique va demeurer également, qui consomme des ressources.
Bref ! Là où on souhaiterait un serveur de VM tournant au-dessus d'un système hôte dépouillé, pour maximiser les perfs et minimiser les interruptions de service, on se retrouve avec tout le tintouin de Windows et les peines qui l'accompagnent. Les systèmes et applications hébergés dans les VM vont en pâtir.
Autre point : tout comme pour VmWare, il faut patcher chaque OS hébergé dans chaque VM pour qu'il se sente à l'aise dans la dite VM. Apparemment, ces "patches" ne sont pas disponibles pour les kernels en eux même, mais conçus distribution par distribution. Microsoft en propose actuellement pour des RedHat et des Suse.
- Sont-ils compatible avec des noyaux compilés manuellement ?
- Qu'est-ce qui est changé dans le Linux ; est-ce transparent, documenté ? Si RedHat diffuse une mise à jour critique pour le kernel de la RHEL4 et les rustines Microsoftiennes "sautent" dans chaque VM qui devient inopérante après mise à jour. En quel délai MSFT diffuse-t-il une nouvelle version de sa rustine, à quoi s'engagent-ils ?
- Et si on veut exécuter une Debian, tester une pré-release, une autre distribution... on pleure. Idem sous VMWare à ma connaissance, d'ailleurs. Qu'en est-il avec Les autres systèmes de virtualisation ?
Pour finir : en deux mois d'utilisation intensive de ces VM sur proc Intel, et nonobstant les problémes mentionnés tout en haut (dont un majeur), la stabilité de Virtual Server + SLES9 a été très satisfaisante (il s'agissait de prototypage, assez exigeant cependant).
# Retour d'expérience et réflexions
Posté par Giboyle . En réponse à la dépêche Virtualisation de Serveur : Linux sous Windows. Évalué à 7.
Les problèmes majeurs rencontrés :
- désynchronisation énorme des horloges (et donc dysfontionnements lourds pour toutes les applications qui en dépendent... c'est à dire beaucoup)
- bug apparent de l'émulation SCSI
Microsoft promet de corriger précisément ces défauts là (voir lien de l'article). Bien joué Bill.
En revanche, sauf pour ceux qui voudraient faire tourner un seul Linux au milieu d'une horde de Windows tous exécutés sous Virtual Server, je ne vois guère l'intérêt de s'appuyer sur Win2003 + Virtual server, sauf si les versions prochaines sont vraiment très, très, très perfomantes. Est-ce probable ?
Entre autre, en première approche, Virtual Server suppose l'installation d'IIS sur la machine hôte, et probablement de tout un tas d'autres "services". La surface d'exposition aux véroles du système hôte est donc importante. Puisque c'est un Windows sur le réseau, il va lui falloir... un anti-virus (et les problèmes qui l'accompagnent). Il va falloir mettre tout ça à jour régulièrement et, sauf à ce que Vista soit vraiment un Windows révolutionnaire, rebooter assez souvent, vérifier que certains services ne se sont pas réactivés durant l'application des services packs, etc... L'interface graphique va demeurer également, qui consomme des ressources.
Bref ! Là où on souhaiterait un serveur de VM tournant au-dessus d'un système hôte dépouillé, pour maximiser les perfs et minimiser les interruptions de service, on se retrouve avec tout le tintouin de Windows et les peines qui l'accompagnent. Les systèmes et applications hébergés dans les VM vont en pâtir.
Autre point : tout comme pour VmWare, il faut patcher chaque OS hébergé dans chaque VM pour qu'il se sente à l'aise dans la dite VM. Apparemment, ces "patches" ne sont pas disponibles pour les kernels en eux même, mais conçus distribution par distribution. Microsoft en propose actuellement pour des RedHat et des Suse.
- Sont-ils compatible avec des noyaux compilés manuellement ?
- Qu'est-ce qui est changé dans le Linux ; est-ce transparent, documenté ? Si RedHat diffuse une mise à jour critique pour le kernel de la RHEL4 et les rustines Microsoftiennes "sautent" dans chaque VM qui devient inopérante après mise à jour. En quel délai MSFT diffuse-t-il une nouvelle version de sa rustine, à quoi s'engagent-ils ?
- Et si on veut exécuter une Debian, tester une pré-release, une autre distribution... on pleure. Idem sous VMWare à ma connaissance, d'ailleurs. Qu'en est-il avec Les autres systèmes de virtualisation ?
Pour finir : en deux mois d'utilisation intensive de ces VM sur proc Intel, et nonobstant les problémes mentionnés tout en haut (dont un majeur), la stabilité de Virtual Server + SLES9 a été très satisfaisante (il s'agissait de prototypage, assez exigeant cependant).