Storage vMotion and the method is disabled by vm-XXXXXXX

I had a bit of a failure the other day that required me to perform a failover with Veeam.  The failover process itself went flawlessly, however when I attempted to go through my normal motions of performing a Storage vMotion of the replica back onto my production hosts I was met with this ‘ method is disabled by vm- ‘ error inside of both vSphere and Veeam which I’ve never encountered before…

The method was disabled by ‘vm-XXXXXXX’ – where XXXX is the moref id of a VM in question.

Now Veeam does have a way around this – instead of performing the Storage vMotion you could use its’ built-in failback mechanism or utilize it’s own ‘moving’ technology called Quick Migrate – however, I wanted to dig a bit deeper into the error a little more to see what exactly caused this and how to subsequently fix it.  This led me to KB2008957, which basically covers a few ways to resolve the issue…

The issue itself is caused by a simple database record which essentially disables vMotion on a VM during a backup job.  This will cause all calls to the vSphere API to fail, as well as disable the ability to event select the ‘Migrate’ option within vCenter.   Backup solutions which utilize the VADP APIs provided by VMware use this functionality to prevent things from moving around when they are performing certain operations – and in my case, the record was unable to be cleared as the outage occurred during one of these operations.  Basically what happens is an API is called which in turn adds a record to the VPX_DISABLED_METHODS table within the vCenter database.  The software goes and does its thing, then sends another API call to remove it.  So in essence, we should just be able to manually remove the record in order to get things working up to snuff again!

So how do we delete the problem record?

If we take our vm in question, vm-856454 and do a simple select statement on our embedded postgres database on the VCSA we can indeed see that a record exists

So to get rid of the above record we can simply run a delete statement on our postgres db as shown below…  As always it’s a good idea to either take a database backup or a full backup of your vCenter before modifying anything 🙂

After doing this you should now have the ability to migrate your VM, be Storage vMotion or just a normal vMotion.  Now there are a lot of other ways to get to this same result and the above is for certain not the easiest method.   You could simply instruct Veeam (or whatever backup solution you are using) to take another backup – at the end of that job it should send the proper instructions to clear the relocate flag – or even removing and re-adding the virtual machine from inventory will do the same thing – however the database route seems to me to be the most unobtrusive way to get the job done!  Again, I can’t stress enough the importance of backing things up and protecting yourself before you do any of the above actions!  You never know what some crazy guy on the Internet will have you doing!  Thanks for reading!