Citrix a les moyens techniques et financiers pour permettre à XenSource de percer dans le monde de l'entreprise d'une manière rapide et professionnelle. Le code source de Xen est en GPL donc pour l'instant rien ne change. Cependant la communauté restera vigilante pour que Citrix joue le jeu et n'abuse pas de la situation. Citrix a tout à y gagner de faire participer la communauté.
Citrix permettra à Xen d'être un challenger de poids face à VMware. La nouvelle situation a forcé VMware à communiquer auprès de ses clients. À ce jour, la solution VMware ESX VI3 est une des solutions les plus abouties du marché en terme d'administration et de fonctionnalités. VMware recherche de nouveaux moyens financiers pour gagner de l'avance par rapport à ces concurrents.
(NdM : A ce propos, VMware vient de réussir son introduction en bourse.)
Nous allons avoir deux belles solutions sur le marché dont une est OpenSource... à vous de choisir.
NdM : Xen est documenté sur XenFR.org et de nombreuses solutions de virtualisation existent en libre : QEMU, KVM, OpenVZ. De même, il existe des systèmes de bureaux à distance libre X Window System, VNC. Citrix Systems, Inc. est le leader mondial dans le domaine des infrastructures de mise à disposition des applications.
XenSource Inc. a été créé début 2005. XenSource fourni des solutions pré-packagés autour de Xen mais également le support et la maintenance autour des solutions XenSource.
Aller plus loin
- XenSource (9 clics)
- Annonce sur XenSource (2 clics)
- Annonce sur Citrix (1 clic)
- Citrix France (7 clics)
- Santé financière de Citrix (3 clics)
- VMware VI3 (5 clics)
# Affiche déporté
Posté par Tonio (site web personnel) . Évalué à 8.
- NOmachine http://www.nomachine.com/
et
- Sun Secure Global Desktop Software http://www.sun.com/software/products/sgd/ plus d'info sur
http://en.wikipedia.org/wiki/Sun_Secure_Global_Desktop (ancienne techno de SCO appelée tarantella)
voila pour l'instant
[^] # Re: Affiche déporté
Posté par brazz . Évalué à 4.
Cela n'a rien à voir avec la virtualisation, c'est "juste" de l'affichage déporté hyper optimisé au niveau compression des modifications de ce qui est affiché à l'écran, sur la machine distante il n'y a rien de plus qu'une session X mais c'est nettement plus optimisé que ce que fait VNC par exemple. D'un autre côté VNC est portable sur n'importe quoi même un PDA ou un grille pain (là je suis moins sur...).
Donc la comparaison et la discussion ne peuvent se faire que sur Citrix, VNC et NoMachine-FreeNX.
[^] # Re: Affiche déporté
Posté par kowalsky . Évalué à 2.
http://www.flickr.com/photos/laughingsquid/sets/738459/
http://pkgsrc.se/net/vnc
Of course it runs NetBSD ! :)
[^] # Re: Affiche déporté
Posté par Tonio (site web personnel) . Évalué à 1.
On peut comparer CITRIX avec Free-NX, nomachine et SUN secure global desktop
Avant de crier qu'il y a d'autre solution il est bon de regarder en détails les caractéristiques des produits...
# Bon à savoir
Posté par newca (site web personnel) . Évalué à 6.
KVM finira par faire sa place.
Je l'utilise déjà tous les jours sans le moindre soucis jusqu'ici.
C'est simple et efficace. Ca manque juste un peu d'outillage.
http://kvm.qumranet.com/kvmwiki
[^] # Re: Bon à savoir
Posté par rarcel . Évalué à 1.
[^] # Re: Bon à savoir
Posté par Clément David (site web personnel) . Évalué à 3.
Pour le serveur c'est compréhensible, dans des mainframes ou en virtualisant chaque utilisateur, mais ces raisons ne sont pas valable pour le desktop.
Pour moi, le seul avantage (niveau desktop) c'est en programmation et pour cibler différentes architectures et la kvm ne tiens plus la route (utilisation de VT).
De plus pourquoi dans le contexte actuel de programmation, je veux dire par la l'utilisation accrue de Runtime (C#, Java), pourquoi ajouter encore une abstraction du matériel (cf dessous)?
Programme -> Runtime -> OS -> Virtual. -> Architecture
[^] # Re: Bon à savoir
Posté par wismerhill . Évalué à 10.
- Faire tourner un windows pour un programme dont on a absolument besoin et sans équivalent (ou pour des jeux).
- Tester un liveCD en cours de développement sans devoir redémarrer à chaque fois.
- Tester une nouvelle distribution sans devoir en faire une installation complète sur sa machine.
- Faire du développement kernel (dans une certaine mesure) sans risquer de tuer son système principal.
[^] # Re: Bon à savoir
Posté par Tonio (site web personnel) . Évalué à 2.
Je rappelle que dans toute société, l'activité qui prend plus de 50% des ressources est compta-paie-contrôle-RH (alors qu'ils représentent 10% des salariés). Ils ont des besoins spécifiques et critiques. Il n'y a pas de d'autres choix que de répondre positivement à leurs demandes....
Et donc on se retrouve avec des logiciels spécifiques dédiés sur un ou 2 postes voir 20 postes donc la meilleur solution pour assurer un plan de reprise et une qualité de service est de gérer les serveurs et d'offrir un affichage déporté... il n'y a pas d'autre solution!
# Virtualbox
Posté par Pol . Évalué à 10.
et n'oublions pas le très très bon virtualbox!
http://www.virtualbox.org/
[^] # Re: Virtualbox
Posté par finss (site web personnel) . Évalué à 5.
\_o<
[^] # Re: Virtualbox
Posté par KiKouN . Évalué à 4.
Il est vrai que VirtualBox est très bien pour la virtualisation Desktop, mais ne joue pas dans la même cours que Xen.
[^] # Re: Virtualbox... issu de qemu
Posté par AP . Évalué à 6.
[^] # Re: Virtualbox... issu de qemu
Posté par gvallee . Évalué à 2.
QEMU/Bosh sont toujours assez incontournables.
[^] # Re: Virtualbox... issu de qemu
Posté par Pinaraf . Évalué à 8.
Sources ?
Si tu regardes les informations sur l'organisation du code source de Virtualbox ( http://virtualbox.org/wiki/Source_code_organization ), tu découvres que du code de Qemu est utilisé certes, mais à un seul endroit :
src/recompiler/ contains a recompiler (emulator based on QEMU) for a few situations within VirtualBox. Essentially, all guest code runs natively on the hardware. The recompiler, however, steps in as a fallback when guest code disables interrupts and VirtualBox cannot determine when they will be switched back on; for single instruction execution on faults; for real-mode code (e.g. BIOS, DOS, operating system startup).
En clair, qemu n'est pas du tout à la base de Virtualbox, c'est utilisé uniquement à un endroit bien précis. Tout le reste c'est fait par Virtualbox et ça n'a rien à voir avec Qemu.
[^] # Re: Virtualbox... issu de qemu
Posté par gvallee . Évalué à 1.
Et puis de ce que j'ai pu comprendre du code de VirtualBox (mais je n'ai regarde que rapidement) du code de QEMU est aussi utilise pour la virtualization des devices. Donc pour des choses assez critiques au final... tout comme pour le support de la "full-virtualization" avec Xen (ce qui a mon avis ne pose pas de probleme en soit : quand quelque chose est de qualite, autant le reutiliser).
[^] # Re: Virtualbox... issu de qemu
Posté par Pinaraf . Évalué à 5.
Ça veut pas du tout dire la même chose.
Virtualbox n'a pas grand chose à voir avec Qemu.
Au passage, si tu fais un grep sur le code source de VirtualBox, c'est du copyright 2003 ou 2004. J'ai vu un fichier avec un copyright 2005. C'est du code de Qemu qui marche et qui n'a simplement pas besoin d'être modifié. Pourquoi réécrire le code qui marche quand il existe ?
Et pourquoi ne pas contribuer à qemu ? Parce que son code ne plaît pas, parce que sa structure ne plaît pas, parce que certains choix techniques peuvent être à l'origine de désaccords...
[^] # Re: Virtualbox... issu de qemu
Posté par galactikboulay . Évalué à 2.
Tu as des exemples précis à ce sujet ? Excepté la partie "dyngen" qui est un gros hack de la mort (mais qui marche) je vois pas trop ce qu'on peut lui reprocher.
[^] # Re: Virtualbox... issu de qemu
Posté par Pinaraf . Évalué à 0.
Je n'ai pas regardé le code de Qemu, mais personnellement je ne contribue pas à un projet dont le code ne me plaît pas. Et un code me plaît ou non selon des critères qui me sont propres, chacun voit le code à sa façon.
[^] # Re: Virtualbox... issu de qemu
Posté par pasBill pasGates . Évalué à 5.
Euh ouais, mais voir le code et le juger sans le voir, je sais pas, j'ai comme un probleme de comprehension...
[^] # Re: Virtualbox... issu de qemu
Posté par Pinaraf . Évalué à 0.
J'ai simplement donné des raisons pour lesquelles de nombreux projets pourraient être créés (et même sont créés) plutôt que de contribuer à qemu.
[^] # Re: Virtualbox... issu de qemu
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Virtualbox... issu de qemu
Posté par Pinaraf . Évalué à 3.
J'ai dit :
Et pourquoi ne pas contribuer à qemu ? Parce que son code ne plaît pas, parce que sa structure ne plaît pas, parce que certains choix techniques peuvent être à l'origine de désaccords...
On le refait en version bien diluée pour aider à la compréhension :
Et pour quelles raisons une personne pourrait décider de ne pas contribuer à Qemu ? Parce que le code de Qemu peut ne pas plaire à cette personne, parce que la structure de Qemu peut ne pas plaire à cette personne, parce que certains choix techniques effectués dans Qemu peuvent être à l'origine de désaccords avec d'éventuels contributeurs...
[^] # Re: Virtualbox... issu de qemu
Posté par gvallee . Évalué à 3.
Premierement, personnellement, je n'ai JAMAIS dis que VirtualBox etait une "simple modification" de QEMU, donc pas la peine de chercher la petite bete comma ca.
Et puis relis bien ce que j'ai ecris : "de ce que j'ai pu comprendre __du__ code de VirtualBox (mais je n'ai regarde que rapidement), __du__ code de QEMU est aussi utilise pour la virtualization des devices" (dans ma phrase originelle il manque une virgule apres la paranthese).
En quoi ta correction "si importante" change le sens de ce que j'ai dis? La il faut m'expliquer!
Ensuite comme je l'ai dis, le code pour la virtualisation des drivers est profondement fonde sur le code de QEMU (j'ai lu le code, c'est bien mieux qu'un grep), et la virtualisation des drivers est tout de meme l'un des composants central d'une solution de virtualisation. Tu refutes ce point egalement?
Je ne comprends pas non plus pourquoi tu sembles refuser absolument l'idee que VirtualBox a pu reutiliser du code de QEMU. Est-ce si important que ca? Je comprends que tu n'aimes pas QEMU (de mon cote, je n'aime pas trop KVM), mais de la a faire de la joute oratoire en deformant mes propos, je trouve que c'est un peu pousse.
Pour finir, exemple pris au hasard (et ce n'est qu'un exemple) : VirtualBox-OSE-1.4.0/src/VBox/Devices/Graphics/DevVGA.cpp
* This code is based on:
*
* QEMU VGA Emulator.
*
* Copyright (c) 2003 Fabrice Bellard
[^] # Re: Virtualbox... issu de qemu
Posté par Pinaraf . Évalué à 2.
(La précision concernait cette phrase : Il n'empeche que le code de QEMU/Bosh est reutilise dans la majorite des solutions de virtualization open source actuelles)
Dire que le code de VirtualBox pour les pilotes est profondément fondé sur le code de Qemu me semble exagéré, VirtualBox a ajouté des fonctionnalités (dans le cas du pilote graphique, y'a la possibilité de configurer la VRAM disponible, et j'ai vu dans leur bugtracker un travail effectué sur le support de la 3D, dispo uniquement avec un patch un peu "bâtard" pour Qemu (patch non intégrable dans Qemu donc))
Au passage, où as-tu vu que je n'aime pas Qemu ? Je l'utilise régulièrement, probablement plus que VirtualBox (qui refusait de marcher jusqu'à peu sur mon ordinateur portable, comme VMWare ou Xen. Qemu était le seul à marcher)
[^] # Re: Virtualbox... issu de qemu
Posté par gvallee . Évalué à 1.
Pour ma phrase "Il n'empeche que le code de QEMU/Bosh est reutilise dans la majorite des solutions de virtualization open source actuelles", cela reste vrai a mon avis. Par contre, je ne voulais absolument pas dire que toutes les solutions de virtualisation sont simplement une modification de QEMU. J'aurais du etre plus clair...
Je voulais seulement dire que la majorite les solutions de virtualisation reutilise du code de QEMU pour tout ce qui est virtualisation de devices, BIOS, etc... C'est d'ailleurs pour cela que j'ai dis QEMU/Bosh car si je me souviens bien du code que j'ai pu lire, pour l'emulation du BIOS, le code vient souvent de Bosh plutot que de QEMU. Je suis sur que quelqu'un avec des connaissances plus fraiches et pointues sur le sujet peut donner plus de details sur ce point.
Sinon j'ai suppose que tu n'aimes pas trop QEMU a cause de cette phrase : "Parce que son code ne plaît pas, parce que sa structure ne plaît pas, parce que certains choix techniques peuvent être à l'origine de désaccords..."
Mais c'est vrai que tu dis uniquement que tu n'aimes pas le code. Pas que tu n'aimes pas QEMU.
Personnellement je prefere Xen car c'est une solution de virtualisation de type-I [1] suivant la classification de Goldberg, i.e, l'hyperviseur s'execute directement sur le hardware, en opposition avec les solutions de type-II (QEMU, KVM) ou l'hyperviseur s'execute sur l'hote. Je trouve ca plus elegant et efficace.
[1] http://en.wikipedia.org/wiki/Hypervisor
[^] # Re: Virtualbox... issu de qemu
Posté par Pinaraf . Évalué à 3.
Attention, je crois, vu la note de mon commentaire, que cette phrase a porté à confusion : je voulais dire par là que la contribution à un projet libre est conditionnée à un point de vue personnel, et qu'on peut souvent réinventer la roue juste par désaccord avec le projet originel.
J'ai pas assez regardé le code de Qemu pour porter un jugement à ce sujet.
Sinon, pour le BIOS, il me semble que le BIOS utilisé par Qemu et Bochs est un BIOS libre, codé spécifiquement pour les émulateurs. Pareil pour le BIOS VGA... Par contre, comme ces BIOS sont liés à une certaine organisation derrière, de nombreuses similitudes seront obligatoires entre les projets les utilisant pour la carte graphique par exemple.
[^] # Re: Virtualbox
Posté par Tonio (site web personnel) . Évalué à 1.
Quand je parle de virtualisation, je pense à OS serveurs et non à OS desktop. Pour ma part, XEN et VMWARE inclut des fonctionnalités de contrôles et de supervision qui n'existent pas dans VirtualBox.
Concernant la virtualisation des OS Desktop, VirtualBox convient très bien, il n'y a aucun soucis. Tout comme la virtualisation de quelques OS serveurs, VirtualBox fait l'affaire mais sur un périmètre limité.
# Xen VS VMWare ?
Posté par GTS . Évalué à 2.
Du coup, vu que c'est le sujet du jour, j'ai une p'tite question.
VMWare, à ce que j'ai compris, permet avec leur solution d'utiliser un pool de serveur physique en tant que "ressources" pour un ou des serveurs virtuels.
C'est notamment ce qu'ils font avec les "lames" d'IBM. Je ne suis pas au courant de tous les détails, mais il me semble avoir compris qu'on pouvait faire la même chose avec une batterie de serveurs reliés en Ethernet.
Est-ce que Xen ( ou une quelconque solution OpenSource ) propose ce type de solution ?
[^] # Re: Xen VS VMWare ?
Posté par dark_moule . Évalué à 1.
C'est un moyen facile et rapide de faire de la répartition de charges.
[^] # Re: Xen VS VMWare ?
Posté par nodens . Évalué à 3.
Autrement dit, la version propriétaire.
Rien ne s'oppose vraiment à faire le même genre de chose avec la version GPL, vu que les fonctionnalités sont là : possibilité de faire de la migration de domaines en live à condition d'avoir un stockage partagé (et je crois que la migration live ne concerne pas encore les domU HVM, c'est à dire utilisant une virtualisation complète s'appuyant sur les extensions VT ou assimilé des processeurs récents), API permettant de controler les domU à distance... on a donc tout l'infrastructure nécessaire.
Après il n'y a plus qu'à déclencher les migrations en fonction des ressources disponibles et donc à avoir une idée de où est ton domU à un instant t... une sorte de scheduler de domU sur plusieurs serveurs physique en somme.... Tiens, c'est marrant, maintenant je comprend pourquoi ils arrivent à le vendre cher (et à augmenter les prix de 300% à 750% d'une version à une autre...) ;)
Bon si on veut simplement faire de la redondance et une répartition de charge "manuelle" il y a déjà tout ce qu'il faut, et il doit même y avoir des softs qui te font de jolies interfaces pour gérer tout ça comme XenMan.
PS: si quelqu'un arrive à faire ce genre de chose avec la version libre, ou si il y a des docs quelque part, autre que des slides succints que j'ai déjà vu, alors je suis *très* intéressé, même que je dois pas être le seul ;)
[^] # Re: Xen VS VMWare ?
Posté par brazz . Évalué à 3.
Pour VMWare (ESX) et tant pis si la société a réussi son introduction en bourse (d'ailleurs sur la rationalité de la bourse il y aurait à dire, on le voit en ce moment...) mais il faut voir qu'il y a depuis des années des fortes présomptions de piratage de la GPL (voir par exemple http://www.venturecake.com/the-vmware-house-of-cards/ ).
Il y aura peut être des surprises.
[^] # Re: Xen VS VMWare ?
Posté par dark_moule . Évalué à 2.
- http://www.enomalism.com/ et http://www.openqrm.org/
selon ce que tu veux faire.
Tu peux également essayer le livecd mis à disposition pour tester openqrm :
http://freshmeat.net/projects/openqrm-live-cd/?branch_id=685(...)
Quelques plugins ont déjà été intégrés.
Il est très complet, trop certainement pour ce que tu veux réellement faire mais ça te donnera une idée des possibilités.
Pour Xen je n'ai pas trouvé le livecd que j'ai utilisé pour faire mes tests mais je viens de voir ce projet : http://unit.aist.go.jp/itri/knoppix/xen/index-en.html
Leur site est très brouillon, j'espère que leur LiveCD sera bien mieux...
[^] # Re: Xen VS VMWare ?
Posté par nodens . Évalué à 2.
J'étais déjà tombé sur openQRM mais je ne sais pas pourquoi, j'avais eu l'impression que la version libre était assez limitée... en relisant les doc j'ai l'impression que je m'étais trompé, à creuser, donc.
Après, quand c'est juste pour gérer des domU pour faire des machines de test ou gérer un seul serveur, xen-tool sous debian et les commandes xm restent mes outils de prédilection ;)
[^] # Re: Xen VS VMWare ?
Posté par vincentxs . Évalué à 2.
Le concept de pool est avant tout de l'administration de machine du clusters et de migration de VM; Xen (l'hypervisor) n'a aucune idee des pools.
Disclaimer: je travaille pour XenSource.
# Grande question....
Posté par ragoutoutou . Évalué à 5.
Xen va t'il continuer sur sa trajectoire? Quels sont les plans de Citrix à son sujet? Les prochaines versions seront-elles libres? Le personnel de XenSource pourra t'il continuer à bosser sur Xen ou sera t'il réalloué à des tâche plus en rapport avec l'activité actuelle de Citrix? Comment cela s'intègre t'il dans la stratégie de Citrix?
# hyperviseur
Posté par Yves-Gaël Chény . Évalué à 2.
Espérons qu'un fork sera créé à ce moment.
Nantes_geek
---------------------------------------
www.antredugeek.fr/wiki
irc: irc.freenode.net #xenfr
[^] # Re: hyperviseur
Posté par rsystem . Évalué à 1.
je vois mal comment la techno disparaitrait.
je ne sais plus ou j'ai lu que XenSource allait se focaliser sur la techno de Microsoft (CodeName Viridian) et
fournir uniquement des "3rd party tools".
le code source de Xen dans ces dernieres version est en GPL.
donc selon les choix fait a l'avenir par Citrix/XenSource , à mon vis un fork apparaitra.
en tous cas une chose est sure, XenSource s'éloigne petit à petit du monde linux, XenCenter4 écrit en dotnet, accords de partenariat large avec microsoft, mise en place d'équipes de développement dédiées à Viridian .....
Wait and see :-)
[^] # Re: hyperviseur
Posté par Yves-Gaël Chény . Évalué à 1.
J'ai également entendu parler d'un noyau Windows paravirtualisable qui serait fourni/vendu par microsoft dans un avenir proche.
Mais ce ne sont que des bruits, quelqu'un peut confirmer ?
# Après Xen c'est au tour de ClamAV !!
Posté par nocode . Évalué à 1.
http://www.clamav.net/2007/08/17/sourcefire-acquires-clamav/
Et oui donc c'est SourceFire qui achète le projet ClamAV, en espérant qui joue le jeux du libre...
[^] # Re: Après Xen c'est au tour de ClamAV !!
Posté par Tonio (site web personnel) . Évalué à 3.
Si tu montes un projet OpenSource et que dans 2 ans on te propose 5 millions ¤ pour te racheter le nom et ton code tu fais quoi?
C'est l'offre et la demande. Il faut arrêter avec des pseudo peurs, il n'y a pas de problème d'éthique et de conscience vu que tout est GPL et que celui qui rachète doit rassurer 1/ les développeurs 2/ les futurs acheteurs
Si il y a un soucis, un fork sera crée et le marché choisira... la nature est bien faite!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.