JaSo2's Accepted Solutions

Hello, Yes, it looks pretty straight forward, but it can be tricky: - If you have DRS fully automated, then nothing else is needed and everything will be done automagically from the maintenance mode (MM) perspective. - You can rename VDS afterwards - after all it is "just" an object. Mind the fact there will be also an uplink portgroup with the similar automatically generated name. The tricky part not mentioned in the docs (at least not the last time I checked) that bit me and turned out not to be a bug (support confirmed) is default timeout for leaving MM of the vds-migrate command. It is 300 seconds - meaning if your running VMs are not migrated off your host in 300 seconds you are running into serious problems. There is an option for the migration command to specify MM timeout (switch maintenance-mode) to modify this default behavior - I recommend checking it in the CLI. If I were you I would go with the API path - it is much more in your control and you can modify the VDS name in the API call along the way. J.

It is possible with command: set hostname hostname.example.com I have just tried it on 3.2.2 and it worked (rebooted the appliance in question, but I don't know if it is necessary) - also after the appliance was back up, it took a while before it was reflected by the cluster status information. Other way would be to delete the appliance and recreate it with FQDN, but I guess this is faster :).

Yes, it does (I would go with Medium size). More is written here https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/installation/GUID-10CF4689-F6CD-4007-A33E-A9BCA873DA8A.html - for production deployment it is recommended to have 3, but it will run also with 1. Not sure what support will tell you though if you mark your environment as production and have only 1 NSX Manager appliance there :). Mind the fact that if you do not have connectivity from the TNs to the Manager node your data plane works, but management and control does not - you won't be able to do any configuration changes and vMotion VMs between hosts / connect them to different logical segments etc.

Hello, Yes, the easiest way in my opinion is to use some kind of NAT. You will then hide everything related to NSX-T behind your NAT (you may be able to do it also with NSX-T, but for basic study purposes it is good to use for example VyOS - a small Linux based router/firewall). On youtube Jeffrey Kusters has a great videos regarding NSX-T and the stuff you would like to do (https://www.youtube.com/watch?v=7d1fwsVlOLI&list=PLF5eL3jdkBq7CAuCd-Eo8qiupcn7chfEX). I usally setup lab in similar manner - an ESXi host with nested environment inside (2-3 other ESXi hosts, vCenter, NSX-T manager either on the nested hosts or on the physical one), 2 vSS - one for the isolated environment with the necessary security settings on, second for physical host management and outside connection. On the physical host I have a VyOS VM with 2 NICs - one inside a portgroup for outside connection, the second inside a portgroup on the isolated environment and this VyOS VM is basically doing NAT service for the nested environment + more (but that is another topic). Check the series - you will find more than enough regarding this in there.   J.

Have you tried the previous version also? According to this https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-T-3-2-on-vSphere-7u3c-Hugepage-issues-on-Edge-VMs/td-p/2894117 the previous version works (there is 3.0 mentioned, but I would go with 3.1.3.5 - that is the latest 3.1.3 version where I did not encounter any issue). J.