Comme j’en faisais la démonstration à un collègue la semaine dernière, en dehors des gros bundle d’update HP ou Dell, voici ce que je fais pour mettre à jour un driver réseau.

Liste des cartes :

esxcfg-nics –l

côté HBA, noter le type de driver mptspi, lpfc par exemple

esxcfg-scsidevs -a

Driver version/firmware réseau :


ethtool -i vmnic0
driver: ixgbe
version: 3.21.4iov
firmware-version: 0x800007f4, 17.0.12
bus-info: 0000:01:00.1

ou

esxcli network nic get -n vmnic0

pour les HBA :

vmkload_mod -s HBADriver | grep Version

_______________________________________

ensuite il faut déterminer le driver recommandé

vmkchdev -l | grep vmnic0
0000:01:00.0 8086:10fb 1028:1f72 vmkernel vmnic0

ici :

  • VID = 8086
  • DID = 10fb
  • SVID = 1028
  • SDID = 1f72

Il est indispensable de vérifier sur le site de VMware : VMware Compatibility Guide

 

Choisir sa version :

 

télécharger le driver :

Intégration du pilote dans VMware Update Manager :

Depuis Update Manager administration > patch Repository > Import Patches :

 

décompresser le zip précédemment télécharger, pour VUM c’est le zip offiline bundle qui nous intéresse :

 

Créer la baseline et l’attacher aux serveurs pour mise à jour

 Alors que je me faisais une joie d’avoir un client vSphere “supporté” en HTML5, quelle ne fut pas ma surprise à la connexion sur le VCSA (vCenter Server Appliance) fraîchement upgradé:

Oui, vous avez bien vu, il y a toujours 2 clients, un avec Flash et l’autre en HTML5 mais avec des fonctionnalités partielles.

Je ne m’attendais pas à ça, mais VMware a simplement pris le fling du client HTML5 et collé un tampon supporté dessus !

Pour rappel, les flings sont des outils mis à disposition en mode laboratoire expérimental, ils ne devraient pas être utilisés en production au dire même de VMware, mais c’est une source d’outils très pratiques et communément utilisés par beaucoup d’Admin. Vous pouvez explorer cette caisse à outils ici : Labs VMware Flings

Du coup, j’ai fait quelques recherches sur les différences entre les deux clients, la liste est un peu longue, elle se trouve ici : vSphere 6.5 HTML 5 functionnality support.

Des mises à jour régulières sont promises et elles seront poussées d’abord sur le fling qui lui reste bien sr non supporté…

 

A noter la convention de nommage, le “vSphere Web Client” correspond au client Flash et le “vSphere Client” le HTML5.

 

Lien vers le fling du client html5 à réserver pour vos labs : vsphere-html5-web-client.

 

Nous avions déjà un export automatique vers notre CMDB en place, mais suite à une demande de modification, je me suis dit qu’il était temps de remplacer notre bon vieux get-vm.

Je pensais arriver à un meilleur résultat, mais les requêtes pour le Datacenter et le Cluster ralentissent vraiment l’exécution, malgré ça, l’ancien script prenait 2h55, le nouveau 39min soit presque 4.5 fois plus rapide pour le même scope soit 5 vCenters et un peu plus de 2200VMs.

@"

===============================================================================
Description:   Exports VM Informations to CMDB
Usage:         Schedule task on vCenter
===============================================================================

"@
$StartMs = (Get-Date)
0..1000 | ForEach-Object {$i++}

#Standard PowerCli cmdlets
add-pssnapin VMware.VimAutomation.Core

#Renseigner votre/vos vCenter(s) separé par des virgules
Write-Host "Renseigner votre/vos vCenter(s) separé(s) par des virgules"
$vCenters= Read-Host "VCENTER_NAME"
$Path = Read-Host "Path"

#Date
$Date = Get-Date -Format yyyy-MM-dd

Write-Host "Renseigner le chemin d'export du fichier resultat ainsi que le nom du fichier"
$ExportFilePath = Read-host "$Path\$date\Export-CMDB.csv"

$listVM=@("VMName,VMHostname,Datacenter,Powerstate,OS,IPAddress,MacAddress,NetworkName,ToolsStatus,Cluster,NumCPU,MemMb,Datastore,DiskGB,DiskFree")

 Foreach ($vCenter in $vCenters) {
 Connect-VIServer $vCenter

 $VMs = Get-View -ViewType VirtualMachine
 

 
ForEach ($vm in $VMs) {
      $VMName = $vm.Name
      $VMHostname = $vm.Guest.Hostname
      $parentObj = Get-View $vm.Parent
      #while ($parentObj -isnot [VMware.Vim.Datacenter]) {$parentObj = Get-View $parentObj.Parent | select -Unique}
      while ($parentObj -isnot [VMware.Vim.Datacenter]) {$parentObj = Get-View $parentObj.Parent}
      #Boucle et remonte d'un niveau dans l'arborescence jusqu'à trouver le datacenter
      $Datacenter =   $parentObj.Name
      $Powerstate = $vm.Summary.Runtime.PowerState
      $OS = $vm.config.GuestFullName
      $IPAddress = $vm.Guest.Net.IPAddress
      $MacAddress = $vm.Guest.net.MacAddress
      $NetworkName = $vm.Guest.net.Network
      $ToolsStatus = $vm.Guest.ToolsStatus
      ## use UpdateViewData() to populate the linked view, then access said linked view
      $vm.UpdateViewData("Runtime.Host.Parent.Name")
      $Cluster = $vm.Runtime.LinkedView.Host.LinkedView.Parent.Name
      $NumCPU = $vm.Summary.Config.NumCpu
      $MemMb = $vm.Summary.Config.MemorySizeMB
      $Datastore = $vm.Summary.Config.VmPathName.Split()[0].split('[]')
      #le premier split prend la premiere expression, le deuxieme retire les crochets
      $DiskGB = [Math]::Round((($vm.Guest.Disk | Measure-Object -Property Capacity -Sum).Sum / 1GB),2)
      $DiskFree = [Math]::Round((($vm.Guest.Disk | Measure-Object -Property FreeSpace -Sum).Sum / 1GB),2)
      $listVM+=("$VMName,$VMHostname,$Datacenter,$Powerstate,$OS,$IPAddress,$MacAddress,$NetworkName,$ToolsStatus,$Cluster,$NumCPU,$MemMb,$Datastore,$DiskGB,$DiskFree")
      Write-Host "Traitement de la machine $VMName" -ForegroundColor Yellow
      }
Disconnect-VIServer $Vcenter -Force -Confirm:$false
}

$listVM > $ExportFilePath
Write-Host "Creation du Fichier résultat" -ForegroundColor Red


Write-Host "Déconnection des vCenters" -ForegroundColor Gray
#$VC = Disconnect-VIServer * -Confirm:$False

$EndMs = (Get-Date)
Write-Host "Le script s'est executé en  $($EndMs - $StartMs)"

 

Nous avions un besoin très spécifique et il nous fallait activer le fameux promiscuous mode afin de “sniffer” l’ensemble du trafic réseau sur un cluster, voici les lignes que j’ai utilisé pour nos PortGroups :

Get-Cluster "Cluster-Name" | Get-VMHost | Get-VirtualSwitch -Name "vSwitch_Name" | New-VirtualPortGroup -Name “VM_VLAN_Name” -VLanId 4095
Get-Cluster "Cluster-Name" | Get-VMHost | Get-VirtualPortGroup -name "VM_VLAN_Name" | Get-SecurityPolicy |  Set-SecurityPolicy -AllowPromiscuous $true

Concernant les VMs, elles ont deux interfaces, voici la ligne que j’ai utilisée pour configurer la deuxième sur ce même VLAN:

Get-VM "VM-name" | Get-NetworkAdapter -name "*2" | Set-NetworkAdapter -NetworkName "VM_VLAN_NAME"

Nous constations depuis quelque temps des alertes contentions CPU sur vROps que nous n’expliquions pas. J’avais fait le tour de ce que cette alerte représentait pour moi : CPU Ready – Co-Stop – I/O Wait – Swap Wait, mais rien de m’avait sauté aux yeux.

contention_cpu

La semaine dernière, je passais en revues nos configurations pour en ressortir les incohérences (ne pas avoir Enterprise Plus n’est pas une excuse pour ne pas vérifier la conformité). Plusieurs hôtes de récupération avaient été ajoutés dans différents clusters, mais leurs configurations étaient légèrement différentes des autres nœuds au niveau de la gestion d’alimentation :

power_management

Je tenais enfin mon explication, et effectivement toutes les VMs qui remontaient de la contention étaient hébergées sur des hôtes qui n’étaient pas configurés en .

Une très bonne définition donnée ici par Valentin du support VMware dans une discussion sur le forum VMware à propos du CPU Latency  :

vmwaresupport

le “Dynamic voltage frequency scaling” est clairement la cause dans mon cas.

Un autre très bon article sur le sujet : http://port5480.blogspot.fr/2015/10/cpu-contention-high-in-vrops.html