Sélectionner une page
Print Friendly, PDF & Email

⚠ MAJ février 2024 : En ce début d’année, j’ai décidé de mettre à jour l’hyperviseur VMware ESXi de mon domicile de la version 7 à la version 8. J’ai donc suivi la procédure que je décris dans cet article pour télécharger la nouvelle version et la clé de licence gratuite. Mais en arrivant sur la page avec les liens de téléchargement et d’information sur la licence, le paragraphe dédié à la licence ne s’affiche pas…

Après quelques recherches sur le Web, je tombe sur cet article de VMware qui précise que, suite au rachat de VMware par Broadcom, la version gratuite de VMware ESXi ne sera dorénavant plus proposée…

J’ai fini par installer la version 8 en achetant une licence un site Web qui en propose à des prix défiants toute concurrence mais pour ceux qui auraient un projet identique, la question de passer à une solution plus ouverte et gratuite se pose. D’autant plus qu’il existe des solutions de virtualisation Open Source performante comme Proxmox VE (distribution Linux) et VirtualBox (package Linux ou appli Windows).

 

Avant d’aborder la question du firewall, il est nécessaire d’évoquer l’architecture de l’hyperviseur VMware ESXi. L’éditeur aborde sur son site Web la question de la sécurité et propose une architecture à double firewall afin de créer une DMZ virtuelle entourée par des firewalls externes et internes installés sur deux VM (Machine Virtuelle) différentes :

C’est la première architecture que j’ai mise en œuvre sur mon serveur VMware ESXi avant de me rendre compte que ça compliquait beaucoup la configuration et… que je ne suis pas non plus une entreprise.

Je suis donc revenu à l’architecture 2015/2018 à un seul firewall à la différence que ce n’est plus une machine physique dédiée mais un serveur hôte VMware ESXi et une VM connectée à différentes zones (DMZ, LAN…) via différents vSwitch (commutateur standard virtuel) eux-mêmes connectés (ou non) à différents adaptateurs réseaux physiques du serveur hôte :

Infra_La_Maison_Bleue_Net_2020_009Télécharger

J’ai appliqué ce même principe sur le serveur dédié loué chez Scaleway, anciennement Online, filiale d’Iliad la maison mère de Free.

Hyperviseur1 VMware ESXi (LAN)

Avant de détailler la configuration du serveur VMware installé dans la baie, voici un schéma qui représente la répartition des VM et des vSwitch (commutateurs virtuels standards) ainsi que leurs liens avec les différentes interfaces physiques du serveur hôte VMware ESXi :

Infra_La_Maison_Bleue_Net_2020_010_1Télécharger

La VM du firewall Untangle est donc la seule à posséder un lien avec tous les vSwitch et toutes les interfaces physiques sauf avec le vSwitch dédié au management de VMware ESXi (vSwitch0).

La carte-mère Supermicro du serveur hôte possède trois ports RJ45 1Gb/s dont un est dédié à l’administration IPMI du serveur et ne sera donc pas découvert par WMware ESXi. J’ai ajouté deux cartes réseaux externes : une carte Ipolex/Intel avec deux ports RJ45 1Gb/s et une carte Intel X710-DA4 avec 4 ports SFP+ 10 Gb/s.

VMware ESXi va nommer ces différentes interfaces réseaux physiques de VMNIC0 à VMNIC7. Elles seront connectées aux équipements réseaux suivants dans la baie :

MAJ janvier 2022 : suite à une mise à jour de VMware ESXi 6.7 U2 à 7.0 U2, l’hyperviseur ne reconnait plus la carte externe Ipolex. Les interfaces réseaux physiques sont maintenant comprises entre VMNIC0 et VMNIC5 :

A noter que la fonction WAN de la Freebox Delta S concerne en réalité le port LAN SFP+ 10 Gb/s mais il est vu tel un « WAN » car la box est en mode bridge. Les trois ports utilisés sur la Freebox sont les suivants (les ports RJ45 ne sont pas utilisés) :

Infra_La_Maison_Bleue_Net_2020_017Télécharger

Voici la page d’accueil du serveur VMware ESXi :

Réseau

Groupes de ports

Dans le menu Mise en réseau et l’onglet Groupes de ports, chaque groupe de ports, qu’on affectera par la suite aux différents VM, est associé à un commutateur standard ou vSwitch standard :

Le groupe de ports LAN est associé au vSwitchLAN et sa topologie est décrite sur cette page :

Dans les propriétés du groupe de ports, le VLAN est défini à 4095, ce qui représente tous les VLAN possibles. Le VLAN des groupes de ports DMZ1 et DMZ2 est également spécifié à cette même valeur (les VLAN seront précisés sur les serveurs et les switches) :

Le groupe de ports WAN est associé au vSwitchWAN et son VLAN est le VLAN 0 (pour tous les groupes de ports WAN) :

Le groupe de ports DMZ1 est associé au vSwitchDMZ1 et son VLAN est le 4095 (multi VLAN) :

Le groupe de ports DMZ2 est associé au vSwitchDMZ2 et son VLAN est le 4095 (multi VLAN) :

Le groupe de ports 4G est associé au vSwitch4G et son VLAN est le 0 (pour tous les groupes de ports WAN) :

Le groupe de ports Management Network est associé au vSwitch0 et son VLAN est le 10 (VLAN LAN) :

Commutateurs virtuels

Dans l’onglet suivant, Commutateurs virtuels, les différents vSwitch standard sont définis :

Par exemple pour le vSwitchLAN utilisé par les VM LAN et DOMO :

Dans le menu Modifier les paramètres, le MTU est fixé à la valeur 9000 (Jumbo Frame) pour le vSwitchLAN mais aussi pour les vSwitchDMZ1 et vSwitchDMZ2 (pour les autres vSwitch, il reste à 1500). Les Liaisons montantes sont aussi attribuées au vSwitch, dans le cas du LAN il s’agit des interfaces physiques vmnic5 et vmnic6 respectivement connectées aux switches SwitchC1 et SwitchC2.

Dans Association des cartes réseaux, l’Equilibrage de la charge est définit sur Route basée sur l’ID du port d’origine et la Détection de basculement de réseau sur Etat de lien seulement :

Le vSwitch0, le management de l’hyperviseur VMware ESXi :

Le vSwitchWAN, connecté à la Freebox Delta S sur le port LAN SFP+ 10 Gb/s :

Le vSwitch4G, connecté au routeur 4G :

Le vSwitchDMZ1 pour les VM de la DMZ1 :

Le vSwitchDMZ2, différent de la première DMZ par des droits plus étendus sur le firewall pour la seule VM présente sur ce vSwitch, le serveur OpenVPN Access Server :

Je n’ai pas créé de groupe de ports DOMO et de commutateur virtuel vSwitchDOMO pour héberger le serveur Domotique à l’installation du serveur WMware pour plus de facilité. Le serveur Domotique utilise le vSwitchLAN, la différenciation des VLAN LAN et DOMO se fera sur les switch et directement sur le serveur Linux. Idem pour les VLAN SURVEILLANCE, WIFI, WIFIGUEST.

NIC physiques

L’onglet NIC physiques liste les différents adaptateurs réseaux :

NIC VMkernel

L’onglet NIC VMkernel concerne les adaptateurs réseaux utilisés pour l’administration de l’hyperviseur :

Piles TCP/IP

L’onglet Piles TCP/IP permet d’indiquer la passerelle et le serveur DNS :

Règles du pare-feu

L’onglet Règles du pare-feu permet de définir les règles de firewall. J’ai modifié les règles vSphere Web Access et vSphere Web Client en précisant les sous-réseaux autorisés à accéder à l’administration de l’hyperviseur :

Stockage

J’ai installé une carte contrôleur RAID sur le serveur car le RAID de la carte-mère Supermicro n’était pas reconnu par VMware ESXi. La première étape a donc consisté à paramétrer le RAID de la carte Broadcom LSI MegaRAID en RAID 10 sur les quatre SSD SATA 2.5″ de 2 To (VM et données). L’accès au paramétrage de la carte RAID se fait lors du lancement de la machine et non dans l’administration VMware ESXi.

L’hyperviseur VMware ESXi a, quant à lui, été installé sur un SSD NVMe de 512 Go.

On retrouve donc ces deux disques dans le menu Stockage puis Banques de données de l’hyperviseur sous les noms de datastore1 pour le SSD NVMe d’environ 512 Go et datastore2 pour les quatre SSD SATA en RAID10 ce qui représente un volume d’environ 4 To :

La troisième banque de données, datastoreNAS, est un montage NFS sur le NAS qui servira pour sauvegarder les VM si vous décidez de sauvegarder avec la VIB ghettoVCB. Cette solution m’ayant empêché d’upgrader VMware, je suis passé sur une solution NAS Synology en 2022 et j’ai donc déinstallé ce datastore NFS.

Pour créer ce datastore, cliquez sur Nouvelle banque de données puis Monter la banque de données NFS et complétez les infos, le partage NFS étant un dossier partagé du volume1 du NAS Synology :

Machines virtuelles

Dans le menu Machines virtuelles, on retrouve les différentes VM :

  • AppServer1 : serveur applicatif Linux Debian présent sur le VLAN 10 (LAN). Pour le moment seul le logiciel Avahi (mDNS) est installé sur ce serveur afin de découvrir les différents Chromecast présents sur le LAN depuis le réseau Wifi Enterprise. Je reviendrai sur ce point lors de l’article à venir au sujet du firewall Untangle,
  • AppServer3 : serveur applicatif Linux Debian présent sur le VLAN 90 (DMZ1). Ce serveur héberge l’application Docker et, aujourd’hui, seul le conteneur logiciel de l’application Azuracast (Web Radio) est installé,
  • DomoServer : serveur applicatif Linux Debian présent sur le VLAN 40 (Domotique). Ce serveur héberge l’application domotique Jeedom. Dans la pratique cette VM utilise le groupe de ports LAN, n’ayant pas créé de groupe de ports et de commutateur virtuel DOMO,
  • OpenVPNAS : serveur applicatif Linux Debian présent sur le VLAN 91 (DMZ2). Ce serveur héberge l’application OpenVPN Access Server,
  • UntangleRouter1 : serveur applicatif hébergeant le firewall Untangle présent sur tous les VLAN,
  • WebServer1 : serveur Web LAMP Linux Debian présent sur le VLAN 10 (LAN) supportant les applications d’administration comme Cockpit (administration de serveurs Linux), InfiniteWP (administration des sites Web sous WordPress) et UniFi Network Controller (administration des points d’accès Wifi Ubiquiti),
  • WebServer3 : serveur Web LAMP Linux Debian présent sur le VLAN 90 (DMZ1) avec notamment les applications Web Nextcloud, Piwigo, X3 Photo Gallery, Afterlogic Webmail Pro PHP, WordPress, Plex et My Media for Alexa,
  • WindowsServer : serveur Windows Server 2016 présent sur le VLAN 10 (LAN).

J’ai appliqué la règle de nommage suivante pour les différentes VM ayant les mêmes fonctions sur les différents VLAN et hyperviseurs :

  • Suffixe « 1 » : VM présentes sur l’hyperviseur1 et le LAN, soit le VLAN 10 (AppServer1, WebServer1 et UntangleRouter1),
  • Suffixe « 2 » : VM présentes sur l’hyperviseur2, le serveur dédié hébergé chez Scaleway (WebServer2 et pfSenseRouter2),
  • Suffixe « 3 » : VM présentes sur l’hyperviseur1 et la DMZ1, soit le VLAN 90 (AppServer3 et WebServer3),
  • Les VM qui n’ont pas de suffixe numéroté sont à usage unique comme le serveur Domotique ou le serveur Windows.

Les différentes VM :

La VM firewall Untangle avec dans l’ordre les adaptateurs WAN, DMZ1, DMZ2, 4G et LAN (plus d’explications dans l’article Firewall) :

Les paramètres de la VM Untangle :

A noter que le type d’adaptateur réseau est toujours VMXNET 3 sauf pour la connexion au routeur 4G qui de type E1000e.

La VM WebServer3 connectée à la DMZ1 :

Les paramètres de la VM WebServer3 :

La VM AppServer3 connectée à la DMZ1 :

La VM OpenVPNAS connectée à la DMZ2 :

La VM WebServer1 connectée au LAN :

La VM AppServer1 connectée au LAN :

La VM WindowsServer connectée au LAN :

La VM DomoServer connectée au LAN :

Gestion

Licence

Dans le menu Hôtes puis Gérer et l’onglet Attribution de licence, saisissez votre licence que vous pouvez obtenir en créant un compte sur VMware Custumer Connect puis en vous rendant sur cette page :

Sécurité

Acceptation

Dans le menu Hôte puis Gérer, onglet Sécurité et utilisateurs, sélectionnez Niveau d’acceptation et enfin Modifier les paramètres afin de modifier le niveau d’acceptation qu’il faudra régler sur Communauté si vous souhaiter installer la VIB ghettoVCB :

Utilisateurs

Pour ajouter un utilisateur, rendez-vous dans le menu Hôte puis Gérer, onglet Sécurité et utilisateurs, sélectionnez Utilisateurs et enfin Ajouter un utilisateur :

Autorisations

Pour affecter des autorisations particulières à un utilisateur, comme les autorisations d’administration de l’hôte (Administrateur), cliquez sur le menu Hôte puis Actions et Autorisations et sélectionnez l’utilisateur que vous venez de créer :

Puis affectez-lui le rôle Administrateur :

Hyperviseur2 VMware ESXi (Serveur Dédié)

Comme pour l’hyperviseur1, voici un schéma qui représente la répartition des VM et des vSwitch ainsi que leurs liens avec les différentes interfaces physiques du serveur hôte VMware ESXi Scaleway (offre Start-2-S-SATA datant de 2019/2020) :

Infra_La_Maison_Bleue_Net_2020_012Télécharger

L’adresse IP est attribuée au serveur dédié qui héberge l’hyperviseur et servira uniquement à l’administration VMware ESXi. Pour accéder au firewall et aux VM, il va falloir commander une seconde adresse IP appelée IP Failover dans l’offre Scaleway et qui sera donc affectée au firewall pfSense.

Les 2 adresses IP sont visibles sur la page Web d’administration du serveur dédié :

Vous pouvez éditer votre IP Failover et l’attribuer à votre serveur dédié :

Vous pouvez ensuite éditer l’adresse MAC de l’IP Failover pour la faire correspondre au bon type d’hyperviseur. Dans notre cas, l’adresse MAC qui sera utilisée par l’interface WAN de la VM pfSense devra être comptatible avec WMware et donc débuter par 00:50:56 :

L’IPv6 n’est pas disponible par défaut pour l’IP Failover mais uniquement en option :

Voici la page d’accueil du serveur VMware ESXi :

Réseau

Groupes de ports

Dans le menu Mise en réseau et l’onglet Groupes de ports, chaque groupe de ports, qu’on affectera par la suite aux différents VM, est associé à un commutateur standard ou vSwitch standard :

Le groupe de ports WAN est associé au vSwitchWAN avec le VLAN 0 (pour tous les groupes de ports de l’hôte), et sa topologie est décrite sur cette page :

Le groupe de ports DMZ1 est associé au vSwitchDMZ1 et son VLAN est le 0 :

Le groupe de ports Management Network est associé au vSwitchWAN et son VLAN est le 0 :

Commutateurs virtuels

Dans l’onglet suivant, Commutateurs virtuels, les différents vSwitch standard sont définis :

Par exemple pour le vSwitchWAN qui sert aussi au management de l’hyperviseur VMware ESXi :

Ce commutateur virtuel s’appelait à l’origine vSwitch0. Pour le renommer en vSwitchWAN, procédez comme suit :

  • Sur la page d’accueil, activez le SSH en cliquant sur le bouton Actions, puis Services et efin Activez Secure Shell. Connectez-vous via un client SSH à l’hôte WMware avec votre compte d’administrateur et éditez le fichier esx.conf
  • vi /etc/vmware/esx.conf
  • Cherchez le vSwitch0 en utilisant la touche « Esc » puis saissisez « /vSwitch0 » et appuyez sur la touche « Enter ». Editez le fichier en appuyant sur les touches « Esc » puis « i » et remplacez le texte vSwitch0 par vSwitchWAN
  • /net/vswitch/child[0000]/name = “vSwitchWAN”
  • Après les modifications, sauvegardez le fichier via « Esc », « :wq! » puis « Enter »
  • Désactivez le SSH en cliquant, depuis la page d’accueil, sur le bouton Actions, puis Services et enfin Désactiver Secure Shell

Le vSwitchDMZ :

NIC physiques

L’onglet NIC physiques liste les différents adaptateurs réseaux :

NIC VMkernel

L’onglet NIC VMkernel concerne les adaptateurs réseaux utilisés pour l’administration de l’hyperviseur :

Piles TCP/IP

L’onglet Piles TCP/IP permet d’indiquer la passerelle et le serveur DNS :

Règles du pare-feu

L’onglet Règles du pare-feu permet de définir les règles de firewall. J’ai modifié les règles vSphere Web Access et vSphere Web Client en précisant les sous-réseaux autorisés à accéder à l’administration de l’hyperviseur :

 

Stockage

Dans l’offre Scaleway, le stockage est composé d’un disque SATA de 1 To  que l’on retrouve sous le nom de datastore1 dans le menu Stockage puis Banques de données de l’hyperviseur :

La seconde banque de données est un montage NFS sur le NAS qui servira pour sauvegarder les VM si vous décidez de sauvegarder avec la VIB ghettoVCB. Cette solution m’ayant empêché d’upgrader VMware, je suis passé sur une solution NAS Synology en 2022 et j’ai donc déinstallé ce datastore NFS.

Pour créer ce datastore, cliquez sur Nouvelle banque de données puis Monter la banque de données NFS et complétez les infos, le partage NFS étant un dossier partagé du volume1 du NAS Synology :

Machines virtuelles

Dans le menu Machines virtuelles, on retrouve les différentes VM installées sur la DMZ :

  • LinuxLite : serveur LinuxLite qui va servir uniquement à l’installation du firewall pfSense et à son premier accès Web pour le paramétrer,
  • pfSenseRouter2 : serveur applicatif hébergeant le firewall pfSense (Community Edition),
  • WebServer2 : serveur Web LAMP Linux Debian.

Les différentes VM :

La VM firewall pfSense connectée au WAN et la DMZ :

Les paramètres de la VM pfSense avec la particularité de l’addresse MAC de l’adaptateur réseau WAN. Il faut en effet indiquer manuellement l’addresse MAC de l’IP Failover (00:50:56:xx:xx:xx), définie précédemment sur le site Web de Scaleway, pour que l’interface récupére l’addresse IP de l’IP Failover :

La VM WebServer2 connectée à la DMZ :

Les paramètres de la VM WebServer2 avec comme adapteur réseau la DMZ :

La VM LinuxLite connectée à la DMZ :

Gestion

Licence

Dans le menu Hôtes puis Gérer et l’onglet Attribution de licence, saisissez votre licence que vous pouvez obtenir en créant un compte sur VMware Custumer Connect puis en vous rendant sur cette page :

Sécurité

Acceptation

Dans le menu Hôte puis Gérer, onglet Sécurité et utilisateurs, sélectionnez Niveau d’acceptation et enfin Modifier les paramètres afin de modifier le niveau d’acceptation qu’il faudra régler sur Communauté si vous souhaiter installer la VIB ghettoVCB :

Utilisateurs

Pour ajouter un utilisateur, rendez-vous dans le menu Hôte puis Gérer, onglet Sécurité et utilisateurs, sélectionnez Utilisateurs et enfin Ajouter un utilisateur :

Autorisations

Pour affecter des autorisations particulières à un utilisateur, comme les autorisations d’administration de l’hôte (Administrateur), cliquez sur le menu Hôte puis Actions et Autorisations et sélectionnez l’utilisateur que vous venez de créer :

Puis affectez-lui le rôle Administrateur :

Certificat SSL

Pour sécuriser l’accès à la page Web d’administration de WMware ESXi avec un certificat SSL, activez le SSH. Sur la page d’accueil, depuis le menu Hôte, cliquez sur le bouton Actions, puis Services et enfin Activer Secure Shell.

Connectez-vous en SSH avec votre compte d’administrateur et le logiciel MobaXterm qui permet de copier facilement des fichiers, comme par exemple les certificats SSL, par un simple Drag and Drop et réalisez les opérations suivantes :

mv /etc/vmware/ssl/rui.crt /etc/vmware/ssl/orig.rui.crt
mv /etc/vmware/ssl/rui.key /etc/vmware/ssl/orig.rui.key
mv votre_certificat_SSL.crt /etc/vmware/ssl/rui.crt
mv la_clé_de_votre_certificat_SSL.key /etc/vmware/ssl/rui.key
chmod 400 /etc/vmware/ssl/rui.key
reboot

Sauvegarde des VM

Solution 1 – ghettoVCB

Il existe une solution de sauvegarde Open, ghettoVCB, qui permet de sauvegarder vos VM et de les restaurer facilement. J’ai monté sur les deux hyperviseurs un Datastore qui accède au NAS en NFS afin de réaliser les sauvegardes car la volumétrie peut être très importante. En effet, VMware ESXi va créer un disque virtuel au format VMDK pour chaque VM sauvegardée ce qui peut, en fonction de l’espace disque réservé pour chaque VM, représenter une taille de plusieurs centaines de gigaoctets.

Pour installer la VIB ghettoVCB, modifiez le niveau d’acceptation pour le passer à Communautaire. Une fois le module logiciel ou VIB ghettoVCB copié sur un Datastore, connectez-vous en SSH (depuis le menu Hôte, cliquez sur le bouton Actions, puis Services et enfin Activer Secure Shell) et installez-le :

esxcli software vib install -v /vmfs/volumes/datastore1/VIB/Sauvegarde/vghetto-ghettoVCB.vib -f

Modifiez le fichier de configuration pour indiquer le dossier de sauvegarde :

vi /etc/ghettovcb/ghettoVCB.conf
VM_BACKUP_VOLUME=/vmfs/volumes/DatastoreNFS/Backup/VM

Paramétrez la crontab pour exécuter régulièrement la sauvegarde des différentes VM :

vi /var/spool/cron/crontabs/root
0 3 * * 1 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m pfSenseRouter1 -g /etc/ghettovcb/ghettoVCB.conf
0 4 * * 1 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m UntangleRouter1 -g /etc/ghettovcb/ghettoVCB.conf
0 3 * * 2 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m WebServer1 -g /etc/ghettovcb/ghettoVCB.conf
0 4 * * 2 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m WebServer3 -g /etc/ghettovcb/ghettoVCB.conf
0 3 * * 3 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m AppServer1 -g /etc/ghettovcb/ghettoVCB.conf
0 4 * * 3 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m AppServer3 -g /etc/ghettovcb/ghettoVCB.conf
0 2 * * 4 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m OpenVPNAS -g /etc/ghettovcb/ghettoVCB.conf
0 3 * * 4 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m DomoServer -g /etc/ghettovcb/ghettoVCB.conf
0 4 * * 4 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m WindowsServer -g /etc/ghettovcb/ghettoVCB.conf

Redémarrer le cron :

kill $(cat /var/run/crond.pid)
crond

Créez un script pour recréer la crontab au redémarrage de l’hyperviseur :

vi /etc/rc.local.d/local.sh
/bin/kill $(cat /var/run/crond.pid)
/bin/echo '0 3 * * 1 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m pfSenseRouter1 -g /etc/ghettovcb/ghettoVCB.conf' >> /var/spool/cron/crontabs/root
/bin/echo '0 4 * * 1 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m UntangleRouter1 -g /etc/ghettovcb/ghettoVCB.conf' >> /var/spool/cron/crontabs/root
/bin/echo '0 3 * * 2 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m WebServer1 -g /etc/ghettovcb/ghettoVCB.conf' >> /var/spool/cron/crontabs/root
/bin/echo '0 4 * * 2 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m WebServer3 -g /etc/ghettovcb/ghettoVCB.conf' >> /var/spool/cron/crontabs/root
/bin/echo '0 3 * * 3 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m AppServer1 -g /etc/ghettovcb/ghettoVCB.conf' >> /var/spool/cron/crontabs/root
/bin/echo '0 4 * * 3 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m AppServer3 -g /etc/ghettovcb/ghettoVCB.conf' >> /var/spool/cron/crontabs/root
/bin/echo '0 2 * * 4 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m OpenVPNAS -g /etc/ghettovcb/ghettoVCB.conf' >> /var/spool/cron/crontabs/root
/bin/echo '0 3 * * 4 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m DomoServer -g /etc/ghettovcb/ghettoVCB.conf' >> /var/spool/cron/crontabs/root
/bin/echo '0 4 * * 4 ulimit -n 4096 ; /etc/ghettovcb/bin/ghettoVCB.sh -m WindowsServer -g /etc/ghettovcb/ghettoVCB.conf' >> /var/spool/cron/crontabs/root
/usr/lib/vmware/busybox/bin/busybox crond

A noter que depuis que j’ai installé cette VIB, je n’arrive plus à mettre à jour VMware ESXi…

Solution 2 – NAS Synology

N’ayant jamais réussi à mettre à jour VMware ESXi en raison de la VIB ghettoVCB qui avait supprimé le niveau d’acceptation et empêchait sa modification, je me suis résolu en janvier 2022 à réinstaller VMware ESXi en version 7.0 U2 from scratch, heureusement sans écraser le datastore qui contenait les VM (option possible lors de l’installation de VMware). J’ai connu les mêmes difficultés avec l’hôte VMware ESXi hébergé chez Scaleway mais un crash du serveur dédié en novembre 2021 a réglé la question. J’ai du en effet migrer sur un autre serveur car Scaleway n’avait plus les pièces de rechange nécessaires pour dépanner ce serveur… et j’ai donc du effectuer une nouvelle installation de VMware ESXi sur un tout nouveau serveur.

Par ailleurs, en cherchant sur les forums, j’ai découvert une autre solution pour sauvegarder les VM, il s’agit de l’application Active Backup for Business disponible sur les NAS Synology et ça tombe bien car je venais d’acquérir un NAS dédié aux sauvegardes fin 2021 !

VM et Hôte VMware ESXi

Pour commencer, il est nécessaire d’activer le mode CBT (Changing Block Tracking) pour chaque VM. Ce paramètre permet de réduire la taille des données transférées et le temps de sauvegarde car le mode CBT permet de sauvegarder uniquement les blocs qui ont été modifiés depuis la sauvegarde précédente.

Pour activer CBT pour une VM :

  • Mettez la VM hors tension
  • Cliquez sur Modifier puis sur Modifier les paramètres
  • Cliquez sur l’onglet Options VM
  • Cliquez sur Avancé puis sur le bouton Modifier la configuration en regard de Paramètres de configuration

Cela ouvre la boîte de dialogue Paramètres de configuration :

  • Cliquez sur Ajouter un paramètre, ajoutez le paramètre ctkEnabled et définissez sa valeur sur TRUE
  • Cliquez à nouveau sur Ajouter des paramètres, ajoutez le paramètre scsi0:0.ctkEnabled et définissez sa valeur sur TRUE
  • Mettez la VM sous tension

Si tout s’est bien passé, vous trouverez dans le dossier de la VM sur le datastore2 un fichier de la forme suivante : Nom_de_la_VM-ctk.vmdk

Une fois que vous avez réalisé cette opération sur toutes les VM, il est encore nécessaire d’activer pour une version gratuire de VMware ESXi les services SSH et shell de l’hôte. Rendez-vous dans le menu Hôte, Actions puis Services :

  • Cliquez sur Activer Secure Shell (SSH)
  • Cliquez sur Activer le shell de la console

NAS Synology

Sur le NAS, la sauvegarde des VM est gérée par Active Backup for Business. L’écran d’accueil de l’appli :

Dans le menu Machine virtuelle, on retrouve toutes les VM de l’hyperviseur local (hyperviseur1) :

Et les VM de l’hyperviseur installé sur le serveur dédié chez Scaleway (hyperviseur 2) :

En cliquant sur le bouton Gérer l’hyperviseur, on obtient la liste des hyperviseurs gérés :

Cliquez sur le bouton Ajouter pour gérer un hyperviseur en précisant l’Adresse du serveur, le Compte de l’hôte et son Mot de passe :

Dans le menu Liste des tâches, créez une tâche de sauvegarde pour chaque VM :

Par exemple la tâche de sauvegarde pour la VM AppServer1 :

Lors de la création de la tâche, vous devez sélectionner le dossier partagé comme destination de la sauvegarde. L’application crée lors de son installation le dossier partagé ActiveBackupforBusiness mais j’ai crée des dossiers avec des noms plus explicites comme backuphome pour les sauvegardes des VM de l’hyperviseur local et backupds pour les VM de l’hyperviseur du serveur dédié Scaleway :

Lors de la création d’une première tâche pour un nouveau dossier partagé de destination, vous pouvez Activer la compression et Activer le chiffrement en indiquant un mot de passe ou encore mieux, une passphrase. L’appli vous proposera de télécharger une clé de chiffrement qui vous vous permettra, comme le mot de passe, d’accéder au dossier partagé de destination lors d’une restauration :

Dans l’onglet Général, activez le suivi des blocs modifiés qui correspond au mode CBT activé sur VMware pour chaque VM. Sur les VM présentes sur le serveur dédié Scaleway, j’ai également activé la compression des données et le chiffrement du transfert des données car elles transitent par le WAN :

Dans l’onglet Planification, programmez le jour et l’heure de la sauvegarde. Je n’ai pas prévu de planification de la sauvegarde pour les VM du serveur dédié Scaleway car le NAS a du mal à se connecter à l’hôte distant. J’effectue donc la sauvegarde manuellement pour ces VM :

Dans l’onglet Conservation, indiquez le nombre de version que vous souhaitez conserver :

Dans l’onglet Privilège, précisez l’utilisateur propriétaire de la tâche de sauvegarde :

Restauration d’une VM

Solution 1 – ghettoVCB

Pour restaurer une VM, il faut commencer par la supprimer dans le Datastore (+ son dossier) en cliquant sur Stockage puis sur Navigateur de banque de données.

Connectez-vous en SSH, copiez le template et modifiez-le en précisant l’emplacement de la VM à restaurer, le Datastore cible et le type de disque (thin) :

cp /etc/ghettovcb/ghettoVCB-restore_vm_restore_configuration_template /etc/ghettovcb/vms_to_restore
nano /etc/ghettovcb/vms_to_restore
#"<DIRECTORY or .TGZ>;<DATASTORE_TO_RESTORE_TO>;<DISK_FORMAT_TO_RESTORE>"
# DISK_FORMATS
# 1 = zeroedthick
# 2 = 2gbsparse
# 3 = thin
# 4 = eagerzeroedthick
# e.g.
"/vmfs/volumes/datastoreNAS/Backup/VM/UntangleRouter1/UntangleRouter1-2021-02-15_04-00-00;/vmfs/volumes/datastore2;3"

Pour vérifier la VM à restaurer :

/etc/ghettovcb/bin/ghettoVCB-restore.sh -c /etc/ghettovcb/vms_to_restore -d 1

Pour la restaurer :

/etc/ghettovcb/bin/ghettoVCB-restore.sh -c /etc/ghettovcb/vms_to_restore -l log.txt

Solution 2 – NAS Synology

Lors de la migration des VM vers VMware ESXi 7.0 U2 (action irréversible), j’ai rencontré un dysfonctionnement sur la VM Windows Server et j’ai du la restaurer dans une version antérieure avant migration.

Pour effectuer cette restauration, rendez-vous sur l’application Active Backup for Business et dans menu Machine virtuelle, l’onglet Liste de tâches, sélectionnez la VM à restaurer et cliquez sur le bouton Restaurer :

Sélectionnez un point de restauration en cliquant sur la clé à molette à droite de la VM puis cliquez sur le bouton Appliquer :

Saisissez le Mot de passe (ou la clé de chiffrement) du dossier partagé de destination que vous avez indiqué lors de la création de la première tâche de sauvegarde :

Précisez qu’il s’agit bien de restaurer la VM dans VMware vSphere :

Sélectionnez le type de restauration, comme par exemple ici la Restauration complète de la machine virtuelle :

Choisissez le mode de restauration comme par exemple Restaurer à l’emplacement d’origine :

A la fin de la procédure, l’application affiche un résumé des options de restauration :

Un message vous indique que la VM existe déjà sur l’hôte et qu’elle sera remplacée par la VM restaurée. Cliquez sur OK pour lancer la restauration :

La VM sera alors restaurée sur l’hôte en remplacant celle déjà existante

Upgrade

Après avoir upgradé l’hôte VMware ESXi 6.7 en version 7.0U2 en janvier 2022, il est nécessaire ou du moins intéressant de migrer les VM dans cette même version afin d’ajuster par exemple la version de l’OS de la VM. En effet, tous les serveurs Linux avaient migré en Debian 11 (Bullseye) fin 2011 mais VMware ESXI 6.7 ne proposait pas de version d’OS supérieure à Debian 10 (Buster). Avant de vous lancer dans cette opération, pensez à bien effectuer une sauvegarde de vos VM.

Pour réaliser cette action, il est nécessaire de sélectionner une VM à miger puis de la mettre hors tension. Cliquez ensuite sur Actions et Configurer la compatibilité VM et sélectionnez la nouvelle version de votre VM, en l’occurence, Machine virtuelle ESXi 7.0 U2 :

Un message vous alerte sur le côté irréversible de l’opération :

Une fois l’upgrade réalisé, précisez la version de l’OS si nécessaire en cliquant sur le bouton Modifier puis Options VM, Options générales et, en regard de Version du SE invité, indiquez la nouvelle version, en ce qui me concerne Debian GNU/Linux 11 (64 bits), et pour finir, mettez sous tension votre VM :

A noter que tout c’est bien passé pour les VM Linux mais, par contre, la VM Windows Server dysfonctionnait après cette migration. J’ai du la restaurer pour la récupérer dans son état antérieur.

Update/Patch

Pour updater ou patcher la version en cours, par exemple de la V7.0U2 à la V7.0U3f, connectez-vous sur la page Product Page, sélectionnez le produit (ESXi), la version (7.0) et téléchargez le dernier dépôt (à la date de l’article “VMware-ESXi-7.0U3f-20036589-depot.zip”).

Connectez-vous au serveur VMware ESXi, sélectionnez Stockage, cliquez sur Explorateur de banque de données, créez un dossier Update sur le datastore1 et copiez le fichier téléchargé précédemment sur VMware. Activez le mode maintenance en sélectionnant Hôtes, puis le bouton Actions et enfin Entrer en mode maintenance. Activez le SSH (Hôtes, bouton Actions, Services, Activer le Secure Shell), connectez-vous en SSH en root et updatez VMware ESXi :

esxcli software sources profile list -d /vmfs/volumes/datastore1/Update/VMware-ESXi-7.0U3f-20036589-depot.zip
esxcli software profile update -d /vmfs/volumes/datastore1/Update/VMware-ESXi-7.0U3f-20036589-depot.zip -p ESXi-7.0U3f-20036589-standard

A la fin de l’installation, de nombreuses lignes vont s’afficher – si vous remontez, vous devriez voir la ligne “Installation successfully”. Redémarrez le serveur pour terminer l’installation de la mise à jour :

reboot

Conclusion

Et voilà, vous êtes arrivé au bout de l’article !

La suite, un article sur les différents firewalls utilisés dans l’infra…