Réponses:
TOUJOURS éjecter tous les supports virtuels (CD / DVD / disquette) une fois que vous avez terminé car le non-respect de cette règle arrêtera souvent une vMotion sur ses pistes.
Obtenez votre configuration NTP et DNS correctement, cela vous évitera d'envisager le suicide :)
Vous ne pouvez jamais avoir suffisamment de mémoire ou de stockage.
Assurez-vous que vous disposez d'un accès à distance, sans système d'exploitation, à vos machines telles que le système iLO de HP.
Gardez un référentiel de fichiers OS / App .ISO.
Pas une réponse directe à votre question, mais dans l'espoir que quelqu'un se sauve de s'arracher les cheveux à l'avenir en trouvant cette réponse - les serveurs lames HP ne sont pas livrés avec leur bit 'VT' activé par défaut, vous devez activer dans le BIOS (F9). Sans cet ESX 3.5U4 ne génère pas d'erreur utile, non, il se bloque juste avant l'installation du code :(
Pour répondre à la question posée - pièges liés aux migrations P2V.
Tout d'abord - les migrations P2V fonctionnent très bien pour la plupart. Plus les systèmes sont propres et récents, mieux c'est, mais même avec la migration d'anciens (systèmes NT4), mon taux de réussite après plus d'une centaine de migrations dans divers environnements a été d'environ 90%. Ce sont des systèmes qui ont migré et ont été remis en production le jour (et surtout la nuit) prévu. Je n'ai eu qu'un seul système que nous avons dû inverser après une migration apparemment réussie - une boîte SQL qui nécessitait plus de puissance CPU que la plate-forme ne pourrait jamais en fournir. VMware Converter est bon et gratuit (pour la version non entreprise), Platespin est très bon (mais coûteux).
Cela dit, il y a des choses à éviter.
Clusters MSCS. Vous pouvez les faire fonctionner, mais ce n'est jamais une excellente idée et Microsoft ne vous aidera certainement en aucune façon si vous rencontrez des problèmes plus tard. Construisez plutôt de nouveaux systèmes autonomes.
Grands serveurs SQL - accent sur les grands. Celles-ci auraient dû être signalées en rouge à partir d'un PDV de configuration processeur requise à l'avance, mais ne soyez pas tenté d'en déplacer une si vous n'êtes pas certain que la machine virtuelle cible disposera d'un espace libre suffisant pour le processeur.
Si vous prévoyez de modifier les noms de système ou les adresses IP (ou les deux) pendant la migration, envisagez d'abord de ne pas le faire et si vous n'avez absolument pas le choix, assurez-vous d'avoir des personnes à portée de main qui comprennent comment ces changements peuvent affecter le systèmes en question. Ma pire migration a été un serveur RSA ACE utilisé pour authentifier un VPN situé dans la DMZ où le client a refusé d'écouter mes objections et a insisté pour changer le nom et l'adresse IP pendant la migration.
En rapport avec ce qui précède - si vous avez autre chose qu'un réseau complètement plat, créez des VM de test et assurez-vous à 100% que vos réseaux de VM reproduisent parfaitement ceux physiques à partir desquels vous migrez.
Dans les environnements Windows AD, assurez-vous toujours que vous disposez d'un compte d'administrateur local sur la zone en cours de migration. Et testez-le avant de migrer.
Assurez-vous d'avoir une bonne idée du temps que cela prendra. Les temps de copie P2V varient en fonction de la bande passante réseau disponible (évidemment) mais peuvent également être considérablement affectés par le nombre de fichiers dans chaque volume migré. Ceci est particulièrement un problème avec les systèmes Platespin migrant NT4 * mais affectera toute copie de logiciel P2V au niveau du fichier (qui s'applique généralement si vous choisissez de redimensionner les volumes). Des taux de copie de 70 à 80 Mo par seconde sont possibles avec les réseaux GigE, une source relativement rapide et une bonne configuration cible, mais 20 à 30 Mo / s est plus typique et pour les systèmes NT susmentionnés avec des réseaux de 100 Mo et beaucoup de fichiers, j'ai vu des taux de copie descendre dans la gamme 50kilobyte / sec.
D'après mon expérience, faites très attention à votre support de stockage. Nous sommes allés avec un SAN iSCSI qui s'est avéré ne prendre en charge que les connexions 100 Mbits. L'exécution d'une VM sur le système n'était pas mauvaise, deux était moins adéquate ... et au moment où nous avons atteint notre objectif de 8 VM, elles étaient horribles.
Ma leçon personnelle apprise: vérifiez les IOPS notées et lisez plus d'avis sur un produit qui se rapportent à la façon dont vous avez l'intention d'utiliser le périphérique de stockage
Une autre chose pratique que j'ai apprise ... La création d'une image disque de «sauvegarde» après une installation de base et un durcissement accélérera la construction de tout autre système et est une chose très pratique à conserver.
Essayez de ne pas exécuter les serveurs de base de données de production dans un environnement virtuel. Les frais généraux pour les E / S sont inacceptables. Nous avons eu d'énormes problèmes lorsque notre DBA a permis à notre serveur MSSQL principal de devenir virtualisé. Les requêtes prenaient des milliers de millisecondes pour s'exécuter. Lorsque nous les avons convaincus de le replacer dans une boîte dédiée, le débit et la vitesse ont augmenté de 10 000%.
Utilisez un réseau redondant pour le trafic vmotion / vmkernel. Vous ne voulez pas que les machines virtuelles s'arrêtent simplement parce qu'un commutateur a redémarré.
Oh, et laissez un serveur DC / DNS / DHCP hors de la virtualisation. Vos utilisateurs vous détesteront moins si vous obtenez un crash SAN majeur.
Si vous n'en avez pas déjà - Ayez une sauvegarde complète de la machine physique avant la migration. Une image est probablement la meilleure ou et une restauration ASR / système ou tout ce qui vous donne un instantané complet du système, au lieu de la sauvegarde de contenu habituelle que la plupart des machines ont.
Les outils P2V peuvent se retourner contre vous de manière inattendue, ruinant la machine physique (j'ai eu un convertisseur VMWare tuer une machine que j'essayais de P2V une fois, heureusement, c'était juste une migration de test). Soyez prêt à devoir restaurer le système à partir de zéro. Oui, c'est peut-être une chance de 1000 pour une, mais voulez-vous être celle-là?
VMWare Converter crée des machines virtuelles qui démarrent à partir de scsi. Les machines virtuelles MS ne peuvent pas démarrer à partir de scsi. [edit - apparemment la version 4 du convertisseur vous permet maintenant de spécifier SCSI ou IDE, j'adore ces gars]
Si vous souhaitez virtualiser une machine physique non ACPI , achetez un logiciel à cet effet. (sauf si vous avez quelques semaines pour un voyage passionnant de découverte!)
En outre, VMWare Converter s'attaquera aux travaux au cours desquels MS SCVMM lèvera les mains au désespoir.
Apportez beaucoup de RAM.
Ne faites rien tant que les outils de virtualisation (que ce soit VMWare ou MS) ne sont pas installés.
Si vous prévoyez de le déplacer vers une autre plate-forme / version, désinstallez les outils susmentionnés.
Faites attention à vos limites CPU. Le P2V de 2 fenêtres CPU 2000 m'a appris qu'un seul est pris en charge.
Microsoft ne prend pas en charge Exchange 2003 exécuté dans VMware (du moins, c'était la réponse officielle). Avec beaucoup de torsions de bras, nous avons pu obtenir un soutien officieux de leur part, mais cela a provoqué des maux de tête supplémentaires dans une crise déjà stressante.
Beaucoup d'entre eux sont spécifiques à VMware:
Gêne stupide avec VMware: différentes versions de VMware utilisent différents pilotes SCSI pour leurs périphériques de disque virtuel. Il est tout à fait possible de perdre 2 heures avant d'envisager cette option.
Eh bien, jusqu'à présent, je n'ai pas d'histoires d'horreur sur moi-même faisant la virtualisation. Cependant, quelques notes cependant.
Planifiez soigneusement dans les détails à venir. Faites surtout des devoirs qui ne peuvent pas être virtualisés.
Si le fournisseur de l'application exécutée sur votre serveur ne prend pas en charge l'environnement virtuel, attendez qu'il le prenne en charge.
Implémentez avec un SAN comme stockage stockant toutes les images de machine virtuelle.
Exécutez ESX ou ESX (i) ou Hyper-V pour obtenir la plupart des performances.
Peut-être plus mais c'est tout pour l'instant. :)
[mise à jour] en voici une autre. Appliquez le dernier micrologiciel au serveur hôte. J'en ai eu un que je n'ai pas fait, ce qui m'a donné un écran violet une fois quelques jours et a complètement bloqué le serveur.
L'impact de la virtualisation représente environ 5% des performances des frais généraux. Mesurez la consommation de ressources sur l'environnement existant pour déterminer si votre environnement de virtualisation peut supporter cette charge.
Avant de mettre en ligne votre solution de virtualisation:
Y a-t-il quelque chose que vous avez essayé de virtualiser mais que vous ne ferez plus jamais?
Je ne dirais pas que je ne vais pas réessayer, mais la virtualisation en couches n'est pas agréable à gérer.
Par couches, je veux dire exécuter xen ou esx sur du matériel virtualisé tel que Egenera, HP Virtual Connect ou Cisco UCS. Cela semble être une bonne idée, mais le débogage peut prendre beaucoup de temps.
Dans VMWare, sachez où se terminent les instantanés. Nous avions le nôtre configuré pour se retrouver dans le LUN sur le SAN avec les fichiers VM eux-mêmes. Un technicien pratiquait le processus d'instantané sur une LUN presque pleine. Plus tard, il a redémarré la machine virtuelle pour une raison quelconque, et les fichiers journaux ont empêché la machine virtuelle de démarrer. C'est un peu de chance qui nous a conduit à ce que le LUN soit plein comme cause.