Articles : Citrix Systems Inc. achète la société XenSource Inc.
Posté par Antoine Nivard (page perso, ). Modéré le 17 août 2007.
XenSource est l'éditeur de Xen, l'hyperviseur libre de machines virtuelles. Un accord de rachat de XenSource par Citrix a été signé par les deux parties il y a quelques jours. Cet accord est une réelle opportunité pour Citrix qui recherche des relais de croissances et des nouvelles technologies à mettre dans son portefeuille de solutions.
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 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.
XenSource (516 hits)
Annonce sur XenSource (323 hits)
Annonce sur Citrix (292 hits)
Citrix France (474 hits)
Santé financière de Citrix (393 hits)
VMware VI3 (477 hits)
> Lire la dépêche (41 commentaires, moyenne: 3,1).
Vous avez demandé le commentaire #859230.




Virtualbox
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.
et n'oublions pas le très très bon virtualbox!
http://www.virtualbox.org/
-Pol-
[^]Re: Virtualbox
Je plussoie vigoureusement d'autant plus que VirtualBox est aussi sous licence GPL, s'installe et fonctionne simplement.
\_o< Coin ! Coin !
[^]Re: Virtualbox
Et permet de relancer facilement une machine virtuelle depuis Windows.
Il est vrai que VirtualBox est très bien pour la virtualisation Desktop, mais ne joue pas dans la même cours que Xen.
KiKouN, Bucheron-Geek
[^]Re: Virtualbox... issu de qemu
Je me désole de ce que les efforts semblent se diluer. Xen a apporté sa pierre dans le domaine de la paravirtualisation... mais côté émulation de machines virtuelles complètes pour faire tourner l'OS sans modification, c'est la solution d'un qemu adapté qui a été retenue. Pour Virtualbox, ici encore on part sur une base de qemu qu'on peaufine et qu'on dote d'une belle interface graphique. Quant à KVM, qui, en soi, n'est qu'une extension du noyau, le seul émulateur s'appuyant dessus à ce jour c'est ? Un qemu patché... alors bien sûr le qemu "initial" profite petit à petit des évolutions de ses dérivés... mais trop lentement à mon goût. C'est sur lui qu'il faudrait travailler directement, plutôt que sur ses dérivés intégrés...
[^]Re: Virtualbox... issu de qemu
Je suis tout a fait d'accord d'autant plus que meme en utilisant Xen avec le support hardware pour la virtualization (full-virtualization, i.e. ne pas avoir a modifier l'OS), on se retrouve... avec du code de QEMU.
QEMU/Bosh sont toujours assez incontournables.
[^]Re: Virtualbox... issu de qemu
Virtualbox issu de qemu... Un "peaufinage" ?? Woaw, ça c'est de l'information.
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
Il n'empeche que le code de QEMU/Bosh est reutilise dans la majorite des solutions de virtualization open source actuelles, et je pense que c'est ce point qui est interessant.
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
Correction importante : du code de Qemu et/ou bochs est réutilisé.
Ç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
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
Pourquoi devrais-je avoir des exemples ?
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
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.
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
L'ai-je jugé ? Non.
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
Ben un peu quand meme, tu as dit que le code ne te plaisait pas, j'ai du mal a imaginer comment tu peux savoir qu'il ne te plait pas sans l'avoir vu.
[^]Re: Virtualbox... issu de qemu
Non, je n'ai pas dit qu'il ne me plaisait pas.
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
Desole mais la tu modifies mes propos.
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
Désolé, j'avais pas fait gaffe aux noms. C'est surtout après l'auteur de ce commentaire que j'en avais : http://linuxfr.org/comments/859230.html#859230
(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
Si il y a eu confusion de personne, tout s'explique. :-)
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
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..."
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
Je comprends bien que cela est bizarre que je ne parle pas de virtualbox.
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é.