We will explain how to log in with a local account to your NSX-T which integrated with VIDM.
We integrated our NSX-T into the VIDM. We had an issue in the VIDM and no one could log in to the NSX.
We had to use the below URL and log in with the admin account.
https://<NSX-T_FQDN/IP>/login.jsp?local=true
once you can reach your ESXi host on it management IP address. you will be able to use the below playbook to configure everything automatically with Ansible
Note: you will need to update the VLANs in this playbook
If you don't have NSX-T in your environment, you will ned to remove the tasks which create the vDS to the NSX.
Hereunder is a playbook to backup all your NSX-T components through simple API calls and then it will make another GET API call ?filter=Type- to backup everything in the NSX-T.
The Ansible playbook will save the output to a remote SFTP server
What you will need to update in the below playbook?
1. The SFTP server.
2. The components paths.
Herebelow you will find an ansible playbook to backup all your NSX-T components. You can add more tasks for your different NSX-Ts. In my playbook I use 2 tasks for my DEV NSX-T. but I have another URL variable and I can use it in another 2 tasks.
The first task will get the output of the listed items (Segmets, Groups, FW Policies,...etc). and the second task will get everything. but it will not be easy to work on teh second task during crisies. because it contains a lot of data and you will get lost 😂.
Note: you can use the second task response to restore your NSX-T environment.Ansible Playbook to backup NSX-T Segments
I thought a lot before I write this blog here. but as it is about the NSX , I will put it here.
I will not go into how to setup Ansible Tower. I assume that you have Ansible Tower and Versioning Control System in your environment.
Hereunder is the playbook that you can use. but I need to show you how you can encrypt your password.
Hereunder I delete several LSWs in one playbook
Hereunder I delete the LSW, SG and a Firewall policy with Ansible Playbook.
Note: the LSW is a member in the SG , and the SG is a member in the FWP , so it has to be done in this order: delete the FW policy then the SG then the LSW
The best way to migrate from a traditional VMware env. "doesn't contain NSX" to a new modern env. "contains NSX-T" id to change the IPs of the VMs and attache them to VxLAN LSWs . but in some situations, we will need to migrate the VMs with their current IPs. so we will need to do one of the following:
1. Bridge the VxLAN to VLAN.
2. Use VLAN LSW and rely on the physical network, but you will be still able to create FW, LB,...etc
In the below example we will use the VRO WF to do for us the second question:
By default there are some limitations on how many API requests you can do per second on the NSX. and when you exceed this number, you will start to get this error message Client 'admin' exceeded request rate of 100 per second
Now we will increase these numbers
We are going to migrate one of our classical environments which doesn't have NSX to a new env. which has NSX.
To start doing some analysis, we will need to collect these data :
We will get the refresh and access tokens for VRA , I am following the below page but with a small adjustment
https://vdc-download.vmware.com/vmwb-repository/dcr-public/97d1d46c-8846-4c12-85a8-5655d1189825/3873335e-1ec6-4bac-a9c2-2f62636ce19f/GUID-AC1E4407-6139-412A-B4AA-1F102942EA94.html
Step number zero :-) . you will need to have a linux VM that can reach to VRA on port 443
1. Define your variables
identity_service_url='https://<vRA-HOSTNAME>' username='<your_username>' password='<your_password>'
2. Execute the below commandapi_token=`curl -k -X POST \
"$identity_service_url/csp/gateway/am/api/login?access_token" \
-H 'Content-Type: application/json' \
-d '{
"username": "'"$username"'",
"password": "'"$password"'"
}' | jq -r .refresh_token`3. Get the refresh tokenecho $api_token
to get the access token:
identity_service_url='https://<vRA-HOSTNAME>' username='<your_username>' password='<your_password>'2. Execute the below commandaccess_token=`curl -k -X POST \ "$identity_service_url/iaas/api/login" \ -H 'Content-Type: application/json' \ -s \ -d '{ "refreshToken": "'"$api_token"'" }' | jq -r .token`3. Get the access tokenecho $access_token
How can you deploy bulk of VRA deployments with the minimum effort , the answer will be Terraform
We will make execute an ansible playbook to get all the NSX-T segments for us
I faced a small issue today. I am creating all the NSX-T segments by Terraform and one of my customers asked me to enable DHCP relay on his segment, and he told me that we will need to do that in the future for other NSX-T segments.
As I am lazy, I started to think how can I automate this kind of requests. and I found 2 possibilities:
1. Providing him a way to edit in his Terraform config. file , and by this way he will have a high priv. on the NSX-T which is not a good idea at all.
2. Create for him a VRO workflow to write in it the segment name and the workflow will add the DHCP relay configuration to his segment.
I decided to proceed with the second option. and I found 2 issues:
1. I have to add a life cycle in the NSX-T segment resource in the Terraform. to avoid rolling back during the next apply :-)
2. I have to get the LSW by its name via API , to be able to edit in it and make post API with the DHCP relay config.
The second point was really tough point. because the segments have been created via terraform and they have random ID in their API path. so I have to find a way to get the segment with its name not with its API path
making GET API call to the below URL after editing it with your data, will get for you the segment
https://YOUR_NSX_T_FQDN/policy/api/v1/search/query?query=display_name:YOUR_SEGMENT_NAME
We are going today to do a backup for the vDS of the vCenter and backup the DRS rules and groups
1. The first step is to encrypt your administrator@vsphere.local password, you will find the script on the Github How to encrypt the password
2. The second step is to use your encrypted password in this script How to backup vDS and DRS rules
3. Schedule this script in the task scheduler of your jump box.
Note: I highly recommend to use a service account to execute the backup scripts.
We will explain here how you can reapply the vSphere Tags after you migrate a VM from one vCenter to another or even when you use VEEAM or any other replication tool to replicate a VM from one vCenter to another vCenter
Before executing this script you will need to create 2 folders in the 2 vCenters with the same name. and put the machines under these folders. because the main Idea of the script is getting the VMs under a certain folder and collect their TAGs , and then login to the other vCenter and search for the collected VMs and start to apply the TAGs on them. you also will need to make sure that the TAGs exist on the destination VC (The script will not create the TAGs , it will apply them only)
Import-Module VMware.VimAutomation.Core
$vCenterIP = "First vCenter"
$FOLDERNAME = 'XXXX' ##Change XXXX with folder Namer###
Connect-VIServer $vCenterIP
$tagsall = @()
foreach($machine in $machines = Get-Folder -Name $FOLDERNAME | Get-VM){
$tagsall+=@(Get-TagAssignment -Entity $machine.name)
}
$tagsall
sleep 10
Disconnect-VIServer $vCenterIP -confirm:$false
1. Don't close your Powershell window.
2. Start to do the cross vCenter vmotion.
3. After you finish from all the VMs.
4. Execute the below script.
$vCenterIP = "Second vCenter"
Connect-VIServer $vCenterIP -User $vCenterUser -Password $vCenterPass
$tagsallnew = $tagsall | select Tag,Entity
for($i = 0; $i -lt $tagsallnew.length; $i++){
$tag = Get-Tag -name $tagsallnew[$i].tag.name -Category $tagsallnew[$i].tag.Category.name -Server "Second vCenter"
$vm = get-vm -name $tagsallnew[$i].Entity.Name -Server "Second vCenter"
New-TagAssignment -Tag $tag -Entity $vm -Server "Second vCenter"
}
We will explain how you can put your Terraform variable in your windows environment variables.
Note: you can for example put your VMC Token in your windows variables. This will avoid you from 2 things:
1. Put the token in the code itself, which is not recommended at all for security reasons.
2. Write the token every time when you plan or apply the code.
Note: The below variable is changeable based on the variable name in your code.
Set-Item -Path env:TF_VAR_token -Value “token_value“
To set the backend access key and secret key:
Set-Item -Path env:AWS_ACCESS_KEY_ID -Value "xyxyxyxyxyx12345"
Set-Item -Path env:AWS_SECRET_ACCESS_KEY -Value "abcabcabcabcabcabcabc12345"
Source: https://www.terraform.io/language/settings/backends/s3
We will create some NSX components on VMC via Terraform
1.1. Segments
You have to use this resource nsxt_policy_fixed_segment , if you try to use the normal resource of the on premises NSX-T , that will not work and you will get an error.
# you can replace the variables with names or numbers as you like
resource "nsxt_policy_fixed_segment" "projectLSW" {
display_name = "LSW-VMC-${var.lswNumber}-01"
connectivity_path = var.connectivity_path
subnet {
cidr = var.subnet
}
tag {
scope = "LSW"
tag = "LSW-VMC-${var.lswNumber}-01"
}
advanced_config {
connectivity = "ON"
}
}
Whenever you create a group in VMC, you have to specify the domain of this group. The domain will be either cgw or mgw
cgw: used for compute groups that will be used in the compute FW rules
mgw: used for the management groups that will be used in the management FW rules
# the below SEC Group will have the LSW as a member {it will match the TAG which we are applying on the Segment}
resource "nsxt_policy_group" "projectSG" {
display_name = "SG-VMC-VPC-${var.lswNumber}"
domain = "cgw"
criteria {
condition {
key = "Tag"
member_type = "Segment"
operator = "EQUALS"
value = "LSW-VMC-${var.lswNumber}-01"
}
}
}
# NSX-T is unlike NSX-V , you have to create SEC group and put your subnet as a member in this SEC group, because there is no option to create IPSET directly
resource "nsxt_policy_group" "SG-IPSET-5_5_5_5_32-To-VPC-7e" {
display_name = "SG-IPSET-5_5_5_5_32-To-VPC-7e"
domain = "cgw"
criteria {
ipaddress_expression {
ip_addresses = ["5.5.5.5"]
}
}
}
resource "nsxt_policy_service" "SRV-TCP-P-4444" {
display_name = "SRV-TCP-P-4444"
l4_port_set_entry {
display_name = "SRV-TCP-P-4444"
protocol = "TCP"
destination_ports = ["4444"]
}
}
# I am using here a dummy VM to apply all the NSX-T Tags on it , because if the TAG is not applied on any resource, the NSX will delete it automatically
resource "nsxt_policy_vm_tags" "projectTAGs" {
instance_id = var.vmBIOS tag {
scope = "FWP"
tag = "FWP-${var.lswNumber}-Dummy"
}
}
Whenever you create a FW policy, you have to specify the domain of the policy. The domain will be either cgw or mgw
resource "nsxt_policy_security_policy" "projectFWP" {
display_name = "FWP-VPC-${var.lswNumber}"
category = "Application"
scope = [nsxt_policy_group.projectSG.path]
domain = "cgw"
locked = false
stateful = true
tcp_strict = false
It will be a small series to show you how you can use Terraform on your VMware cloud env. on AWS.
Create your first resource on VMC via Terraform
terraform {
required_providers {
nsxt = {
source = "vmware/nsxt"
version = "3.2.5"
}
}
}
# The below Token and NSX host are just for explanation :-) , they are not real data
provider "nsxt" {
host = "https://nsx-1-38-60-79.rp.vmwarevmc.com/vmc/reverse-proxy/api/orgs/53045f5a-59f7-4921-8bcb-0b09e8c3ac16/sddcs/24163dc6-2b22-475b-b197-167932ef5124/sks-nsxt-manager"
vmc_token = "12345IZf8Elb9VFTorfvnoyk6CsDXi15678utfdsFHfdsdafsadfasfIUTdghuy7815"
allow_unverified_ssl = true
enforcement_point = "vmc-enforcementpoint"
}
resource "nsxt_policy_fixed_segment" "Terraform-segment1" {
display_name = "Terraform-segment1"
description = "Terraform provisioned Segment"
connectivity_path = "/infra/tier-1s/cgw"
subnet {
cidr = "12.12.2.1/24"
dhcp_ranges = ["12.12.2.100-12.12.2.160"]
dhcp_v4_config {
server_address = "12.12.2.2/24"
lease_time = 36000
}
}
}
How can you generate access token for your account on VMC?
How to use Terraform on NSX-T on VMC/AWS ?
The first step is to collect the needed information like your NSX-T host on your VMC environment.
The second step is to create access token for your account to be able to connect to the NSX-T.
1. How to get your NSX-T host on your VMC env.:
it should be something like that
https://nsx-1-38-60-79.rp.vmwarevmc.com/vmc/reverse-proxy/api/orgs/53045f5a-59f7-4921-8bcb-0b09e8c3ac16/sddcs/24163dc6-2b22-475b-b197-167932ef5124
How to create NSX-T TAG and Security Group match on this TAG with Terraform?
resource "nsxt_policy_vm_tags" "VM123TAG" {
instance_id = var.vmBIOS
# you can get the vmBIOS from the NSX-T GUI , go to inventory and then Virtual machines
tag {
scope = "FWP"
tag = "FWP-VPC-1000e-on-P15172"
}
}
resource "nsxt_policy_group" "SG-FWP-VPC-1000e-on-P15172"{
display_name = "SG-FWP-VPC-1000e-on-P15172"
criteria {
condition {
key = "Tag"
member_type = "VirtualMachine"
operator = "EQUALS"
value = "FWP|FWP-VPC-1000e-on-P15172"
}
}
}
How to create NSX-T Service with Terraform?
resource "nsxt_policy_service" "SRV-TCP-P-22-SSH" {
display_name = "SRV-TCP-P-22-SSH"
How to create Service Group on NSX-T with Terraform?
resource "nsxt_policy_service" "SRV-GRP-TCP-P-1024-To-1064-443-22" {
display_name = "SRV-GRP-TCP-P-1024-To-1064-443-22"
l4_port_set_entry {
display_name = "SRV-TCP-P-1024-To-1064"
protocol = "TCP"
destination_ports = ["1024-1064"]
}
l4_port_set_entry {
display_name = "SRV-TCP-P-443"
protocol = "TCP"
destination_ports = ["443"]
}
l4_port_set_entry {
display_name = "SRV-TCP-P-22-ssh"
protocol = "TCP"
destination_ports = ["22"]
}
}
How to create NSX-T IPSET with Terraform
resource "nsxt_policy_group" "SG-IPSET-172_25_11_104_32" {
display_name = "SG-IPSET-172_25_11_104_32"
criteria {
ipaddress_expression {
ip_addresses = ["172.25.11.104"]
}
}
}
Note: you are free to put any preferred resource name and display name, but from my point of view, this is the best way of naming because once you see it in the GUI, you will know directly what is the IP or the subnet included in this IP-SET
Today we are going to upgrade VMtools for virtual machine without reboot.
at the beginning we will do it for one machine and after that we will make a simple loop to upgrade VMtools of bulk of virtual machines
PS C:\> Get-VM VMname
Name PowerState Num CPUs MemoryGB
---- ---------- -------- --------
VMname PoweredOn 2 4.000
PS C:\> Get-VM VMname | Update-Tools -NoReboot
I am trying now to upgrade the Terraform provider which I am using for my NSX-T
First you have to put the new provider version in your main.tf file
terraform {
required_providers {
nsxt = {
source = "vmware/nsxt"
version = "3.2.5"
}
}
}
Second is to execute the below command
.\terraform init -upgrade
once you execute the above command you will find output like the below output. That means that you upgraded your Terraform provider successfully
