Steve Wilson, Sun : « notre hyperviseur n'aura pas de limites »

Sun avait à l'origine annoncé xVM Server pour la fin du mois de mai, mais il semble que ce sera plutôt pour le début de l'été?

Steve Wilson : Effectivement, la bêta de xVM Server 1.0 devrait arriver fin juin ou début juillet, même si, par prudence, nous annonçons une disponibilité pour cet été. La version finale devrait quant à elle arriver à la fin de l'été ; disons vers la fin du mois d'août. xVM Server sera sous la même licence open source que Solaris (la licence Sun CDDL ou cuddle, NDLR) tandis que la console d'administration sera sous licence GPL v3.

En quoi consiste exactement xVM Server?

S.W. : A l'instar d'ESX Server, d'Hyper-V ou de Xen Server, xVM Server est l'hyperviseur de Sun. C'est un produit autonome : La base technologique est une combinaison entre Xen et Solaris. Nous avons ajouté un certain nombre de technologies destinées à simplifier l'administration, ainsi qu'un jeu complet de pilotes para-virtualisés pour supporter la plupart des grands OS du marché. Le savoir-faire d'Innotek dans le développement de tels pilotes est l'une des raisons de l'achat de cette société en plus de ce qu'elle nous apporte sur le poste client.. C'est Innotek qui a développé les pilotes para-virtualisés d'xVM Server.

xVM Server embarque un agent qui permet de gérer l'hyperviseur au travers de notre outil d'administration xVM Ops Center ou de tout autre outil supportant WS Management. Nous travaillons ainsi avec plusieurs éditeur tiers qui supporteront l'administration d'xVM Server depuis leurs propres outils de gestion d'environnements virtuels. Pour les déploiements plus simples, où il ne faut administrer qu'un seul serveur, xVM Server dispose d'un serveur web embarqué qui expose une console web relativement sophistiquée réalisée en Ajax. Cette dernière permet de gérer le serveur et les environnements clients qu'il héberge. Par rapport aux solutions de VMware ou de Citrix, cette solution présente l'avantage de ne pas nécessiter de logiciel client propriétaire pour administrer le serveur. Un simple navigateur suffit et on peut effectuer l'administration depuis n'importe où. Seul l'accès en mode console aux machines virtuelles requiert un plug-in VNC.

Quelles seront les limites d'xVM Server en matière de nombre de processeurs supportés et de nombre de cœurs par machine virtuelle ?

S.W. : Il n'y a aucune limite. Nous sommes Sun Microsystems, ce genre de limites n'est pas une habitude pour nos clients.

xVM Ops Center est pour l'instant limité à l'administration des seuls serveurs physiques. La version 2.0, qui arrivera avec xVM Server, supportera les environnements virtuels. Quelles fonctions proposera-t-elle ?

S.W. : xVM Ops Center arrivera entre 30 et 60 jours après xVM Server. Avec cet outil, nous pourrons gérer à la fois des serveurs physiques et logiques, mais aussi effectuer la gestion de correctifs sur les deux types de serveurs (tout d'abord sous Linux et Solaris, puis dans une mise à jour ultérieure sous Windows, NDLR). xVM Ops Center permettra aussi de gérer la notion de pool de serveurs, ce que nous appelons un Vpool. Un Vpool est en fait une collection de nœuds physiques qui ont accès au même réseau et aux mêmes ressources de stockage. On peut faire des migrations dynamiques de machines virtuelles d'un nœud d'un vpool à l'autre, car on est sûr de l'homogénéité de leurs ressources.

La console xVMOps Center 2.0 proposera aussi des fonctions d'analyse de performance. En temps réel mais aussi en décortiquant en profondeur les données historiques. Dans un premier temps, nous analyserons des métriques génériques (consommation CPU, mémoire, disque, réseau…), mais à terme nous prévoyons d'utiliser Dtrace pour offrir une bien plus large palette de métriques. Cela viendra dans une future version. On imagine même des scénarios où, grâce à Dtrace, on pourra aussi analyser ce qui se passe à l'intérieur d'une machine virtuelle. Nos ingénieurs sont convaincus que cela est possible même pour Windows.

Vous avez retenu vmdk comme format de disque pour les machines virtuelles. Pourquoi ?

S.W. : Ce sera notre format par défaut, mais nous supporterons aussi nativement le format xva de Xen. Dans une prochaine version, nous prévoyons aussi d'ajouter le support du format VHD de Microsoft. Même si, sur ce point, je suis incapable de fournir un calendrier précis. Le choix du vmdk comme format préféré fait sens pour nous, dans la mesure où la plupart des clients qui utilisent aujourd'hui la virtualisation sur des serveurs x64 utilisent ce format. Cela simplifiera les migrations. Par défaut, xVM Server 1.0 utilisera ZFS comme système de fichier et nous préconisons l'usage de NFS et de CiFS pour le stockage en réseau. La prochaine mouture de xVMServer supportera iSCSI et Fibre Channel.

Quelles sont les autres améliorations prévues pour la prochaine mouture de xVM Server ?

S.W. : La seconde version de xVM Server, qui arrivera un peu plus tard dans l'année, intégrera le code du projet Crossbow (une nouvelle pile réseau pour Solaris, NDLR). Elle permettra de faire de l'allocation sophistiquée de ressources réseaux, mais aussi de créer des routeurs virtuels, des ponts virtuels, des réseaux virtuels entre machines elles-mêmes virtuelles ou d'allouer des priorités de trafic à chaque VM (machine virtuelle, NDLR) cliente sur une ressource réseau. C'est un point sur lequel nous pensons avoir rapidement de l'avance sur nos concurrents. D'ailleurs, avec l'inclusion de Crossbow dans xVM Server, nous proposerons aussi une nouvelle génération de pilotes para-virtualisés capables de tirer parti des capacités de Crossbow depuis les machines virtuelles.