Datastore UUID is required when a cluster UUID is specified

Get-VMHost|%{($_|get-esxcli).vsan.datastore.add($null, "vsanDatastore2", "11111111-1111-1111-1111-111111111111")}

En utilisant $null pour la propriété ClusterUUID, ca passe crème.

MAJ 18/05/2021 : On me signale dans l’oreillette que VMware supporterai officiellement cette méthode :

Engineering have advised that the procedure you are carrying out is applicable to your specific need and is considered supported from us

Tous les admin VMware le savent, après renommage d’une VM il convient de faire un petit Storage vMotion (aka d-motion pour les boomers) pour “propager” le nouveau nom aux fichiers de la VM en question. Et pour ceux qui l’ignorait encore, cette feature était un bug jusqu’à la version 5.0 U2 d’ESXi.

Évidement, cela nécessite d’avoir un 2eme datastore (idéalement avec des performances identiques et la bonne volumétrie) pour faire l’aller-retour de la VM (ou un Storage Pod) ce qui n’est pas souvent le cas sur un cluster vSAN pour des raisons évidentes.

Jusqu’à maintenant, les seules solutions étaient de … ne rien faire ou de connecter un datastore NFS ponctuellement pour faire le svmotion. Mais en cherchant à faire du HCI mesh en ligne de commande nous sommes tombé sur la solution (très discrètement documenté) : esxcli vsan datastore add pour créer un 2eme datastore sur le vmdk namespace.

Cette feature semble être apparu à partir de la version 6.7 U3 et est évidement accessible en PowerCLI également. Il suffit donc d’ajouter un “datastore” vSAN en précisant le nom et l’UUID de votre choix si vous le souhaitez. Il est nécessaire d’exécuter cette même commande sur tous les ESX du cluster avec le même nom et le même UUID.

Add a new datastore to the vSAN cluster. This operation is only allowed if vSAN is enabled on the host. In general, add should be done at cluster level. Across a vSAN cluster vSAN datastores should be in sync.

Voila ce que ça donne sur un cluster à 3 noeuds :

On peut donc maintenant faire notre svmotion aller-retour sans perte de performances.

Une fois l’operation terminé on peut utiliser la commande “remove” en precisant le nom et l’UUID du datastore ou carrément la commande “clear” :

Remove all but the default datastore from the vSAN cluster. This operation is only allowed if vSAN is enabled on the host. In general, add should be done at cluster level. Across a vSAN cluster vSAN datastores should be in sync.

Et aucun risque de se rater, si une vm est toujours présente sur le datastore, vous aurez droit à une belle erreur. Après avoir fait du ménage, ça passe crème :

la VCSA 6.7 introduit le backup automatique programmé mais toujours pas le support du SMB (raison pour laquelle nous avions boudé la feature en 6.5). En fouillant dans la doc, nous nous sommes aperçu que le protocole webdav était supporté, c’est certainement ce que VMware sous-entend par http et https bien que ce ne soit pas extrêmement clair.

En grand fan et utilisateur intensif de NextCloud que nous sommes, nous avons testé le backup en secure webdav (https) vers un nextcloud avec succès et ce très facilement (on s’attendait à des histoires d’url comme c’est souvent le cas avec le webdav) :

Reste plus qu’à tester le restore maintenant

$i=0
$pre = '{"fields" : ["message"],"from":'
$post = ',"size": 2000,"query":{"filtered":{"query":{"bool":{"should":[{"query_string":{"query":"hostname.raw:esx.vmware.com"}}]}},"filter":{"bool":{"must":[{"range":{"@timestamp":{"from":1450738800000,"to":1450997999999}}}]}}}}}'
$msgs=1

while ($msgs) {
$msgs=$false
$body = $pre + $i + $post
$msgs=(Invoke-RestMethod -URI "http://demo.sexilog.fr:9200/_search?pretty=1" -Method 'POST' -ContentType 'application/json' -Body $body -TimeoutSec 5).hits.hits.fields.message
$msgs|%{$_.Trim()}|Out-File -FilePath c:\temp\esx.vmware.com.log -Append
$i=$i+2000
}

Il convient de remplacer les FQDN esx.vmware.com et demo.sexilog.fr par les vôtres et d’ajuster les valeurs from/to en epoch.

Le script extrait tous les messages pour le serveur donné, sur la période donné vers un fichier de log par batch de 2000 :

Et une fois l’export terminé, le script se termine par une erreur “attendue” :

A titre indicatif, il a fallut 1h pour extraire 1Go de log. Egalement dispo sur GitHub si besoin.

Et on a bien fait, parce qu’on a même réussi à créer une partition VMFS sur une clef de boot ESXi 6.0 :

Pour que ça ait de la gueule, nous avons utilisé ce qui se fait de mieux en la matière : une clef USB 3.0 MX-ES SLC NAND Ultimate Endurance capable d’encaisser 180Mo/s en écriture.

La procédure est la même que pour créer un datastore en cli avec partedUtil et vmkfstools :

Et pour le fun, on a aussi essayer sur une clef Kingston/VMware ESXi “special” :

Nous vous laissons imaginer les possibilités que cette nouvelle “unsupported“ feature pendant que nous préparons un post qui n’attendait que ça pour voir le jour…

]]> http://www.hypervisor.fr/?feed=rss2&p=5461 3 http://www.hypervisor.fr/?p=5300 http://www.hypervisor.fr/?p=5300#comments Mon, 10 Nov 2014 11:02:37 +0000 NiTRo http://www.hypervisor.fr/?p=5300 Depuis l’apparition du thin provisioning, la question de la récupération de l’espace disque libéré après allocation refait surface régulièrement.

Historiquement, il suffisait de “zeroer” l’espace libre inGuest et faire un storage vmotion vers n’importe quel autre datastore pour récupérer l’espace “zeroé” grâce au datamover fsdm qui zappe les zéros. Malheureusement, depuis l’apparition du datamover fs3dm dans vSphere 4.0 cet avantage a disparu comme l’explique Duncan dans un vieux post de 2011.

A cette époque, il était courant d’avoir des datastores configurés avec des blocksize différents ce qui permettait de contourner le problème facilement. Aujourd’hui, VMFS 5 a changé cette approche avec le blocksize unifié à 1M.

Pour tricker comme avant et forcer fsdm à faire le boulot il faut une rupture technologique VMFS <> NFS ou jouer avec un paramètre caché de vsish comme l’indique William Lam dans son commentaire :

Whether VMFS should handle data movement requests by leveraging FS3DM

Et depuis le temps que nous voulions le tester, nous sommes enfin tomber sur une VM avec ~60Go à récupérer dans un environnement VMFS5 only:

Un coup de sdelete -z plus tard, on change le paramètre /config/VMFS3/intOpts/EnableDataMovement dans vsish et on lance un storage vmotion.

Au passage on remarque bien la phase de lecture sans écriture pendant le svmotion :

Après la migration (qui vous permettra aussi de renommer officiellement les fichiers de votre VM), la VM a maigri comme il faut :

Pour ceux qui voudrait tout simplement le faire offline, il y a l’option –punchzero de vmkfstools.

La seule référence que nous ayons pu trouver à ce sujet est une kb d’un path pour ESXi 5.0, dommage.

En passant, nous vous rappelons qu’il est possible de rediriger le log d’une VM vers le syslog d’ESXi pour vous éviter de fouiller dans le fichier vmware.log et c’est bien sûr faisable à chaud en PowerCLI (comme d’hab, vmotion pour appliquer le setting) :

Get-VM toto|Get-View|?{-not $_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="vmx.log.destination"; Value="syslog-and-disk"}))}))}

Après on peut faire des belles requêtes dans son Graylog2 :

Un grand merci à William pour cette pépite.

La recette est assez simple : Image Builder pour générer l’Offline Bundle + Get-EsxCli pour l’update + Reboot. Du PowerCLI de bout en bout donc on est bon.

Dans notre cas, il fallait mettre à jour des serveurs HP et DELL de sorte que le résultat soit le même qu’avec la customized ESXi image fourni par les éditeurs. Malheureusement il est impossible d’utiliser une iso pour générer un Offline Bundle (indispensable à esxcli) et si vous vous demandez comment VUM y parvient, allez fouiller dans le répertoire /UPGRADE d’une iso d’ESXi et vous comprendrez… Pas le choix, il a fallut se taper les Bundle à la main !

La toute première étape c’est évidement le choix de la version d’ESXi à atteindre (ESXi 5.0 Complete Update 3) et de faire un clone de l’Image Profile afin de pouvoir le customizer en y ajoutant des packages :

Add-EsxSoftwareDepot https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

New-EsxImageProfile -CloneProfile ESXi-5.0.0-20131002001-standard -Name "VMware-ESXi-5.0.0-Update3-1311175-HP-5.44.21-Feb2014" -Vendor "Hypervisor.fr"

Si vous voulez voir la liste des build disponibles, l’idéal c’est un petit GridView :

Au passage, on peut apercevoir le process Image Factory Server (if-server.exe) qui fait office de moulinette :

HP propose depuis longtemps un vibsdepot (aka HP Online Depot) qui facilite grandement la tâche. Vous n’avez qu’à choisir le répertoire qui correspond à la date de l’iso (Feb2014 dans notre cas) et ajouter le dépôt (index.xml et index-drv.xml) à votre liste :

Add-EsxSoftwareDepot http://vibsdepot.hp.com/hpq/feb2014/index.xml, http://vibsdepot.hp.com/hpq/feb2014/index-drv.xml

Il faut ensuite ajouter les packages (un minimum filtrés pour éviter les insultes toutes rouge de powershell) au profil custom et l’exporter au format Bundle (.zip) :

Get-EsxSoftwarePackage|?{$_.SourceUrls -match "vibsdepot.hp.com/hpq/feb2014" -and !($_.Depends -match 'vmkapi_2_[1-9]')}|Add-EsxSoftwarePackage -ImageProfile "VMware-ESXi-5.0.0-Update3-1311175-HP-5.44.21-Feb2014"

Export-EsxImageProfile -ImageProfile "VMware-ESXi-5.0.0-Update3-1311175-HP-5.44.21-Feb2014" -ExportToBundle -FilePath "C:\Temp\VMware-ESXi-5.0.0-Update3-1311175-HP-5.44.21-Feb2014.zip"

Si vous voulez consulter la liste des package avant de les ajouter, encore un petit GridView :

Du coté de DELL c’est radicalement différent puisque leur dépôt ne contient que les vib “iDRAC Service Module” et “OpenManage”. Heureusement, en fouillant un peu nous avons pu trouver un pdf qui recense toutes les modifications apportées à l’iso originale de VMware pour parvenir à la version customizé made in DELL. S’en suit un travail de fourmi pour retrouver tous les offline bundle associés, les télécharger et les ajouter au profil custom.

Une fois que le bundle est prêt, un petit coup de Get-EsxCli pour le distribuer sur le même principe qu’ESXCLI mais a l’échelle d’un cluster :

Get-Cluster toto|Get-VMHost|%{($_|Get-EsxCli).software.profile.update($false, "/vmfs/volumes/datastore/HP/VMware-ESXi-5.0.0-Update3-1311175-HP-5.44.21-Feb2014.zip", $true, $null, $true, $null, $null, "VMware-ESXi-5.0.0-Update3-1311175-HP-5.44.21-Feb2014", $null)}

Il vous faudra évidement personnaliser le nom du cluster, le chemin du bundle ainsi que le nom du profil mais surtout changer la variable de dry run $true (celui juste après le path dans le oneliner) en $false pour effectuer la mise a jour. Ce oneliner ne fait que vérifier que la mise a jour est possible et vous permet de contrôler le process :

Pour plus d’informations, nous vous recommandons vivement de consulter la série de post “ImageBuilder Deep Dive” d’Andreas Peetz.

La touche finale c’est un oneliner qui reboot le cluster en séquentiel (DRS auto obligatoire et les ESX doivent avoir au moins 1 jour d’uptime) :

Get-Cluster toto|Get-VMHost|Get-View|?{$_.Runtime.BootTime -lt (Get-Date).adddays(-1) -and $_.Runtime.ConnectionState -eq "connected" -and !$_.Runtime.InMaintenanceMode}|%{$_.EnterMaintenanceMode("60",0);while (!(get-view -viewtype hostsystem -filter @{"name"=$_.name}).Runtime.InMaintenanceMode){sleep 15};$_.RebootHost(0);while ((get-view -viewtype hostsystem -filter @{"name"=$_.name}).Runtime.ConnectionState -eq "connected"){sleep 15};while ((get-view -viewtype hostsystem -filter @{"name"=$_.name}).Runtime.ConnectionState -eq "notResponding"){sleep 30};$_.ExitMaintenanceMode("60");while ((get-view -viewtype hostsystem -filter @{"name"=$_.name}).Runtime.InMaintenanceMode){sleep 15}}

MAJ 25/04/2014 : Mise à jour du script (version 1.1) : A la demande express de notre ami DR, nous avons rajouté le paramètre -VIX pour faire la requête WMI via les vmtools et le paramètre -noSSO pour spécifier des credentials autre que ceux de votre session courante. A ce propos, et à notre plus grande surprise, la cmdlet Invoke-VMScript semble dorénavant supporter le SSO donc si votre compte AD à les bons droits sur le vCenter et dans le GuestOS, plus besoin du paramètre “GuestCredential” pour faire du VIX !

Lorsqu’on vous demande de retirer quelques disques d’une VM Windows qui en possède une cinquantaine, c’est généralement le début d’une longue chasse où on essaye de faire correspondre les id scsi, les contrôleurs ou les tailles de volume quand on est vraiment au bout du rouleau…

Il y a bien des scripts PowerCLI pour surmonter la tâche mais l’élément de référence est toujours l’id scsi ce qui pose parfois des problèmes comme ça l’à été pour nous lors d’une opération similaire :

Une kb VMware décrit comment faire une correspondance via le device manager de windows (et non pas le disk manager) mais où il faut chercher à la main la propriété “location” qui correspond au contrôleur scsi :

To correlate the virtual device node SCSI controller to the Windows drive letter. Each controller increments by 32.
The first SCSI controller is given a location ID of 160. Therefore the second controller is 192, 224 for the third and 256 for the fourth.

Nous vous laissons apprécier l’ampleur de la tache lorsqu’on a plusieurs disques à détacher :

En cherchant un peu sérieusement, nous avons trouver un point commun parfaitement identique entre Hard disk et PHYSICALDRIVE : l’UUID (ou SerialNumber sous Windows). Un petit coup de PowerCLI plus tard, on obtient un beau tableau pour faire la correspondance sans risque (avec le chemin du vmdk en bonus) :

Les prérequis du script sont que vous soyez connecté au bon vcenter et que vous puissiez accéder en WMI à la VM en question (si le FQDN de la vm ne correspond pas à son nom, il faut utiliser le paramètre -winname). Le paramètre -grid controle la sortie dans un GridView pour ceux qui n’aime par le style CLI :

Get-VMWinUUIDMap

Malheureusement, si vous ne voulez pas investir dans une solution telle que SRM, Zerto ou VPLEX ou encore si vous aspirez à plus de simplicité, le failback des VM peut rapidement se transformer en cauchemar (register de vmx à la main par exemple). En effet, depuis vSphere 5.0, HA (aka FDM) est capable à lui seul d’assurer le redémarrage des VM (failover) dans un stretched cluster tant que le stockage d’un site est répliqué sur l’autre site et présenté aux ESX après un crash (extrais tiré de VMware vSphere 5 Clustering Technical Deepdive) :

The master [agent] will also attempt to take ownership of any datastores it discovers along the way, and it will periodically retry any it could not take ownership of previously.

Il est donc possible d’envisager un cluster étendu sur 2 sites où HA serait capable de redémarrer les VM d’un site crashé après une simple manipulation coté stockage. Après de nombreux tests, il s’avère que cette solution est parfaitement fonctionnelle mais elle souffre néanmoins d’un gros problème : le failback. En effet, lorsqu’il est question de renvoyer les VM sur leur site initial, il est nécessaire d’arrêter les VM pour re-synchroniser le stockage et redémarrer les VM sur le site primaire. Lors de cette opération, on se retrouve inévitablement confronté à des VM “inaccessible” :

A partir de ce moment, il n’est plus possible de faire autre chose que d’enregistrer les VM manuellement sur un des ESX (directement) du site primaire et laisser l’agent vpx faire le reste. Evidemment, c’est l’un des pires scénarios mais il existe des solutions comme celle de faire un storage vmotion pour déplacer les VM sur un autre espace de stockage avant de faire les opérations sur les baies mais bien qu’il soit possible de faire le failback à chaud dans ce cas, il faut prévoir un espace supplémentaire non négligeable et trop de manipulations à nos yeux.

Après avoir travaillé un certain temps sur le sujet avec notre ami vmdude.fr, nous avons trouvé LA solution la plus élégante pour qu’un passage en production soit envisageable. Elle nécessite quelques manipulations simples et parfaitement scriptables. A vrai dire, la solution était sous notre nez depuis le début et existe depuis longtemps car utilisé dans un autre cas de figure. Il y a même de forte chance pour que vous vous en soyez déjà servi une fois… Lorsqu’une VM est configurée pour ne pas être redémarrée par HA, elle apparaît comme “disconnected” tant que l’ESX n’est pas redémarré (lui aussi est “disconnected” d’ailleurs “not responding”) et dans cet état, vous pouvez démarrer cette VM car vcenter va automatiquement enregistrer la VM ailleurs alors qu’il ne peut plus communiquer avec l’ESX pour “unregister” la VM. Nous avons donc utiliser cette fonctionnalité pour “cacher” au vcenter les manipulations de stockage en regroupant les VM sur un ESX que l’on déconnectera avant. Ouvrez grand les yeux :

La liste des commandes PowerCLI utilisées est disponible ici, elles doivent évidement être modifiées pour correspondre à votre environnement (nom de cluster, ESX et resource pool). Voici un récapitulatif des étapes post crash :

• <==failover==>
• présentation du stockage aux ESX
• montage des snapshot VMFS ou des shares NFS
• <==failback==>
• shutdown des VM
• move des VM sur l’ESX helper
• enter maintenance mode de l’ESX helper
• disconnect de l’ESX helper
• *disable SIOC*
• démontage des snapshot VMFS (ou des share NFS)
• failover du stockage
• Power on des VM
• reconnect de l’ESX helper
• exit maintenance mode de l’ESX helper

Une autre solution consiste à présenter un petit espace temporairement à tous les ESX (un share NFS est ideal dans ce cas) afin d’y déplacer uniquement la “home” de la VM (vmx, log, etc…) avec un svmotion scripté afin d’éviter l’état “inaccessible” et pouvoir facilement redémarrer les VM après la re-synchronisation du stockage. L’avantage est qu’il n’est pas nécessaire de “sacrifier” un ESX mais cela rajoute des manipulations au PRA et un espace de stockage à gérer en plus.

Disponible uniquement sur les resource pools dans le client legacy, cette vue synthétise l’utilisation “near real-time” cpu/ram du cluster des 5 dernières minutes (quickstats). Il suffit de créer un resource pool à la racine de votre cluster (sans reservations ni limites, les shares n’ont pas d’importances ici) pour avoir une visibilité comparable des ressources du cluster :

La vue “Guest Memory” se paye même le luxe d’être un peu plus détaillée graphiquement alors que la vue “Host Memory” est faussée par la mémoire allouée aux VM.

su - -c 'cd /usr/share/graylog2-web;rake RAILS_ENV=production streamalarms:send>>/var/log/graylog.log'
su - -c 'cd /usr/share/graylog2-web;rake RAILS_ENV=production subscriptions:send>>/var/log/graylog.log'

Ceux qui connaissent Graylog2 savent à quel point c’est un serveur syslog surpuissant mais pas vraiment simple à installer. De plus, ceux qui s’en servent pour des ESXi ont eu la douloureuse surprise de constater que graylog2 ne supportait pas le format syslog d’ESXi 5.x alors que celui de 4.x était parfaitement géré. Nous allons donc faire d’une pierre deux coups.

En ce qui concerne la simplicité, Mick Pollard a posté cet été comment utiliser ses packages sur un Ubuntu 12.04, ce à quoi nous ajouterons des morceaux d’un autre how-to pour faire tourner l’interface web de graylog2 sous apache.

Et pour la compatibilité, nous configurerons graylog2 pour écouter sur un port “alternatif” (10514 dans notre exemple) car le port 514 sera pour rsyslog qui réécrira tout ce qui passe au bon format et le forwardera (non, ce mot n’existe pas) à graylog2. Attention ca va aller très vite :

echo 'deb http://ppa.lunix.com.au/ubuntu/ precise main' | sudo tee /etc/apt/sources.list.d/aussielunix.list
apt-key adv --keyserver keyserver.ubuntu.com --recv D77A4DCC
apt-get update
apt-get install mongodb elasticsearch graylog2-server graylog2-web apache2 libapache2-mod-passenger

Vous pouvez aller boire un café, ya ~500Mo à downloader/installer. Ensuite il faut configurer quelques trucs :

/etc/graylog2.conf
syslog_listen_port = 10514

/etc/rsyslog.conf
$ModLoad immark
$ModLoad imudp
$UDPServerRun 514
$ModLoad imtcp
$InputTCPServerRun 514

/etc/rsyslog.d/50-default.conf
#*.*;auth,authpriv.none -/var/log/syslog

/etc/apache2/sites-available/default

<VirtualHost *:80>
    DocumentRoot /usr/share/graylog2-web/public/
        RailsEnv 'production'
    <Directory /usr/share/graylog2-web/public/>
        Allow from all
        Options -MultiViews
    </Directory>

    ErrorLog /var/log/apache2/error.log
    LogLevel warn
    CustomLog /var/log/apache2/access.log combined
</VirtualHost>

/etc/rsyslog.d/32-graylog2.conf

$template GRAYLOG2,"<%PRI%>1 %timegenerated:::date-rfc3339% %HOSTNAME% %syslogtag% - %APP-NAME%: %msg:::drop-last-lf%\n"
$ActionForwardDefaultTemplate GRAYLOG2
$PreserveFQDN on
*.*     @localhost:10514

/etc/security/limits.conf
root – nofile 64000
root – memlock unlimited

/etc/pam.d/su
session required pam_limits.so

Après, on secoue bien :

service elasticsearch start
service mongodb restart
service graylog2-server start
service rsyslog restart
service apache2 restart

Selon le formatage des messages, il est parfois nécessaire d’avoir un reverse DNS pour que le hostname remonte bien (au lieu de l’ip). Sur le screenshot suivant vous pourrez constater la présence de log provenant d’ESXi 5, de pfSense et d’Astaro/UTM mais nous avons pu également valider que cette solution était fonctionnelle pour ESXi 4, FreeNAS, NTsyslog, Snare/Epilog et nxlog.

On vous laisse découvrir les joyeusetés des streams et des analytics de Graylog2

C’est tellement plus pratique dans une VM

Get-Datastore vsp50sas01|Get-View|?{$_.Summary.Accessible -eq $true -and $_.Capability.StorageIORMSupported -and $_.Summary.MultipleHostAccess}|%{(Get-View (Get-View ServiceInstance).Content.StorageResourceManager).ConfigureDatastoreIORM_Task($_.MoRef, (New-Object VMware.Vim.StorageIORMConfigSpec -Property @{enabled="1"; congestionThresholdMode="automatic"; percentOfPeakThroughput="90"; statsAggregationDisabled="0"; statsCollectionEnabled="1"}))}

Ce oneliner permet, en plus d’activer SIOC en mode automatique, de jouer sur la proprieté “percentOfPeakThroughput” (90% par défaut), décrite dans le “What’s New in VMware vSphere 5.1 – Storage” :

The latency threshold is set to the value determined by the I/O injector (a part of SIOC). When the I/O injector calculates the peak throughput, it then finds the 90 percent throughput value and measures the latency at that point to determine the threshold.

De plus, dans la GUI, “Exclude I/O statistics from SDRS” correspond à la propriété “StatsAggregationDisabled“. Et “StatsCollectionEnabled” vous permettra de désactiver le mode “stats only” si vous êtes certain que le datastore ne fera jamais parti d’un storage POD datastore cluster et que vous souhaitez alléger votre VCDB.

Depuis leur apparition dans vSphere 4.0 en 2009 et jusqu’à aujourd’hui (malgré les nouvelles features exclusives), nous avons considéré les distributed switch comme des SPOF. L’idée de départ est très bonne mais la dépendance au vcenter nous paraissait trop importante, il était possible de lancer des actions irréversibles (sur le management network en particulier), de nombreuses kb vmware ont fait état de bugs assez gênant (surtout pour la v4.x) et nous avons toujours été inquiet de ne pouvoir presque rien faire en direct sur un ESXi en cas de problème réseau. VMware admet même le pire scénario (qui poussait les plus prudents d’entre nous à mixer standard/distributed lorsque le nombre de nic le permettait) dans  le “What’s New in vSphere 5.1 – Networking” :

However, in the VDS environment, where multiple hosts are connected to a distributed switch, any network failure or misconfiguration of the management port group can potentially disconnect all hosts from the vCenter Server system.
[...]
In vSphere 5.0, the only way for the user to recover from this situation is by going to individual hosts and building a VSS with a proper management network configuration.

vSphere 5.1 apporte, en plus d’une certaine maturité, toutes les fonctionnalités qui manquaient à DVS. L’une d’entre elles, nommé Host Networking Rollback, fera certainement changer d’avis les plus réticents (y compris nous-même). Pour faire court, cette feature “déjoue” automatiquement la dernière reconfiguration du stack réseau (standard ou distributed) qui aboutie à une déconnexion du vCenter :

Tout à fait logiquement, lorsque les ESXi recontactent le vCenter, le distributed switch annonce un “out of sync” du au rollback :

C’est là qu’une autre nouvelle feature (le Distributed Switch Rollback) rentre en scène et permet de restaurer la précédente configuration d’un distributed switch ou distributed portgroup. Attention, en cas de restart du vCenter, la dernière configuration est perdue.

When you use a VMware distributed virtual switch, each time you reconfigure the switch, the Server saves the switch configuration before applying the updates. If the vCenter Server is restarted, the saved configuration is not preserved and the method does not return a configuration specification.

Cette fonctionnalité n’étant accessible qu’avec le webclient, voici comment procéder en PowerCLI :

(Get-VirtualPortGroup -Name TargetdvPortGroup|get-view).ReconfigureDVPortgroup($(Get-VirtualPortGroup -Name TargetdvPortGroup|get-view).DVPortgroupRollback($()))

(Get-VirtualSwitch -name TargetDistributedVirtualSwitch|get-view).ReconfigureDvs((Get-VirtualSwitch -name TargetDistributedVirtualSwitch|get-view).DVSRollback($()))

Cette dernière action n’est d’ailleurs même pas possible en GUI, à moins d’avoir exporté la configuration du DVS dans un fichier.

Bonus : nous vous avons concocté un petit onliner pour créer une alarme afin d’être averti en cas rollback automatique sur les ESXi attachés à un distributed switch :

(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "vSphere Distributed Switch Rollback Event";Description = "Custom alarm to monitor vim.event.RollbackEvent Event";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.EventAlarmExpression -Property @{eventType = "EventEx";EventTypeId = "vim.event.RollbackEvent";objectType = "HostSystem";status = "yellow"});)});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmare.local";Subject = "[vAlarm] {targetName} NetworkRollback Event - {newStatus}";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "green";FinalState = "yellow";Repeats = $false}))})});ActionFrequency = "1800"}))

Nous n’avons pas encore trouvé une solution correcte pour exporter la configuration des distributed switch/portgroup dans un fichier (le web client renvois un zip ressemblant à un vib), n’hésitez pas à nous remonter vos idées et/ou réactions sur le sujet.

Pour finir, il est maintenant possible de reconfigurer “automatiquement” la partie management network (standard ou distributed) via la DCUI :

En exclusivité mondiale (si, si), nous vous livrons aujourd’hui les méthodes, longtemps gardées secrètes, pour créer cette précieuse alarme qui vous avertira lorsqu’un datastore NFS n’est plus accessible sur un ESX. Tout cela grâce à l’event “esx.problem.vmfs.nfs.server.disconnect” que nous avons trouvé dans la fameuse liste de veeam qui couvre vim 2.5 à 5.0

A la “mano” :

Avec un oneliner PowerCLI :

if (!((Get-View AlarmManager).GetAlarm((Get-Folder -NoRecursion |Get-View).MoRef)|?{(get-view $_).info.name -match "Lost connection to NFS server"})){(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "Lost connection to NFS server";Description = "Custom alarm to monitor esx.problem.vmfs.nfs.server.disconnect event";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.EventAlarmExpression -Property @{eventType = "EventEx";EventTypeId = "esx.problem.vmfs.nfs.server.disconnect";objectType = "HostSystem";status = "red"}))});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmware.local";Subject = "[vAlarm] {targetName} nfs.server.disconnect - {newStatus}";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "yellow";FinalState = "red";Repeats = $false}))})});ActionFrequency = "1800"}))}

Plutôt que de monter une usine à gaz comme notre ami William (qui ne semble pas porter windows dans son coeur – just kidding William ), nous avons fait le tour des agents capables de forwarder des fichiers log vers du syslog, gratos évidement. Le plus satisfaisant semble être Epilog for Windows qui reconnait par défaut plusieurs formats de log (IIS, Exchange, Apache, etc…) et qui dispose même de sa propre interface web (comme tous les agents snare) :

Nous avons toute fois du faire face à un petit problème concernant le patern de fichier à fournir à Epilog car “vpxd-*.log” correspond à plusieurs types de log dans le répertoire logs du vcenter (vpxd-, vpxd-alert- et vpxd-profiler-) et, contrairement à linux, il n’existe pas de fichier vpxd.log pour simplifier la chose. Heureusement, VMware semble avoir quand même prévu le coup car il est possible de changer le prefix du log en rajoutant une ligne dans le vpxd.cfg (nous avons choisi “vpxdsvc”) :

<name>vpxdsvc</name>

Il suffit ensuite de configurer le serveur de destination et de sélectionner le format syslog :

On obtient alors quelque chose de pas trop mal dans notre appliance Graylog2 (Partylog2) de test (pour celui de prod nous nous sommes inspiré de ce howto sans oublier le trick pour le “too many open files”) :

]]> http://www.hypervisor.fr/?feed=rss2&p=3997 4 http://www.hypervisor.fr/?p=3972 http://www.hypervisor.fr/?p=3972#comments Tue, 24 Jul 2012 23:39:58 +0000 NiTRo http://www.hypervisor.fr/?p=3972 Pour un projet particulier, il nous a fallu trouver une méthode industrialisable pour patcher des ESXi 4.0 U1 > U4 à chaud et sans maintenance mode. Evidemment la mise à jour nécessite un reboot pour être effective mais cela offre la possibilité (contrairement à VUM) de séparer totalement la partie patch de la partie “maintenance mode”/reboot afin de partager les taches entre 2 équipes par exemple (et accessoirement d’être plus rapide que VUM).

Nous savions que c’était techniquement envisageable compte tenu du fait qu’un patch pour ESXi se résume à la copie d’une nouvelle build dans la “bootbank” après avoir copier la build courante dans la “altbootbank“ la “bootbank” inactive. Compte tenu du fait qu’ESXi est un OS stateless, le fait d’écraser la “bootbank” et la “altbootbank” pendant le fonctionnement ne pose pas de problème. Malgré tout, il nous a fallu chercher un peu pour trouver le bon paramètre à passer à “esxupdate” pour forcer la mise à jour (qui nécessite le “maintenance mode” par défaut) avec des vm en fonctionnement.

Voici un petit oneliner qui vous permettra de reproduire cet exploit (oubliez le support vmware naturellement) :

(get-view (get-vmhost vsp41esx01*|get-view).configmanager.PatchManager).InstallHostPatchV2($null, "http://www.hypervisor.fr/img/ESXi410-201206001.zip", $null, ((new-object Vmware.Vim.HostPatchManagerPatchManagerOperationSpec -Property @{cmdOption = "--maintenancemode"})))

Comme le détail le SDK, il est possible de choisir entre 3 sources de patch : metaUrls, bundleUrls ou vibUrls, tout dépendra du format du patch. Concernant le “maintenance mode”, toute la magie réside dans le paramètre ”–maintenancemode” qui fait parti des “hidden options” d’esxupdate (malheureusement pas toutes commentées) :

–HA
–vib-view
–maintenancemode
–force
–test ‘Test update transaction only–do not change sytem.’
–all ‘Display all bulletins. Default is to display only the applicable updates.’
–long ‘Produce more detailed response in query or info output.’
–noobsoletes ‘Ignore obsoletions during update. (Enables downgrading to older bundles.)’
–reinstall ‘Re-install a bundle that is already installed.’
–nodeps
–nosigcheck
–nocache
–olderversion
–cachesize
–cleancache
–compliant

A l’opposé, il est aussi possible de désinstaller un patch (à chaud toujours), ce qui est malheureusement impossible à faire avec VUM :

(get-view (get-vmhost vsp41esx02*|get-view).configmanager.PatchManager).UninstallHostPatch("ESXi410-201101223-UG",((new-object Vmware.Vim.HostPatchManagerPatchManagerOperationSpec -Property @{cmdOption = "--maintenancemode"})))

En GUI comme en PowerCLI ce sont les mêmes paramètres à passer :

/s /v"/qn ADDLOCAL=ALL REMOVE=Audio,ThinPrint,WYSE,Hgfs REBOOT=ReallySuppress"

Get-VM VM1,VM2,VM3|Get-View|%{$_.UpgradeTools('/s /v"/qn ADDLOCAL=ALL REMOVE=Audio,ThinPrint,WYSE,Hgfs REBOOT=ReallySuppress"')}

La liste des modules est disponible dans la kb 2000399 (le REBOOT=ReallySuppress empêche la vm de rebooter après la mise à jour) et pour l’occasion nous avons créé une belle url mnémotechnique qui vous mènera directement au repository des vmtools chez VMware : vmtools.vmwa.re

MAJ 19/04/2012 : Modification du script pour afficher nom du server et le status dans l’objet du mail

Le coup du PCPU Used vs PCPU Util c’est un classique de Krishna Raj (grand maître d’esxtop) aux VMworld pendant la session “esxtop for advanced users”. Il s’agit d’une situation où la consommation cpu “théorique” (basé sur la fréquence de base du cpu) est différente de la consommation ”réelle” (basée sur la fréquence courante du cpu). Les exemples de troubleshooting des sessions de Krishna sont lié à l’Hyperthreading et aux mécanismes qui permettent aux cpu de baisser leur fréquence pour économiser de l’énergie.

En fervents adeptes d’esxtop, nous avons tout de suite remarqué l’anomalie décrite par Krishna lors d’une séance de troubleshooting :

Le problème c’est que nous n’étions pas dans esxtop pour ça et, pire, aucune alarme ne nous était parvenue. Et pour cause, c’est le compteur “usage” qui est utilisé par vCenter et non pas “coreUtilization” :

Après investigation, il s’agissait d’une mauvaise configuration ACPI/C-State dans le BIOS et comme nous ne sommes pas infaillibles, nous nous avons pondu un petit oneliner PowerCLI pour créer une alarme qui se base sur le compteur coreUtilization :

(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "Host core usage";Description = "Custom alarm to monitor core Utilization";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.MetricAlarmExpression -Property @{Metric = (New-Object VMware.Vim.PerfMetricId -Property @{CounterId = ((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "cpu"}|?{$_.nameinfo.key -match "coreUtilization"}|?{$_.RollupType -match "average"}).key;Instance = ""});Operator = "isAbove";Yellow = "7500";YellowInterval = "300";Red = "9000";RedInterval = "180";Type = "HostSystem"}))});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmware.local";Subject = "[vAlarm] {targetName} core usage is {newStatus}";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "green";FinalState = "yellow";Repeats = $false});(New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "yellow";FinalState = "red";Repeats = $true}))})});ActionFrequency = "1800"}))

Les seuils sont les mêmes que pour l’alarme “Host CPU Usage”, à savoir 75/90, mais nous avons réduit le temps pour l’alerte (red) à 3min au lieu de 5.

Malheureusement en VM c’est pas forcement la même chanson car il y a de fortes chances que vous soyez bloqué par le fait que le noeud actif du cluster utilise une addresse mac virtuelle mais que votre vswitch ne l’autorise pas, que le MTU de l’interface dédiée au heartbeat soit forcée à 2000 mais que le driver e1000 ne l’y autorise pas ou que le timeout de heartbeat de 3 sec par défaut soit un peu juste pour vos vswitch trop chargés. Heureusement la communauté d’Astaro a toujours été très active et les réponses à ces problèmes sont disponibles au détour de quelques topics (ici ou là par exemple).

Pour modifier les paramètres avancés du firewall, il faut se connecter en ssh (comme d’hab avec le compte “loginuser” puis un su pour atterrir en “root”) et taper la commande “cc” puis naviguer dans les différentes rubriques pour modifier les paramètres suivant :

cc > ha > advanced > virtual_mac$ =0

cc > ha > advanced > mtu$ =1500

cc > ha > times > dead_time =15

Il ne faudrait pas oublier de vous dire que pour les paramètres virtual_mac et mtu, il faut faire l’opération sur les 2 noeud avant de configurer le cluster (le noeud 2 n’est plus disponible après cela car il devient la copie conforme du node 1).

Sinon, on est désolé de vous annoncer qu’Astaro va bientôt changer de nom grâce à nos amis visionnaires de chez sophos (qui avait déjà saccagé le logo après le rachat), ca va s’appeler Sophos UTM (Unified Threat Management). Oui, c’est complètement pourri. Nous, on reste fan du logo de la v6 :