While working with NSX-T, there are many reasons to access edge appliances using SSH. Most troubleshooting options are only available using nsxcli on the appliance itself. During the deployment, each appliance has 3 user account: root, admin, and audit. Alle Accounts are configured with password-based authentication. In a previous article, I've already described how to deploy SSH Keys using nsxcli, which allows a secure and comfortable authentication method. In this article, I'm explaining how to use ansible to deploy SSH public keys to NSX-T Edges. This option allows you to easily manage keys on a large platform.
The Linux Version of the vCenter Server is not new anymore but with vSphere 6.0 the vCenter Server Appliance (VCSA) has overtaken the Windows Version in many aspects. The completely rewritten linked mode removes the need for a Windows-based vCenter and the scalability of both appliances are identical.
VCSA6 is delivered as appliance based on openSUSE. Nevertheless its a Linux, VMware want's you to use the GUI. Unless you are in a testing environment I would highly recommend to limit shell usage to the following usage scenarios:
- During Service Requests under advice of VMware GSS
- For advanced troubleshooting
- When required for complex deployments (eg. PSC 6.0 High Availability)
Check if a remote host is online and reachable.
~ # ping 220.127.116.11 PING 18.104.22.168 (22.214.171.124): 56 data bytes 64 bytes from 126.96.36.199: icmp_seq=0 ttl=58 time=13.701 ms 64 bytes from 188.8.131.52: icmp_seq=1 ttl=58 time=10.176 ms 64 bytes from 184.108.40.206: icmp_seq=2 ttl=58 time=9.055 ms --- 220.127.116.11 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 9.055/10.977/13.701 ms
Ping from a specific VMkernel adapter.
~ # ping -I vmk1 18.104.22.168 PING 22.214.171.124 (126.96.36.199): 56 data bytes 64 bytes from 188.8.131.52: icmp_seq=0 ttl=58 time=9.991 ms 64 bytes from 184.108.40.206: icmp_seq=1 ttl=58 time=9.270 ms
I recently had an issues where a virtual machine crashed. VM Monitoring (VM HA) tried to restart it, but did not succeed. The virtual machine was greyed out in the inventory and could not be started because it was locked. Unfortunately, it was not possible to identify which ESXi host holds the lock. This post explains how to quickly identify which server is blocking the Virtual Machine.