Migration d’un port vmkernel d’un virtual switch standard vers un virtual switch distribué

Aujourd’hui j’ai rencontré la problématique suivante: J’ai voulu migrer le port vmkernel dédié au management traffic d’un virtual switch standard existant vers un virtual switch distribué depuis le vSphere Client mais cela n’a pas fonctionné correctement.

La procédure en temps normal est de s’assurer d’avoir une redondance réseau (nic teaming) au niveau du vmkernel portgroup du Vss avant de procéder à la migration vers un dvportgroup d’un vDs. On rajoute le host depuis l’interface Networking (Home -> Networking) du vSphere Client en prenant le soin de sélectionner une seule des deux cartes réseaux faisant partie du nic teaming pour le port vmkernel à migrer vers le vDs. Malheureusement lors de cette phase de migration, la carte réseau à migrer avec la configuration IP du vmkernel se retrouve systématiquement sur le premier DvUplink créé sur le vDs ; or ce DvUplink1 n’a pas la bonne configuration associé pour le management traffic (Vlan ID). Le host se retrouve alors dans un état isolé et n’est plus joignable.

Pour résoudre ce problème et migrer correctement son port vmkernel sur le dvportgroup correspondant au management traffic, il faut passer par une remote console (de type KVM ou iLO) et activer le local tech support mode puis faire alt+F1 pour passer en mode support. Une fois en mode support, faites un esxcfg-vswitch -l pour lister la configuration active des switchs virtuels standard et distribués.

Vous verrez alors un DVport ID attribué pour un client de type vmk0 (qui correspond au vmkernel management traffic) et la carte réseau attribué au premier DVPort ID (attribution réalisée de façon automatique lors de la tentative précédente de migration via le vSphere Client). Il faudra alors réattribuer la carte réseau du premier DVPort ID au DVPort ID correspondant au DVportgroup du management traffic (avec la bonne configuration VLAN associée)

Procéder alors comme suit :

1) esxcfg-vswitch -Q vmnic -V DVPortID_1 dvSwitch_name (permet de retirer la carte du DVPort ID mentionnée par DVPortID_1 )

2) esxcfg-vswitch -P vmnic -V DVPortID_mgmt_traffic dvSwitch_name (permet de réattribuer la carte réseau au DVPortID correspondant au DVPortgroup du management traffic sur le vDs)

Le host ne se retrouve plus isolé et vous avez correctement réalisé la migration de votre port vmkernel d’un switch virtuel standard vers un switch virtuel distribué.

Sortie de VMware vSphere 5 !!!!

En ce jour qu’est le 12 Juillet 2011, VMware sort enfin la version 5 de vSphere.

Au programme de cette nouvelle version de vSphere :

– Des machines virtuelles pouvant aller jusqu’à 1To de mémoire, 32 vCPUs

– Une refonte de VMware HA avec la notion de master/slave pour les nodes (il n’y a plus de notion de primary nodes limités à 5 primary). AAM n’existe plus, place à FDM (Fault Domain Manager)

– Storage DRS (on peut créer un cluster de datastores et tout comme DRS, sDRS se chargera automatiquement de migrer les données sur des datastores en fonction de l’occupation et de la charge IO)

– Profile-Driven Storage (création de profils de données spécifiques pour les machines virtuelles ; ceci permettra notamment en connaissant les besoins en terme de données ou d’IOps pour une machine virtuelle donnée d’y affecter un profil spécifique)

– vStorage API (amélioration du VAAI avec possibilité de réclamer l’espace perdu lors de suppressions de machines virtuelles sur un datastore)

– Stateless (possibilité de lancer des installations d’ESXi 5 en diskless et d’avoir une seule version qui sera patché et maintenu grâce à vCenter pour ensuite être massivement déployé sur l’ensemble des serveurs ESXi 5 de vos environnements)

Il y a encore plein d’autres nouveautés avec cette version majeure de vSphere !!! Je reviens vers vous très vite pour partager tout ça…

VMware rules !!!!!

VMware GO pour ESXi 4

Depuis Janvier 2010, VMware a sorti un produit du nom de VMware GO permettant de gérer les serveurs sous VMware ESXi 4. Il s’agit d’une console web qui permet d’initialiser et de patcher les serveurs ESXi 4, de créer et exploiter les machines virtuelles, appliquer les patchs aux VMs. Ce produit s’installe comme une application hébergée sur une machine Windows XP SP3, Vista SP2 ou encore Seven et est ensuite utilisée comme un proxy vers les serveurs VMware ESXi 4.

Les composants logiciels suivants sont nécessaires pour le bon fonctionnement de VMware GO :

– Microsoft .NET framework
– PowerShell
– VMware vSphere Power CLI
– La Remote Console
– VMware Converter Stand-Alone

Cette semaine, VMware a annoncé l’ajout de nouvelles fonctionnalités pour son produit VMware GO ; parmi ces nouvelles fonctionnalités on retrouvera :

– La possibilité de réaliser du Virtual to Virtual (V2V)
– La migration de VMware Server vers ESXi (Pour information, en juin 2011 VMware Server ne sera plus maintenu par VMware)
– Le Collective Intelligence Engine qui permettra de collecter des informations depuis la communauté des utilisateurs afin de proposer des préconisations sur les OS Guests installés sur ESXi, le nombre de VMs par ESXi, le top 5 des appliances installées,…

Pour plus d’informations sur VMware GO, n’hésitez pas à aller sur leur site.

En bonus, je vous donne également le lien vers une Training video de David Davis expliquant comment implémenter et utiliser VMware GO pour ESXi 4.0 :

VMware Go – The On Ramp to Virtualization