VMware VCF and vSphere Diagnostic tool-VDT

VMware VDT- VCF Diagnostic Tool Overview

VDT (developed and built by VMware Support) is a utility designed to run a series of comprehensive checks live on a target appliance. In its current state, VDT supports the vCenter Server and SDDC Manager appliances.

The VCF Diagnostic Tool (VDT) is a diagnostic tool that is run directly on the SDDC Manager or vCenter server. It runs through a series of checks on the system configuration and reports user-friendly PASS/WARN/FAIL results for known configuration issues. It also provides information (INFO) messages from certain areas which we hope will make detecting inconsistencies easier. The goal of these tests is to provide live diagnostic information to the user about their environment which might otherwise be missed.  

This tool is completely read-only for the entire environment. hence, it will not make any changes to the environment and no risks to use it.

Another important thing about this tool that, it is completely offline and does not reach out to the Internet or any VMware depots for any information. Therefore, it is geared to be run in offline and air-gapped environments, making it a very useful tool for troubleshooting, considering it is often not possible to share logs or screen-share with VMware support.

How to use VCF-VDT on SDDC manager:-

1. Download the latest version of vSphere Diagnostic Tool from the below VMware KB.

     https://kb.vmware.com/s/article/94141

2. Use the file-moving utility of your choice (WinSCP for example) to copy the entire ZIP directory to the /home/vcf/ partition on the SDDC-Manager on which you wish to run it.

3. SSH into the SDDC-Manager and elevate to root with su.

4. Change your directory to the location of the file, and unpackage the vdt zip file:

       cd /home/vcf/

       unzip vdt-<version>.zip

       cd vdt-<version>

5. Run the tool with the command:

      python vdt.py -p sddc_manager

6. You will then be prompted for the administrator@vsphere.local password.

Note:If you are unable to provide the SSO password the script will only run checks that do not require authentication. 

The utility logs to the following directory on the SDDC-Manager.

/var/log/vmware/vcf/vdt/

How to use VDT on vCenter Server:-

1. Download the version of VDT 2.0 compatible with your vCenter version from below VMware KB article.

    

    https://kb.vmware.com/s/article/83896

2. Use the file-moving utility of your choice (WinSCP for example) to copy the entire ZIP directory to /root on the node on which you wish to run it.

  

3. Change your directory to the location of the file, and unpack the zip:

      cd /root/

      unzip vdt-version_number.zip

4.Run the tool with the command:

      python vdt.py

You will be prompted for the password for administrator@sso.domain. Many checks will still run even if credentials are not supplied.

Please send feedback/feature requests to vcf-gcs-sa-vdt.pdl@broadcom.com

Refer below KB articles for more info:

For VCF-https://kb.vmware.com/s/article/94141

For vSphere- https://kb.vmware.com/s/article/83896

DISCLAIMER: This script is currently in its beta release phase.

As such, it may contain bugs, errors, or incomplete features. Please leverage results with caution.

CVE-2023-48795 Impact of Terrapin SSH Attack

CVE-2023-48795 describes a vulnerability in OpenSSH v9.5 and earlier. This vulnerability, also known as the "Terrapin attack", could allow an attacker to downgrade the security of an SSH connection by manipulating information transferred during the the connection's initial handshake/negotiation sequence. The attacker must have already gained access to the local network, and must be able to both intercept communications and assume the identity of both the recipient and the sender. The CVSS 3.x rating of "Medium" reflects the difficulty in successfully exploiting this vulnerability.

CVE-2023-48795 has since been resolved in OpenSSH v9.6. It's mitigation requires both client and server implementations to be upgraded to this fixed or later version. Additionally, this vulnerability can also be addressed by disabling use of the "ChaCha20-Poly1305" cipher in affected OpenSSH implementations. 

This vulnerbility affects all systems having the openssh installed "Linux and Windows".

For VMware products like NSX Managers, Edge Nodes running on Linux kernel(same as Linux) are also affected by this vulnerbility.

Workaround to fix this on NSX Appliances is remove the affected ciphers from SSH and SSHD config files.

Login to NSX appliances(Managers & Edge nodes) via putty and switch to "root" account.

root@nsxmgr001:~# vi /etc/ssh/ssh_config 

root@nsxmgr001:~# vi /etc/ssh/sshd_config 

and remove the below ciphers from both of these files and save & exit.

# Cipher and MAC algorithms

chacha20-poly1305@openssh.com

hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com

Restart the ssh service then--

root@nsxmgr001:~# /etc/init.d/ssh restart

After removing the vulnerable ciphers & MAC Algorithms, both config files will looks like below:

Plz Note: There is no offically update on this vulnerability from VMware side as of now, so do it own risk.

Refer below documentation for more info.

https://learn.microsoft.com/en-us/answers/questions/1525235/need-solution-to-terrapin-vulnerability-cve-2023-4

https://nvd.nist.gov/vuln/detail/CVE-2023-48795

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48795

VMware vSAN OSA and ESA overview.

 VMware vSAN 8™, Introduces the revolutionary Express Storage Architecture™.  This is an optional, alternative storage architecture to the vSAN original storage architecture also found in vSAN 8.  When running on qualified hardware in approved vSAN ReadyNodes, the vSAN Express storage architecture will offer supreme levels of performance, scalability, resilience, and data services without compromising performance.  The vSAN Express Storage Architecture unlocks the capabilities of modern hardware to allow the workloads of today and tomorrow.

Below are some key differences between OSA and ESA Architecture.

OSA: Original Storage Architecture

1. OSA is a vSAN Distributed File System (vDFS)

2. Drives like SSDs, HDDs, and hybrid supported by OSA.

3. 1 Cache drive per Disk group is supported by OSA.

4. Hardware requirements for OSA is Varies as per vSAN config.

5. With OSA we can get good performance by leveraging different RAID policies with stripping options.

6. OSA is using disk groups with caching devices. It can be configured with various hardware, including spinning disks.

7. OSA can run on vSphere 6.x,7.x and 8.x versions.

8. Minimum 10Gbps network required for host networking.

9. Minimum storage device required to configure OSA is 2.

 

ESA:  Express Storage Architecture

1. ESA is a Log Structured File System (vSAN LFS)

2. Drives Certified with NVMe SSDs are supported by ESA.

3. There are no disk groups, hence no caching drive needed.

4. ESA supports only vSAN ReadyNodes.

5. Performance is excellent with ESA as compared to OSA.

6. ESA uses a storage pool instead of disk groups. This makes it more storage effective.

7. ESA is available from vSphere 8.x version only.

8. Minimum 25GBps network required for host networking.

9. Minimum storage device required to configure ESA is 4.

For more information about VMware vSAN ESA, refer below article.

https://core.vmware.com/blog/comparing-original-storage-architecture-vsan-8-express-storage-architecture