jeudi 10 avril
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | O'Reilly | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Liens connexes

Dépêche modérée par

Dépêche éditée par

Logiciel : Virtualisation de Serveur : Linux sous Windows

Posté par NOULARD Eric (page perso, ). Modéré le 26 avril 2006.
Microsoft
La virtualisation de serveur est une technologie très intéressante car elle permet de faire fonctionner plusieurs instances de systèmes d'exploitation au sein d'une même machine physique. Ceci permet notamment d'offrir des hébergements "dédiés virtuel" (VDS) à un coût inférieur à un serveur dédié réel.

Des logiciels libres (Xen, UML, QEmu, OpenVZ, etc..) ou propriétaires (VMware, MS Virtual Server) permettent de construire des solutions de serveurs virtuels avec différentes fonctionnalités/contraintes. Microsoft annonce le support de Linux par MS Virtual Server 2005 R2.

Qu'en pensez-vous ? Mettriez-vous votre système libre préféré dans une cage gardée par un logiciel propriétaire ?

> Lire la dépêche (64 commentaires, moyenne: 3).  

Le principe des serveurs virtuels est qu'un système hôte (Host OS) puisse héberger un ou plusieurs systèmes invités (Guest OS) en leur allouant une partie des ressources physiques de l'hôte. On peut donc avoir un hôte Linux qui héberge un invité Linux et un invité FreeBSD et/ou un invité Windows ou vice versa.

Il existe aujourd'hui environ 3 catégories de techniques/solutions de virtualisations:

Les émulateurs ou machines virtuelles (QEmu, VMWare, Bochs ou Microsoft Virtual Server)
Ces logiciels s'exécutent sur la machine hôte (généralement Windows ou Linux) et émulent une machine invitée sur laquelle on pourra installer le système invité qui croira s'installer sur une machine réelle.

Les hyperviseurs-like (Xen, UML)
Ces hyperviseurs n'ont pas nécessairement besoin d'un système hôte mais visent plutôt à offrir une couche d'abstraction matérielle la plus fine possible qui permettent d'isoler les ressources utilisées par les différents systèmes invités. Ces solutions nécessitent d'adapter/porter le système invité, ce qui empêche les systèmes propriétaires d'y être supporté facilement. Cette contrainte permet toutefois d'obtenir de meilleures performances que les émulateurs.

Les émulateurs d'OS (OpenVZ, Linux VServer ou encore les container Solaris)
Ces dernières solutions permettent à plusieurs instances du même système de partager les ressources de la même machine. On ne peut donc pas héberger un système Windows ou Linux dans un container Solaris. Toutefois, ces solutions semblent être les plus performantes et les mieux adaptés à la consolidation de serveur.

Toutes ces solutions sont très utiles et seront probablement de plus en plus présentes dans les offres d'hébergement Web ou d'autres services Internet.

Microsoft a annoncé que la version 2005 R2 de son produit MS Virtual Server supporterait des systèmes Linux . Je ne sais pas si on doit se réjouir ou non de voir certains serveurs Linux fonctionner en tant qu'invité d'un système propriétaire mais chacun se fera son opinion. Personnellement, j'aurais plutôt tendance à remettre (seulement si nécessaire) à sa place dans une fenêtre QEmu ledit système propriétaire. Mais on peut aussi y voir un signe de la nécessité de Microsoft de s'ouvrir à une demande réelle et également une tentative d'atteindre plus largement le marché des serveurs internet (Web notamment).

La question que je posais au départ attends donc vos réponses:
Mettriez-vous votre système libre préféré dans une cage gardée par un logiciel propriétaire?

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Ca existe déjà ...

Posté par totof2000 () le 26/04/2006 à 08:32. (lien). Évalué à 6.

Mettriez-vous votre système libre préféré dans une cage gardée par un logiciel propriétaire ?

Ce genre de chose existe déjà (IBM Z/OS et Linux, il me semble également que les architectures Regata permettent de faire tourner des systèmes Linux, mais la supervision reste sous AIX. Un connaisseur pour confirmer ou rectifier mes âneries?).

VmWare (propriétaire) permet déjà de faire tourner un Linux dans une "cage" windows.

Pour répondre à ta question: à titre personnel je ne le ferai pas. Je n'y vois pas d'intérêt.

coLinux

Posté par lcld () le 26/04/2006 à 08:41. (lien). Évalué à 5.

Tu oublies coLinux, alors que c'est certainement la meilleure solution pour faire tourner Linux sous Windows. http://www.colinux.org/

Qu'en pensez-vous ?

Posté par oops (page perso, ) le 26/04/2006 à 08:59. (lien). Évalué à 4.

>Mettriez-vous votre système libre préféré dans une cage gardée par
>un logiciel propriétaire ?

Ces technos me semble interessantes pour les hébergeurs.

Et dans ce cas là je ne vois pas l'intérêt d'utilser un Linux dans un Windows. ( les hébergeurs ont beaucoup de machines )

Pour ce genre d'utilisation chacun dans son coin:

Des Linux dans dans Xen ( par exemple )
Des Windows dans Microsoft Virtual Server ( par exemple )

Cela me semble bien plus judicieux et normalement plus stable et performant.

Performances de UML

Posté par Pierre Palatin (page perso, ) le 26/04/2006 à 09:19. (lien). Évalué à 7.

En fait, il est loin d'être évident que UML soit plus performant que du Qemu (avec du kqemu en mode kernel) ou du vmware, particulièrement dans le cas de code avec beaucoup de syscalls (typiquement, quand il y a des I/O à la pelle).

Clairement, ça reste moins performant que du Xen, cf les benchmarks (venant de l'équipe de xen certes) : http://www.cl.cam.ac.uk/Research/SRG/netos/xen/performance.h(...)

Le problème est que pour pouvoir faire tourner du code non modifié, UML doit pouvoir émuler les syscalls en userland. Or pour cela, il n'y a pas énormement de solutions. En l'occurrence, UML surveille l'exécution via ptrace(). Donc à chaque syscall d'un processus guest, il va avoir un switch userland -> kernelland, le kernel s'aperçoit que y'a du ptrace(), retour en userland coté UML, UML fait disparaitre d'un coup de baguette magique le syscall original (et doit laisser probablement un syscall bidon s'exécuter, donc 2 switchs à nouveau), puis s'occupe d'émuler le syscall, ce qui signifie probablement souvent plusieurs syscalls et donc switch userland/kernelland. Et ensuite, 2 derniers switchs pour continuer l'exécution du processus guest.

Or le problème c'est que du switch kernelland/userland, c'est extrêmement lent (un long call c'est rien à coté), d'où des perfs qui s'écroulent des qu'il y a des I/O.

Xen, pour éviter cela, joue avec les ring 1/2 des x86 (chose qui existe sur peu d'autres processeurs, beaucoup n'ayant que 2 modes, kernel & user, contre 4 pour les x86).

Je ne prétends pas que qemu/kernelkqemu & vmware sont systématiquement plus rapides que UML, mais juste que les perfs d'UML ne sont certainement pas à rapprocher de Xen. J'aimerais bien mettre en place qq benchmarks, mais le temps n'étant pas extensible, c'est pas gagné ...

(et je soupçonne que CoLinux ai le même problème - mais là c'est de la pure spéculation :)

Non bien sur!

Posté par Christophe Garault (page perso, ) le 26/04/2006 à 10:07. (lien). Évalué à 10.

De ce que je perçois des nouveautés sur ce secteur, si Microsoft a décidé de développer le support de Linux, c'est certainement pour ne pas se laisser prendre trop de parts de marché par VMWare qui rappellons-le a sorti récemment une version gratuite (mais non libre) pour serveur.

Il est évident que le géant de Redmond ne peut se permettre d'être absent ou acteur mineur sur un marché en pleine expension. En effet, comme d'autres l'ont mentionné, les machines virtuelles existent depuis des lustres sur les Mainframe IBM et sur le haut de gamme de Sun. La nouveauté c'est qu'avec la montée en puissance des micros et l'arrivée récente des processeurs à coeur multiples, il est devenu tout à fait rentable de développer des solutions de virtualisation pour micros. A n'en pas douter, il s'agit là d'un marché en pleine expension. Que ceux qui n'ont pas encore gouté au plaisir d'avoir plusieurs OS tournant en même temps aillent télécharger la version d'essai de VMWare. :)

Ce qui est ici intéressant de noter c'est tout de même que Microsoft fait contre mauvaise fortune bon coeur. Après avoir tant décrié son adversaire Linux en lui taillant toutes les croupières possibles, le voilà presque obligé de lui accorder une reconnaissance en le supportant dans l'un de ses produits. C'en est presque risible..

Sur le même sujet, une interview du créateur d'OpenVZ est parue il y a quelques jours: http://kerneltrap.org/node/6492
Sa lecture permettra de compléter les informations techniques de cette dépêche.

Enfin pour répondre à la question initiale, je préfèrerai mille fois faire le contraire, à savoir mettre l'OS proprio dans une cage plutôt que d'enfermer un logiciel libre...


PS: merci pour cette dépêche fort intéressante et très bien rédigée.

[+] Vista // Linux

Posté par salvaire () le 26/04/2006 à 11:50. (lien). Évalué à -1.

Mettriez-vous votre système libre préféré dans une cage gardée par un logiciel propriétaire ?
Aurons nous le choix? Émulé Linux c'est possible! Mais émulé Vista ça va être plus dur (déjà en natif ..., sans parler des drm). À moins que QEmu explose MS Virtual Server.

Hurd

Posté par Sébastien TeRMiToR (page perso, ) le 26/04/2006 à 18:06. (lien). Évalué à 2.

Ce n'est pas pour lancer un troll idiot, mais une vrai question.

Hurd si il tourne sur un micro noyau genre l4 ou coyotos, defini un mecanisme de capacibilite, permetant de dire telles taches on le droit d'utiliser telles ports, or la gestion du hardware passe aussi par des serveurs donc des ports.

Hurd permet de redefinir les serveurs auth et proc , et tous ce que l'on veut.

Donc Hurd permet une virtualisation sans pariel de chaqu'un de ces composant ou des groupe de composant pour faire tourner autant de pilote taches serveur protocole ou systeme de fichiers que l'on veux

La question est de savoir si la virtualisation type xen a un tant soit d'interet sur le Hurd ?

Demande de précision

Posté par Jean-Michel Caricand () le 27/04/2006 à 06:51. (lien). Évalué à 2.

Bonjour à tous,

J'aimerais obtenir une précision de la part de personnes ayant déjà utilisé OpenVZ.

Sur mon lieu de travail, nous utilisons Xen. Cela nous permet d'avoir par exemple sur une même machine physique plusieurs machines virtuelles faisant tourner un serveur HTTP sur le port standard, donc 80. Les VM étant complètement indépendantes, cela ne pose pas de problème.

Avec OpenVZ, si je crée 2 VM hébergeants chacune un serveur HTTP, ceux-ci peuvent-ils être attachés tous deux au port 80 ?

Si mes souvenirs sont exacts, il me semble avoir eu des problèmes avec Vserver. Je crois me rappeler que Vserver fonctionnait dans le principe comme un "super" chroot, donc avec les mêmes limitations.

Merci pour les eventuelles informations.

Retour d'expérience et réflexions

Posté par Giboyle (page perso, ) le 27/04/2006 à 23:19. (lien). Évalué à 7.

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).

Revenir en haut de page

Run by Team LinuxFr

Cette page a été générée par Templeet en 0.2246s (dont 0.0338 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.