VMmark 3.1.1 erreur lors du lancement de notre premier “Tile”

Dernièrement nous avons testé VMmark 3.1.1 (pour rappel VMmark permet de bencher et mesurer l‘évolution des plates-formes virtuelles) afin de bencher des serveurs DELL (PowerEdge R7515). On vous passe les étapes douloureuses (nous ferons un billet sur l’installation de VMmark 3.1.1 très prochainement) de l’installation et la configuration. Une fois l’installation terminée on lance notre premier Tile et là une belle erreur (ce n’est pas comme si c’était la première en plus…) mais celle-là aurait pu être évitée (genre RTFM) : “Error : machine = client0: Invalid Trust Level (3).

Ca commence pas bien notre affaire 🙂

La seule info qui nous intéresse dans le message d’erreur est “Client0”, comme tout bon Sysadmin on fait un ping de notre fameux “Client0”, comme nous n’avons pas de retour, direction le vCenter.

Sans IP elle ne risque pas de répondre notre CLIENT0 🙂

En allant plus loin on constate que l’IP du CLIENT0 (192.168.1.2) a été attribué à la VM DeployVM0 (le conflit d’IP explique notre message d’erreur). Direction le fichier VMmark3.properties (situé dans /root/VMmark3 de la VM “PrimeClient”) afin de voir si on n’a pas un problème de configuration sur la VM “Client0” ou  DeployVM0. Après une recherche dans le fichier VMmark3.properties on comprend d’où vient le problème, le deploy/DeployVMinfo est égal à DeployVM0:192.168.2 soit l’IP de de notre VM “CLIENT0”. 

Il ne reste plus qu’à mettre la bonne IP

Quand on lit le commentaire “Specifies the name and IP address of the deployed VMs. Ex DeployVM0:192.168.1.245,DeployVM1:192.168.1.246” on se dit qu’on a raté quelques chose 🙂 .

Une fois l’IP de la VM “DeployVM0” passer sur 192.168.1.245 notre Tile est passé sans encombre

Post to Twitter

Error : A specified parameter was not correct……

Lors d’un Storage vMotion en masse nous avons rencontré sur certaines VMs l’erreur ci-dessous.

A specified parameter was not correct: ConfigSpec.files.vmPathName

En regardant de plus près même la suppression d’une des VMs en question n’était pas possible non plus (au préalable on a bien vérifié qu’on avait un backup récent 🙂 ).

Afin de pouvoir terminer notre Storage vMotion nous avons dû faire un “Remove from Inventory”sur les VMs qui posaient problème puis les inventorier dans le vCenter (6.7.0.48000)

Ci-dessous la commande pour afficher les VMs d’un vCenter avec leurs clusters, dossiers et le chemin du vmx.

Get-VM | Select Name, @{N="Cluster";E={Get-Cluster -VM $_}}, @{N="vmx Path";E={$_.ExtensionData.Config.Files.VmPathName}},@{N="VM Folder";E={$_.folder}}

Ci-dessous un exemple de commande pour inventorier une VM qui causait problème.

New-VM -VMFilePath "[datastore0] FolderVm/MyVM1.vmx" -VMHost (Get-Cluster "MyCluster" | Get-VMHost | Get-Random) -Location (Get-Folder MyFolder) -RunAsync

Comme vous savez faire vos boucles, il vous reste plus qu’à….. 😉

Post to Twitter

vCenter error : interface com.vmware.vim.binding.integrity.VcIntegrity is not visible from class loader

Sur un vCenter 6.5 Version 6.5.0.10000 Build 5973321 nous avons rencontré l’erreur ci-dessous dans l’onglet “Update manager – Attacher une ligne de base”

 

interface com.vmware.vim.binding.integrity.VcIntegrity is not visible from class loader

 

Mais comme on est pressé et que VMware fait bien les choses la KB 60640 répond pile-poil à notre problème

  • Allez en SSH sur le vCenter
  • Lancez la commande service-control –stop –all
  • Lancez la commande service-control –start –all

 

Nickel ça nous a pris 10 mn 🙂

Post to Twitter