Archive pour le Tag: ‘PowerCLI

8 articles trouvés dans cette archive
Nov/1124
Par , Dans View

Il peut arrive lors de reprovisionnement d’un Pool suite à une erreur de manipulation (suppression du Snapshot de l’image, suppression de l’image de référence…) que le Pool parte en erreur et qu’il soit impossible de le supprimer dans l’interface View Managing (il reste grisé en « Deleting »). On peut quand même supprimer les VMs mais la partie Events de View se remplit d’erreur « Provisionning error occured on Pool pool_id because of a configuration problem » toute les 30 secondes.

Pour forcer la suppression du Pool, il faut passer par le PowerCLI pour View (installé de base avec View Manager). Pour cela, lancer le PowerCLI à partir du menu Start > VMware > View PowerCLI et taper la commande suivante (Pool_Id étant l’ID du pool présent dans les messages d’erreur):

remove-pool -pool_id "Pool_Id"

Et voila le Pool est supprimé et il n’y a plus d’erreur dans les Events.

Août/1113
Par , Dans SRM

Lors de la mise en place de PRA avec VMware Site Recovery Manager, il est plus qu’utile mettre en place des routines pour vérifier que les services applicatifs contenu sont bien repartis. Pour cela le produit inclut la possibilité de lancer des scripts, cependant si les commandes des scripts sont passées à travers le réseau elles sont incompatible 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 communiquer avec le serveur SRM qui doit lancer les scripts. Il est alors impossible de vérifier le bon fonctionnement des scripts.

Il y a cependant une solution: c’est d’utiliser VIX pour demander à la couche de virtualisation de lancer un script local aux VMs. Cette fonction est disponible en PowerCLI avec le cmdlet Invoke-VMScript. Pour info, cette partie sera intégré dans la prochaine version: SRM5.

Je vais donc présenter un exemple de lancement de scripts pour réaliser cela à l’étape « Post Power-On » des VMs. Il faut faire appel à plusieurs scripts qui en appel d’autres, l’important est d’être capable de récupérer les codes retour d’erreurs entre les différents contextes pour qu’ils soient prises en compte comme résultat par SRM.

Pour commencer, voici un synopsis de la communication en différents scripts et le traitement des codes retour:

Lire la suite…

Avr/1126

Voici un petit script qui permet de récupérer dans un fichier Excel la liste des VMDK utilisés par les machines virtuelles vues d’un vCenter. C’est utilisable sans ce dernier, en saisissant à l’invite de commande le nom ou l’adresse ip d’un ESX.

Le résultat se présente sous forme d’un tableau Excel. Les machines virtuelles démarrées génèrent des remplissages de cases en VERT. Pour un inventaire complet, il faut que les VMware tools fonctionnent sur toutes les VM et que le nombre de partitions des VM soit identique au nombre de VMDK. Cela permet d’avoir une vue depuis l’intérieur de la VM la taille des partitions, le taux de remplissage et de générer les alertes rouges ou oranges suivant ce taux.

Exemple de rendu :

Lire la suite…

Fév/1122

Avec la sortie de l’Update 1 de vSphere 4.1, VMware a aussi sorti la version 4.1.1 de PowerCLI.

Et du coup, le poster pour PowerCLI a été mise à jour. On y trouve notamment une partie Quick Reference (faite par A. Renouf). Téléchargable ici: PowerCLI-4.1.1.pdf

Déc/10290

Le projet Onyx est un enregistreur de trafic SOAP depuis le vSphere Client et le converti en PowerShell. Son fonctionnement  est très similaire à l’enregistreur de macro VB sous Excel.

Onyx est sorti en version 2 depuis le 15 septembre 2010 mais il est toujours en beta. Il est disponible sur la page des VMware Labs et sur la VMware Communities.

Voici un aperçu du fonctionnement du produit: Lire la suite…

Déc/10240

Le module vEcoShell de Quest (forum ici) permet d’ajouter de fonctionnalité et de simplier la génération de code PowerShell (suivant l’incitative VESI).  Il permet également de générer des rapports et des diagrammes. On peut voir dans cet article de Virtu-Al, un exemple de ce que l’interface vEcoShell ou PowerGUI apporte à PowerCLI.

Après l’installation de vEcoShell, on peut avoir l’erreur suivante dans le liste des plugins du vSphere Client: « Could not load ‘ProductInfo, version…’ or one of its dependencies. le fichier est introuvable.  »

Cette erreur vient du fait qu’il n’arrive pas à trouver la DLL dans les Paths. Pour résoudre cela, il faut copier de ProductInfo.dll (de C:Program FilesVirtualization EcoShell ) dans le répertoire du Plugin vSphere Client (dans C:Program FilesVMwareInfrastructureVirtual Infrastructure ClientVirtualization EcoShell). Et ensuite, cliquer sur « Activé ».

Nov/10260

Lors d’une problème ou d’une maintenance planifier sur un switch fibre, il peut être judicieux de déactiver les paths. Mais quand on a beaucoup de LUNs et beaucoup d’ESXs, ca devient très long. C’est la qu’un bon script PowerCLI va permettre de tout faire.

Dans le script suivant, il faut remplacer le [esxname] par le nom de l’ESX tel qu’il est connu dans l’interface connu dans vCenter, et le paramètre [wwpn] est le WordWidePortName (commence par 21) de la carte Fibre sans les caractères « ; » , il est possible d’en mettre plusieurs en les séparant 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

Juin/10270

Le process de Resignature n’a rien de nouveau surtout en VI3, mais il demande une quantité énorme d’opération sur une grosse infra. Voici donc quelle commande pour automatiser un peu le process:

Pour faire une première fois la resignature  des LUNs sur un ESX (un rescan sur une hba est suffisant), en ligne de commande dans le Service 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 PowerShell, taper la commande suivante 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 commande 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 éventuellement, s’il faut ré-inventorier l’ensemble des VMs d’un VMFS, taper la commande suivante à partir du Service 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: