Certain service appliances cannot be edited manually inside vCenter. For instance, VMware NSX Edge appliances are an example of such service appliances. These VMs are managed by the NSX Manager and you shouldn’t change their configuration manually. Normally. 😉

But sometimes you need to edit those VMs. There are not many reasons why you would want to do this (as it’s heavily unsupported), but one reason might be to free up resources in your home lab (which is exactly why I wanted to do this). For instance, NSX Edge appliances come with a CPU & memory reservation placed on their VMs. Unfortunately you can’t change this in NSX, but you can change it after the fact.

Again, I must repeat that this procedure is not supported and you should not do this in production (unless directed to by VMware GSS).

Removing the Lock

To remove the lock, you have to go into the database of vCenter and remove some records. There is a table called VPX_DISABLED_METHODS and it contains the lock for each VM. This means you can remove the lock on a per VM basis.

We’re going to be messing inside the Postgres database of vCenter, so first thing you need to do is SSH into it. When you’re in the VCSA, execute the following commands to get a list of all VMs that have been locked from editing:

Command> shell
Shell access is granted to root
root@vcenter [ ~ ]# /opt/vmware/vpostgres/current/bin/psql -U postgres
psql.bin (9.4.9 (VMware Postgres 9.4.9.1-4536683 release))
Type "help" for help.

postgres=# \connect VCDB
You are now connected to database "VCDB" as user "postgres".
VCDB=# SELECT * FROM VPX_DISABLED_METHODS;
 entity_mo_id_val |          method_name           | source_id_val | reason_id_val 
------------------+--------------------------------+---------------+---------------
 vm-1945          | vim.VirtualMachine.reconfigure | vShield_SVM   | vShield_SVM
 vm-3177          | vim.VirtualMachine.reconfigure | vShield_SVM   | vShield_SVM
 vm-3204          | vim.VirtualMachine.reconfigure | vShield_SVM   | vShield_SVM
(3 rows)

You’ll notice that there are no VM names here. The entity_mo_id_val is the underlying ID of the VM. You can look up the names via PowerCLI (I was too lazy to look where it is in the database schema) as follows:

PS /> Get-VM LD-HOME-VPN-0 | Select Name, Id

Name                                                Id                    
----                                                --                    
LD-HOME-VPN-0                                       VirtualMachine-vm-1945

Notice that the Id matches the mo_id of the first line. I wanted to make this VM editable, so I removed the record with ‘vm-1945’ like so:

VCDB=# DELETE FROM VPX_DISABLED_METHODS WHERE entity_mo_id_val = 'vm-1945';

You can also remove the lock from every VM by leaving out the id like so:

VCDB=# DELETE FROM VPX_DISABLED_METHODS;

Restart vCenter

After making this change in the database, the vCenter service needs to be restarted before it actually takes effect.

postgres-# \q
root@vcenter [ ~ ]# /etc/init.d/vmware-vpxd restart

That’s it! You can now edit the VM via the vSphere Web Client, which you could not edit before doing this.

Share the wealth!