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 [email protected] [ ~ ]# /opt/vmware/vpostgres/current/bin/psql -U postgres psql.bin (9.4.9 (VMware Postgres 18.104.22.168-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;
After making this change in the database, the vCenter service needs to be restarted before it actually takes effect.
postgres-# \q [email protected] [ ~ ]# /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.
November 5, 2019 at 13:02
Martijn, nice article but the 2 last commands are the same and I’m looking for the command to remove all entries from the table:
VCDB=# DELETE FROM VPX_DISABLED_METHODS WHERE entity_mo_id_val = ‘vm-1945’;