Perte de connectivité LDAP après upgrade vCenter en 6.7 u3f

Cette semaine, j’ai été confronté à un incident plutôt particulier suite à un upgrade d’une appliance vCenter (6.5 vers 6.7 u3f – build 15976714). En effet, après l’upgrade, j’étais incapable de me reconnecter en utilisant mon login ActiveDirectory, pas plus qu’en utilisant un autre compte lié à ce même ActiveDirectory. Cependant, la connexion avec l’utilisateur local fonctionne bien.

Les vérifications de base ne donnent rien de particulier :

  • L’appliance existe bien dans l’ActiveDirectory en tant qu’objet Computer (je n’utilise pas de compte pour faire la connexion)
  • Les entrées DNS directes et reverse sont bien correctes

La sortie et réintégration à l’ActiveDirectory de l’appliance n’ont rien donné non plus, cependant il y a du mieux : tous les comptes renseignés en dur dans les autorisations globales peuvent ouvrir une session sur le vCenter. Cependant les comptes qui sont membres des groupes étant dans les autorisations ne fonctionnent toujours pas. De plus, l’appel aux webservices SOAP est toujours impossible par un compte sur l’ActiveDirectory (Veeam utilise ces webservices pour interagir avec le vCenter afin de sauvegarder les VM).

Étant donné le caractère plutôt urgent de la résolution de cet incident puisqu’il impacte les sauvegardes, nous avons contacté le support VMware qui nous a confirmé que ce dysfonctionnement pouvait arriver de manière aléatoire lors d’un upgrade de VCSA vers ce dernier build (6.7 update 3f) et que ce bug sera corrigé lors d’une prochaine release.

Malgré tout, le support ne nous a pas permis de trouver la cause du dysfonctionnement ; en faisant jouer nos réseaux, nous avons été mis sur la piste du fichier /etc/resolve.conf, que j’aurais dû vérifier en me connectant en SSH sur l’appliance (si je peux avoir une excuse, il était plus de 22h quand je me suis penché sur le sujet en urgence !).

Pour ce faire, ouvrir une session SSH sur le VCSA, puis saisir shell dans le prompt afin d’accéder au prompt standard de PhotonOS qui est le système d’exploitation socle de vCenter (basé sur GNU/Linux), puis saisir la commande suivante :

more /etc/resolve.conf

Cette instruction doit imprimer le contenu du fichier qui doit à minima contenir l’IP loopback et les DNS renseignés, ainsi que les zones DNS dans lesquelles chercher les enregistrements. Et c’est précisément ici que ça coinçait puisque notre zone ActiveDirectory n’était pas renseignée dans le paramètre search, alors qu’elle l’était sur l’ancienne appliance.

Une fois la zone ActiveDirectory renseignée et un redémarrage complet de l’appliance plus tard, la connexion avec des comptes LDAP était fonctionnelle et les sauvegardes opérationnelles.

Perte de connectivité réseau sur machines virtuelles

J’ai été confronté à un problème de manière aléatoire sur quelques machines virtuelles d’un cluster vSphere. Ce problème se traduisait par une perte de connectivité réseau : les machines virtuelles étaient incapables de joindre leur gateway et de communiquer avec d’autres machines du même VLAN. Une manière temporaire de rétablir la connectivité réseau était de réaliser un vMotion sur la machine virtuelle afin de la déplacer sur un autre hôte.

De nombreuses manipulations ont été tentées sur ces machines pour tenter de garder une connectivité durable : changement de type de carte réseau, création de nouvelle machine avec rattachement des disques virtuels, changement d’adresse MAC, etc. mais sans succès.

Les 2 hôtes vSphere formant le cluster ont chacun 4 interfaces physiques : 2 pour les machines virtuelles, une pour le management network et la dernière pour le vMotion. Sur ces deux dernières interfaces, seul un VLAN était déclaré côté switch physique.

En regardant du côté des vSwitch positionnés sur chaque hôte, il apparaissait qu’en fait les VLAN déclarés sur vSphere étaient poussés sur toutes les interfaces physiques (vmnic) du serveur. Cette configuration pouvait donc faire qu’une machine située sur le VLAN « PROD_CLIENT » tentait de communiquer sur les 2 interfaces qui n’avaient pas ce VLAN de déclaré côté switch physique.

Explications : considérons un serveur avec 4 interfaces (vmnic0 à vmnic3) branchées sur les ports 1, 2, 3 et 4 d’un switch. Les ports 1 et 2 (branchés sur vmnic0 et vmnic1) donnent accès au VLAN « ADMIN » tandis que les ports 3 et 4 (branchés sur vmnic2 et vmnic3) donnent accès aux VLAN « PROD_CLIENT », « PROD_INTERNE », « RE7_CLI », « RE7_INT ». Côté vSphere, ces VLAN sont visibles et peuplés ; seulement ils doivent être configurés sur les bonnes interfaces. Si le VLAN « PROD_CLIENT » était accessible sur vmnic2 et vmnic3 puisqu’il est disponible sur les ports 3 et 4 du switch, il ne l’était pas sur les ports 1 (vmnic0) ni 2 (vmnic1). Or, ce VLAN était configuré sur ESXi pour utiliser les 4 interfaces physiques.

Sur cette capture, le VLAN est configuré pour être accessible sur tous les vmnic ; cependant côté switch physique cela n’est pas le cas puisque le VLAN est configuré sur les seuls ports 3 et 4 (vmnic2 et vmnic3).

Étant donné que ce VLAN utilisait des interfaces sur lesquelles il était injoignable côté switch physique, lorsque vSphere faisait passer le trafic réseau de la VM sur ces interfaces les machines devenaient de ce fait inaccessibles et incapables de joindre leur passerelle. Un redémarrage complet de la machine virtuelle (et non pas uniquement l’OS invité) pouvait résoudre le souci temporairement puisque vSphere réinscrit la carte réseau virtuelle sur une des interfaces sur lesquelles le VLAN en question était accessible (dans notre exemple, vmnic2 ou vmnic3). La même action de réinscription se faisait dans le cadre d’un déplacement d’hôte, puisque la VM passait sur un autre hôte physique, avec d’autres cartes physiques ; cependant le dysfonctionnement persistait puisque l’autre hôte du cluster était configuré de la même manière.

Afin de résoudre le dysfonctionnement, il a donc fallu déplacer les vmnic0 et vmnic1 dans les adaptateurs inutilisés pour les VLAN « PROD_CLIENT », « PROD_INTERNE », « RE7_CLI » et « RE7_INT ». Ainsi, le trafic des VM configurées sur ces réseaux passent désormais uniquement via vmnic2 et vmnic3 et le problème est résolu.

Sur cette capture, les VLAN sont bien configurés pour n’utiliser que les vmnic qui sont interfacés sur les ports du switch physique donnant accès aux VLAN en question.

VMware et Powershell : liste des datastores en surcharge

J’avais déjà développé un script envoyant un mail si un datastore tombait sous un seuil défini dans le script d’espace libre. Aujourd’hui, voici une variante de ce script puisque celui-ci ne va détecter une espace disque trop faible mais une sur-allocation de celui-ci. En effet, avec les disques à provisionnement dynamique, il est possible de se retrouver en surcharge en créant de nouveaux disques virtuels positionnés sur ce même datastore sur lequel l’espace disque aura été jugé suffisant, en omettant de prendre en compte la croissance des disques déjà présents. Une capture d’écran peut permettre de comprendre le phénomène.

Cette capture d’écran montre bien les différences entre l’espace libre affiché et celui que l’on peut calculer en déduisant l’espace provisionné de la capacité maximale.

Sur cette capture, le sixième datastore affiche 320,49 Go de libre sur 749,75 Go : sur le papier, il est possible de créer une nouvelle VM puisque nous sommes en dessous du seuil d’occupation que l’on ne souhaite pas dépasser (généralement 80%). Seulement, 652 Go sur les 749 sont provisionnés. Cela signifie que si les disques virtuels viennent à atteindre leur taille maximale, nous serons en dessous des 20% d’espace libre. Pire, si la taille provisionnée est supérieure à la capacité, les disques virtuels seraient incapables de grossir et les VM pourraient planter.

Cela dit, il n’est pas forcément nécessaire de s’en tenir simplement à l’espace alloué et à la capacité maximale du datastore. Avec des machines bien dimensionnées et des données de capacity-planning, il est tout à fait possible d’exploiter chaque méga-octet du datastore sans perdre systématiquement au minimum 20% de l’espace de stockage.

Ce script liste donc tous les datastores qui ont un espace provisionné supérieur au seuil défini par rapport à la capacité maximale. Par défaut, ce seuil est de 80% (calculé par 1 – 0,20 dans le script). Il prend le nom du cluster en paramètre -Cluster. Dans une fenêtre PowerCli, on appellera le script ainsi si l’on souhaite analyser le cluster nommé PROD_PARIS :

.\vmw_ds-allocated-size.ps1 -Cluster "PROD_PARIS"
Param([string]$Cluster)
 $threshold = 0.20
 $dslist = Get-Datastore -Location $Cluster
 foreach($ds in $dslist){
     $allocsize = 0
     $hdlist = Get-HardDisk -Datastore $ds
     foreach($hd in $hdlist){
         $allocsize += $hd.CapacityGB
     }
     if($allocsize -gt $ds.CapacityGB*(1-$threshold)) { echo $ds.Name }
 }

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."