Il peut arrive lors de repro­vi­sion­ne­ment d'un Pool suite à une erreur de mani­pu­la­tion (sup­pres­sion du Snap­shot de l'image, sup­pres­sion de l'image de réfé­rence...) que le Pool parte en erreur et qu'il soit impos­sible de le sup­pri­mer dans l'interface View Mana­ging (il reste grisé en "Dele­ting"). On peut quand même sup­pri­mer les VMs mais la par­tie Events de View se rem­plit d'erreur "Pro­vi­sion­ning error occu­red on Pool pool_id because of a confi­gu­ra­tion pro­blem" toute les 30 secondes.

Pour for­cer la sup­pres­sion du Pool, il faut pas­ser par le Power­CLI pour View (ins­tallé de base avec View Mana­ger). Pour cela, lan­cer le Power­CLI à par­tir du menu Start > VMware > View Power­CLI et taper la com­mande sui­vante (Pool_Id étant l'ID du pool pré­sent dans les mes­sages d'erreur):

remove-pool -pool_id "Pool_Id"

Et voila le Pool est sup­primé et il n'y a plus d'erreur dans les Events.

Lors de la mise en place de PRA avec VMware Site Reco­very Mana­ger, il est plus qu'utile mettre en place des rou­tines pour véri­fier que les ser­vices appli­ca­tifs contenu sont bien repar­tis. Pour cela le pro­duit inclut la pos­si­bi­lité de lan­cer des scripts, cepen­dant si les com­mandes des scripts sont pas­sées à tra­vers le réseau elles sont incom­pa­tible avec le mode "Test" de SRM. En effet, lors du mode "Test", les VMs sont démarré dans un réseau isolé qui ne peut com­mu­ni­quer avec le ser­veur SRM qui doit lan­cer les scripts. Il est alors impos­sible de véri­fier le bon fonc­tion­ne­ment des scripts.

Il y a cepen­dant une solu­tion: c'est d'utiliser VIX pour deman­der à la couche de vir­tua­li­sa­tion de lan­cer un script local aux VMs. Cette fonc­tion est dis­po­nible en Power­CLI avec le cmd­let Invoke-VMScript. Pour info, cette par­tie sera inté­gré dans la pro­chaine ver­sion: SRM5.

Je vais donc pré­sen­ter un exemple de lan­ce­ment de scripts pour réa­li­ser cela à l'étape "Post Power-On" des VMs. Il faut faire appel à plu­sieurs scripts qui en appel d'autres, l'important est d'être capable de récu­pé­rer les codes retour d'erreurs entre les dif­fé­rents contextes pour qu'ils soient prises en compte comme résul­tat par SRM.

Pour com­men­cer, voici un synop­sis de la com­mu­ni­ca­tion en dif­fé­rents scripts et le trai­te­ment des codes retour:

Lire la suite...

Voici un petit script qui per­met de récu­pé­rer dans un fichier Excel la liste des VMDK uti­li­sés par les machines vir­tuelles vues d'un vCen­ter. C'est uti­li­sable sans ce der­nier, en sai­sis­sant à l'invite de com­mande le nom ou l'adresse ip d'un ESX.

Le résul­tat se pré­sente sous forme d'un tableau Excel. Les machines vir­tuelles démar­rées génèrent des rem­plis­sages de cases en VERT. Pour un inven­taire com­plet, il faut que les VMware tools fonc­tionnent sur toutes les VM et que le nombre de par­ti­tions des VM soit iden­tique au nombre de VMDK. Cela per­met d'avoir une vue depuis l'intérieur de la VM la taille des partitions, le taux de rem­plis­sage et de géné­rer les alertes rouges ou oranges sui­vant ce taux.

Exemple de rendu :

Lire la suite...

Avec la sor­tie de l'Update 1 de vSphere 4.1, VMware a aussi sorti la ver­sion 4.1.1 de PowerCLI.

Et du coup, le pos­ter pour Power­CLI a été mise à jour. On y trouve notam­ment une par­tie Quick Refe­rence (faite par A. Renouf). Télé­char­gable ici: PowerCLI-4.1.1.pdf

Le pro­jet Onyx est un enre­gis­treur de tra­fic SOAP depuis le vSphere Client et le converti en Power­Shell. Son fonc­tion­ne­ment  est très simi­laire à l'enregistreur de macro VB sous Excel.

Onyx est sorti en ver­sion 2 depuis le 15 sep­tembre 2010 mais il est tou­jours en beta. Il est dis­po­nible sur la page des VMware Labs et sur la VMware Com­mu­ni­ties.

Voici un aperçu du fonc­tion­ne­ment du pro­duit: Lire la suite...

Le module vEco­Shell de Quest (forum ici) per­met d'ajouter de fonc­tion­na­lité et de sim­plier la géné­ra­tion de code Power­Shell (sui­vant l'incitative VESI).  Il per­met égale­ment de géné­rer des rap­ports et des dia­grammes. On peut voir dans cet article de Virtu-Al, un exemple de ce que l'interface vEco­Shell ou Power­GUI apporte à PowerCLI.

Après l'installation de vEco­Shell, on peut avoir l'erreur sui­vante dans le liste des plu­gins du vSphere Client: "Could not load 'Pro­duc­tInfo, ver­sion...' or one of its depen­den­cies. le fichier est introuvable. "

Cette erreur vient du fait qu'il n'arrive pas à trou­ver la DLL dans les Paths. Pour résoudre cela, il faut copier de ProductInfo.dll (de C:\Program Files\Virtualization Eco­Shell\ ) dans le réper­toire du Plu­gin vSphere Client (dans C:\Program Files\VMware\Infrastructure\Virtual Infra­struc­ture Client\Virtualization Eco­Shell\). Et ensuite, cli­quer sur "Activé".

Lors d'une pro­blème ou d'une main­te­nance pla­ni­fier sur un switch fibre, il peut être judi­cieux de déac­ti­ver les paths. Mais quand on a beau­coup de LUNs et beau­coup d'ESXs, ca devient très long. C'est la qu'un bon script Power­CLI va per­mettre de tout faire.

Dans le script sui­vant, il faut rem­pla­cer le [esx­name] par le nom de l'ESX tel qu'il est connu dans l'interface connu dans vCen­ter, et le para­mètre [wwpn] est le Word­Wi­de­Port­Name (com­mence par 21) de la carte Fibre sans les carac­tères ";" , il est pos­sible d'en mettre plu­sieurs en les sépa­rant par une virgule.

Voici le code PowerShell:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

$esxName = "[esxname]"
$tgtPaths = @("[wwpn]")
$esx = Get-VMHost -Name $esxName | Get-View
$hstorMgmt = Get-View $esx.ConfigManager.StorageSystem
$hbaKeys = @()
# Get the key(s) of the HBA(s)
$esx.Config.StorageDevice.HostBusAdapter | where{$_.GetType().Name -eq "HostFibreChannelHba"} | %{
$WWN = "{0:x}" -f $_.PortWorldWideName
  if($tgtPaths -contains $WWN){
    $hbaKeys += $_.Key
  }
}
# Disable all paths that run through the HBA(s)
foreach($lun in $esx.Config.StorageDevice.MultipathInfo.Lun){
  foreach($path in $lun.Path){
    if($hbaKeys -contains $path.Adapter){
      $hstorMgmt.DisableMultipathPath($path.Name)
    }
  }
}

Source: LucD

Le pro­cess de Resi­gna­ture n'a rien de nou­veau sur­tout en VI3, mais il demande une quan­tité énorme d'opération sur une grosse infra. Voici donc quelle com­mande pour auto­ma­ti­ser un peu le process:

Pour faire une pre­mière fois la resi­gna­ture  des LUNs sur un ESX (un rescan sur une hba est suf­fi­sant), en ligne de com­mande dans le Ser­vice Console taper:

1
2
3
4

echo 0 > /proc/vmware/config/LVM/DisallowSnapshotLUN
echo 1 > /proc/vmware/config/LVM/EnableResignature
esxcfg-rescan vmhba1
echo 0 > /proc/vmware/config/LVM/EnableResignature

Ensuite pour faire  un rescan sur tous les ESX en Power­Shell, taper la com­mande sui­vante pour toute un cluster:

1
2
3
4
5

Connect-VIServer  -server "localhost"
get-cluster "cluster" | get-vmhost | Get-VMHostStorage -RescanAllHBA
get-cluster "cluster" | get-vmhost | Get-VMHostStorage -RescanAllHBA
get-cluster "cluster" | get-vmhost | Get-VMHostStorage -refresh
Disconnect-VIServer -Server "localhost"

Ou cette com­mande pour tout le VirtualCenter:

1
2
3
4
5

Connect-VIServer  -server "localhost"
get-vmhost | Get-VMHostStorage -RescanAllHBA
get-vmhost | Get-VMHostStorage -RescanAllHBA
get-vmhost | Get-VMHostStorage -refresh
Disconnect-VIServer -Server "localhost"

Et éven­tuel­le­ment, s'il faut ré-inventorier l'ensemble des VMs d'un VMFS, taper la com­mande sui­vante à par­tir du Ser­vice Console d'un ESX:

1
2
3
4
5
6

#!/bin/sh
for i in `find /vmfs/volumes/LUN -name *.vmx`
do
echo "registering VM: $i"
vmware-cmd -s register "$i"
done

Réfé­rence:

• L'explication des Resi­gna­ture de LUN sur Yel­low­Bricks