Archives: April 20, 2021

Change NSX-T password with API

Last night, I logged into the NSX-T manager in my lab and was greeted with the following message.

In the past, I would SSH into the edge nodes and change the password like that. But since NSX-T is suggesting to use the API, I figured I would try it. This would be a lot easier to do for the 3 users on both my edge nodes than having to type out all the commands.

Connecting to the API

Whenever I want to explore an API, I fire up Postman to see what I can learn. To connect to NSX-T, you can just enter the URL in the address bar. In this case, I’m going to explore https://s-bi-nsxmgr1/api/v1/node/users . Where s-bi-nsxmgr1 is the hostname of one of my NSX-T managers, and /api/v1/node/users is the API endpoint I’m querying.

Before we can hit the send button, we need to provide some credentials in the Authorization tab. Here in my lab, I’m just using basic auth and the admin user.

Getting the users

Once you’ve specified credentials to authorize onto NSX-T, you can hit send and get a list of all users that exist in your NSX-T environment. Here in my lab, only 5 users exist, 2 of which are not activated. This will probably be the same in many labs, I only have the root, admin, and audit user configured.

For each user, you also get some additional attributes like the last time the password was changed and the required password change frequency.

Changing the password

So let’s go ahead and change the password of the audit user. Note down the userid of the audit user from the previous API call. In my case, it’s 10002. Now that we’ve got the userid, we can verify if it’s actually the user we want. Type the userid in the URL so it looks like this; https://s-bi-nsxmgr1/api/v1/node/users/10002 and hit enter again. You’ll see all the details of the audit user.

Now to actually change the password, we need to send a body along with our API call. In the body, we need to define 2 attributes; password and old_password. Where password is the new password and old_password is, well it’s the old password of course! 🙂

In postman, go to the Body tab and make sure the radio button is set to raw and the type to JSON. Also change the call type from GET to PUT, since we’re putting a new password.

In the body you can set the following, change the values accordingly;

{
    "password": "UltraHighS3cur!ty123!",
    "old_password": "SuperSecurePassword2"
}

If all goes well you should get the following output

HTTP code 200 indicates a success and you can see the last_password_change attribute has been reset to 0, indicating it was just changed.

So you can see, changing the password via the API is not something to be scared of, in fact it’s dead simple and can save you a lot of time. Just make sure to clean up the postman tabs you used, so no-one can get to the new password.


Homelab 2021

Homelabs…It’s a topic that gets a lot of interest everywhere. We’re all geeks at heart who like to tinker with hardware and play around and break things. I haven’t had a homelab since I sold my Supermicro server back in 2016. Back then, I had access to a lab at my employer and felt that I could no longer justify the cost of running that thing in my basement. Fast forward to 2020 and I find myself really missing that lab.

Why a homelab

Earlier this year, I decided I would start to learn some more about NSX. My entire VMworld schedule was built around getting as much NSX content as I could. With the VMworld VCP Exam voucher, I tried to get my VCP-NV but ultimately failed.

I ended up scoring 275, which caused a great deal of frustration because I was so close. With the questions that I got, I did feel that it would have been a pass if I had some hands-on experience with the product. So, I decided it was time to take the plunge and invest in a new homelab.

Whenever I talk to other people, in or outside of the industry, about homelabs, the cost is always a big issue that comes up. “Why would you run something in your basement that sits there eating power”, “You’re going to spend how much on some computers?”, … These are statements we’ve all probably heard before. But you need to look at it as an investment in yourself, remember that you have to always keep learning. If you stop learning, you’ll eventually miss out on opportunities that could mean the next step in your career.

Design

Before just going out and buying random gear, I figured this exercise is no different than making a new design for a customer. Eventually, I would also like to give VCDX a shot, so I need the practice. So I decided that I would approach this like I would a normal customer interaction.

Requirements

The first step in the design process is to ask myself what the requirements were. As this is a homelab, some requirements here are not what you would see during a typical engagement. The lab will be running in my basement so noise and power consumption are things that become important. I didn’t really want jet engines running in my basement.

I also wanted something that I could expand later on when other use cases or requirements present themselves. This is the list of requirements that I came up with;

  • Support nested virtualization
  • System must be silent
  • System must be relatively low power
  • System should support 10 GbE for future-proofing
  • System should support NVMe drives
  • Solution should be expandable
  • Solution should be able to support GPUs in the future

Constraints

As with any design, there were some constraints that limited my choices;

  • Budget isn’t unlimited
  • Limited 1 GbE ports available on existing switch
  • Limited storage capacity on existing Synology
  • No 10 GbE capabilities present at the moment
  • Since this lab is being housed in my basement, WAF is definitely a thing

Assumptions

As I could verify a lot of things, I only had 1 real assumption left in my design;

  • Existing NAS capacity is sufficient for backups

This is both an assumption and a risk, the risk being that the capacity is not enough. In a normal customer engagement, I would try to mitigate this risk. But for this scenario, I’m willing to accept the risk, the mitigation here is that I need to purchase additional hardware to provide more capacity.

The design I wrote has a lot more information and decisions in there, but I’m going to keep those for some more blog posts about AMPRS 🙂

So what did I end up with?

In the end, I decided to build a 4-node all-flash vSAN cluster. Since I’m pretty familiar with Intel CPUs and power consumption was also a thing, I went with an AMD EPYC (Rome) CPU. This also helped with the future proof requirement as this platform supports PCI-e Gen 4 already.

Each host has 8 cores, 128 GB of RAM and 2 NVMe SSDs (500 GB and 2 TB). This should be plenty to test some DCV stuff and to take my first steps with NSX.

Bill of Materials

This is the part most of you have probably been waiting for, the full BoM can be found below. All prices are in euro and links point to the dutch website tweakers.net.

QuantityItemPrice / ItemTotal price
4AMD Epyc 7252 Boxed€ 375,66€ 1502,64
4Asrock Rack ROMED8-2T€ 574,45€ 2.297,80
4Fractal Design Define R5 Black€ 106€ 424
4Samsung FIT Plus 64 GB€ 16,95€ 67,80
2Netgear Prosafe XS708T€ 519€ 1.038
4Noctua NH-U9 TR4-SP3€ 67,91€ 271,64
12Noctua NF-A14 FLX 140 mm€ 20,18€ 242,16
16Micron MTA36ASF4G72PZ-3G2J3€ 188,38€ 3.014,08
4Seasonic Focus-PX750€ 161,14€ 644,56
4Gigabyte Aorus Gen 4 2 TB€ 309€ 1.236
4Samsung 980 Pro 500 GB€ 117,90€ 471,60
Total€ 11.210

I hope this blog can help you in your search for the perfect homelab for your needs. Be sure to check out William Lam’s collection of homelabs on Github for more ideas and resources.