Fév 012016
 

Dans mon environnement, se trouvent des « vieux » ESX(i)s 4.1 qui se font régulièrement jeter par le vCenter.
Après avoir fait les vérifications de base (firewall, heartbeat,…), nous avons constaté que le problème venait de la vérification des certificats SSL.
Windows vérifie régulièrement que les certificats utilisés ne sont pas sur une liste de certificats révoqués. Pour ce faire, le PC (dans ce cas ci, le vCenter) se connecte chez Microsoft pour obtenir cette liste.
Or, nous n’avons pas autorisé cette connexion réseau, et donc, timeout, et le vcenter continue sa vie sans probleme.

MAIS, dernièrement, notre équipe réseau préférée a fait un changement dans la topologie et maintenant, les paquets ne sont plus justes droppés, mais rebondissent entre 2 routeurs jusqu’à la fin de leur TTL. Et donc, le timeout dure plus longtemps que prévu… et vCenter (et les ESX(i)s 4.1) n’aiment pas ça du tout.

Nous avons donc désactivé la Policy qui vérifie cette liste de certificats révoqués, et… plus AUCUN problème.

La Policy :
Local Computer Policy
-> Computer configuration
–> Windows Settings
—> Security Settings
—-> Public key Policies
====> Certificate Path Validation Settings
=====> Network retrieval
======> Define these Policy settings : aucune case cochée.

Bon, c’est moins sécurisé, mais… ça fonctionne.

Sep 072015
 

Bonjour,

Si, comme moi, vous ne savez pas « vraiment » sur quel switch, ni quel port se trouve connecté la vmnic de votre ESX ET que votre switch ne supporte pas CDP, mais LLDP, voici un script maison qui va vous donner l’info.

Mon script lance une capture d’une trame spécifique émise par le switch sur chaque porte afin de faire un inventaire.
L’info est sauvée dans un datastore connu de tous les ESXs (plus facile pour récupérer l’info)

Prérequis :

  • un accès ROOT sur chaque ESX
  • Une connexion via SSH possible sur la console
  • Un datastore commun à tous les ESXs

La création du tableau de correspondance ESX <> mot de passe ROOT

$ESXs =@{'ESX01' ='abc123'}
$ESXs+=@{'ESX02' ='def456'}

Le script :

get-datacenter "MON DataCenter" | get-vmhost | foreach {
$esx=$_.name
$password=$ESXs.Get_Item($_.name)
$_ | Get-VirtualSwitch | select -expandproperty nic| foreach {
$vmnic=$_

$file= »C:\temp\$esx-$vmnic.sh »
‘ps | grep « pkt » | awk  »{ print $1 } » | kill’ | out-file $file -Encoding ascii
« pktcap-uw –uplink $vmnic –ethtype 0x88cc -c 1 -o /tmp/$vmnic  » | out-file $file -append -Encoding ascii
‘FEX=`hexdump -e « 500 \ »%_p\ » \ »\\n\ » » /tmp/’+$vmnic+’ | cut -b 67-77`’ | out-file $file -append -Encoding ascii
‘echo `hostname`,’+$vmnic+’,$FEX >> /vmfs/volumes/MonDatastore/vmnicInventory.csv’ | out-file $file -append -Encoding ascii
« putty.exe $esx -l root -pw $password -m C:\temp\$esx-$vmnic.sh »
putty.exe $esx -l root -pw $password -m C:\temp\$esx-$vmnic.sh | out-null
}
}

Si tout se passe bien, vous vous retrouvez avec un super fichier texte avec toutes les infos.

NB : J’affiche dans la console la ligne de commande que j’execute, car il m’est déjà arrivé de voir « putty » planter en pleine collecte. Plutôt que de tout relancer, je ne lance que la commande qui a planté.
NB2 : Je ne lance pas toutes les collectes en même temps, car il peux arriver que 2 commandes veuillent écrire en même temps et alors, ca plante. C’est plus lent, mais plus sur.

Jan 272014
 

Cr?er le vSwitch (et conserver l’information pour y ajouter les port Group

$VirtualSwitch = New-VirtualSwitch -VMHost VESX01 -name vSwitch1 -NumPorts 256 -Nic vmnic1,vmnic4

Ou, r?cup?rer le vSwitch existant:

$VirtualSwitch=(Get-VMHostNetwork -VMHost VESX01).VirtualSwitch[1]

Cr?er les portGroup avec les vLans

New-VirtualPortGroup -Name "DMZ" -VirtualSwitch $virtualSwitch -VLanId 13
New-VirtualPortGroup -Name "FrontEnd WEB" -VirtualSwitch $virtualSwitch -VLanId 14

Et voil?…