Conseil

Configurer un lab vSphere à base d'hyperviseur imbriqué

Un laboratoire vSphere créé à base d'hyperviseur embarqué est plus stable et moins gourmand en ressource qu'un lab à base d'hyperviseur de type 2 comme VMware Workstation.

Christophe Bardy
par
Publié le: 20 oct. 2014

Bâtir un laboratoire de virtualisation à la maison permet aux professionnels de l’IT ou aux étudiants de tester les dernières technologies quand ils le souhaitent et sans risque pour leur environnement de production.

Il y a plus d’une façon de bâtir un laboratoire VMware à la maison. Une des options qui s’appuie sur les capacités de virtualisation imbriquée de vSphere n’est pas forcément supportée par VMware et permet de tester les fonctions avancées de vSphere 5.1 avec une faible surconsommation de ressources.

Comme le confirme Matt Kozloski, en charge de la virtualisation chez Kelser Corp et président de groupe utilisateurs VMware, disposer d’un laboratoire vSphere 5.1 peut être extrêmement utile pour des administrateurs préparant le test de certification VMware Certified Professional.

Kozloski a accepté de partager ses conseils pour la mise ne place d’un laboratoire vSphere 5.x avec un hyperviseur imbriqué durant une réunion de son groupe utilisateur. Des conseils que nous reproduisons aujourd’hui

Bâtir un laboratoire à la maison

Un hyperviseur imbriqué est un hyperviseur fonctionnant dans une machine virtuelle tournant elle-même au-dessus d’un hyperviseur. Kozloski a opté pour cette solution plutôt que pour une solution à base VMware Workstation car ce dernier dépend d’une couche OS additionnelle et que sa couche de translation NAT peut être parfois susceptible. L’utilisation d’un hyperviseur imbriqué peut être plus compliquée mais cela fait partie du jeu indique Kozloski.

L’utilisation d’un hyperviseur imbriqué peut être plus compliquée mais cela fait partie du jeu.

Matt Kozloski

Pour débuter avec votre lab, installez la version d’évaluation de VMware vSphere sur votre machine. Cette dernière doit répondre aux exigences minimales de vSphere et Kozloski recommande d’utiliser des CPU intégrant les spécifications Intel EPT ou AMD RVI pour les clients 64-bit.

 

"Conservez vos disques durs pour créer les volumes VMFS destinés à stocker vos VM et utilisez plutôt une clé USB pour installer vSphere. Comme le lab s’appuie sur vSphere, la stabilité est au rendez-vous, mais rappelez-vous que la configuration imbriquée n’est pas forcément supportée et que vous pourriez être confrontés à des messages d’alerte (Figure 1). Toutefois, ces derniers, ne vous empêcheront pas d’utiliser le laboratoire imbriqué.

Figure 1. Ce message d'erreur indique que la virtualisation imbriquée n'est pas supportée par le CPU. Mais celà n'empêchera pas le lab de fonctionner.

Quelles spécifications techniques pour le lab?

Le laboratoire vSphere imbriqué requiert à minima une machine avec deux CPU et capable d’allouer un minimum de 2 Go de RAM par VM comprenant les deux hyperviseurs embarqués dans des VM. D’un point de vue réaliste, une machine avec 16 Go de RAM ou plus est recommandée afin notamment de pouvoir faire tourner sans souci l’hyperviseur maître, les deux hyperviseurs imbriqués, quelques VM et la console vCenter.

 

À partir de VMware vSphere 5.1, il n’est pas nécessaire d’activer les fonctions d’hyperviseur embarqué et il est possible d’utiliser des VM 64 bit dans votre hôte vSphere.

 

Pour mettre à disposition un stockage partagé dans votre lab personnel, créez des disques VMDK partagés. La mise en œuvre de VSAN est consommatrice de ressources. Kozloski recommande donc de préférer une solution à base d’un disque SAS partagé. Le stockage SAS partagé évite l’overhead et rend possible un environnement de type « multi-write » normalement non autorisé par VMFS (le file system est conçu par défaut pour empêcher plusieurs VM d’écrire sur le même fichier. vmdk, même si l’option multiwriter permet de faire sauter cette limitation).

Pour économiser de l’espace si vous utilisez des disques SSD, vous pouvez aussi créer ce que Kozloski appelle des clones liés manuels : « construisez un VMDK de base, puis faites un snapshot et réalisez autant de copie que nécessaire de ce snapshot ». Ces dernières sont désormais des deltas du VMDK parent. Utilisez ces VMDK différentiels pour vos nouvelles VM ». Méfiance toutefois : il ne faut surtout pas effacer le VMDK parent.

Kozloski recommande de créer un sous-réseau pour votre hyperviseur imbriqué. Cela permet de créer un « pod portable » relié au réseau physique par des commutateurs virtuels et isolé dans une bulle réseau privative. Des outils de routage et de firewall comme Vyatta peuvent être utilisés pour contrôler le trafic entrant et sortant dans les VM clientes. Pour connecter les VM imbriquées, activez le mode promiscuité vers le réseau physique sur le commutateur virtuel.

 

Il y a deux options pour fournir un adaptateur réseau aux hyperviseurs embarqués : l’usage du VMXNET3 de VMware ou celui de l’E1000, qui émule une carte Gigabit Ethernet Intel 82545EM. Kozloski préconise plutôt l’usage de l’E1000, moins sujet à des plantages. Mais il indique que VMXNET3 ne pose pas de souci dans les VM hébergées au-dessus des hyperviseurs imbriqués.

A.

Figure 2. Voici à quoi ressemble le système hôte (A) et comment le cluster imbriqué apparaît (B).

Images fournies par Matt Kozloski.
 

B.

 

Pour approfondir sur Virtualisation de serveurs