De quoi s’agit-il ? Et bien d’un petit programme en python qui s’interface avec grub2, si grub a le patch BLS (RHEL 7 & dernières versions de Fedora) comme indiqué sur le site upstream :
https://github.com/bmr-cymru/boom

OK, mais c’est quoi l’intérêt du dit programme ? Bah c’est simplement de pouvoir booter très facilement sur un snapshot LVM du / d’un serveur et donc de pouvoir revenir rapidement sur une version d’OS précédent l’application de patchs…. Et là ça rejoint justement quelque chose que je regardais en ce moment et j’avais justement creusé plusieurs solutions telles :

– Un miroir de LV que je peux synchroniser et désynchroniser à loisir… Le mirroring LV commence à bien mûrir désormais, les fonctionnalités –splitmirrors & –trackchanges sont plutôt intéressantes à regarder. En fait ce qui manque vraiment au niveau du mirroring au niveau LV c’est un bon support au niveau des distributions qui ne chargent souvent pas les modules correspondants au niveau de leur noyau de boot par défaut et surtout de leur noyau en mode rescue… Comme malgré tout c’est ce que j’ai mis en place au niveau de mon OS sur mes serveurs chez OVH, si j’ai un jour du temps je finirais peut-être par proposer un patch pour Debian & Fedora au niveau de leur installateur.

– Les snapshots LV… Là encore j’ai découvert qu’il existait désormais deux types de snapshot, les snapshot classique et le splitsnapshot, je dois creuser les différences…

Sur ces deux solutions, le truc à gérer c’est qu’il faut faire les entrées « à la main » dans grub pour pouvoir booter rapidement en cas de soucis sur la version N-1… Et c’est là justement qu’intervient boom, j’y reviens dans 2 secondes…

– La troisième solution consiste à avoir un autre VG (potentiellement sur le même DD) activable/désactivable à loisir contenant une copie complète au niveau des FS…. Et là rsync avec l’option -x peut être intéressante.

Reprenons nos explications sur boom…

Par défaut tout semble configurer pour que boom apparaisse dans grub

[root@testrhel75 ~]# more /etc/default/boom
BOOM_USE_SUBMENU= »yes »
BOOM_SUBMENU_NAME= »Snapshots »
BOOM_ENABLE_GRUB= »yes »
[root@testrhel75 ~]#

Et le fichier /etc/grub.d/42_boom montre bien que la création des entrées va se faire lors du lancement du grub2-mkconfig

Mais par défaut rien n’est présent… Et c’est bien là que la doc est pas top. Il faut « juste » lancer la commande suivante :

[root@testrhel75 ~]# boom profile create --from-host --uname-pattern Linux
Created profile with os_id 2bd22ca:
OS ID: « 2bd22ca1d1cf1a59e24623c92fcbb6aa7fbc867c »,
Name: « Red Hat Enterprise Linux Server », Short name: « rhel »,
Version: « 7.5 (Maipo) », Version ID: « 7.5 »,
UTS release pattern: « Linux »,
Kernel pattern: « /vmlinuz-%{version} », Initramfs pattern: « /initramfs-%{version}.img »,
Root options (LVM2): « rd.lvm.lv=%{lvm_root_lv} »,
Root options (BTRFS): « rootflags=%{btrfs_subvolume} »,
Options: « root=%{root_device} ro %{root_opts} »
[root@testrhel75 ~]#

A partir de là on voit que le profil existe :

[root@testrhel75 ~]# boom profile list
OsID Name OsVersion
2bd22ca Red Hat Enterprise Linux Server 7.5 (Maipo)
[root@testrhel75 ~]#

Créons alors un nouveau LV de snapshot… (Note: On a pas le droit d’appeler les LV en commençant par « snapshot »)

[root@testrhel75 ~]# lvcreate -s -L500M -n snap20180222 /dev/mapper/rhel-root
Logical volume « snap20180222 » created.
[root@testrhel75 ~]#

[root@testrhel75 ~]# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root rhel owi-aos— <17.00g
snap20180222 rhel swi-a-s— 500.00m root 0.02
swap rhel -wi-ao—- 2.00g
[root@testrhel75 ~]#

On peut alors créer l’entrée correspondante dans boom :
boom create --title snap20180222 --root-device /dev/mapper/rhel-snap20180222 --profile 2bd22ca

Et relancer la création du fichier de configuration de grub :
grub2-mkconfig > /boot/grub2/grub.cfg

J’ai une erreur sur le duplicate UUID ce qui est bien normal
[root@testrhel75 ~]# grub2-mkconfig > /boot/grub2/grub.cfg
Generating grub configuration file …
Found linux image: /boot/vmlinuz-3.10.0-830.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-830.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-46f4128a747747718e53b6edf2592896
Found initrd image: /boot/initramfs-0-rescue-46f4128a747747718e53b6edf2592896.img
[126444.820507] XFS (dm-4): Filesystem has duplicate UUID beb5c54c-a3b1-4e28-92b1-61df4b1873ea – can’t mount
done
[root@testrhel75 ~]

On peut vérifier que grub a désormais la config liée à boom activé si on a les lignes suivantes dans le grub.cfg

### BEGIN /etc/grub.d/42_boom ###
submenu « Snapshots » {
insmod blscfg
bls_import
}

D’ailleurs il n’y a pas besoin de relancer la création du grub.cfg une fois cette opération faite…

On peut désormais faire un touch d’un fichier (mais on pourrait faire une mise à jour de tout un tas de package RHEL, hein)

[root@testrhel75 ~]# touch /toto
[root@testrhel75 ~]#

Et rebooter sur notre snapshot :

Red Hat Enterprise Linux Server (3.10.0-830.el7.x86_64) 7.5 (Maipo)
Red Hat Enterprise Linux Server (0-rescue-46f4128a747747718e53b6edf25928>
Snapshots

Use the ^ and v keys to change the selection.
Press ‘e’ to edit the selected item, or ‘c’ for a command prompt.

snap20180222

Use the ^ and v keys to change the selection.
Press ‘e’ to edit the selected item, or ‘c’ for a command prompt.
Press Escape to return to the previous menu.

Et là c’est le drame…. J’utilise virsh en ligne de commande et donc avec l’émulation du port série et l’option n’est pas reprise…. Ce qui est vite corrigé en faisant ça :

boom profile edit 2bd22ca --os-options="root=%{root_device} ro %{root_opts} console=ttyS0"

Et en détruisant/recréant l’entrée correspondant à mon snapshot…

Désormais si je boote sur le snapshot et lorsque je fais un ls sur /, je ne trouve pas le fichier /toto créé précédemment…

En espérant avoir un peu éclairé vos lanternes sur le sujet boom

virt-install –network model=virtio,bridge=br0,mac=02:00:00:e0:49:da –autostart –disk /dev/VGdata/LVvirtualserver1 -l http://archive.kernel.org/centos-vault/6.2/os/x86_64/ –memory 1024 –name VM1 –accelerate –graphics none –hvm -x « console=tty0 console=ttyS0,115200n8 »

Vous pouvez améliorer la commande avec un fichier de kickstart pour pouvoir gérer plus soigneusement la partie LVM… mais vous avez l’idée.

Attention je n’ai pas réussi à faire fonctionner la ligne avec de la CentOS 5.x, uniquement avec CentOS 6 & 7

Vous n’aurez pas forcément cet écran :

Après le reboot, ESXi boote sur la carte vmnic0 en DHCP, pas forcément ce que l’on veut…

Installation du Vcenter pour gérer ces 2 serveurs :

Créons la coquille vide pour Nas4Free :

Nas4Free est à base de BSD :

On alloue beaucoup de disque parce qu’on va ensuite le découper pour le présenter en NFS et en iSCSI (le screenshot est à revoir puisqu’il faut prévoir un disque de 8 Go et un disque de 300 Go pour bien séparer installation des données) :

Avec deux points d’accès NFS et deux points d’accès en iSCSI : On boote sur l’iso d’installation et après la phase de boot on sélectionne le choix « 9 » pour l’installation :

Puis on choisi le mode « Embedded » :

On reboot (et on fait attention de retirer l’ISO ou de booter d’abord sur le disque dur) puis on choisi la configuration de la partie IP : On peut alors paramétrer la deuxième interface du Windows d’Admin pour pointer vers l’IP 10.10.0.2

Et à partir de là, on continue avec l’interface web depuis le poste Windows d’Admin (utilisateur: admin, mot de passe par défaut : nas4free)

On ne fait pas le reboot tout de suite…. On reboote… et on commence alors la configuration disque :

Pas certain que la partie DataSet soit obligatoire (à vérifier)

J’ai fait trois schémas pour représenter ce que je souhaite faire :

Commençons donc à créer le vSwitch VLANAdmin :

Il manque une copie d’écran ici, le mode prosmicuité étant à activer au niveau de « Commutateur virtuel » et « Commutateur standard » (j’ai perdu plusieurs heures à trouver pourquoi cela déconnait) :

Répétons l’opération pour les différents réseaux à créer…

Puis affectons aux différents serveurs des cartes réseaux pour ces VLANs :

To be continued…

La première question que je me suis posé quand j’en ai entendu parler c’est pourquoi ? Peut-être que vous êtes riche comme Rothschild et que vous avez une baie SAN ou NAS qui ne sert à rien et que vous avez 3 serveurs qui ne servent pas… mais ce n’est pas le cas de tout le monde !

Aussi si par contre vous avez un poste (ou un serveur) sur-gonflé en RAM (En dessous de 16 Go c’est très compliqué, avec 32 Go cela devient cool) vous pouvez vous amusez à faire un super lab pour tester VMWare et ses fonctionnalités, ou juste répéter une mise à jour par exemple. (Il existe des licences d’évaluation chez VmWare qui permettent de tourner pendant 60 jours, de quoi faire de beaux tests !).

L’exemple que je propose ici est la mise en œuvre d’un cluster de deux ESXi virtuels attachés à une baie (virtuelle) NAS en NFS et une baie (virtuelle) SAN en Iscsi, Nas4Free permettant d’assurer ces fonctions… Voici quelques schémas permettant de se donner une idée du câblage réseau virtuel désiré…

Les étapes préliminaires :

Installez ESXi et Vcenter 6.0 en version appliance vcsa (cf. mon post précédent)…  et vérifiez que vous pouvez effectivement faire du virtuel dans du virtuel.

Pour cela, utilisez l’URL suivante que vous adapterez pour pointer vers votre serveur ESXi installé par vos soins : https://test-esxi-ovh.lenhof.eu.org/mob/?moid=ha-host&doPath=capability et vérifiez dans la page que la ligne « nestedHVSupported »  a la valeur « true ».

Je vais tenter d’être le plus détaillé possible en décrivant l’ensemble des tâches… de la création du DataCenter, des hôtes, etc…

Première étape :

Une fois VMWAre VSphere Web Client accessible, il faut vous connecter sur l’URL que vous adapterez à votre environnement :

https://vsphere.lenhof.eu.org/vsphere-client avec le compte administrator de votre domaine SSO que vous avez créé lors de l’installation…

Création du Datacenter

Puis on ajoute l’hôte :

Puis on créé le 1er ESXi Nested :

On choisi « Autre » dans la liste « famille des systèmes d’exploitation clients » et on sélectionne « Autre (64 bits) » dans la liste « version du système d’exploitation client » :Sélectionnez 2 vCPUs (sinon ESXi ne veut pas s’installer) et 6 Go de RAM

On sélectionne l’ISO de l’installateur d’ESXi que l’on aura préalablement recopier via ssh dans le dossier ISOs de notre datastore :Pensez à cocher « Exposer l’assistance matérielle à la virtualisation au SE invité », sinon ESXi ne s’installera pas en disant que le processeur n’a pas les capacités de virtualisation…

On coche « La prochaine fois que la machine virtuelle démarre, forcer l’entrée sur l’écran de configuration BIOS », pour avoir le temps de sélectionner le fait de booter sur le CD dans le BIOS, sinon cela va trop vite…

Une fois la machine créée, il faut remodifier les paramètres du système d’exploitation

Et là miracle on peut choisir « ESXi 5.5 »

On fera de même pour la création du deuxième Nested ESXi…

La suite dans un prochain post…

Malheureusement il va nous falloir installer une petite machine sous Windows pour « boostraper » l’installation de vsphere 6.0 (vcsa) contrairement à la version 5.5 où l’on pouvait s’en sortir via ovftool… (cf. un des articles précédents sur mon blog).

J’ai donc choisi l’opportunité de télécharger Windows 10 Preview dont l’ISO est disponible ici :

http://windows.microsoft.com/fr-fr/windows/preview-download

Pendant le téléchargement, j’ai décidé de renommer le datastore créé par défaut pour lui donner un nom parlant en se connectant en ssh sur le serveur esxi :

vim-cmd hostsvc/datastore/rename datastore1 test-esxi-ovh.lenhof.eu.org_datastore

On peut alors vérifier que cela fonctionne en utilisant la commande :

vim-cmd hostsvc/datastore/listsummary

Vous pouvez ensuite télécharger « vmware-player » pour Linux pour pouvoir administrer de façon assez confortable les VMs que vous créerez par la suite sur votre serveur ici :

http://www.vmware.com/fr/products/player

Cet outil nous permettra la prise en main à distance des consoles des différentes VMs créées de façon bien plus sympa que la console en mode web de VSphere Web Client qui joue pas mal de tour au niveau du mappage de clavier… l’outil VMRC n’étant lui pas encore disponible sous Linux

Une fois l’ISO de Windows téléchargée, j’ai décidé de pousser l’ISO sur le datastore dans un dossier ISOs via ssh…

cd /vmfs/volumes/test-esxi-ovh.lenhof.eu.org_datastore/ISOs
ls -la
total 4115464
drwxr-xr-x 1 root root 420 Mar 15 08:59 .
drwxr-xr-t 1 root root 1400 Mar 15 08:59 ..
-rw-r--r-- 1 root root 4212791296 Mar 15 09:05 win_10_x86_64.iso

On créé ensuite les fichiers de la VM à la main, d’abord le disque correspondant à la VM :

#mkdir /vmfs/volumes/test-esxi-ovh.lenhof.eu.org_datastore/VMWindowsAdmin
#vmkfstools --createvirtualdisk 20G --diskformat zeroedthick --adaptertype lsilogic /vmfs/volumes/test-esxi-ovh.lenhof.eu.org_datastore/VMWindowsAdmin/VMWindowsAdmin.vmdk
Create: 100% done.
#ls -la /vmfs/volumes/test-esxi-ovh.lenhof.eu.org_datastore/VMWindowsAdmin
total 20972552
drwxr-xr-x 1 root root 560 Mar 15 09:15 .
drwxr-xr-t 1 root root 1540 Mar 15 09:15 ..
-rw------- 1 root root 21474836480 Mar 15 09:15 VMWindowsAdmin-flat.vmdk
-rw------- 1 root root 476 Mar 15 09:15 VMWindowsAdmin.vmdk

Puis on créé le fichier correspondant au hardware de la machine (vous devrez changer l’adresse mac présente sur la ligne « ethernet0.address » par l’adresse que vous aura attribué OVH dans votre interface pour l’IP concernée (si vous avez pris un paquet d’IP publiques comme j’ai fait) :

#cat > /vmfs/volumes/test-esxi-ovh.lenhof.eu.org_datastore/VMWindowsAdmin/VMWindowsAdmin.vmx <<EOF
config.version = "8"
virtualHW.version = "7"
vmci0.present = "TRUE"
displayName = "VMWindowsAdmin"
floppy0.present = "FALSE"
numvcpus = "1"
scsi0.present = "TRUE"
scsi0.sharedBus = "none"
scsi0.virtualDev = "lsisas1068"
memsize = "2048"
scsi0:0.present = "TRUE"
scsi0:0.fileName = "VMWindowsAdmin.vmdk"
scsi0:0.deviceType = "scsi-hardDisk"
ide1:0.present = "TRUE"
ide1:0.fileName = "/vmfs/volumes/test-esxi-ovh.lenhof.eu.org_datastore/ISOs/win_10_x86_64.iso"
ide1:0.deviceType = "cdrom-image"
pciBridge0.present = "TRUE"
pciBridge4.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"
pciBridge5.present = "TRUE"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge6.present = "TRUE"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge7.present = "TRUE"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
ethernet0.pciSlotNumber = "32"
ethernet0.present = "TRUE"
ethernet0.virtualDev = "e1000"
ethernet0.networkName = "VM Network"
ethernet0.generatedAddressOffset = "0"
guestOS = "windows7-64"
ethernet0.addressType = "static"
ethernet0.address = "00:50:56:06:E7:7D"
EOF

Et on enregistre la VM :

#vim-cmd solo/registervm /vmfs/volumes/test-esxi-ovh.lenhof.eu.org_datastore/VMWindowsAdmin/VMWindowsAdmin.vmx

On peut alors se connecter pour booter la VM depuis Linux :

vmplayer -H test-esxi-ovh.lenhof.eu.org

Et configurer tranquillement son Windows… avec notamment la partie réseau avec notamment la route pour atteindre la gateway un peu spéciale d’OVH :

route add -p 188.165.209.254 188.165.79.253

Une fois le Windows installé, RDP activé et le firewall ouvert pour RDP, on peut prendre garder la main avec le vmplayer et y installer un google chrome des familles, parce que je ne supporte pas IE longtemps….

Puis on récupère l’ISO de vCSA 6.0 sur le site de VMWARE après s’y être loggué.

Puis on monte cette iso sous windows en cliquant dessus, cf la copie d’écran :

Puis on installe l’outil d’intégration.

Puis on charge la page setup depuis Google-Chrome…

On accepte les conditions du contrat :

On saisi l’IP, le compte root et le mot de passe du serveur ESXi sur lequel on veut installer l’appliance  :

On valide la clé SSH :

On saisi le nom de l’appliance et on choisit un mot de passe pour le compte root de l’appliance :

On valide le choix par défaut :

On créé le domaine SSO (Attention là où est indiqué « Port SSO de VCenter » c’est le mot de passe qui est en fait demandé, oui un bug de traduction il semblerait )

J’utilise la taille minimale :

On coche le mode disque dynamique :

On créé une base intégrée :

On renseigne l’IP de la machine et on met l’IP aussi au niveau du nom du système sinon l’installation va se viander parce que la résolution inverse ne fonctionne pas (à cause du coup de la gateway un peu spéciale d’OVH) :

On accepte le warning (cf. explication au-dessus) :

Et on accepte le tout :

L’installation démarre alors :

Et cela dure :

Un bon moment :

Jusqu’à l’affichage de ce message :

On peut alors utiliser vmware-player pour se connecter à la VM pour terminer la configuration réseau :

On se loggue (attention le clavier est en qwerty encore à cette étape ) :

On active le mode troubleshooting :

Notamment l’accès au BASH :

Puis on fait du CTRL+F1/F2, etc et on se loggue (toujours en qwerty) :

On accède au shell :

On charge le clavier français et on fait la modification pour que ce soit le clavier français qui soit chargé par défaut :

Puis on va créer un petit script pour charger les routes un peu spéciales pour la gateway d’OVH :

On fait les liens qui vont bien…

Et enfin on clique sur configuration avancé sur la carte réseau pour modifier à distance le fichier vmx de la machine virtuelle pour indiquer la mac adresse que l’on a généré auparavant dans l’interface d’OVH :

Il ne reste plus alors qu’à rebooter la machine virtuelle via un petit reboot et accéder via google chrome à l’URL du type : https://vsphere.lenhof.eu.org/vsphere-client/

Voilà, voilà ça a l’air simple comme ça, mais j’ai mis un petit moment pour écrire une procédure qui fonctionne…

EDIT : J’espère peut-être avoir une solution avec ovftool du type de ce que j’ai fait avec vcsa pour vsphere 5.5, puisqu’il semblerait qu’il y ait un fichier au format OVA (mais sans l’extension) dans l’ISO d’installation… Ce serait bien, puisque cela permettrait peut-être d’éviter l’installation d’une machine windows qui ne sert juste que pour cette phase d’installation.

Et vous pouvez ensuite accéder à votre serveur vsphere en allant à l’adresse https://localhost:9443/vsphere-client/

Vous aurez alors le droit à un message sur le certificat puisque le certificat ne correspondra plus…

Après avoir installé ovftool (il existe une version 32 et une version 64 bits) en version 4.0 ici :

https://my.vmware.com/web/vmware/details?downloadGroup=OVFTOOL400&productId=353

Vous pouvez alors faire un petit script (largement inspiré du travail de William Lam du site www.virtuallyghetto.com) qui va installer VCSA directement et le configurer aux petits oignons… à adapter avec les infos IPs, DNS, etc de vos environnements :

Suivant le débit de votre réseau, cela peut prendre du temps…

Si vous faites ça vers un serveur chez OVH (mon cas), attention avec les protections au niveau Mac Adress, il vous faut modifier le fichier .vmx alors généré pour y mettre en manuel l’adresse mac que vous avez créé dans votre interface…

Il faut alors supprimer les lignes suivantes :