Two vCPU NSX controller for lab environment

When installing NSX in a environment, you will at some point need to deploy NSX controllers. By default these controllers are equiped with four vCPU’s, which is fine for a production environment. But if you want to play around with NSX in a lab environment like I wanted to, then you might not have the hardware (in my case 1 CPU, 2 cores) to support those four vCPU’s. In this article I will describe how I managed to deploy a two vCPU NSX controller for lab environment.

Before we start I need to mention that this procedure isn’t supported by VMware. Do not use this in your production environment!

First time I tried to deploy the NSX controller it went well up until the controller needed to power up. It was then that I got the warning my hardware wasn’t able to start the virtual machine. Because the process is automated by the NSX manager, the NSX controller was immidiately deleted after the the warning. Leaving me with no option to adjust the vCPU.

Unlocking virtual machine reconfiguration

Searching the internet I found this article from www.virten.net which describes for a great part what I was seeing. Reconfiguring a NSX controller is only possible after you remove a record in the vCenter database. This can be done like described in the article of Virten:

1. SSH to the vCenter server
2. Enter the Shell
   1. Shell.set –enable True
   2. Shell
3. Setup the connection with the vCenter Postgres database: /opt/vmware/vpostgress/current/bin/psql -U postgress
4. Connect with the VCDB: \connect VCDB
5. Find the objects that are protected against reconfigurations: select * from VPX_DISABLED_METHODS;
6. Delete the record for the NSX controller: delete from VPX_DISABLED_METHODS where entity_mo_id_val = ‘MO_ID’ (where MO_ID is the VM ID found in step 5)

I found out that the step for restarting the vCenter Server Service, wasn’t needed for me to get it to work.

Setup virtual machine reconfigure

The big difference between the Virten article situation and mine was they could deploy the NSX controller, start it and then reconfigure it afterwards. For me to get this working I had to find a way to quickly change some configurations in a very short amount of time, before the NSX controller was deleted again. So this is what I eventually ended up with.

Each time that you deploy a virtual machine or in this case a NSX controller, the object gets a VM ID. Luckily for us this number increases by 1 each time, so we can predict the next VM ID. Knowing this I used the first 5 steps described before to find the last VM ID.

The screenshot shows VM-61 as the last ID. But since I tested several ways to get it working this won’t be the ID used later on in the article.

Deleting the record can only be done in the last few seconds of the deployment. It is only then that the record is created in the database. Knowing the next VM ID, enter the delete command with this ID. And keep executing the command nearing 100% completion of the deployement. I simply used the UP key to get the last executed command. Eventually you will see a reply that 1 record was deleted.

What remains is reconfiguring the NSX controller to use 2 vCPU’s. Since the record can only be deleted near the end of the process, I could not reconfigure the virtual machine fast enough. Thus the virtual machine was started, hardware was not compliant and the controller was removed again.

To resolve this I used PowerCLI. When you exucte a set-vm command, powershell will try to do so for some time before timing out. The command I used containes a wildcard as the last part of the NSX controller name is randomly generated.

get-vm -name nsx_con* | set-vm -NumCpu 2

Now that all the parts are ready, it’s time to execute this pitstop for the NSx controller.

The pitstop

Before you start the next attempt deploying the NSX controller, make sure you got the delete record command ready with the next VM-ID. And be sure to have your PowerCLI entered and ready to execute.

Now you start the deployement of the NSX controller. When around 50% of the deployment you execute the powershell command and confirm it. Powershell will now keep trying to reconfigure the virtual machine.

When nearing 100% completion you start spamming the delete command until you see 1 deleted record. Powershell should now be able to change the virtual machine.

The NSX controller will start without error, thus completing the pitstop ;)

Again, keep in mind that this is not supported by VMware and you should not use it in production environments.