VMware vCenter Converter Standalone est un logiciel complet fournit par VMware dans le but d’effectuer la conversion de machine, notamment V2V (Virtual to Virtual) et P2V (Physical to Virtual), afin de convertir une machine physique en machine virtuelle ou une machine virtuelle vers un type de machine virtuelle différent.
Dans ce tutoriel, nous verrons comment se passe la conversion d’une machine physique en machine virtuelle, ou plutôt, comment créer une machine virtuelle à partir d’une machine physique.
Pré-requis : Avoir installé VMware vCenter Converter Standalone sur sa machine
II. Procédure
Pour commencer, ouvrez l’application. Cliquez ensuite sur le bouton nommé “Convert machine“.
Dans la zone “Select source type” choisissez “Powered-on machine” puis comme dans mon cas il s’agit d’une machine distante, je choisis “A remote machine” et ensuite j’indique l’adresse IP de la machine dans la zone “IP address or name“. Enfin, indiquez un compte privilégié (administrateur de la machine ou du domaine).
Pour pouvoir réaliser une machine virtuelle à partir de la machine physique, en toute logique un agent VMware est nécessaire et doit être installé sur la machine distante. Choisissez “Automatically uninstall the files when import succeeds” pour supprimer l’agent automatiquement à la fin de la création de la VM. Si vous désirez laisser l’agent installé, sélectionnez la seconde option.
En ce qui concerne la source, c’est réglé. Maintenant, il faut configurer le système de destination. Pour ma part, la machine virtuelle sera directement importée sur un serveur ESXi donc je sélectionne “VMware Infrastructure virtual machine“. Ensuite, l’adresse du serveur ainsi qu’un couple identifiant/mot de passe doit être saisit afin de pouvoir exécuter l’action.
Indiquez un nom et une destination pour la machine virtuelle puis poursuivez.
Indiquez au sein de quelle banque de données vous souhaitez stocker la machine virtuelle.
Éditez éventuellement les options de configuration de la machine virtuelle, ceci dans le but de lui mettre plus de mémoire, de vCPU, etc… Sachez que vous pourrez y revenir plus tard en éditant les paramètres de la VM une fois qu’elle sera créée.
Le résumé apparaît, cliquez sur “Finish” pour exécuter la tâche de conversion.
La tâche apparaît sur l’écran d’accueil de VMware vCenter Converter Standalone. Le temps restant (Estimated time remaining) est indiqué et il correspond bien à la réalité.
Une fois la conversion terminée, vous n’aurez plus qu’à aller sur votre serveur de destination et exécuter la VM.
Cela est intéressant de pouvoir installer l’hyperviseur de Microsoft en VM pour effectuer des tests. Ce procédé s’appelle de la nested virtualization : de la virtualisation dans la virtualisation, dans notre cas on parlera plus précisément de nesting Hyper-V.
Pour ma part, j’utilise un PC sous Windows 8.1 avec VMware Workstation 10 installé, dans le but d’ajouter la fonctionnalité Hyper-V à une machine sous Windows Server 2012 R2.
Si vous tentez une installation sans effectuer de configuration adéquat de votre machine virtuelle, vous obtiendrez ce message :
II. Procédure
Après avoir fait face à ce message d’erreur, éteignez votre machine virtuelle proprement via le menu du système d’exploitation ou par le menu de VMware Workstation (clic droit sur la VM, Power, Shut Down Guest).
Nous devons modifier le fichier de configuration VMX de la machine virtuelle, ce dernier se trouve dans le répertoire de stockage de la VM. Vous devriez retrouver une arborescence comme ceci et le fichier .vmx :
Éditez ce fichier de configuration avec votre éditeur de texte préféré et ajoutez ceci à la fin du fichier :
Le paramètre “hypervisor.cpuid.v0” lorsqu’il est actif indique à l’OS de la machine virtuelle qu’il est exécuté sur un environnement virtualisé. On le passe à FALSE pour que Windows Server ne se rende pas compte qu’il est virtualisé.
Le paramètre “mce.enable” permet de rendre actif le Machine Check Exception afin d’autoriser la machine virtuelle à rapporter des erreurs CPU. Enfin, “vhu.enable” permet d’activer le mode nested.
Une fois les modifications effectuées, sauvegardez le fichier de configuration. Ensuite, accédez aux paramètres de votre VM en effectuant un clic droit sur son nom dans VMware Workstation puis “Settings“. Accédez à la section “Processors” et cochez les deux options suivantes utiles pour le mode nested :
– Virtualize Intel VT-x/EPT or AMD-V/RVI
– Virtualize CPU performance counters
Validez. Votre VM est fin prête, il ne reste plus qu’à démarrer votre machine virtuelle et à effectuer l’installation d’Hyper-V !
J’en ai profité pour faire une procédure en vidéo :
Lors de l’installation de VMware ESXi il se peut que toutes vos cartes réseaux Ethernet ne soient pas détectée. En effet, le système embarque des pilotes matériels par défaut, de périphériques étant déclarés compatible chez VMware, mais ne contient pas les pilotes des cartes non supportées officiellement.
A ce titre, si vous utilisez du matériel un peu ancien ou exotique… Ce qui peut être le cas lorsque l’on se fait un serveur ESXi de test (et qu’il est installé sur une configuration Poste de travail), il se peut que la carte réseau ne soit pas installée à cause d’un manque de pilote.
Ce tutoriel explique l’installation du pilote pour la carte D-LINK 528T, présente en 3 fois dans la machine sur laquelle j’ai installé l’ESXi. Quant au système d’exploitation VMware, il s’agit de la version 5.5.
Pré-requis : Assurez-vous d’avoir un accès au shell de l’ESXi via SSH.
II. Procédure
En toute logique, lorsque vous saisirez la commande indiquée ci-dessous votre carte réseau manquera à l’appel. La commande affiche uniquement les périphériques réseaux opérationnels.
esxcfg-nics -l
Ensuite, recherchez parmi les périphériques détectés sur votre serveur les contrôleurs Ethernet grâce à cette commande :
lspci | grep Ethernet
Normalement, vous devez voir apparaître la ou les cartes réseaux dont le pilote n’est pas installé. Pour moi, cela représente trois cartes comme on peut le voir sur la copie d’écran ci-dessous.
Vous devez désormais télécharger le pilote correspondant à votre carte réseau, pour ma part D-LINK 528T. J’ai obtenu le pilote pour ESXi sous la forme d’un fichier ZIP contenant un fichier VIB. Transférer l’archive du pilote sur votre serveur ESXi, vous pouvez utiliser le logiciel de transfert de fichiers WinSCP (transfert de fichiers over SSH).
Pour ma part, je place l’archive dans le répertoire “/tmp“. Je me rend dans ce répertoire afin de décompresser l’archive grâce à la commande unzip présente sous ESXi 5.x.
cd /tmp
unzip DLink-528T-1.x86_64.vib.zip
Avant de procéder à l’installation, vous pouvez vérifier sur la Hardware Compatibility List de VMware si votre carte réseau est officiellement compatible. Si ce n’est pas le cas de toute manière vous obtiendrez un message d’avertissement lors de l’installation et vous devrez changer le niveau d’acceptation des pilotes.
La commande ci-dessous permet de passer le mode en “CommunitySupported” pour que l’ESXi soit plus souple au niveau des restrictions d’installation.
esxcli software acceptance set –level=CommunitySupported
Le message de validation “Host acceptance level changed to ‘CommunitySupported’” apparaît. Nous pouvons passer à l’installation comme ceci en indiquant le chemin vers le fichier .vib :
Lisez le message qui s’affiche afin de vérifier que l’installation est complète : “The update completed successfully“. Il est à noter qu’un redémarrage est requis : “Reboot Required : True“.
Une fois l’installation terminée, vous pouvez saisir à nouveau la commande “esxcfg-nics -l” et vous devrez voir apparaître vos cartes réseaux. On peut également voir cela via le vSphere Client, dans la “Configuration” puis “Adaptateurs réseau“.
Si besoin, consultez les fichiers de logs /var/log/messages et /var/log/vmware/hostd-0.lo
Les cartes sont désormais opérationnelles et utilisables !
Lors de la mise en place d’un serveur VMware vCenter en version 5.5, sous Windows Server 2012 R2, il y a de très fortes chances que l’installation se bloque sur le message suivant : “Installation de Services d’annuaire en cours“.
Voyons comment résoudre ce problème et pouvoir finaliser l’installation.
II. Procédure
Si l’on regarde le fichier de log “vminst.log” qui se situe dans %temp%, on remarque que l’installation est en attente de lancement de ocsetup.exe.
En fait, ce programme qui permet d’installer des paquets et notamment au format MSI, est absent de Windows Server 2012 R2. De ce fait, VMware ne le trouve pas et cela bloque l’installation.
En fait, il faudra récupérer l’exécutable sur un serveur Windows Server 2008, 2008 R2 ou 2012 (R1) afin de l’importer sur votre serveur. Vous trouverez cet utilitaire au chemin suivant :
C:\Windows\System32\ocsetup.exe
Il suffit de le copier au même emplacement. Ensuite, vous devez relancer l’installation de VMware vCenter Server et l’installation ne bloquera plus sur ce point !
Je vous ai déjà parlé du promiscious mode sur IT-Connect dans un précédent post, ce mode de configuration des cartes réseau permet d’accepter les trames qui ne semblent pas destinées au périphérique réseau qui les reçoit. Pour une description détaillée, je vous recommande d’aller voir mon précédent article sur ce qu’est le promiscious mode Nous allons ici voir comment activer ce mode sous VMware pour que les hôtes et les machines virtuelles qui s’y situent puissent en profiter.
Cela peut par exemple être utile dans le cadre de la mise en place d’un IDS sur lequel on redirige le trafic ou encore lors de la mise en place d’une IP virtuelle pour un cluster de machine et une haute disponibilité comme c’est mon cas.
II. Procédure
La procédure est plutôt simple, VMware ayant prévu cette fonctionnalité. On va commencer par se logguer sur notre VCenter avec notre client VSphere . On va ensuite sélectionner notre hôte ESX puis aller dans “Configuration” et ” Mise en Réseau” :
On va ensuite choisir la carte réseau “physique” sur laquelle se positionne l’hôte ou l’interface devant profiter du promiscious mode et cliquer sur “Propriétés”. On pourra alors sélectionner noter vSwitch et ensuite cliquer sur “Modifier”.
Ici, on sélectionnera l’onglet “Sécurité” puis on sélectionnera “Accepter” dans la liste de la ligne “Mode espion” :
On pourra cliquer sur “OK” et profiter du promiscious mode !
Sous VMware Workstation, il existe une fonctionnalité très pratique qui permet de partager une machine virtuelle. Cela peut par exemple servir dans le cadre de démonstration, d’intervention à distance ou lors de procédure d’échange et de test. Nous allons voir comment activer cette fonction dans ce tutoriel.
Note : Pour faire ce tutoriel, vous aurez besoin d’un client VNC. Etant sous Windows, j’utilise personnellement UltraVNC.
II. Procédure d’activation
Une fois sur Workstation, il faut se rendre dans les Paramètres de notre machine virtuelle :
On va ensuite aller dans “Options” et sélectionner “VNC Connections” :
Sur la droite de cette fenêtre, on pourra alors cliquer sur “Enable VNC connections”, on pourra alors spécifier un port et une mot de passe qui est optionnel :
Note : Comme le précise le message dans la fenêtre de paramétrage, le VNC n’est pas un protocole sécurisé et les données qu’il fait transiter ne sont pas chiffrées. Soyez donc prudent lors de son utilisation.
On pourra alors utiliser notre client VNC (ultraVNC dans mon cas) et pointer vers l’IP:port cible. Pour l’illustration, j’ai utilisé localhost mais un voisin pourra tout à fait se connecter en saisissant votre IP.
Note : Pensez à votre pare-feu Windows si vous rencontrez des soucis de connexions.
On aura alors un accès VNC à notre machine virtuelle, une machine KaliLinux dans mon cas :
Sur l’hôte, il est possible de voir les connexions VNC en cours sur la machine virtuelle, cela à partir de la même fenêtre depuis laquelle on active le VNC :
Dans ce tutoriel, nous allons voir comment mettre en place un répertoire partagé en un hôte disposant de VMware Workstation et une machine virtuelle sous Linux. C’est une procédure qui se fait assez simplement grâce à l’intégration de cette fonctionnalité directement dans VMware Workstation.
Note : Pour pouvoir utiliser cette fonctionnalité, il faut que les VMware-tools soient installée sur la machine virtuelle Linux en question, je vous oriente vers ce tutoriel expliquant comment installer les VMware-tools sur Linux pour la procédure d’installation.
II. Procédure
Il faut commencer par se rendre dans la configuration de notre machine virtuelle. Dans la fenêtre des paramètres on ira dans “Options” puis on sélectionnera “Shared Folder” :
Sur cette fenêtre, on pourra cliquer sélectionner “Always enabled” si l’on souhaite que notre partage soit toujours actif et existant même après un redémarrage ou “Enabled until next power off or suspend” pour avoir un répertoire partagé monté temporairement :
En dessous, on va cliquer sur “Add”, on pourra alors aller chercher sur l’hôte le répertoire que nous souhaitons partager et lui donner un nom :
On pourra ensuite choisir quelques options supplémentaires comme la possibilité de monter ce partage en mode lecture seule :
Une fois le partage terminé, on se rendra sur notre machine virtuelle. Par défaut, les partages sont déjà montés dans “/mnt/hgfs” :
On peut néanmoins le démonter via la commande suivante :
umount /mnt/hgfs
Puis le remonter sur un autre répertoire que nous aurons créé auparavant :
mkdir /mnt/montage
mount -t vmhgfs .host:/ /mnt/montage
On trouvera ensuite le contenu de notre répertoire partagé dans “/mnt/montage” pour cet exemple.
Note : Si vous disposez de plusieurs montages, vous pourrez les sélectionner indépendamment avec leurs noms. Par exemple .host/TMP pour celui que nous avons créé dans ce tutoriel.
Les VMtools sont un package de logiciel permettant une meilleure intégration de la virtualisation entre les machines virtualisées et la machine hôte. On ressent généralement leurs effets au niveau de l’utilisation des ressources qui est optimisée. Nous allons ici voir rapidement comment installer les VMtools sans même toucher à la ligne de commande sous Pfsense.
En effet, depuis Pfsense 2, il existe la possibilité d’installer ” Open-VM-Tools” qui est une version libre des VMtools et qui effectuent le même rôle.
II. Procédure d’installation
Pour installer les VMtools, il faut se connecter sur l’interface d’administration du Pfsense en question puis aller dans “System” puis “Package” :
On va ensuite chercher “Open-VM-Tools” puis sur l’onglet “Available Packages” et cliquer sur le “+” à droite de cette ligne :
Nous aurons alors une fenêtre de confirmation pour l’installation de ce package sur laquelle il nous faudra simplement cliquer sur “OK” :
L’installation des VMtools va alors débuter :
Lorsque la ligne “Executing custom_php_install_command()…done” s’affichera, les VMtools seront installés et on pourra alors vérifier cette information dans notre vCenter :
La ligne “VMware Tools :” contient “Exécution”, ce qui montre que les VMtools sont bien en cours d’exécution. Seulement c’est par le paquet “Open VM tools” est non pas par les paquets officiels, c’est pourquoi il est marqué “(Tiers / indépendant) “
Lorsque vous activez le shell et/ou le SSH sur un hôte VMware ESXi, les messages “ESXi Shell for the host has been enabled” et “SSH for the host has been enabled” peuvent apparaître dans le client vSphere (ou en français selon la langue de votre client vSphere).
Si vous souhaitez laisser continuellement le SSH actif, vous avez surement envie de vous débarrasser de ce message. Pour cela, une légère modification dans la configuration s’impose.
II. Procédure
Ouvrez le client vSphere et connectez-vous à l’hôte ESXi en question ou au serveur vCenter. Sélectionnez votre ESXi dans l’inventaire.
Cliquez sur l’onglet “Configuration” sur la droite puis descendez ensuite dans la page et cliquez sur “Paramètres avancés” de la section “Logiciel”
Sélectionnez la section “UserVars” sur la gauche, puis, dans la partie de droite descendez jusqu’à trouver le paramètre “UserVars.SuppressShellWarning“.
La valeur par défaut est 0, indiquez 1 et validez. Désormais, les messages d’avertissements concernant le Shell et SSH n’apparaîtront plus.
Sous VMware Workstation, il est possible d’échanger rapidement des fichiers grâce à la fonction de “glisser-déposer” possible entre un hôte et une VM, après installation des VMware Tools. Une autre méthode consiste à définir un dossier partagé sur la machine hôte, et à monter ce dossier partager sur une ou plusieurs machines virtuelles. Cela simplifiera les échanges entre les VMs et entre les VMs et l’hôte.
Nous allons voir dans ce tutoriel comment cela fonctionne dans le cadre d’une machine virtuelle sous Windows. La procédure est effectuée depuis VMware Workstation 10.
II. Procédure
Ouvrez VMware Workstation 10, effectuez un clic droit sur la VM concernée puis accédez aux propriétés (“Settings“). Cliquez sur l’onglet “Options” et sélectionnez “Shared Folders“. Sur la partie de droite, par défaut “Disabled” est sélectionné, car les dossiers partagés sont désactivés. Sélectionnez “Always enabled” pour activer la fonctionnalité continuellement sur cette machine, ou, l’option “Enabled until next power off or suspend” si vous souhaitez activer la fonctionnalité jusqu’au prochain redémarrage ou mise en pause de la VM.
Cliquez sur “Add” pour ajouter un nouveau dossier partagé. Un assistant s’ouvre. Dans le champ “Host Path” indiquez le chemin vers le dossier partagé, sur la machine hôte. Pour le “Name” donnez un nom à ce dossier partagé. Cliquez sur “Next” pour continuer.
Désormais, il faut gérer les droits attribués à ce dossier. Cochez “Read-only” pour que le partage soit accessible uniquement en lecture seule, sinon il sera en lecture/écriture. Par ailleurs, activez le dossier partagé en cochant la case “Enable this share“. Poursuivez en cliquant sur “Finish“.
On remarque l’apparition de notre dossier partagé dans la liste “Folders“. Il ne reste plus qu’à activer l’option “Map as a network drive in Windows guests” pour que le dossier partagé apparaisse comme un lecteur réseau dans votre machine virtuelle Windows.
Enfin, sur la machine virtuelle on remarque que le lecteur réseau est bien présent. Le dossier partagé est fonctionnel !
I. Présentation de l’intégration GNS3 et VMware Workstation
GNS3 est un simulateur réseau assez poussé qui permet de mettre en place des infrastructures réseau de façon réaliste, mais totalement virtuelle. Je vous avais déjà présenté une manière d’intégrer les machines virtuelles VirtualBox dans GNS3, nous allons ici voir comment intégrer les machines virtuelles sous Workstation dans un réseau GNS3, cela peut être particulièrement pratique pour :
Simuler une mise en production à moindres frais
Reproduire un environnement de production pour simuler une migration, une attaque ou une panne
Tester, vérifier ou faire éprouver une configuration ou une architecture aussi bien système que réseau
C’est un processus que je trouve particulièrement pratique pour les phases de test, car il permet de lier la partie système, désormais très répandue, dans la virtualisation au réseau lui aussi virtualisé.
Nous travaillons ici donc sur GNS3 et sur Workstation 10 bien que les autres versions de Workstation suivent le même procédé. Je pars ici du principe que ces deux éléments sont configurés et fonctionnels sur votre plate-forme.
Suivez le guide !
II. Préparer ses cartes réseau
Dans le but d’avoir une mise en place simple, nous allons commencer par identifier les cartes réseau virtuelles (vous savez, celles que Vmware a créé sur votre poste pour lier vos VMs à votre poste, puis au réseau) que nous allons utiliser. On se rend donc dans notre gestionnaire de carte réseau.
Voici les cartes réseau par défaut de Workstation
On voit donc la VMnet1 et la VMnet8, j’ai personnellement choisi de les renommer en HOST-ONLY et NAT pour que leur identification soit plus simple, mais ce n’est pas une obligation. Si vous ne désirez pas les renommer, renommer seulement ceci :
NAT = VMnet8
Host Only = VMnet1
Je renomme ici ces deux cartes réseau
Note : Le renommage des cartes réseau, même physique, n’a aucun impact sur la connectivité ou la configuration réseau des machines virtuelles.
Pour ceux qui souhaitent faire simple & clair et renommer leur carte réseau, il suffit de faire un clic droit sur celles-ci pour les renommer.
III. Configurer Workstation pour GNS3
Nous pouvons ensuite passer à la configuration coté Workstation qui est aussi simple. On commence par aller dans “Édit”, puis dans “Virtual Network Editor” et enfin on sélectionnera “NAT” qui est donc associé à “VMnet8” :
Accès à la configuration réseau de VMware Workstation
Pour montrer que l’on peut effectuer cette intégration aussi bien avec une carte existante qu’avec une nouvelle carte, nous allons changer l’adresse réseau de cette VMnet8 – NAT, nous verrons ainsi tous les champs auxquels il faut penser. On commence donc par aller changer l’IP du réseau et le masque au besoin dans “Subnet IP” :
Changement de la plage IP de la carte NAT
On va ensuite se rendre dans “DHCP Settings” et configurer notre nouveau réseau :
Configuration de la partie DHCP de la carte réseau virtuelle Workstation
Enfin, nous paramétrerons dans “NAT Settings” l’IP de la passerelle du réseau pour notre environnement virtuel (ne paramétrez pas “.1” comme IP, il s’agit de l’IP que votre hôte Windows aura dans ce réseau !) :
Modification de l’IP passerelle pour le réseau virtuel
Enfin, nous pourrons valider en cliquant sur “Apply”
Redémarrage du service réseau de Workstation
Bien sûr, il faudra pour tester notre connectivité finale que la ou les machines virtuelles à mettre dans notre réseau virtuel GNS3 ai(en)t au moins une interface réseau dans la carte réseau que nous assignerons à GNS3, ici la carte réseau VMware-NAT – VMnet8, comme suivant :
Configuration de la carte réseau d’un VM Workstation en NAT
IV. Configurer GNS3
Nous allons ensuite passer à la partie configuration sur GNS3, il s’agit de la dernière étape avant d’avoir une intégration fonctionnelle de VMware Workstation dans GNS3 ! Il faut pour cela penser à démarrer GNS3 en tant qu’Administrateur pour pouvoir accéder aux cartes réseau du système, après avoir ouvert votre schéma réseau, il faut ajouter à celui-ci un “nuage” :
Intégration d’un Cloud dans le réseau GNS3 pour connecter les VM Workstation
Liaison de la carte réseau Workstation dans le réseau GNS3
On va donc ajouter un “Cloud” à notre schéma qui va servir de passerelle entre nos schémas réseau GNS3 et notre machine virtuelle Workstation, on fait ensuite un clic droit “Configurer” sur ce nouvel élément pour y ajouter notre carte réseau configurée :
Configuration de la carte réseau Workstation dans le réseau GNS3
On va ici trouver notre carte réseau par son nom, pour moi “VMware-NAT”, on clique ensuite sur “Ajouter” pour assigner cette carte réseau virtuelle au nuage. Ainsi, tous les éléments que nous lierons au nuage “C1” communiqueront vers et au travers la carte réseau assignée, ici, la même que nos machines virtuelles :
Création du lien Workstation – GNS3 au travers le Cloud GNS3
On va ensuite valider la configuration puis ajouter un Hub/Switch ainsi qu’un routeur par exemple pour avoir un hôte avec lequel notre machine virtuelle va dialoguer pour tester la liaison. On va ensuite faire un clic droit “Ajouter un lien” sur notre Cloud et un clic gauche sur notre Cloud C1 pour sélectionner la carte “VMware-NAT” que nous lui avons assigné, on liera l’autre bout du lien à notre Switch par exemple : j’ai ensuite eu à configurer mon routeur “R1” pour lui donner une IP sur l’interface ethernet0 (“en0”) :
Configuration d’une IP sur le routeur en vue de tester la liaison avec Workstation
V. Tester la connectivité
Nous allons maintenant tester notre connectivité, on va pour cela simplement procéder à un test de ping entre mon routeur que j’ai configuré sur le réseau virtuel GNS3 et ma machine virtuelle VMware Workstation qui possède une interface sur la carte réseau virtuel VMware-NAT ou VMnet8 que j’ai également configuré correctement au niveau du réseau :
Teste de l’intégration d’une machine virtuelle VMware Workstation dans un réseau GNS3
On voit donc que ma machine virtuelle sous VMware Workstation et mon routeur qui est dans le réseau virtuel GNS3 communiquent bien entre eux au travers l’élément cloud mis en place et lié à la carte réseau NAT.
Depuis quelques semaines, un problème apparait sur VMware Workstation installé sur Windows 8.1. En effet, lors du démarrage d’une machine virtuelle avec plus de 2 Gigaoctets de mémoire virtuelle, on peut voir apparaitre le message d’erreur “Not enough physical memory is available to power on this virtual machine with its configured settings” :
Erreur sur Workstation indiquant une impossibilité d’allouer des ressources RAM lors du démarrage de la machine virtuelle
Nous allons ici voir une méthode de contournement à ce problème.
II. Contournement de l’erreur
Il faut savoir que ce problème est présent depuis une mise à jour de Windows en octobre 2014, VMware travaille actuellement (en nov. 2014) sur un patch de correction, mais nous conseille en attendant la méthode de résolution suivante.
Il faut commencer par faire un clic droit sur l’icône Windows puis aller sur “Programmes et fonctionnalités” :
On va ensuite cliquer sur “Afficher les mises à jour installées” pour visualiser l’ensemble des mises à jour présentes sur le système :
Dans le filtre de recherche présent en haut à droite de l’explorateur Windows, il faut saisir “KB2995388” pour rechercher cette mise à jour qui est celle rentrant en conflit avec Workstation et qui cause l’affichage de cette erreur :
Sélectionner la mise à jour Windows causant le conflit pour désinstallation.
Il nous suffit ensuite de faire un clic droit sur la ligne de la mise à jour en question puis de la désinstaller, après un redémarrage système, les machines virtuelles Workstation démarreront normalement.
Par défaut dans les produits VMWare (Player, Workstation et même la console Linux dans vSphere), la taille du terminal Linux est en 640×480 :
Cette taille de terminal peut être assez handicapante lorsque l’on passe beaucoup de temps sur un terminal. Il est généralement préféré d’avoir une taille de terminal plus grande pour avoir plus d’informations en visuel par exemple. Dans ce tutoriel, nous allons apprendre à agrandir la taille du terminal Linux, cette documentation sera d’une grande aide à ceux qui utilisent les produits VMware mais la procédure peut être appliquée dans beaucoup d’autres contextes (VirtualBox par exemple).
II. Taille du terminal, tout est dans le GRUB
Comme l’indique mon titre, la taille du terminal peut facilement être ajustée, il faut pour cela aller modifier le paramétrage du GRUB qui initie, au lancement de la machine, la taille du terminal. Juste avant d’appliquer notre modification, il faut savoir quelle taille mettre, il existe pour cela une codification que vous retrouverez ici : Console FrameBuffer
En suivant ce tableau :
Par exemple si je souhaite avoir une taille de terminal en 1024×768 et que mon affichage est en 16bits (ce qui, il me semble, est le cas par défaut sous VMware), le code est “791”. On va donc aller modifier le fichier /etc/default/grub avec notre éditeur de texte préféré :
Voici le fichier comme on peut le trouver dans sa configuration par défaut :
A l’option “GRUB_CMDLINE_LINUX_Default=”quiet”, nous allons ajouter notre code sous la forme “vga=valeur” :
On va ensuite sauvegarder et quitter le fichier en question puis recharger notre configuration GRUB pour que nos modifications soient prises en compte, on utilise pour cela la commande suivante :
update-grub
Il nous suffira ensuite de redémarrer notre machine Linux pour voir le terminal dans une forme plus sympathique
Note : Certaines documentations sur cette procédure recommandent parfois également de modifier la ligne GRUB_GFXMODE du fichier de configuration du GRUB en enlevant le “#” qui le commente et en assignant le même code que celui vu précédemment. Cette modification n’ayant pas fonctionné pour mon cas, il est toutefois intéressant de connaitre cette seconde procédure.
Que ce soit à des fins de tests ou d’expérimentations, le fait de disposer d’une machine virtuelle faisant tourner Android en ravira plus d’un ! Cela tombe bien, c’est ce que nous allons voir dans ce tutoriel, où il sera question d’installer Android KitKat sous VMware Workstation 10. Un des intérêts est de pouvoir faire des tests sous Android sans forcément bidouiller dans son propre appareil, voir même si l’on a pas d’appareil Android, cela permet d’expérimenter l’OS bien que l’expérience utilisateur soit fortement réduite en absence de tactile.
Le projet se nomme “Android x86” est met à disposition des images ISO d’Android qu’il est possible de faire tourner sur PCs. Pour commencer, c’est vers le site du projet que je vous dirige afin de télécharge le fichier source : Android x86 Téléchargement.
Au moment où j’écris ces lignes, la version la plus récente est “android-x86-4.4-RC2” c’est donc avec celle-ci que je vais procéder.
Pour ceux qui préfèrent, suivez le cours en vidéo :
II. Création de la machine virtuelle Android x86
Dans VMware Workstation, créez une nouvelle machine virtuelle. Indiquez votre fichier ISO fraîchement téléchargé.
Là, vous verrez que VMware détecte l’OS comme étant FreeBSD c’est d’ailleurs pour cela qu’il nomme ainsi votre VM. Renommez-là “Android x86 4.4” par exemple.
Créez un disque dur virtuel, pour ma part j’indique 32 Go, pour reprendre une taille que l’on trouve communément sur smartphone et tablette.
Cliquez sur “Customize Hardware” afin de personnaliser le matériel virtuel de la VM avant de poursuivre.
Dans Memory, attribuez de la mémoire RAM supplémentaire. Choisir 1 Go ou 2 Go me semble bon, vous pourrez adapter par la suite de toute manière.
Concernant la partie connexion réseau, que l’on trouve dans Network Adapter, je choisis de laisser la machine en NAT afin qu’elle utilise mon hôte physique pour accéder à internet.
La création de la machine virtuelle est terminée.
III. Installation d’Android x86
L’installation est très simple, il faudra juste être rigoureux au moment du partitionnement. Pour le reste, c’est très bien guidé. Lorsque vous démarrez sur l’ISO, un menu apparaît. Sélectionnez “Installation – Install Android-x86 to harddisk” et appuyez sur Entrée, pour installer Android sur votre disque dur virtuel.
Android x86 – Boot menu
Le disque n’est pas partitionné, nous devons donc le faire. Choisissez “Create/Modify partitions“.
Créez une nouvelle partition en choisissant “New“. La partition doit être primaire (Primary) et bootable (Bootable – Ce qui ajoutera la mention “Boot” au niveau de la colonne “Flags“).
Validez ces changements choisissant “Write“, et écrivez “yes” pour indiquer que vous êtes sur de vouloir opérer les changements. Enfin, cliquez sur “Quit” pour quitter le gestionnaire de partition.
Ensuite, on se retrouve au précédent menu où l’on peut désormais sélectionner notre partition sda1.
La partition doit être formatée en ext3, sélectionnez ce système de fichiers dans la liste et validez avec Entrée. Confirmez une seconde fois que vous souhaitez formater sda1 en ext3.
Choisissez d’installer le boot loader GRUB au démarrage, ceci permettra d’obtenir un menu démarrage GRUB comme on le trouve sur d’autres distributions comme Ubuntu ou Debian.
“Do you want to install /system directory ad read-write ?” Indiquez “Yes” afin d’être en mesure d’écrire sur le système et de pouvoir effectuer des changements, sinon vous allez vous retrouver en lecture seule.
Patientez pendant l’installation…
Une fois l’installation terminée, choisissez de redémarrer la machine virtuelle ! Démarrez sur le premier choix présent dans le GRUB comme ceci :
IV. Finaliser l’installation d’Android x86
Comme lorsque l’on allume son appareil Android pour la première fois, il est nécessaire de répondre à quelques questions (langue, wi-fi, compte Google, etc), c’est ce qui vous attend là aussi. Ces étapes sont basiques et dépendent des paramètres que vous souhaitez adopter.
Remarque : Le clavier est en QWERTY par défaut, méfiez-vous lorsque vous saisirez différentes informations.
Dans les applications, on pourra remarquer la présence de “Super Utilisateur“. En effet, sur cette édition d’Android, le mode rooté est directement actif.
Voilà Android est opérationnel, amusez-vous bien ! Si vous rencontrez des difficultés, obtenez de l’aide dans notre forum.
Dans cet article nous allons naviguer entre plusieurs milieux bien intégrés au sein du SI actuel, à savoir la virtualisation et le stockage. Pas à pas nous mettrons en place une solution de stockage basé sur une distribution OmniOS et le système de fichier ZFS puis celui-ci sera exposé à l’hyperviseur VMware ESXi via une liaison Fibre Channel en Point-to-Point.
Prérequis :
Une machine faisant office de serveur stockage (OmniOS)
Une machine faisant office d’hyperviseur (VMware ESXi dans cet exemple)
2 cartes Fibre Channel QLogic (ici les modèles sont des QLE2460) connectées en Point-to-point donc sans switch FC (http://en.wikipedia.org/wiki/Fibre_Channel_point-to-point).
Les cartes peuvent être trouvées à un prix abordable sur eBay sous la référence QLE2460 (~40€ la paire + 1 fibre optique connecteur LC/LC à 10€ )
Dans mon cas mes machines sont les suivantes :
Stockage
Processeur AMD Phenom II X4 925
Carte mère Gigabyte GA-890GPA-UDH3
16Go DDR3
IBM ServeRaid M1015 SAS flashé en firmware IT (ZFS à besoin dans le meilleur des cas d’avoir les disques présentés directement (passthrough) sans aucune sur-couche raid puisque il fera du raid logiciel par la suite)
5 disques SATA Samsung spinpoint F1 de 1To 7200trs
2 SSD Kingston V200 de 60Go
1 SSD Kingston V300 de 120Go
1 Carte Fibre Channel 4gb QLogic QLE2460
ESXi 5.5
Processeur Intel Core i7 4770s
Carte mère ASUS H87M-E C2
32Go DDR3
2 Cartes Intel Pro 1000 CT
1 Carte Fibre Channel 4gb QLogic QLE2460
II. Mise à jour des cartes HBA QLogic
Les cartes ont été mise à jour avec le dernier firmware disponible à savoir 3.63. Au cas où cela se produirait les cartes étaient forcées en 2Gb après la mise à jour du firmware. La modification de ce paramètre se trouve dans le BIOS des cartes QLogic (Data rate).
La gestion des services sous OmniOS se fait avec la commande svcadm.
svcadm enable ssh
Pour avoir le statut du service (ONLINE,OFFLINE ect) il faut utiliser la commande svcs. Example : svcs ssh
Installation des paquets serveur de stockage
pkg install storage-server
Activation du service stockage :
svcadm enable stmf
III. Configurer le filesystem ZFS et les volumes
L’avantage de OmniOS ou des systèmes dérivant de Solaris est d’embarquer le système de fichier ZFS (http://en.wikipedia.org/wiki/ZFS) avec ses principaux avantages :
Le zpool est un espace virtuel de stockage (un pool) regroupant plusieurs médias de stockage physique. Il va être représenté comme un seul disque virtuel.
Afin de créer notre pool nous avons besoin d’identifier nos disques. Il est possible d’obtenir cette information avec la commande format.
Ce qui nous intéresse ici c’est le nom des disques c1xxxxxx par exemple c1t50024E90034D7D6Fd0
Une fois ceci fais nous passons à la création du zpool que nous nommerons ZVM. Celui-ci sera constitué de 2 vdev en miroir, 1 cache L2 (L2ARC) et 1 slog (ZIL) + disque en spare (ayant 5 disques SATA de marque et modèle identique).
Voici la commande de création de notre zpool. Il faut remplacer hddX par le nom du disque vu précédemment (c1xxxx).
La priorité de ZFS étant de conserver l’intégrité des données plutôt que fournir des performances pures (même s’il est adroit aussi sur ce point avec un peu de matériel !).
Je me permets de préciser que les performances du pool de stockage (zpool) dérive de beaucoup de facteurs et notamment le nombre de vdev dans le pool ainsi que leurs géométries.
Maintenant que ceci est fait il faut configurer certaines options ZFS. Pour afficher les options/informations disponibles sur notre zpool il faut faire zfs get all <zpool>
Options utilisés sur cette installation :
zfs set recordsize=8k ZVM
Définit la taille des blocs pour notre zpool
zfs set compression=lz4 ZVM
Active la compression lz4
zfs set mountpoint=/volumes/ZVM ZVM
Changement du point de montage par défaut
zpool set autoreplace=on ZVM
Remplace le disque défectueux par le disque de spare automatiquement si une erreur est détectée
zpool set autoexpand=on ZVM
Permet d’étendre le pool dans le futur
zfs set quota=1.4T ZVM
Une des best practice étant de réserver environ 20% d’espace libre sur un zpool afin d’éviter une dégradation des performances.
1.76To – 20% = 1.4To (taille du zpool – 20%)
Désormais nous devons créer nos volumes (zvol) block afin de les présenter à l’hyperviseur au travers de la liaison Fibre Channel.
Nous allons donc créer 2 zvol dans les 1.4To restant ce qui nous donne environ 690Go par zvol.
Côté hyperviseur, il faut aller dans Configuration > Storage Adapters
Il ne nous reste plus qu’à les formater en VMFS , il faut pour cela aller dans Configuration > Storage > Add Storage
Et vous voilà avec votre Fibre Channel @home !
III. Le mot de la fin ..
Il est vrai que la machine stockage peut paraître surdimensionné pour du stockage en comparaison avec un NAS. Avec ZFS, certains paramètres comme le CPU ou la RAM ne doivent pas être négligés (tout dépend aussi des besoins et exigences de chacun). ZFS est friant de la mémoire ram, car il s’en sert environ à 80% comme cache pour ses opérations (ARC)
Capture Cacti du lab (paramètre arc_size)
La tendance est d’environ 1Go de RAM par To de stockage supplémentaire tout en ayant une base d’au moins 2 ou 4Go.
Le processeur permet de gérer plus sereinement la compression, mais également la déduplication qui est vraiment gourmande en utilisation CPU. Je vous conseille d’activer la compression (lz4), mais pas déduplication.
Je posterais quelques tests de performance un peu plus tard afin d’avoir une idée. Pour le moment je dispose de 8 VM de toute sorte (Active Directory, Exchange 2013, serveur web, Veeam B&R) tout OS confondu (OpenBSD, Debian, Windows serveur 2012) qui démarrent, fonctionnent et réagissent rapidement.
Pour aller plus loin voici les différents liens qui m’ont permis de réaliser ce tutoriel :
Lors de l’utilisation de machines virtuelles sous VMware ESXi, il peut arriver qu’une machine virtuelle soit visuellement allumée dans le client vSphere mais que le vSphere lui estime qu’elle est allumée. Cet état intermédiaire et plutôt curieux oblige une extinction forcée et manuelle en ligne de commandes de la VM concernée.
Lorsque l’on tentera d’éteindre depuis le client vSphere la VM, on obtiendra le message d’erreur suivant : “L’opération tentée ne peut être effectué dans l’état actuel (Désactivé).”
Avant de commencer, vous devez activer le SSH et le Shell sur votre serveur ESXi pour initier une connexion à distance en SSH (port 22).
II. Procédure
Commencez par lister toutes les VMs exécutées sur cet ESXi :
vim-cmd vmsvc/getallvms
On obtient une liste :
On repère l’identifiant (ID) de la VM que l’on souhaite éteindre, ici 268. On demande à obtenir l’état de cette VM :
vim-cmd vmsvc/power.getstate 268
Du point de vue de l’ESX, cette VM est allumée :
“Retrieved runtime info Powered on”
On va tenter d’éteindre la machine virtuelle proprement mais il y a de fortes chances pour que ça ne fonctionne pas… Indiquez la commande ci-dessous avec votre ID :
vim-cmd vmsvc/power.off 268
Ceci ne fonctionne pas :
“Powering off VM: Power off failed”
Désormais nous allons réaliser un arrêt forcé mais pour cela il faut obtenir le “World ID” correspondant à la VM. On va lister les processus VM en fonctionnement :
esxcli vm process list
On repère la ligne WorldID de la VM ciblée :
Ma VM avec l’ID 268 dispose du WorldID 4365, donc pour forcer l’arrêt cela donnera :
esxcli vm process kill -t force -w 4365
Enfin, on vérifie que la VM est bien éteinte avec la commande que l’on a utilisée précédemment :
vim-cmd vmsvc/power.getstate 268
C’est tout bon puisque la VM est éteinte :
“Retrieved runtime info Powered off”
Il ne reste plus qu’à démarrer votre VM depuis le client vSphere et tout doit rentrer dans l’ordre !
OVH propose à ses clients d'activer un espace de stockage dédié aux sauvegardes au travers la fonctionnalité "Backup Storage" accessible directement depuis l'espace client. L'espace de stockage accessible sans surcoût est de 500 Go chez OVH, ce qui est intéressant. Du côté de SoYouStart (marque OVH), la capacité proposée gratuitement est 100 Go.
Si vous utilisez un serveur dédié OVH, sachez qu'il est possible de monter l'OVH Backup Storage sur VMware ESXi (Free ou sous licence) en NFS pour y stocker vos sauvegardes de machines virtuelles ! 🙂
Je vous montre comment procéder dans ce tutoriel, et je pense qu'un autre article sortira pour la sauvegarde des VMs.
II. Activer et configurer OVH Backup Storage
Sur votre espace client OVH, dans la partie serveur dédié, accédez à votre serveur et ensuite à la partie "Backup storage". Il vous sera proposé de l'activer, quelques minutes plus tard il sera actif. Plusieurs informations importantes sont à noter pour la suite : le nom et l'identifiant, nous les utiliserons pour établir la connexion.
Ensuite, vous devez activer le protocole NFS à partir de l'adresse IP publique correspondante à votre serveur ESXi. Ce qui nous donne l'état suivant :
III. Ajouter OVH Backup Storage sur ESXi
Connectez-vous à l'interface web de votre ESXi, et sur la gauche cliquez sur "Stockage". Ensuite, cliquez sur "Nouvelle banque de données".
Sélectionnez "Monter une banque de données NFS".
Nous voilà à la partie la plus importante : la configuration de la connexion à l'espace de stockage OVH.
Nom : le nom du datastore tel qu'il s'affichera sur ESXi (préférez un nom sans espace)
Serveur NFS : le nom indiqué sur l'interface de gestion OVH, sous la forme "ftpback-xxxx-xxx.ovh.net"
Partage NFS : vous devez indiquer /etc/ftpbackup/ qui est le chemin imposé par défaut suivi du nom de votre serveur, récupérable également sur l'interface OVH. Ce qui donne par exemple : /export/ftpbackup/nsxxxxxxx.ip-xx-xx-xx.eu
Version NFS : NFS 3
Poursuivez et cliquez sur "Terminer", si tout est OK votre espace de sauvegarde est à présent monté sur votre ESXi ! 🙂
Maintenant que cet espace de stockage est connecté à votre ESXi, il va falloir l'exploiter. Attention, ne l'utilisez pas pour héberger des machines virtuelles à exécuter, ce n'est pas du tout prévu à cet effet... Dans cet exemple, je monte l'espace de stockage sur l'ESXi mais il est bien entendu possible d'accéder à cet espace directement depuis une VM à l'aide de trois protocoles différents : NFS, CIFS (SMB) et FTP.
Les solutions de sauvegarde de machines virtuelles telles que Veeam, Altaro ou encore Naviko sont performantes, mais également coûteuses. Bien que proposée en version gratuite, l'utilisation n'est pas sans contrainte (nombre limité de VMs, planification impossible, etc.). Certains produits sont même incompatibles avec la version Free de VMware ESXi.
Si vous avez besoin de sauvegarder vos machines virtuelles sur ESXi à moindre coût, alors il existe un outil gratuit nommé GhettoVCB. Ce dernier existe depuis plusieurs années et il s'avère performant, si ce n'est qu'il faut passer un peu de temps à le configurer, car tout se joue en ligne de commande.
Dans ce tutoriel, je vous propose de voir comment sauvegarder vos VM sur ESXi avec GhettoVCB. Pour stocker vos sauvegardes, nous avons le choix entre : stockage local, SAN ou montage NFS.
II. Installer GhettoVCB sur ESXi
Depuis votre machine, téléchargez la dernière version de GhettoVCB depuis Github à l'adresse suivante : GhettoVCB
Lorsque le fichier est téléchargé, vous devez l'envoyer sur le serveur ESXi via SSH, dans le dossier "/tmp" (par exemple) avec WinSCP si vous êtes sur Windows. Continuez une fois le fichier transféré.
Maintenant, vous pouvez fermer WinSCP. Connectez-vous sur votre ESXi en ligne de console via l'accès SSH. Ensuite, installez l'outil GhettoVCB fraîchement transféré :
Pour le reste, ce sont des fichiers de configuration que je vais vous présenter :
/etc/ghettovcb/ghettoVCB.conf : fichier de configuration principal qui contient les paramètres de sauvegarde globaux de l'outil
Deux fichiers de template comme exemple pour la sauvegarde et la restauration (ghettoVCB-vm_backup_configuration_template / ghettoVCB-restore_vm_restore_configuration_template)
vms_to_backup : fichier où l'on déclare les VMs à sauvegarder (fichier facultatif)
vms_to_restore : fichier où l'on déclare la ou les machines virtuelles à restaurer
Passons à l'utilisation du script GhettoVCB 🙂
III. Configuration de GhettoVCB
Je vous propose de voir comment configurer GhettoVCB, ouvrez le fichier de configuration :
Dans le cas où l'on utilise l'espace de stockage OVH Backup Storage pour les sauvegardes, il est nécessaire de le monter via NFS au préalable. Cela est plus intéressant comme ça il est visible au niveau ESXi et vous pouvez parcourir la banque de données directement depuis l'interface web.
Dans le fichier de configuration, il y a trois paramètres indispensables :
VM_BACKUP_VOLUME : la cible où vous souhaitez stocker vos backups
DISK_BACKUP_FORMAT : la valeur "thin" correspond à dynamique ça veut dire que le disque de la sauvegarde utilisera uniquement l'espace disque utilisé dans la VM, il n'est pas statique, ce qui permet d'optimiser la taille utilisée par vos backups (mais allonger le temps de l'opération). Autrement dit, cette option permet de choisir le format du VMDK de la sauvegarde. Les autres valeurs sont : zeroedthick, eagerzeroedthick, et 2gbsparse
VM_BACKUP_ROTATION_COUNT : le nombre de sauvegardes à conserver pour chaque VM
ENABLE_COMPRESSION : lorsque cette option est activée, la sauvegarde est compressée une fois qu'elle est réalisée. La tâche de compression peut s'avérer longue, je préfère ne pas utiliser cette fonctionnalité.
Sachez que ces paramètres peuvent être écrasés pour une VM en particulier qui ne rentrerait pas dans le moule de base en créant un fichier de configuration spécifique. Si vous souhaitez mettre en place les notifications par e-mail, configurez les différentes options qui commencent par "EMAIL_".
La configuration étant définie, on va tester !
IV. Exécuter une sauvegarde avec GhettoVCB
L'exécution d'une sauvegarde s'appuie sur le script "ghettoVCB.sh" comme je le disais précédemment. Celui-ci supprime un ensemble de paramètres. Voici quelques exemples :
Sauvegarder une seule VM
./ghettoVCB.sh -m <nom-VM>
Sauvegarder toutes les VMs de cet ESXi
./ghettoVCB.sh -a
Sauvegarder les VMs contenues dans le fichier "/etc/ghettovcb/vms_to_backup" (le chemin peut-être différent)
./ghettoVCB.sh -f /etc/ghettovcb/vms_to_backup
Vous devez créer ce fichier et indiquer un nom de fichier par ligne, tout simplement.
Au niveau de l'espace de stockage, l'outil crée un dossier avec le nom de la VM, ici "ITC-DESKTOP" puis un sous-dossier par sauvegarde de cette VM.
Comme tout logiciel de sauvegarde, GhettoVCB crée un snapshot de la VM le temps de la sauvegarde. Ce dernier est automatiquement supprimé à la fin du processus.
Si vous obtenez le message "Final Status: All VMs backed up OK!" à la fin, c'est tout bon 🙂
V. Planification de la sauvegarde GhettoVCB
Faire des sauvegardes, c'est bien. Planifier les sauvegardes, c'est encore mieux 🙂
Cela est possible sur un serveur ESXi mais il y a quelques manipulations (un peu chiante) à réaliser. Suivez ces étapes pas à pas.
Nous allons modifier les droits sur le fichier crontab de root et ensuite éditer le fichier :
chmod +w /var/spool/cron/crontabs/root
vi /var/spool/cron/crontabs/root
Maintenant, à la fin du fichier, ajoutez la ou les lignes en fonction de vos besoins pour planifier les sauvegardes via GhettoVCB. Par exemple, pour sauvegarder la VM "ITC-DESKTOP" à 23h00 tous les jours :
Pour prendre en compte les changements, nous devons recharger le processus cron. Pour cela, identifiez son PID avec la commande suivante :
cat /var/run/crond.pid
Tuez le processus, en adaptant la commande ci-dessous avec le bon PID :
kill <PID>
Relancez le processus :
crond
En fait, il y a un problème : le fonctionnement d'ESXi fait que lorsque l'on va redémarrer le serveur, les tâches planifiées seront perdues. Nous allons devoir intégrer au script local.sh l'ajout de nos tâches planifiées cron, puis le rechargement du cron. Ainsi, tout sera automatiquement recréé à chaque reboot du serveur.
La deuxième ligne permet d'ajouter au cron la tâche à planifier. Si besoin, dupliquer cette ligne autant de fois que nécessaire. Il est important de valider que ça fonctionne en redémarrant votre serveur ESXi, à vous de trouver le meilleur moment pour le faire 🙂
VI. Restaurer une VM
Pour restaurer une machine virtuelle, il y a là aussi, une procédure bien précise à suivre.
Tout d'abord, il faut se positionner dans le dossier ghettovcb :
cd /etc/ghettovcb/
Créer une copie du template (c'est bien de le garder de côté !) pour configurer notre tâche de restauration dans un fichier à part :
Elle est constituée de 4 paramètres séparés par un point-virgule :
- Le chemin vers le sauvegarde (source)
- Le chemin vers le stockage de destination (où restaurer la VM)
- Le format du disque (1 pour zeroedthick, 2 pour 2gbsparse, 3 pour thin et 4 pour eagerzeroedthick)
- Le nom de la VM à restaurer
Lorsque tout est bon pour vous, exécutez la sauvegarde en appelant votre fichier de config que nous venons de créer :
Lorsque l'on déploie une machine virtuelle sur un environnement VMware, il convient d'installer les VMware Tools au sein de la machine virtuelle, qu'elle tourne sous Windows ou Linux. Dans ce tutoriel, je vais prendre une machine virtuelle sous Debian 10, sur un ESX de VMware, et vous expliquer comment installer les VMware Tools en ligne de commande. La procédure est similaire sur d'autres distributions Linux.
L'installation des VMware Tools est importante pour bénéficier de certaines fonctionnalités, mais aussi pour optimiser les interactions entre la machine virtuelle et l'hyperviseur VMware. Que ce soit un serveur VMware ESX ou simplement VMware Workstation / Player.
Synchronisation de l'heure entre l'hyperviseur et la VM
Éteindre proprement la VM directement à partir de l'hyperviseur
Glisser-déposer et Copier-coller entre la VM et l'hôte physique (dans le cas d'une installation en mode graphique de Debian)
Etc.
Nous verrons dans ce tutoriel qu'il y a deux façons d'installer les outils VMware dans une VM Linux : VMware Tools ou Open-VM Tools.
II. Installer les VMware Tools sous Debian
A. Monter les sources VMware Tools dans la VM
Dans le système d'exploitation invité, nous devons monter le "CD" qui contient les sources d'installation des VMware Tools. Pour cela, effectuez un clic droit sur la VM, puis : SE invité > Installer VMware Tools.
La suite de l'installation s'effectue en ligne de commande sur le serveur : soit en console directement, soit au travers d'une connexion SSH.
B. Réaliser l'installation des VMware Tools
On va devoir monter notre CD d'installation sur la machine, ce qui nécessite de créer un point de montage. Pour les commandes à venir, je pars du principe que je suis connecté avec un compte "root" sur la machine, mais sinon ajoutez "sudo" devant les commandes.
mkdir /mnt/cdrom
Maintenant que le point de montage "cdrom" est créé, on va lui associer le périphérique "cdrom", comme ceci :
mount /dev/cdrom /mnt/cdrom
Vous devriez obtenir le retour suivant dans la console :
mount: /mnt/cdrom: Attention: périphérique protégé en écriture, monté en lecture seule.
À partir de ce moment-là, le contenu des VMware Tools est accessible dans le dossier "/mnt/cdrom". Maintenant, on va se positionner dans le dossier "/tmp" pour extraire à cet emplacement le contenu de l'archive TAR.GZ correspondante aux VMware Tools.
cd /tmp
Ensuite, avec la commande "tar" on va décompresser le contenu du fichier "VMwareTools-10.3.22-15902021.tar.gz". Attention, le nom du fichier peut varier en fonction de la version de votre hyperviseur VMware.
tar xzpf /mnt/cdrom/VMwareTools-10.3.22-15902021.tar.gz
Sinon, on peut utiliser la commande suivante qui fonctionnera peu importe la version grâce au wildcard :
tar xzpf /mnt/cdrom/VMwareTools-*.tar.gz
Les sources d'installation sont désormais copiées en local sur notre machine virtuelle : on peut démonter le point de montage "/mnt/cdrom" car nous n'avons plus besoin du CD.
umount /mnt/cdrom
Il ne reste plus qu'à exécuter le script Perl d'installation. Il se situe dans le dossier "vmware-tools-distrib", ce dernier étant lui-même dans "/tmp" (dossier dans lequel nous sommes actuellement).
cd vmware-tools-distrib
Une fois dans le dossier, exécutez le script d'installation :
./vmware-install.pl
Validez l'installation en indiquant "yes" et appuyez sur "Entrée". Nous reviendrons en fin d'article sur le message qui s'affiche au sujet du paquet "open-vm-tools".
Ensuite, il y a une série de questions : dans la majorité des cas, appuyez simplement sur "Entrée" pour valider, sauf si vous souhaitez répondre autre chose que la valeur par défaut. Il n'est pas nécessaire d'activer toutes les fonctionnalités proposées par les VMware Tools.
L'installation doit s'effectuer sans encombre sur votre machine ?
C. Supprimer les sources
Pour finir le travail, nous allons supprimer le dossier avec les sources des VMware Tools :
rm vmware-tools-distrib/ -Rf
Terminez par un redémarrage de votre machine pour finaliser l'installation.
IV. L'installation avec Open-VM Tools
Open-VM Tools (OVT), c'est l'équivalent des VMware Tools, mais sous licence open source, supportée par VMware. Il s'agit d'une alternative stable qui offrira les mêmes fonctionnalités, mais son fonctionnement est différent, notamment pour les mises à jour.
Pour mettre à jour les VMware Tools, il faut passer par l'hyperviseur directement comme nous avons pu le voir, et on peut gérer les mises à jour avec vSphere Update Manager. En comparaison, pour mettre à jour Open-VM Tools, il faut mettre à jour le paquet dans la VM directement : comme n'importe quel autre paquet.
L'installation est très simple puisque ce paquet est disponible dans les dépôts officiels de Debian (et d'autres distributions). Il suffit d'exécuter la commande suivante :
apt-get install open-vm-tools
Dans le cas où vous utilisez un système avec une interface graphique, utilisez plutôt cette commande pour installer un paquet supplémentaire :
Aujourd'hui, nous allons voir comment créer des modèles de VM sous VMware afin de créer des VMs de "référence" pour vos déploiements. Celles-ci vous permettent de pouvoir créer des machines virtuelles à la volée, sans passer par l'étape fastidieuse de création de VM classique.
Un modèle de machine virtuelle est une image d'une VM personnalisable afin de répondre à certaines exigences métier. Un template peut être utilisé plusieurs fois à des fins de déploiement en masse d'instances de VMs. Après avoir déployé une VM à partir d'un modèle, elle n'est plus liée à son modèle, et est donc indépendante.
Note : certaines informations non essentielles de ce tutoriel ont été masquées.
II. Modèle VS clone VS OVA/OVF
A. La différence entre un clone de VM et un modèle de VM
Un clone de VM "standard" est une copie exacte d'une VM à un instant T qui n'est pas personnalisable (au niveau de l'OS, et certaines ressources physiques). Si vous devez cloner périodiquement une machine virtuelle en cours d'exécution, les clones résultant de celle-ci seraient différents les uns des autres. Un modèle de machine virtuelle vous aide à éviter ces problèmes, car il ne peut pas être modifié* et ne peut jamais être en cours d'exécution. On évite alors les erreurs de manipulations...
VMware fournit des outils qui simplifient la personnalisation du système d'exploitation invité pour les clones de VM. Un point que nous aborderons dans le troisième chapitre de ce tutoriel.
*Vous ne pouvez pas la mettre sous tension et modifier une machine modèle dès lors qu'elle a été créée, afin que personne ne puisse accidentellement démarrer/modifier la machine virtuelle utilisée comme modèle. Si vous souhaitez modifier un modèle, vous devez convertir un modèle en machine virtuelle, modifier la machine virtuelle, puis convertir la machine virtuelle modifiée en un nouveau modèle. Cette approche offre une plus grande sécurité (et une méthode plus « infaillible ») que les clonages classiques de VM.
B. La différence entre un modèle de VM et un modèle OVA/OVF
Les modèles OVA et OVF sont utilisés pour distribuer des logiciels préconfigurés en tant qu'appliances virtuelles. Ils peuvent contenir plusieurs machines virtuelles, ce qui est utile dans les cas où une application se compose de plusieurs instances de VM qui doivent fonctionner indépendamment.
Pour rappel :
.OVF est un format de fichier qui contient des métadonnées, des disques virtuels et des éléments de fichier décrivant les machines virtuelles, ainsi que des informations supplémentaires importantes pour le déploiement et le fonctionnement de l'application.
.OVA est un package qui englobe les fichiers cités précédemment dans une archive de fichiers unique (plus pratique selon moi).
Les modèles de VM ne sont pas compressés. Ils sont accessibles uniquement à partir d'emplacements disponibles pour vCenter (datastore, etc.) et ne sont pas destinés à être partagés avec d'autres organisations.
III. Environnement de mise en place
Plantons le décor, voici ce que nous allons utiliser :
Un VCSA (VMware vCenter Server Appliance), avec un ou plusieurs hôtes ESXi connectés
Une machine virtuelle (Windows) fonctionnelle disposant des VMware tools installées. Dans mon cas, je vais utiliser une machine Windows 10 21H1 pour réaliser le didacticiel.
Option : personnaliser votre machine virtuelle en installant un ensemble de logiciels pour vos besoins, les besoins d'une entité particulière, etc. Je vous recommande d'utiliser le logiciel Ninite afin de faire une seule installation groupée des logiciels les plus connus et les plus utiles, que vous pourriez avoir besoin. Par exemple : WinRar, Firefox, Chrome, Visual Studio Code, etc.
Aperçu de la VM qui doit devenir un modèle
IV. Création du modèle
Depuis une machine virtuelle, fraichement installée, cliquez sur : action, clone, clonez vers un modèle.
Choisissez un nom pour cette future VM de référence. Il doit être différent du nom de la machine originale (ici : Win-10-Pro-21H1-Desktop). Le nom pour cette machine de référence sera dans mon cas Windows-10-Pro-21H1-Desktop-Master.
VMware - Assistant "Cloner la machine virtuelle vers un modèle"
Il vous est demandé par la suite de choisir la ressource de calcul pour héberger votre futur VM template. Choisissez par défaut votre cluster d'hôtes ESXi, ou un hôte ESXi en particulier.
Puis, sélectionnez le datastore où vous souhaitez stocker le modèle de machine virtuelle.
Ensuite, un récapitulatif des actions effectuées s'affiche à l'écran. Dès que vous cliquez sur "Finish", le template va se créer. Patientez pendant la création.
V. Création d'une spécification de personnalisation d'invité VM
La personnalisation du système d'exploitation invité est une fonctionnalité de vSphere qui permet aux utilisateurs de modifier les paramètres du système d'exploitation invité Linux ou Windows d'une Template de VM. Pour rappel l'approche traditionnelle était de :
Démarrer manuellement une machine virtuelle,
Se connecter au système d'exploitation invité
Modifier la configuration dans différentes parties du système d'exploitation via une interface graphique ou l'invite de commande,
etc.
Cette méthode est lourde et fastidieuse. Avec la personnalisation du système d'exploitation invité de VMware, vous pouvez créer un fichier de personnalisation et utiliser celui-ci pour personnaliser chaque instance de VM générée à partir du modèle. Vous pouvez facilement modifier les paramètres du réseau, le nom d'hôte, le nom d'utilisateur, le mot de passe, le fuseau horaire, les paramètres de licence, le SID (identifiant de sécurité) et le domaine/workgroup.
Remarque : les paramètres de personnalisation pour Linux et Windows sont différents. La procédure aussi. Les problèmes de compatibilité sont malheureusement nombreux en fonction des distributions. Cette fonctionnalité sera plus utile et exploitable pour un environnement virtuel Windows. Je ne vais donc pas la développer ici. Pour plus d'informations, reportez-vous à la documentation officielle de VMware.
Pour créer votre "procédure d'instanciation de template", rendez-vous dans > Menu > Stratégies et profils
Puis, créez une nouvelle "spécification de personnalisation d'une VM" (sacré charabia ^^). Renseignez les informations suivantes :
La famille de l'OS concernée (Windows dans mon cas)
Si vous souhaitez utiliser l'utilitaire SYSPREP. Personnellement, je n’y vois aucun intérêt sachant que VMware propose de générer automatiquement un nouveau SID et cela nous évite une tâche fastidieuse.
Définissez par la suite le nom du propriétaire. Par défaut, ici je vais mettre User. Le nom du compte que j'ai crée lors de l'installation de Windows 10.
Puis, nous pouvons personnaliser le hostname (nom NETBIOS) de l'hôte Windows qui sera généré. Dans mon cas, je vais préfixer le nom d'hôte de chaque machine avec "PC-itco-" suivi d'un numéro d'identification random fourni par VMware, mais vous pouvez choisir de préfixer le nom de la machine, lors du déploiement de la VM, ou via une extension X via VCSA.
VMWare vous laisse le choix d'activer ou non Windows 10 depuis son formulaire en précisant une clé d'activation.
Vous devez ensuite définir le mot de passe du compte administrateur du template.
Puis, sélectionnez ensuite le bon fuseau horaire en fonction de votre géolocalisation.
Si vous souhaitez injecter un script PowerShell/batch, cette section est faite pour vous :). Dans mon cas, je ne vais pas l'utiliser.
Choisissez ensuite vos paramètres réseau. Dans mon cas, je vais utiliser l'option par défaut DHCP (IP+DNS), mais la deuxième option vous permet d'entrer manuellement les paramètres IP/DNS lors du déploiement d'une nouvelle VM.
La 9e étape nous octroie la possibilité de joindre directement la nouvelle machine déployée à un domaine Active Directory. Dans le cadre du tutoriel, nous allons nous en passer. ^^
Enfin, un récapitulatif vous est présenté. Il suffit de cliquer sur "Finish".
Le profil sera stocké, dans le menu : Menu > Stratégies et profils. À tout moment vous pouvez l'éditer, sans en créer un nouveau.
VI. Déploiement d'une machine virtuelle à partir de notre modèle
Afin de tester notre template, créez une machine virtuelle, cochez l'option "Déployer depuis un modèle", puis cliquez sur "Next".
Je vais donc choisir de déployer une VM Windows 10, à l'aide du template que je viens de réaliser.
Je lui assigne le nom suivant : Win10-21H1-Test. Remarque : le nom de la machine virtuelle, ce n'est pas son hostname au sein de l'OS.
Par la suite, je choisis d'utiliser mon cluster d'ESXi, pour gérer la partie gestion des ressources de calcul.
Je sélectionne un emplacement pour le stockage de cette future VM.
Arrive une étape importante, où nous pouvons choisir de cocher les options suivantes :
Personnaliser l'OS de la future VM (via le fichier de personnalisation créé plus tôt)
Personnaliser le matériel de cette VM (CPU, RAM, stockage (agrandir le disque dur, choisir le type de provisionnement : thin/thick), etc.)
La mettre sous tension dès lors que celle-ci sera déployée.
Évidemment, je vais sélectionner mon profil personnalisé.
Ensuite, si vous le souhaitez, vous pouvez ajuster les ressources physiques. Ce qui est l'occasion d'agrandir la taille du disque dur virtuel, par exemple.
Enfin, VCSA nous présente un récapitulatif des informations que nous lui avons fournies. Après quoi il déploiera la machine virtuelle.
Le déploiement de celle-ci prend environ une bonne minute. Et voilà, notre machine Win10-21H1-Test, est déployée et opérationnelle !
Nous pouvons constater que le nom d'hôte de la machine déployée a bien été modifié automatiquement lors du déploiement de celle-ci, ce qui confirme que la customisation de l'OS a bien été réalisée par VCSA.
VII. Conclusion
J'espère que l'article vous aura plu ! Avant de vous laisser, voici deux rappels pour conclure :
- Un modèle de machine virtuelle est une image spécifique d'une VM qui peut être utilisée pour créer des instances de VM lors de déploiements en masse. Les templates ne peuvent pas être modifiés et activés comme les machines virtuelles ordinaires, ce qui améliore la sécurité.
- La spécification de personnalisation de l'OS du template vous aide à personnaliser les paramètres du système d'exploitation tels que la configuration réseau, le nom de l'ordinateur, le fuseau horaire, injecter un script Batch/Powershell, etc. Cela rend vos déploiements de VM plus rapide et plus pratique. Vous bénéficiez d'avantages importants tel que l'automatisation, la réduction du nombre d'erreurs, et la standardisation de vos machines.
