Il y a quelques jours un de mes collègues est venu me voir car sur une VM la consolidations des disques n’était plus possible.
Les symptômes sur la Vm était multiple :
- La suppression des Snapshots s’exécutait bien dans le « Snapshot Manager », mais pas la suppression de ses vmdk associés.
- La consolidation des disques était impossible
- L’option migration de la vm était grisé
Mon premier réflexe fut de chercher ce qui pouvait locker les fichiers de la VM… et j’ai donc ressortie un KB que j’avais lu quelques mois auparavant le 2107795
Après avoir constaté qu’aucune machine n’avait posé de locks sur les fichiers de notre VM, nous avons effectué un Arrêt/Redémarrage de la vm, cela a résolu partiellement nos soucis, nous pouvions consolider les disques mais la migration de la vm était toujours impossible ….
Après quelques recherche sur le net j’ai trouvé que notre souci venait d’une entrée dans la table de « VPX_DISABLED_METHODS ».
Quand les outils de Backup lance une opération de sauvegarde sur une VM, ils placent une entrée dans la table « VPX_DISABLED_METHODS » avec l’identifiant de la vm à fin de bloquer son vMotions.
Une sauvegarde de test en cours sur cette machine avait été stoppé et l’entrée dans la table « VPX_DISABLED_METHODS » etait toujours présent…
Pour vérifier notre souci, nous avons tout d’abord récupéré en Powershell l’identifiant de notre VM
|
1 2 3 4 5 6 7 8 9 |
. D:\> Get-VM -name maVmDeTest | ft -Property Name,ID Name Id ---- -- maVmDeTest VirtualMachine-vm-584 . |
Ensuite, nous nous sommes connectés à l’appliance pour lire les entrées de la table « VPX_DISABLED_METHODS »
Lors de la connexion à l’appliance du vCenter, il faut activer le shell
|
1 2 3 |
. Command> shell Shell access is granted to root |
Connectez-vous à l’instance Postgres
|
1 2 3 4 |
. root@monvcenter[ ~ ]# /opt/vmware/vpostgres/current/bin/psql -U postgres psql.bin (9.6.6 (VMware Postgres 9.6.6.0-7698979 release)) Type "help" for help. |
Connectez-vous à la base de données VCDB
|
1 2 3 4 5 6 7 |
. postgres=# \connect VCDB You are now connected to database "VCDB" as user "postgres" . |
Lire les entrées de la table « VPX_DISABLED_METHODS »
|
1 2 3 4 5 6 |
. VCDB=# VCDB=# select * from VPX_DISABLED_METHODS; entity_mo_id_val | method_name | source_id_val | reason_id_val -----------------------+-------------------------------------+------------------------------------------------+------------------------------- vm-584 | vim.VirtualMachine.relocate | NetBackup Lock by JobId 2416619 | Prevent vMotion during backup (1 row) |
Correction de l’Anomalie
Pour corriger cette anomalie, plusieurs solution s’offre à nous, nous allons ci-dessous détailler 2.
Solution 1 : Supprimer l’entrée dans la base de données de votre vCenter
Avant de mettre en place cette solution de résolution, sauvegarder la base de données de votre vCenter, ou vérifier que votre dernier Backup s’est bien déroulé.
Pour supprimer l’entrée invalide , exécuter la commande suivante :
|
1 2 |
. delete from VPX_DISABLED_METHODS where entity_mo_id_val = 'MO_ID'; |
Puis relancer les service du vCenter server
|
1 2 3 4 |
. service-control --stop vmware-vpxd service-control --start vmware-vpxd |
Solution 2 :
la 2nd solution est pour moi un contournement, elle consiste à sortir de l’inventaire la Vm puis de la réintégrer à l’inventaire du vCenter. Votre vm obtiendra un nouvel identifiant VMware et vous pourrez alors de nouveau effectuer des vmotions … Par contre, l’entrée polluera toujours votre table VPX_DISABLED_METHODS.
Le KB 2044369 Détaille parfaitement ces cas de figures, ainsi qu’une troisième solution à n’utilisez que si les deux premières solution échouent..
Les articles ci-dessous explique aussi fort bien comment résoudre cette anomalie.