Passez de VMWare à HyperV ? Est ce un projet finger in the nose ? Part 2

Bonjour à tous,

Voila déjà plusieurs mois depuis mon 1er article sur la migration

Vmware -> Hyper V que vous pouvez retrouver ici. Nous allons essayer de répondre intelligemment à ces quelques questions.

J’ai maintenant un peu plus de corde à mon arc pour vous en parler puisque cette migration (environ 250 machines virtuelles réparties sur plusieurs fermes ESX) est sur le point de se terminer en douceur d’ici fin d’année 2015.

 

1. Y a t-il un intérêt à changer d’hyperviseur ?
2. En pratique, est ce faisable ?
3. A quel prix ? changement de matériel, formation, licence …
4. Quels problèmes va t’on rencontrer ?
5. Peut on se passer de SCVMM 2012R2 ?
6. La gestion de la haute dispo est elle équivalente voir meilleur que sous ESX ?
7. IDEM pour la live migration – vmotion

 

Y a t-il un intérêt à changer d’hyperviseur ?

Oui ! en tout cas dans notre cas, effectivement nous sommes une équipe de Windowsien et mettre les mains dans le cambouis dans un environnement FULL Microsoft apporte plus de compréhension, de facilité, d’autonomie et de visibilité à l’hyperviseur et l’ensemble des outils qui oscille autour de lui, pour ne pas les citer: la suite System Center 2012R2 avec Virtual Machine Manager, Data Protection Manager, Opération Manager, Orchestrator. La réponse aurait été la même si nous étions Linuxiens avec le souhait de remplacer Hyper-v par la solution VMWare.

Pour le coté financier, je ne peux hélas pas m’étaler, je n’ai pas eu à gérer cette partie, de plus chaque société dispose de ces propres partenariats que ce soit avec Microsoft, Vmware, CISCO et j’en passe, et en fonction, elle pourra avoir des tarifs plus ou moins compétitifs.

En pratique, est ce faisable ?

Oui ! mais non sans difficultés et son lot de surprise\blocage technique, ca prend également du temps, beaucoup de temps en fonction du nombre de VM à déplacer et du nombre de personne en charge de la migration. L’aspect « production » n’est pas à négliger, il est effectivement plus facile de migrer 30 machines virtuelles de qualité de dev de recette que de déplacer 5 vm de production que vous aurez à migrer en HNO avec le stresse d’espérer que tout se passe bien et avec un impact utilisateur proche du zéro absolu.

Sans trop exagérer j’ai le sentiment que chaque vm à ses particularités, son histoire, ses défauts …. voir un peu plus bas dans « Quelle problème va t’on rencontrer? ».

C’est génial de débuter la migration mais il faut également penser à sauvegarder les VM qui arrivent, au fil des migrations, sur l’environnement Hyper V, à les monitorer à nouveau etc .. il faut également prendre son temps et vérifier que le nouveau matériel absorbe bien la charge. Pensez à surveiller les IOPS et les temps de latence de votre SAN.

A quel prix ? changement de matériel, formation, licence …

Dans nos cas, le prix qu’impose l’achat de nouveaux serveurs DELL R630 avec double CPU E5-2667 v3 3.2Ghz, la RAM qui va bien (256Go sur chacun de nos 6 noeuds Hyper V), les switch CISCO dédiés au réseau ISCSI, les nouveaux SAN (NETAPP), il est difficile de prévoir au plus juste mais avec marge le dimensionnement d’une plateforme Hyper V. Faire en sorte que si un serveur crash, les autres tiendrons la charge supplémentaire le temps de le remonter. Une toute petite précision nous sommes effectivement partis sur une connectique de stockage à moindre coût, celle de l’ISCSI mais je ne vais pas plus m’étaler sur les choix d’infrastructure ici.

pour les licences nous utiliserons naturellement des licences Windows 2012R2 DC pour un nombre de VM illimité.

pour la formation, si il n’y a pas de compétence en interne, c’est plus prudent de se faire accompagner ne serait ce que quelques jours par une société externe, aussi bien pour la configuration du cluster Hyper V que pour la partie SAN et l’interconnexion des deux.

Heureusement ce n’était pas mon cas j’ai pu mener à bien ce projet et partager avec mes collègues mes idées, mes craintes, mes solutions de contournement.

Quels problèmes sommes nous susceptible de rencontrer ?

Alors il était difficile de deviner ce qui allait nous tomber dessus même avec un audit poussé. Mais avec le recul c’est tout de suite plus facile de vous en parler, surtout quand c’est encore tout chaud.

Dans un premier temps il y a la question de comment migre t on les données présentes sur un vmdk (vmware) en vhd(x) (hyper V)

Les serveurs ne sont pas les mêmes, les SAN ne communiquent pas entre eux, les technology de virtualisation sont différentes, idem pour les réseaux virtuels.

Il y a heureusement plusieurs options (non exhaustives j’imagine) mais avec ca vous devriez pouvoir vous en sortir.

La première vous passez par System Center Virtual Machine Manager 2012R2, mais là encore ca ne se fera pas à chaud ce qui implique un arrêt de production et c’est long …. très long …. très très très long…. pour avoir un ordre d’idée une douzaine d’heure pour une VM de 50Go. Il faudra également au préalable dégager le vswitch de la vm coté Vmware sans quoi SCVMM ne voudra pas la déplacer même éteinte.

Une fois terminée, la vm ayant été créée dans Hyper V vous n’aurez plus qu’à configurer la partie switch de la vm et reconfigurer l’@IP. Normalement SCVMM récupère l’ensemble des information de configuration, exemple RAM CPU. L’avantage est qu’il y a très peu de manipulation humaine. L’inconvénient étant la lenteur de l’opération.

La deuxième vous récupérez le(s) vmdk depuis le datastore puis vous le(s) convertissez en vhd(x) avec StarWind V2V Image Converter par exemple. La récupération du VMDK est également très lente. De l’ordre de 6-8Mbits/s. J’espère pour vous que si vous utilisez cette méthode vous aurez des meilleurs débits.

Là encore vous devez faire cela OFFLINE mais ca va ceci dit plus vite qu’avec SCVMM, vous aurez cependant besoin de reconfigurer entièrement la VM (vcpu, ram, remapper les vhd, etc ..). Si vous voulez éviter d’avoir à reconfigurer la VM, vous pouvez détacher tous les vmdk de la vm ESX et la migrer « vide » via SCVMM (premiere méthode).

Vous pouvez si la vm et l’application qu’il y a dessus le permettent cloner la vm ESX et ainsi récupérer le vmdk sans toucher à la vm encore en production. C’est possible si le delta entre le clonage -> la copie du clone ->  la conversion puis la création de la vm coté hyper-v peuvent être perdue, exemple un site web (blog ?) sur lequel tout le monde s’accorde à ne plus faire de modification le temps de la maintenance

Si toutes ces opérations vous prenne du temps, attention au redémarrage de la VM, il se peut qu’elle ne soit plus synchroniser avec votre AD. Il faudra alors réinitialiser le compte Ordinateur du serveur dans Active Directory, sortir la VM du domaine et rejoindre celui ci.

Troisième solution et c’est ma préférée, Disk2vhd, un petit utilitaire « efficace » de microsoft qui permet à la suite d’un snapshot de copier la vm vmware à chaud en .vhd sur un lecteur réseaux. Il ne vous reste plus qu’à créer la vm coté hyperV en pointant sur le vhd et ca boot. Quand vous êtes prêt, vous déconnectez le réseaux coté vmware de la vm encore allumée et vous activez le vswitch coté hyper-v. Il faudra en amont reparamétrer l’@IP sur la VM hyper V. Ce type de conversion, même rapide peuvent poser un problème si le delta entre l’opération disk2vhd et la mise à dispo de la vm sous hyper v prend trop de temps au risque de perdre des données, exemple une vm hébergeant une base de donnée.

Si on veut éviter une corruption de base de donnée, il est plus sage d’arrêter certains services avant le snapshot. (exemple SQLSERVER)

C’est également le seul outil à ma connaissance capable de récupérer le contenu d’un RDM. Petit bémol cet outil fonctionne qu’avec une VM source Windows. Pour les linux faudra passer par la solution 1 ou 2 ou 4.

En toute franchise j’ai déplacé 98% des VM Windows avec Disk2VHD.

Quatrième solution que je viens de découvrir post migration ………………….

Microsoft Virtual Machine Converter.  Je vais le tester ces prochains jours et vous faire un retour.

mais il semblerait que cet outil permet la migration à chaud des vm windows et linux selon la version installée. il est également capable de déinstaller les vmware tool et ce de façon entièrement automatisée.

Il permettrait aussi le P2V. Module disparue de VMM2012R2

ci dessous le snapshot réalisé par MVMC

le suite de la migration, à mon grand étonnement, la VM source n’était pas accessible pendant la période de conversion, l’OS source était pourtant un Win 2008R2Sp1

 

Fin de la migration

ce n’est pas terminé, il faut ensuite configurer le réseaux virtuel de la VM et installer les services d’intégrations. Pour le délais je n’ai pas été bluffé. Encore une fois Disk2VHD est en tête mais la migration n’étant pas une course, ces différentes possibilités de migration peuvent vous attirer.

 

Peu importe de quelle maniere vous allez vous y prendre profitez en pour nettoyer la vm, les TEMP, les LOGS, les user Profils, les SoftwareDistribution directory, etc … ca sera toujours ca de moins à copier, on peut facilement récupérer une dizaine de Go. Ceci étant attention à ne pas abuser du nettoyage, garder en tête que si la migration se passe mal vous serez rassuré de pouvoir redémarrer la vm vmware le cas échéant en l’ayant laissée quasi intacte.

Ci dessous, une liste des problèmes rencontrés:

bon à savoir\retenir également -> https://technet.microsoft.com/en-us/library/dn792027.aspx

• L’application ne démarre pas correctement, effectivement dans certain cas, les licences sont basées sur les @mac des serveurs! il vous suffira de reporter l’@mac de la vm ESX à celle d’HyperV.
• Version windows non supportée (cf lien du dessus) -> impossible d’installer les services d’intégration, pas de réseau, pas de souris -> Service Pack à installer soit sur la VM déplacée via un ISO soit sur la source mais opération de migration à refaire et impact prod.
• Version linux non supportée -> pour que la vm dispose d’une connection on va devoir passer un « legacy network », pas le choix -> baisse des performances réseaux. Je ne suis pas capable de juger de la baisse de perf, si elle existe vraiment et encore moins sa valeur en %. j’ai meme vue des VM linux refusant de booter tant que je n’avais pas retiré la carte réseau ou mis une carte virtuelle de type « Legacy network »
• Perte du mdp admin local windows -> impossible d’installer les services d’intégration, refaire la migration en modifiant le mdp sur la VM source. C’est tout bête mais ca m’est arrivé … en effet vous avez beau vous etre logé en domain admin sur la vm avant la migration, je me suis vue refuser l’installation des services d’intégration et donc pas de détection de carte réseaux
• internal error lors de l’installation des services d’intégration sur un win2008Sp2 par exemple. solution qui a fonctionné pour moi -> https://srvcore.wordpress.com/2010/05/28/integration-components-setup-error-an-error-has-occurred-internal-error/
• Dans le même genre perte du mdp root linux -> impossible de paramétrer l’@IP de la nouvelle interface détectée.
• Plus brutal, le fatal kernel error au boot d’une VM linux. Vous partez pour des heures de recherches sur google.
• Os linux trop vieux -> le linux commence a charger puis s’arrête il ne trouve pas ses disk de démarrage car il est passé de sda à hda, rescue linux à faire, gparted dans certain cas, etc …. au secours !
• Avec Vmm j’en ai également vu de toutes les couleurs j’ai du migrer 5 vm avec SCVMM puis les 100 autres avec la solution 2 ou 3 car il y a trop souvent quelque chose qui lui pose problème. C’est d’ailleurs hallucinant que Microsoft (outre MVMC et Disk2VHD) n’est pas facilité ce genre de migration. Et quel intérêt d’enlever le module P2V de SCVMM2012R2 ? ca fait tout de même râler.
• la question des RDM (disks pass through coté Microsoft). Nous avons opter pour ne plus nous en servir et déplacer les data sur un vhd. Ce type de connectique n’a quasi plus aucun intérêt de nos jours. (hormis décharger le CPU car on ne passe pas par le system NTFS du parent). Encore une fois pour une VM windows ce n’est pas compliqué on se fait un robocopy /syncall /sec, coté linux, rsync vous aidera mais c’est tout de même moins évident avec les points de montage le fstab et j’en passe.
• Quid des vmware tools ? Pour être franc je ne les ai pas retiré des machines virtuelles puisque je voulais modifier le moins possible les VM sources. Il faut maintenant prendre le temps de les retirer proprement …  si c’est faisable. Ca n’a pas l’air simple.

Peut on se passer de SCVMM 2012R2 ?

NON et OUI, non car vous devez obligatoirement passer par là pour la création de vos « logical switch » que vous viendrez ensuite distribuer à vos hotes Hyper V.

Vous passerez également par là pour la création de vos TEAMING dédiés au flux de vos machines virtuelles.

Vous devrez passer par là pour la migration de VM inter Cluster Hyper V et pour l’utilisation de template.

Vous devrez passer par là pour supprimer proprement une machine virtuelle. sans quoi il restera les dossiers vide de la VM voir pire le VHD.

si vous avez un abonnement avec des VM dans AZURE vous devrez également utiliser VMM pour les voir et les administrer.

en dehors de ca (je vais pas tout lister !) vous pouvez vous en passer.

Effectivement l’utilisation de l’hyper v manager et/ou la console de cluster management jouent également assez bien leur rôle. On peut pour ainsi dire tout faire à partir de là. Si je ne m’abuse certaines fonctionnalités telles que le status des repli sont beaucoup plus lisible via hyperV manager .

lorsqu’on travaille sous VMM on se rend vite compte qu’on est obligé de régulièrement mettre à jour le cluster les hosts et les vm sans quoi on a pas le vrai status à l’instant T, c’est très vite fatigant.

pour finir sur cette question, VMM reste l’outil qui permet d’avoir une vision globale de son infrastructure de virtualisation (ESX Vcenter et Hyper v + Azure dans la même console)

La gestion de la haute dispo est elle équivalente voir meilleur que sous ESX ?

je n’ai pas assez d’expérience pour juger Vmware à ce sujet.

je vais donc juger Microsoft uniquement. Nous avons eu beau plantage récemment.

sur notre cluster de production à deux nœuds, l’un des nœuds a redémarré violemment. Toutes les VM qui étaient hébergées sur ce dernier se sont mises à redémarrer sur le noeud encore actif jusqu’au moment où certaines VM n’ont pas pu démarrer faute de mémoire libre  🙂

bien dimensionner son infra c’est la clé du succès !

tout ca pour dire qu’on a beau tester\recetter son infra, y a que lorsque ca plante en pleine production qu’on voit si ca tient la route; et ce fut le cas. Alors certes on a eu une perte de la production, mais notre PCA a joué son role. Pour le manque de mémoire nous étions au courant ce qui nous a permis de rapidement éteindre les VM non critique afin de libérer quelques Go. Nous allons régler ce problème par l’ajout de deux nouveaux serveurs à notre cluster de production.

et c »est aussi dans ce genre de cas qu’on peut justifier que le budget alloué à l’infra n’était pas insensé. Quand on met tout ces œufs dans même panier à un moment donné il faut de la redondance partout sinon à quoi bon..

Gestion de la live migration – vmotion ?

je n’ai rien à dire sur la partie VMware, ca répondait vite et ca « faisait le job ». RAS

Idem pour la partie live migration de Microsoft, pas de mauvaise surprise, aucune perte de ping, l’utilisation de la bande passante est optimale. Attention tout de même lorsque vous déplacer plusieurs VM d’un seul coup, si l’une d’elle est arrêtée, vous allez lancer une quick migration de vos VM et non une Live migration … pas tout à fait pareil !

dans les best pratice de microsoft, il est préconisé un réseau dédié pour ce flux. J’ai toujours aimé séparer les flux que ce soit le heartbeat, les flux SAN, les flux d’admin, les flux de live migration, les flux de sauvegarde pourquoi pas ?

ceci dit, et cela m’a été imposé, pour nos serveurs sur les 8 ports ethernet Gigabits nous avons opté pour ceci:

un teaming de 3 ports pour l’admin, le heartbeat et la live migration

un teaming de 3 port en mode trunk pour le virtual switch des VM

2 ports ISCSI, avec chacun leur sous réseaux et MTU 9000.

ci joint un petit schéma ( merci à Swan pour sa maitrise de Visio :p )

me voilà arrivé à la fin de cet article

en espérant qu’il vous a plu et qu’il pourra vous servir si un jour

vous partez en croisade VmWare -> Hyper V

Maxime

 

petite mise à jour de l’article

Les étapes d’une bonne migration

Ci joint la liste des tâches à réaliser lorsqu’on veut migrer une VM ESX vers Hyper V via Disk2VHD. J’espère que ca vous permettra de ne rien oublier

• Communication aux utilisateurs et chef de projet J-1 Migration
• Communication aux utilisateurs  et chef de projet jour J de la Migration
• Créer le répertoire de la VM sur un LUN de votre cluster Hyper V
• Préparer la VM – Audit du nombre de lecteur, leur lettre leur taille, le nombre de vcpu le nombre de RAM et la ou les IP, Audit applicatif, se renseigner si la licence applicatif est basée sur une @Mac par exemple, auquel cas pensez à la repositionner sur la vm Hyper-V
• Nettoyer c:\temp + C:\Windows\SoftwareDistribution (arrêt windows update service avant) + C:\Windows\temp + C:\Users obsolète
• Positionner le répertoire disk2vhd dans c:\temp
• Vérifier qu’il y a un espace libre convenable sur le lecteur C:\ pour que disk2vhd puisse effectuer son snapshot
• Arrêter les services applicatifs de la VM avant de lancer le disk2VHD exemple SQL Service
• Une fois le Disk2VHD terminé, on a le ou les VHD dans le répertoire sur le LUN, on peut créer la VM à partir d’HYPER-V MANAGER en attachant les vhd et en positionnant la RAM, ajouter la carte réseaux sans la connecter, cette étape sera réalisée via VMM uniquement
• Retourner dans la configuration de la VM et ajuster le nombre de VCPU
• Vérification : Démarrer la VM et vérifier qu’elle boot et qu’elle retrouve ces lecteurs. il est possible qu’il y est une première demande de reboot
• Installer les services d’intégration Hyper V, il faut redémarrer encore une fois la VM la plupart du temps.
• Au redémarrage, positionnez l’@IP récupérer dans l’ancienne VM et l’@mac si besoin de la conserver
• Via la console Cluster Manager, ajouter la VM au cluster en faisant clic droit sur roles -> Configurer role -> Next -> Virtual machine -> votre VM fraichement créée puis Next Next et Next
• Une fois la VM Hyper V complètement prête, on va pouvoir couper le réseaux de la VM ESX, exécutez un ping -t vers l’ip de la vm
• Allez sur VCenter, dans les paramètre de la VM ESX, décoché Connected sur l’interface réseaux pour qu’on commence à perde le ping vers la VM que l’on migre
• Dès qu’on perd le ping, allez sur la console VMM, positionnez vous sur la conf de la nouvelle VM HYPER-V et connectez votre interface au réseau (je ne rentrerai pas dans le détail des VLAN) puis OK, la machine virtuelle va s’actualiser, si la conf IP et Gateway sont bonnes, le ping devra revenir positif, à partir de là, redémarrer la VM encore une fois
• Vérifier que l’applicatif répond bien au redémarrage
• Vérifier sur votre outil de monitoring que les services sont UP
• Dans la VM Hyper V, désactiver le service Vmware tool, il est préférable de déinstaller les VMware tool avant mais moins pratique en cas de retour arrière d’urgence.
• Concrètement la migration est terminée, il reste des tâches de fond
• Communiquer pour cloturer l’opération
• Eteindre la VM ESX qui n’est plus accessible
• Si retour OK des utilisateurs le lendemain de l’opération, ajouter la VM Hyper V à votre outil de sauvegarde
• Si retour OK Global le sur lendemain renommer la VM ESX en « NomdelaVM-MIGRE HV »
• A J+7 de la migration – faire un remove from inventory de la VM ESX migrée