VMware NSX-T 2.5 only allows a VMware digital signature signed OVF to be deployed. It was newly introduced in NSX-T 2.5. This article describes a couple of known issues that the change has caused when deploying Deep Security Virtual Appliance (DSVA) in NSX-T 2.5.
An issue has been found on SSL certificate of VMware NSX-T 2.5 certification checking mechanism if the partner console provides a self-signed certificate. After importing Deep Security Appliance 12.0.0-682 or later to Deep Security Manager, the following error may appear when deploying DSVA from VMware NSX-T 2.5 console, which leads to DSVA deployment failure.
The workaround is to prepare a web server to deploy Deep Security Virtual Appliance. However, it is recommended to use HTTP and avoid using HTTPs.
For more details about this known issue, please see this VMware article.
In earlier versions, pre-configured OVF was allowed and you can modify the resources (e.g. CPU, memory) before deploying DSVA. In NSX-T 2.5, however, OVF modification may cause failure in DSVA deployment because of the integrity checking on NSX.
Here is a workaround in case you want to deploy a non-default OVF:
- Prepare an HTTP web server to deploy Deep Security Virtual Appliance.
- Use the OVF file that best suits your environment. Trend Micro provides four (4) OVF files which differs in resource allocation. For more details on suggested resource allocation, refer to Deep Security Help Center.
OVF Files vCPU Memory dsva.ovf 2 4096 MB dsva-small.ovf 2 8192 MB dsva-medium.ovf 4 16384 MB dsva-large.ovf 6 24576 MB
