ESXi 6.5 : migration à chaud via vMotion

Introduction et mise en place du service vMotion de chez vSphere.

vMotion est un module de vSphere très connu et permettant donc de faire de la migration à chaud de VMs, comprenez par là que la machine pourra être migrée d’un hôte à l’autre sans coupure de service. Nous avions déjà testé ce concept sur Proxmox (article ici pour les plus curieux) et aujourd’hui c’est donc le tour de VMware, en sachant que certaines notions sont identiques ou presques.

I) Pré-requis et présentation du lab

Ici rien de très complexe, nous aurons deux hôtes ESXi en version 6.5 :

• ESXi-01, en 192.168.1.100/24 ;
• ESXi-02, en 192.168.1.110/24 ;
• VCSA sur ESXi-01, en 192.168.1.120/24 ;

Il vous faudra donc les avoir préalablement installés, je ne vais pas revenir dessus car d’autres articles sur le blog en parlent déjà, et de même pour le vCenter (ou VCSA, qui n’est ni plus ni moins que l’appliance Linux du vCenter).

Une fois que ce setup est fait, il convient de se connecter sur le fameux VCSA pour créer un centre données puis un cluster, et y rajouter nos deux hôtes, c’est relativement trivial.

Ensuite, on rajoute une carte réseau sur chacun de nos hôtes. Pourquoi ? Et bien car la bonne pratique (comme pour Ceph avec Proxmox par exemple) consiste à utiliser un réseau dédié pour mieux gérer les flux relatifs au vMotion. Nous aurons donc :

• 192.168.1.0/24, réseau « classique » pour nos hôtes et VMs ;
• 192.168.2.0/24, réseau vMotion où transiteront les informations par rapport à ce dernier ;

Bien entendu, en entreprise, on peaufinera les réseaux utilisés pour ne pas gaspiller des IPv4 inutilement, et on créera des VLANs pour nos VMs et pour gérer nos hôtes, mais le but ici est de bien cerner ce qu’est vMotion donc restons au plus simple 😉

II) Un stockage pour les gouverner tous

La seconde étape est de configurer un datastore accessible par les membres de notre cluster, ici aussi, c’est identique à Proxmox. Cela peut donc être un partage réseau d’un disque dur de l’un de nos hôtes ou bien comme nous allons le faire ici un simple partage NFS sur un FreeNAS, qui sera donc ajouté sur nos deux hôtes. Vous l’aurez compris, tant que c’est accessible par les membres du cluster, le protocole utilisé importe peu.

Une fois votre stockage réseau mis en place, on peut poursuivre !

III) Configuration des interfaces pour le réseau vMotion

Comme dit précédemment, nous avons rajouté une interface réseau sur chacun de nos hôtes ESXi, maintenant il convient de les configurer pour ensuite pouvoir mettre en place le vMotion.

On créer tout d’abord un nouveau commutateur virtuel, basé sur notre seconde carte réseau (classique). Ensuite, on se rend donc dans Mise en réseau, puis NIC VMkernel et enfin Ajouter une NIC VMkernel :

Ici rien de très sorcier, on nomme notre nouveau groupe de ports (ici nommé sobrement vMotionPorts), on choisi sur quel switch virtuel il sera créé (ici le vSwitch vMotion, celui créé juste avant donc) puis on peut setup une IP statique et pour la partie Pile TCP/IP on peut choisir Pile vMotion.

Vous devriez obtenir ceci, et il convient de faire la même manipulation sur les autres hôtes de votre cluster, en changeant forcément l’IP de l’interface réseau :

IV) Le fameux test

J’ai installé rapidement un petit CentOS 7 avec comme IP 192.168.1.66/24 et stocké sur notre partage NFS, ensuite je lance un ping en continu et désormais si l’on se rend sur notre vCenter (et pas un de nos hôtes ESXi !) on peut clic droit sur la VM en question et l’option Migrer apparaît :

Concernant les warnings affichés n’en tenez pas compte, c’est dû à mon lab personnel ; j’ai activé la fonctionnalité HA sans l’avoir encore configurée, donc rien d’important 😛

On peut donc ensuite choisir le type de migration souhaitée :

*Petite note ma foi assez importante: vous ne pouvez migrer une VM que si celle-ci a les VMware Tools d’installés, et pas ceux de OpenVM-Tools, mais bien ceux du CD… et oui, c’est comme ça…

En cliquant en haut à droite on peut savoir où se trouve la dite VM (bien pratique) :

On choisi donc l’hôte sur lequel on va migrer la VM :

Un éventuel réseau différent :

Définir la priorité par rapport à cette opération, est-ce que cette VM est vraiment vitale (AD par exemple) ou au contraire ce n’est pas quelque chose de très important :

On a ensuite le classique résumé des opérations à effectuer, et on peut valider !

Comme on pouvait s’y attendre, aucune coupure et la VM a bien changé d’hôte, c’est donc une réussite. Concernant la vitesse et les performances en général, je ne peux pas faire de parallèle avec Proxmox car nous étions avec du Ceph et ici du simple NFS, puis la taille de la VM n’était pas la même et ainsi de suite… seul point noir pour moi c’est l’obligation d’installer les VMware Tools, et ceux « officiels » qui plus est, impossible d’utiliser les
open-vm-tools comme dit plus haut.

Cet article est donc terminé, comme d’habitude j’espère vous avoir fait découvrir certaines choses et je vous prépare d’ores et déjà un article sur la mise en place de la HA côté Vmware, on verra si c’est aussi simple que pour Proxmox haha 😉

Bonne journée/soirée à vous !