VMware et Powershell : rapport des versions d'hôtes vSphere

Voici un script permettant de lister les versions des hôtes vSphere présents dans un vCenter. Le premier mode liste tous les hôtes tandis que le deuxième permet de lister une version spécifique, majeure ou mineure. Par exemple, en saisissant "6", alors le script cherchera les serveurs en 6.x.x tandis qu'en envoyant "5.5", il cherchera les serveurs en 5.5.x. Dans tous les cas, un export CSV exploitable est réalisé. Naturellement, il est nécessaire que les modules Powershell de VMware soient déployés sur la machine exécutant le script (si ils ne le sont pas, il suffit simplement de télécharger PowerCli).

Import-Module VMware.VimAutomation.Core

function allhosts{
Write-Host "Retrieving all hosts on vCenter $vcenter"
$spheres = Get-VMHost
process
}

function spechosts{
Write-Host "Retrieving specific hosts on vCenter $vcenter."
$reqver = Read-Host "Please input the desired version in one of those formats : 6, 6.0 or 6.0.0"
if($reqver.Length -lt 5) { $reqver = "$reqver*" }
$spheres = Get-VMHost | Where-Object {$_.Version -like $reqver}
process
}

function process{
$path = "$env:temp\vmware-hostver-$vcenter.csv"
$header = "Hostname,PowerState,Version"
Add-Content -Value $header -Path $path
foreach($vsphere in $spheres) {
$row = $vsphere.Name+","+$vsphere.PowerState+","+$vsphere.Version
Add-Content -Value $row -Path $path
}
Write-Host "Processing is done. Results are located in $path."
explorer $env:temp
}

Write-Host "vSphere host version listing script"
Write-Host "===================================`r`n"
$vcenter = Read-Host "vCenter to connect to ?"
Connect-VIServer $vcenter | Out-Null
Write-Host "1: List all hosts and versions on this vCenter`r`n2: List only hosts running under a specific version"
$mode = Read-Host "Choice"
switch ($mode){
1 { allhosts }
2 { spechosts }
}
Disconnect-VIServer $vcenter -confirm:$false | Out-Null
Write-Host "Bye."

Le script est téléchargeable dans une version commentée. 💾

VMware et Powershell : liste des alarmes déclenchées sur les hôtes physiques et VM

J'ai développé rapidement sur un coin de bureau un script pour lister les alarmes déclenchées sur les hôtes ESX et les machines virtuelles portées par ces hôtes, car à ma grande surprise, PowerCli ne possède pas de commande permettant de les obtenir directement. Il faut donc ruser un peu et utiliser les vues d'ensemble de machines virtuelles et physiques pour récupérer leur état et ensuite afficher les alarmes en lien. Ce script a été développé et testé avec PowerCli 6.5 ; à noter que depuis la version 6, ce ne sont plus des SnapIn mais des modules (source), il faudra donc adapter le début du script si jamais la version exécutée fonctionne avec des SnapIn.

Import-Module VMware.VimAutomation.Core
$ESXI = Read-Host "vSphere vCenter server to connect to"
Connect-VIServer $ESXI
Write-Host ""
Write-Host "Collecting virtual machines list..."
Write-Host ""
$VMArrayList = Get-VM
foreach ($VM in $VMArrayList)
{
$VMView = Get-View -ViewType VirtualMachine -Filter @{"Name" = "$VM"}
if ($VMView.TriggeredAlarmState.Overallstatus -eq "red")
{
foreach ($VMAlarm in $VMView.TriggeredAlarmState)
{
$VMAlarmType = $VMView.TriggeredAlarmState.Alarm
$VMAlarmTime = $VMView.TriggeredAlarmState.Time
$VMAlarm = Get-AlarmDefinition -id $VMAlarmType
Write-Host "Virtual Machine: $VM"
Write-Host "Alarm: $VMAlarm"
Write-Host "Time: $VMAlarmTime"
Write-Host ""
}
}
}
Write-Host "Done!"
Write-Host "Now collecting physical hosts list..."
Write-Host ""
$HostArrayList = Get-VMHost
foreach ($HostSys in $HostArrayList)
{
$HostView = Get-View -ViewType HostSystem -Filter @{"Name" = "$Host"}
if ($HostView.TriggeredAlarmState.Overallstatus -eq "red")
{
foreach ($HostAlarm in $HostView.TriggeredAlarmState)
{
$HostAlarmType = $HostView.TriggeredAlarmState.Alarm
$HostAlarmTime = $HostView.TriggeredAlarmState.Time
$HostAlarm = Get-AlarmDefinition -id $HostAlarmType
Write-Host "Host: $Hostsys"
Write-Host "Alarm: $HostAlarm"
Write-Host "Time: $HostAlarmTime"
Write-Host ""
}
}
}
Write-Host "Done!"

Le script commenté est téléchargeable sur le miroir de téléchargement 💾.

Installation des VMware Tools sur Debian 4

J'ai dû installer aujourd'hui des VMware Tools sur une machine Debian Etch.

La documentation VMware est plutôt complète et ne voulant pas utiliser le paquet open-vm-tools, j'ai quand même décidé d'en faire un article même si l'installation est plutôt aisée pour qui est adepte de GNU/Linux, ce qui n'est pas tellement mon cas dans un contexte professionnel.

A noter qu'il peut être nécessaire de procéder à un snapshot de la machine virtuelle si une installation des paquets additionnels gcc, make, binutils ainsi que les sources du kernel est souhaitée pour utiliser toutes les fonctionnalités des outils ; dans ce cas précis, j'ai installé ces paquets en pré-requis.

apt-get update
apt-get install make gcc binutils

Ensuite, il faut récupérer la source du kernel propre à la version de Debian exécutée. On la récupère grâce à uname -r. Par exemple, pour une Debian 4.0, on est sur une version de kernel 2.6.18. Pour se faciliter la tâche, on utilisera le retour de l'instruction comme nom de paquet.

apt-get install linux-image-$(uname -r)

Tout d'abord, monter le disque virtuel des vmtools sur l'enveloppe de machine virtuelle via l'interface VMware, puis la monter dans l'OS. En fonction de la configuration, cela pourra être /dev/cdrom ou /dev/cdrom1 ; dans cet exemple j'utiliserai /dev/cdrom1. On monte donc dans le répertoire /media/cdrom, en s'assurant qu'il existe avant d'envoyer l'instruction :

mount /dev/cdrom1 /media/cdrom

On créé ensuite un répertoire à l'emplacement de son choix pour copier les sources en local et pouvoir extraire l'archive. Dans mon cas, n'ayant qu'un utilisateur root, je l'ai créé dans /root/vmtools.

mkdir /root/vmtools
cd /media/cdrom

En faisant un ls -l, on peut constater que le disque a bien été monté et que divers fichiers remontent :

Ensuite, on copie ces fichiers vers le répertoire fraîchement créé :

cp * /root/vmtools

Puis on procède à l'extraction de l'archive :

cd /root/vmtools/
tar xzf VMwareTools-<version>.tar.gz

Cette extraction va nous donner un dossier vmware-tools-distrib dans lequel on exécutera vmware-install.pl. Il ne reste ensuite plus qu'à suivre l'assistant d'installation, les valeurs par défaut couvrant une grosse majorité des besoins. En fonction des paquets installés sur la machine, l'assistant se plaindra de l'absence de certains d'entre eux (comme gcc, binutils et make ainsi que le linux-image que j'ai évoqué plus haut) qui pourront bloquer certaines fonctionnalités si ils ne sont pas installés.

Présentation de mon "cloud" personnel

Je possède une plateforme en ligne me permettant entre autres d'assouvir ma curiosité IT mais également de répondre à plusieurs besoins - que je me suis moi-même créé, d'ailleurs. Après avoir eu pendant longtemps un serveur (généralement sous Debian), il y a quelques temps j'ai décidé de passer sur une plateforme virtualisée afin de séparer chaque fonctionnalité de mon nuage et de gérer les choses plus facilement. Initialement sous Proxmox VE, je suis passé sous VMware après l'avoir pratiqué dans un contexte professionnel. Le but de cet article est d'essayer de présenter ce nuage, ce que j'en fais, comment je l'ai pensé et comment il vit.

Tout d'abord, ce nuage est basé sur une seule machine physique. Il s'agit d'un serveur que je loue chez SoYouStart qui est le milieu de gamme de chez OVH (l'entrée de gamme étant assurée par Kimsufi et le haut de gamme par OVH lui-même). Sa configuration est la suivante :

  • CPU : AMD Opteron 4334 à 6 coeurs, 6 threads et 3.1 GHz
  • RAM : 32 Go DDR3 1333 MHz
  • HDD : 2 x 3 To SATA, configurés en RAID 1
Il s'agit de la configuration OP-SAT-1-32. Après plusieurs années sur un modèle moins puissant fonctionnant sous Proxmox VE, j'ai fait ce choix car les 32 Go de RAM sont le minimum dont j'ai besoin dans le cadre de la virtualisation afin de ne pas dimensionner un peu court les machines ; le processeur plutôt puissant suffit à toutes les tâches et ne peine pas face à de multiples décodages de vidéos en 1080p sur Plex ; les disques durs, bien que simples SATA en 7200rpm suffisent même si le confort des SSD que j'ai pu essayer manque à l'appel, en ayant en contrepartie un espace suffisant pour tout type de machine virtuelle.
La couche de virtualisation est un VMware ESXi 6.5u1. Elle héberge donc - entre autres, je ne vais présenter que les machines qui sont permanentes - :
  • 1 appliance pfSense, fonctionnant sous BSD ;
  • 2 contrôleurs de domaine sous Windows Server 2012 R2 ;
  • 1 serveur de fichiers sous Windows Server 2012 R2 ;
  • 1 serveur applicatif sous Windows Server 2012 R2 ;
  • 1 serveur RDP sous Windows Server 2012 ;
  • 2 serveurs multimédia Plex sous Debian ;
  • 1 serveur applicatif sous Debian ;
  • 1 serveur VPN sous Debian ;


L'appliance pfSense : 1 vCPU et 512 Mo de RAM

J'en ai déjà parlé dans ce billet. pfSense est un serveur BSD pouvant entre autres remplir le rôle de routeur/pare-feu. Etant donné qu'à la différence de Proxmox VE qui permet de faire du NAT nativement grâce à iptables, l'adoption de VMware m'a forcé à passer par une solution tierce pour mettre en réseau mes machines virtuelles derrière un pare-feu en n'utilisant qu'une seule IP publique. Mon serveur fonctionne donc avec deux adresses IP : l'une utilisée par la carte physique, l'autre en IP failover utilisée par l'interface virtuelle de pfSense et qui sert d'IP publique pour mes machines virtuelles et de base pour le routage des paquets vers les bons ports.

Les contrôleurs de domaine : 1 vCPU, 2 Go de RAM et 120 Go d'espace disque par DC

Je pourrais très bien fonctionner avec un seul contrôleur de domaine étant donné que je ne possède qu'un seul serveur pour héberger toutes mes machines et qu'il n'y a aucune notion de haute disponibilité. Cependant, ayant déjà eu le cas d'un contrôleur de domaine complètement planté suite à une mise à jour qui s'est mal déroulé sur une précédente infrastructure personnelle, je préfère en avoir deux fonctionnant de concert ce qui me permet de toujours avoir le domaine même si une mise à jour ou un plantage grave arrive sur l'un (corruption du fichier VMDK par exemple, ce qui m'est déjà arrivé).
Le premier porte tous les rôles (FSMO, PDC...), les deux ont le rôle DNS et ont été installés avec l'interface graphique. C'est un point que je souhaite changer prochainement et qui fera sans doute l'objet d'un billet. Ayant toutes les consoles d'administration sur une autre machine, je ne m'y connecte que très rarement et fonctionner uniquement en mode core pourrait limiter la consommation - déjà très faible - de ressources.

Le serveur de fichiers : 2 vCPU, 3 Go de RAM et 3 disques virtuels pour un total de 720 Go

Ce serveur fonctionnant sous 2012 R2 me sert pour stocker une partie de mon OneDrive, ainsi qu'héberger divers espaces partagés entre les machines (sources d'applications, scripts, téléchargements, bases de données...). J'y stocke également les sauvegardes des serveurs Windows que je réalise grâce à l'outil intégré. Afin d'avoir une compatibilité maximale avec les applications, ce serveur fait fonctionner un serveur FTP fonctionnant sous FileZilla.


Le serveur applicatif sous Windows : 2 vCPU, 3 Go de RAM et 2 disques virtuels de 120 Go

J'utilise cette VM pour faire fonctionner des applications qui ont besoin d'un environnement Windows (ou qui sont plus faciles à faire fonctionner ou configurer sous Windows). Je m'en sers principalement pour faire fonctionner un serveur Minecraft personnel ou d'autres serveurs de jeux, afin de ne pas avoir à conserver les fichiers et exécuter le serveur dédié sur mon propre PC personnel. Cela me permet également de donner accès à des personnes de ma famille qui sont en dehors de mon réseau personnel. 

Le serveur RDP : 2 vCPU, 2 Go de RAM et 120 Go d'espace disque

C'est ce serveur qui permet de rebondir sur le reste du réseau et le seul RDP à être ouvert sur l'extérieur. Plutôt que d'ouvrir les RDP ou les bureaux graphiques des autres machines, j'ai préféré tout fermer et ne laisser l'accès que depuis cette seule machine afin de limiter le nombre de ports à nater. Cette VM possède ensuite tous les clients nécessaires à la connexion aux services VMware de l'hyperviseur, aux bureaux graphiques des machines Linux, PuTTY pour le SSH, sans oublier les consoles d'administration pour les services répartis sur les serveurs. Plus qu'un serveur de rebond, il s'agit également d'un serveur d'administration et c'est sur cette machine que je réalise la majorité de mes scripts. Pour des questions de sécurité, la connexion à cette machine se fait avec un autre compte utilisateur que les autres machines Windows, ce compte n'ayant aucun autre droit sur le domaine (et mon compte utilisateur standard n'ayant aucun droit sur le serveur RDP, seul mon compte d'administration ayant des droits transverses).

Les 2 serveurs Plex : 4 vCPU, 4 Go de RAM et 50 Go d'espace disque pour le premier, 1 vCPU, 2 Go de RAM et 100 Go d'espace disque pour le second

Pourquoi deux serveurs Plex ? Car ils fonctionnent différemment.
Le premier serveur Plex, avec sa grosse configuration, est dédié à la diffusion de contenu vidéo. Films, séries, concerts, émissions TV... tout ce qui peut demander une bonne puissance de calcul en cas de diffusion sur un appareil qui ne peut décoder le flux directement (comme un iPad). Comme je l'ai expliqué dans ce billet, le contenu n'est pas stocké directement sur le serveur, mais en ligne, sur Google Drive. J'utilisais auparavant Amazon Drive mais le blocage complet de l'API suivi d'un changement des grilles tarifaires m'a fait résilier mon abonnement pour me diriger vers celui de Google, qui s'est avéré plus fiable, plus rapide pour pas beaucoup plus cher dans l'absolu (8 euros par mois contre 70 euros à l'année). Afin de supporter le streaming sur plusieurs appareils (généralement un seul, mais 3 devant être un nombre géré sans problème avec du 1080p), il a fallu dimensionner correctement la machine et 4 cœurs virtuels sont suffisants.
Le deuxième serveur Plex à la configuration bien plus modeste est dédié à la diffusion de contenu audio. La musique est stockée directement sur le disque de la machine virtuelle afin de ne pas avoir à faire des appels à l'API de Google Drive sans arrêt à chaque changement de piste, sans compter que 100 Go sont aisément disponibles sur l'hyperviseur.


Le serveur applicatif Debian : 2 vCPU et 2 Go de RAM pour 120 Go d'espace disque

Cette VM héberge un serveur web, un serveur de base de données MySQL, ainsi que quelques autres applicatifs web. L'usage est principalement local, certaines applications dont je me sers peuvent avoir besoin d'une base de données, par exemple. Grâce à des scripts conçus sous Webmin, les bases de données ainsi que certains fichiers sont sauvegardés sur le serveur de fichiers, qui lui-même les sauvegarde par la suite sur OneDrive, ce qui me permet de pouvoir restaurer à un instant T si besoin.


Le serveur VPN : 1 vCPU et 1 Go de RAM pour 10 Go d'espace disque

Afin de pouvoir profiter de réseaux Wi-Fi publics sans me sentir "nu", ce petit serveur VPN est idéal. Fonctionnant sur une base d'OpenVPN Access Server, l'installation et la configuration se font très facilement, et des clients existent aussi bien pour les ordinateurs que les appareils mobiles. Je m'en sers dès que je suis sur un réseau Wi-Fi qui n'est pas celui que j'utilise à la maison. 
Et c'est déjà pas mal ! J'ai également possédé pendant quelques temps un serveur de messagerie personnel, lié à mon nom de domaine, dont je me servais à des fins personnelles, connecté à mes clients de messagerie ou accessible via un webmail. Fonctionnant sous Debian avec Postfix et Dovecot, lorsque j'ai repensé intégralement l'architecture en adoptant VMware, j'ai décidé de ne pas conserver la messagerie personnelle. Trop peu d'utilité et de confort par rapport à mon usage : sauvegarde horaire de la boîte aux lettres, adresse considérée chez certains destinataires comme spam, difficulté de configuration... Concernant le dimensionnement des machines, il est plutôt large, et d'ailleurs, si toutes les machines devaient occuper 100% de leurs vCPU, cela saturerait l'hyperviseur ; cependant, très peu de risque que cela arrive. En moyenne, le CPU tourne entre 5 et 10% de ses capacités, avec une moyenne à 30% lors de la diffusion de médias via Plex. Actuellement, le serveur en est à 245,24 jours de fonctionnement... et ça n'est pas prêt de s'arrêter.

Extension de partition sur Debian Jessie grâce à GParted

Comme évoqué dans mon précédent article, je me suis confronté à un problème d'espace disque sur ma machine virtuelle faisant fonctionner Plex Media Server. Je vais donc procéder à l'augmentation de la taille du disque virtuel pour élargir la partition /dev/sda1 qui a besoin de plus d'espace.

Première étape, l'extension de disque dans la console ESXi elle-même ; étant donné que je suis en 6.5 et que ma machine virtuelle est de version 12 - si mes souvenirs sont corrects - je suis obligé de passer par l'interface web, bien que je préfère très nettement le client lourd. Mon datastore composé de deux disques durs de 3 To en RAID 1 me le permettant très largement, je passe de 60 Go à 100 Go.

Etant donné qu'à l'installation de Debian, je n'ai pas séparé certains répertoires sur des partitions distinctes (/var, /home par exemple) - ce qui n'est pas très propre, j'en conviens, mais plus facile pour gérer l'espace libre lorsqu'on est pas aguerri sur Debian - je suis condamné à réaliser l'élargissement avec GParted en live CD.

Il faut donc démarrer sur le disque virtuel, en pressant échap dans la console VMware.

Puis on arrive sur cet écran :

On choisit la première option, vient par la suite la configuration du clavier, rien de difficile. Il faut ensuite confirmer la disposition de celui-ci.

Une fois l'initialisation terminée - ce qui peut prendre quelques minutes - on arrive sur l'écran principal de l'application GParted qui présente l'état du stockage.

Confirmation de la bonne extension du VMDK : on a 40 Go non alloués. Je ne peux étendre directement /dev/sda1, car comme cela est visible sur le graphique, mon espace non alloué est après la partition étendue et le swap. Je vais donc devoir supprimer le swap, la partition étendue, puis étendre /dev/sda1 et recréer une partition et le swap.

Une fois le disque étendu, on valide l'écriture sur le disque. Si tout s'est bien passé, /dev/sda1 a bien été étendue à environ 100 Go - car il ne faut pas oublier de laisser un peu de place pour le swap ! - puis on procède à la recréation de la partition étendue, puis du swap.

On écrit de nouveau les modifications sur le disque.

Une fois l'écriture terminée, on constate que tout semble s'être bien déroulé : /dev/sda1 a été agrandie, et le swap a bien repris sa place et son point de montage.

Un simple redémarrage plus tard - il y a un raccourci pour faire un redémarrage proprement sur le "bureau" du live CD, df nous indique bien que /dev/sda1 a grossi pour nous offrir quelques dizaines de Go supplémentaires.