Browse Category

VMware

VMware products

Replacing the CSM Corfu certificate in NSX

In this blog we will go over replacing the Corfu certificate in NSX. In this example I will be using the UI to generate the self signed certificate and then an API call to replace the certificate.

In my case the CSM Corfu certificate has already expired

In the top menu bar I went to Generate -> Generate Self Signed Certificate

Next I had to grab the new certificate ID

The next step is to replace the old certificate with the new certificate via an API call. For this I used Postman but any other tool could potentially be used.

The URL for the post call would go against https://nsx-vip-01a.corp.local/api/v1/trust-management/certificates/cert_id?action=apply_certificate&service_type=CBM_CSM&node_id=node_id

The node ID can be found under Appliances -> View details on node, the value to the right for UUID ex

For authentication I used basic, per best practices we should be using a token.

For headers had to add Content-Type application\json ex

In the body I picket raw and added the following in

{ "cert_id": "65f3c890-485c-4c54-b80a-51cef8db7124",
"service_type": "CBM_CSM" }

The cert ID is from the certificate I generated earlier. ex

Once I clicked send I was presented back with a 200 OK

Going in the web browser I can also see that the new certificate is now used and the old one doesn’t have anything assigned to it ex

The final step I did was removing the old certificate by clicking on the 3 dots to left and picking delete from the menu

Replacing the GM Corfu certificate in NSX

In this blog we will go over replacing the Corfu certificate in NSX. In this example I will be using the UI to generate the self signed certificate and then an API call to replace the certificate.

In my case the GM Corfu certificate has already expired

In the top menu bar I went to Generate -> Generate Self Signed Certificate

Next I had to grab the new certificate ID

The next step is to replace the old certificate with the new certificate via an API call. For this I used Postman but any other tool could potentially be used.

The URL for the post call would go against https://nsx-vip-01a.corp.local/api/v1/trust-management/certificates/cert_id?action=apply_certificate&service_type=CBM_MP&node_id=node_id

The node ID can be found under Appliances -> View details on node, the value to the right for UUID ex

For authentication I used basic, per best practices we should be using a token.

For headers had to add Content-Type application\json ex

In the body I picket raw and added the following in

{ "cert_id": "570dace5-8c8a-4f0f-a08f-69dc2054285b",
"service_type": "CBM_GM" }

The cert ID is from the certificate I generated earlier. ex

Once I clicked send I was presented back with a 200 OK

Going in the web browser I can also see that the new certificate is now used and the old one doesn’t have anything assigned to it ex

The final step I did was removing the old certificate by clicking on the 3 dots to left and picking delete from the menu

Replacing the MP Corfu certificate in NSX

In this blog we will go over replacing the Corfu certificate in NSX. In this example I will be using the UI to generate the self signed certificate and then an API call to replace the certificate.

In my case the MP Corfu certificate has already expired

In the top menu bar I went to Generate -> Generate Self Signed Certificate

Next I had to grab the new certificate ID

The next step is to replace the old certificate with the new certificate via an API call. For this I used Postman but any other tool could potentially be used.

The URL for the post call would go against https://nsx-vip-01a.corp.local/api/v1/trust-management/certificates/cert_id?action=apply_certificate&service_type=CBM_MP&node_id=node_id

The node ID can be found under Appliances -> View details on node, the value to the right for UUID ex

For authentication I used basic, per best practices we should be using a token.

For headers had to add Content-Type application\json ex

In the body I picket raw and added the following in

{ "cert_id": "e060f100-5e5a-42c8-b735-0cb58f944b43",
"service_type": "CBM_MP" }

The cert ID is from the certificate I generated earlier. ex

Once I clicked send I was presented back with a 200 OK

Going in the web browser I can also see that the new certificate is now used and the old one doesn’t have anything assigned to it ex

The final step I did was removing the old certificate by clicking on the 3 dots to left and picking delete from the menu

Replacing the CCP Corfu certificate in NSX

In this blog we will go over replacing the Corfu certificate in NSX. In this example I will be using the UI to generate the self signed certificate and then an API call to replace the certificate.

In my case the CCP Corfu certificate has already expired

In the top menu bar I went to Generate -> Generate Self Signed Certificate

Next I had to grab the new certificate ID

The next step is to replace the old certificate with the new certificate via an API call. For this I used Postman but any other tool could potentially be used.

The URL for the post call would go against https://nsx-vip-01a.corp.local/api/v1/trust-management/certificates/cert_id?action=apply_certificate&service_type=CBM_CCP&node_id=node_id

The node ID can be found under Appliances -> View details on node, the value to the right for UUID ex

For authentication I used basic, per best practices we should be using a token.

For headers had to add Content-Type application\json ex

In the body I picket raw and added the following in

{ "cert_id": "5a6f1a51-95ec-45f3-8b7a-92ac2abd75cb",

"service_type": "CBM_CCP" }

The cert ID is from the certificate I generated earlier. ex

Once I clicked send I was presented back with a 200 OK

Going in the web browser I can also see that the new certificate is now used and the old one doesn’t have anything assigned to it ex

The final step I did was removing the old certificate by clicking on the 3 dots to left and picking delete from the menu

Replacing the AR Corfu certificate in NSX

In this blog we will go over replacing the Corfu certificate in NSX. In this example I will be using the UI to generate the self signed certificate and then an API call to replace the certificate.

In my case the AR Corfu certificate has already expired

In the top menu bar I went to Generate -> Generate Self Signed Certificate

Next I had to grab the new certificate ID

The next step is to replace the old certificate with the new certificate via an API call. For this I used Postman but any other tool could potentially be used.

The URL for the post call would go against https://nsx-vip-01a.corp.local/api/v1/trust-management/certificates/cert_id?action=apply_certificate&service_type=CBM_AR&node_id=node_id

The node ID can be found under Appliances -> View details on node, the value to the right for UUID ex

For authentication I used basic, per best practices we should be using a token.

For headers had to add Content-Type application\json ex

In the body I picket raw and added the following in

{ "cert_id": "625fb6e6-00ff-4c59-9275-0e7583bcb0c7",

"service_type": "CBM_AR" }

The cert ID is from the certificate I generated earlier. ex

Once I clicked send I was presented back with a 200 OK

Going in the web browser I can also see that the new certificate is now used and the old one doesn’t have anything assigned to it ex

The final step I did was removing the old certificate by clicking on the 3 dots to left and picking delete from the menu

Certificate delete failed: Certificate cannot be deleted because it is used by 1 MP node

I was recently trying to replace some service certificates and I accidentally associated the certificate with the wrong service. When trying to delete the certificate I was presented with an error “Certificate delete failed: Certificate cannot be deleted because it is used by 1 MP node”

The first step I did was try to figure out what service is associated with the certificate. For that I leveraged the instructions in KB 75277. Performing a GET /api/v1/trust-management/certificates/{cert-id} I was able to identify that CBM_API service was using the certificate.

To remove it I had to run curl -k -X POST -H "Content-Type: application/json" -H 'X-NSX-Username:admin' -H 'X-NSX-Groups:superuser' -d '{"service_type":"CBM_API","node_id":"{node_id}"}' "http://localhost:7440/nsxapi/api/v1/trust-management/certificates/{certificate_id}?action=release"

The command allowed me to unregister the component and allowed me to delete the old certificate.

Replacing the Corfu API certificate in NSX

In this blog we will go over replacing the Corfu API certificate in NSX. In this example I will be using the UI to generate the self signed certificate and then an API call to replace the certificate.

In my case the Corfu API certificate has already expired

In the top menu bar I went to Generate -> Generate Self Signed Certificate

Next I had to grab the new certificate ID

The next step is to replace the old certificate with the new certificate via an API call. For this I used Postman but any other tool could potentially be used.

The URL for the post call would go against https://nsx-vip-01a.corp.local/api/v1/trust-management/certificates/cert_id?action=apply_certificate&service_type=API&node_id=node_id

The node ID can be found under Appliances -> View details on node, the value to the right for UUID ex

For authentication I used basic, per best practices we should be using a token.

For headers had to add Content-Type application\json ex

In the body I picket raw and added the following in

{ "cert_id": "79a25913-643a-4aa0-9d1b-0262e2a706b0",

"service_type": "API" }

The cert ID is from the certificate I generated earlier. ex

Once I clicked send I was presented back with a 200 OK

Going in the web browser I can also see that the new certificate is now used and the old one doesn’t have anything assigned to it ex

The final step I did was removing the old certificate by clicking on the 3 dots to left and picking delete from the menu

Replacing the LocalManager certificate in NSX

In this blog we will go over replacing the LocalManager certificate in NSX. In this example I will be using the UI to generate the self signed certificate and then an API call to replace the certificate.

In my case the LocalManager certificate has already expired

In the top menu bar I went to Generate -> Generate Self Signed Certificate

Next I had to grab the new certificate ID

The next step is to replace the old certificate with the new certificate via an API call. For this I used Postman but any other tool could potentially be used.

The URL for the post call would go against https://nsx_fqdn/api/v1/trust-management/certificates?action=set_pi_certificate_for_federation

For authentication I used basic, per best practices we should be using a token.

For headers had to add Content-Type application\json ex

In the body I picket raw and added the following in

{ "cert_id": "8d56e224-52a0-462a-a971-9f2c19c1d33a",

"service_type": "LOCAL_MANAGER" }

The cert ID is from the certificate I generated earlier. ex

Once I clicked send I was presented back with a 200 OK

Going in the web browser I can also see that the new certificate is now used and the old one doesn’t have anything assigned to it ex

The final step I did was removing the old certificate by clicking on the 3 dots to left and picking delete from the menu

Simplifying NSX Edge Removal in VMware Cloud Foundation (VCF) Environment

VMware Cloud Foundation (VCF) has revolutionized data center virtualization by seamlessly integrating compute, storage, and networking components. In a VCF environment, the NSX platform provides crucial software-defined networking capabilities. At times, removing NSX edges becomes necessary due to infrastructure changes, optimization efforts, or other reasons. To simplify this process, VMware has introduced the NSX Edge Removal Tool. In this blog post, we will explore how this tool can streamline the removal of NSX edges in a VCF environment while preserving dependencies.

Understanding the NSX Edge Removal Tool

The NSX Edge Removal Tool is a powerful utility developed by VMware to assist with removing NSX edges in a VCF environment. It simplifies the edge removal process and ensures the preservation of critical dependencies. Let’s delve into the steps involved in using this tool effectively.

Step 1: Preparing for NSX Edge Removal

Before utilizing the NSX Edge Removal Tool, it is crucial to thoroughly understand your VCF environment and identify all dependencies associated with the NSX edges you plan to remove. Review your network configuration, firewall rules, security policies, and any applications or services relying on the edges. This assessment will help you plan and execute the edge removal process more efficiently.

Step 2: Installing and Configuring the NSX Edge Removal Tool

To begin, download the NSX Edge Removal Tool from the VMware website. As of the writing of this blog the latest download can be found here. Follow the installation and configuration instructions provided by VMware to integrate the tool into your VCF environment seamlessly. Ensure that you have the necessary credentials and permissions to access and modify the NSX edges. In my case I downloaded edge_cluster_cleaner_0.27.tar.gz and transferred it to the server.

Step 3: Running the NSX Edge Removal Tool

Once the tool is installed and configured, it’s time to execute the removal process. Launch the NSX Edge Removal Tool and provide the required information, such as the NSX Manager IP address, credentials, and the specific edges you wish to remove. The tool will validate the environment and dependencies, ensuring a safe removal process. ex ./remove_edge_cluster.sh --cluster WLD1-edge-cluster --workload SDDC-MGT --user [email protected]

Step 4: Verifying and Analyzing the Dependency Report

After executing the removal process, the NSX Edge Removal Tool generates a dependency report. This report provides crucial insights into the dependencies associated with the removed NSX edges. Review the report thoroughly to understand any potential impacts on your network infrastructure and applications.

Step 5: Addressing Dependencies and Network Adjustments

Based on the generated dependency report, it’s essential to address the identified dependencies and make necessary adjustments to your network configuration. Collaborate with network administrators, application owners, and other stakeholders to migrate the dependencies to alternative network resources. Update firewall rules, adjust routing configurations, and ensure seamless connectivity for critical services.

Step 6: Post-Removal Validation and Testing

After addressing the dependencies and making the required adjustments, perform comprehensive validation and testing to ensure that the network connectivity and critical services are functioning optimally. Monitor the network closely for any abnormalities or performance issues, and address them promptly.

Conclusion

The NSX Edge Removal Tool provides a streamlined approach to removing NSX edges in a VMware Cloud Foundation (VCF) environment while preserving critical dependencies. By following the steps outlined in this blog post and utilizing the tool effectively, you can simplify the edge removal process and ensure the smooth operation of your VCF environment. Embrace this tool to optimize your network infrastructure and enhance the agility of your virtualized data center.

Downloading specific VCF bundles via CLI

I wanted to reuse my VCF downloaded bundles on another SDDC Manager system so that i wont have to download it from internet again. I found an easy guide here in the VMware documentation. My goal was to download the specific bundle once and upload it on other SDDC Managers.

The first command from SDDC manager was to list the bundles. The lcm bundle transfer utility can be found in /opt/vmware/vcf/lcm/lcm-tools/bin

./lcm-bundle-transfer-util -du ${depotUser} -l -p ${product_version}

I replaced the ${depotUser} with my vmware email address and ${product_version} with the version of the VCF product i wanted to install in my case 5.0.0.0. I was greeted with a list of bundle IDs and the specific component that it was for:

Enter Myvmware user password:
Validating the depot user credentials...

Bundle         Product  Bundle Size  Components
               Version  (in MB)
bundle-80035   5.0.0.0  599.5 MB     ESX_HOST-8.0.1-21813344
bundle-80031   5.0.0.0  10089.9 MB   NSX_T_MANAGER-4.1.0.2.0-21761691
bundle-80029   5.0.0.0  2044.7 MB    SDDC_MANAGER_VCF-5.0.0.0-21822418
bundle-80030   5.0.0.0  251.3 MB     SDDC_MANAGER_VCF-5.0.0.0-21822418
bundle-80033   5.0.0.0  9867.6 MB    VCENTER-8.0.1.00100-21815093

In my case i need the installer. To download a specific bundle we run

./lcm-bundle-transfer-util --download --outputDirectory ${absolute-path-output-dir} --depotUser ${depotUser} -b ${bundle_name}

in my case it was:

./lcm-bundle-transfer-util --download --outputDirectory /some/temporary/location --depotUser [email protected] -b bundle-80029

This allowed me to grab the download from /some/temporary/path and save it/upload it on my other SDDC Managers that were missing it.

Finally before the patch can be used in SDDC Manager we need to upload it to the repo. Please note that once we issue the upload command the download gets deleted, so make sure you save the download ahead of time

./lcm-bundle-transfer-util --upload --bundleDirectory /some/temporary/path -b bundle-80029

Once the upload was complete i was able to see it in SDDC Manager as an package that i can apply.