Error “method is disabled by BKB_PLUGIN” is seen during Storage VMotion with a VM
virtual machine locking has been enabled in netvault by following procedure in the user guide at URL below page 21 section 3.4.0.
http://us-downloads.quest.com/Repository/support.quest.com/NetVault%20Backup/8.6.3/Documentation/Plugin%20for%20VMWare/Quest_NetVault_Backup_Plug-in_for_VMware_Users_Guide_English.pdf
VMware bug, see VDDK 5.0 release notes at URL below, section “To delay Storage vMotion, PrepareForAccess must run on vCenter not ESXi”
http://www.vmware.com/support/developer/vddk/VDDK-500-ReleaseNotes.html
This problem is documented in our VMware 2.1.80 release notes seen at URL below and see suggested WMware KB for releasing lock on the VM
http://us-downloads.quest.com/Repository/support.quest.com/NetVault%20Backup/8.6.3/Documentation/Plugin%20for%20VMWare/Quest_NetVault_Backup_Plug-in_for_VMware_2.1.80_ReleaseNotes_Rev1.htm
Section from release note that applies to this problem:
To prevent a virtual machine from being migrated while its disks are being accessed for a backup or restore, the plug-in uses VDDK APIs to lock and unlock a virtual machine. This functionality is disabled by default. To enable it, refer to the Quest NetVault Backup Plug-in for VMware User's Guide. Currently, the locking functionality includes the following known issues:
Locking a virtual machine may not always succeed even though API indicates success. This issue is under review with VMware. This failure can be ignored in most cases.
Unlocking is known to fail occasionally. This issue has been documented by VMware in the VDDK 5 release notes. For details, review the "EndAccess sometimes does not reenable migration after PrepareForAccess" section in the VDDK 5.0 Release Notes.
Moreover, if the plug-in exits unexpectedly after locking a virtual machine, the virtual machine may be left in a locked state so that it is disabled for migration thereafter.
For information on removing the lock and enabling migration for the virtual machine, refer to the VMware KB article
http://kb.vmware.com/kb/2008957.
Resolution from VMware KB:
VMware is aware of this issue.
Note: VMware strongly recommends you back-up your existing database before proceeding with this KB. Involve a Database Administrator if you find any difficulty in these steps.
To workaround this issue:
1.Power off the virtual machine.
2.In the vSphere Client, right-click the virtual machine and click Remove from Inventory.
3.Browse to the datastore where the virtual machine resides.
4.Right-click the .vmx file of the virtual machine and click Add to Inventory. This gives the virtual machine a new ID.
5.Power on the virtual machine and retry the Storage vMotion.
As an alternative workaround, you can manually remove the entries from the vCenter Server database:
1.Stop the vCenter Services.
2.Take a backup of the vCenter Server database.
3.Run this command against the vCenter Server database.
select * from VPX_VM WHERE FILE_NAME LIKE '%Virtual-Machine-Name%'
4.Take note of the numerical ID value returned by the above SQL stmt, as this will be required in the SQL stmt in steps 5 and 6.
5.Run this command against the vCenter Server database, to confirm the stale entry:
select * from VPX_DISABLED_METHODS WHERE ENTITY_MO_ID_VAL = 'vm-<ID from step 4>'
6.To remove the stale entry run this command against the vCenter Server database:
delete from VPX_DISABLED_METHODS WHERE ENTITY_MO_ID_VAL = 'vm-<ID from step 4>'
7.Start vCenter Server Services, then retry the Storage vMotion.
For more information, see Manually enable vSphere solutions 1021265.
Note: You may wish to disable this in netvault until VMware have resolved the problem. To do this see user guide at URL below page 21 section 3.4.0. This show the option being enabled so set the option to False to disable.
[Custom:GetMigrationLock]
Value=False
http://us-downloads.quest.com/Repository/support.quest.com/NetVault%20Backup/8.6.3/Documentation/Plugin%20for%20VMWare/Quest_NetVault_Backup_Plug-in_for_VMware_Users_Guide_English.pdf
