NSX could better integrate with open-source products. Of course, it integrates with some, but I know many people are uncomfortable deploying NSX with certain open-source solutions, such as Radar. They don't integrate so well, and the integration is usually so complex that many people would rather not use them.

Traffic flow introspection topology visibility is definitely needed because at the moment, NSX-T lacks in this area.

A hardware scan of the ESXi host for possible incompatibilities should be added to NSX-T/vSphere, as it would allow us to know in advance, for example, if a pNIC is not compatible with a version of vSphere before moving forward with an NSX-T deployment. 

It needs a better, integrated migration tool. Something like RestNSX with more elaborate capabilities from a troubleshooting perspective and pre-migration perspective would be an improvement.

It's very complex. However, I don't work directly with it typically.

We had started two projects for integration with OpenShift and OpenStack with NSX. It was declared by VMware that this is possible, however, the process is very tricky. The full integration was delayed to wait for a new official release. I don't know the actual stage, as this is something that happened more than a year or two ago. It was the beginning of the pandemic. In any case, the integration with OpenShift, the open-source cloud platform, at the time was in need of work and was (and remains) something required from our customers. 

They have to work more and more on the integration for public cloud services and have cyber security platform integration.

In rare situation there are  mismatch in the control plane data and dataplane data i.e. the details and what you actually see on the transport note. This is rare but time consuming to troubleshoot . Additionally, there could be better integration between VMware Cloud Federation (VCF) and NSX-T. Currently, there are some limitations, for example, VCF allows just one overlay transport zone. Also there is not upgrade path from VCF 3(NSX-T 2.5.x) to VCF 4 (NSX-T 3.x)

• NSX Manager console: limit on number of NSX Controllers an architecture can have
• Support for ESXi, KVM, bare-metal servers, Kubernetes, OpenShift, AWS and Azure.
• Integrate NSX Controllers into NSX Manager as a single virtual appliance so controllers no longer need to be deployed independently.
• Directs to vCenter by registering Transport Nodes instead of registering NSX Manager inside of vCenter.
• Use a more modern overlay technology for encapsulation that performs better and is more flexible for the future over older, more traditional VXLAN overlay technology.

There is always room for improvement, in any solution. 

In some cases, this product is very technical. 

Some configuration maximums are limiting to the user, especially when it comes to the deployment of very, very large environments. There are limits to the number of firewall rules, security groups, et cetera. With the number of security groups, you can nest all these limits, however, somehow limiting the use cases may be restrictive for the free design of different use cases.

Any technical product has its own limitations in one place or another.

Our technical team is always looking for the solutions that they work with to offer more convenient integrations.

I would like to see improvements made to the certification process. As it is now, you have to do the training with VMware itself, and you have to spend a lot of money doing it, which is very discouraging. 

If you compare other certifications especially from the cloud providers, you can get trained from your choice of training providers and not very expensive or learn on your own at your pace, prepare for exams and pass and your certificate will be issued. In contrast, you have to register under VMware to get training done at minimum of $3000 before your certificate is issued to you. The training costs a minimum of $3,000, which is expensive and should be reduced. 

I cannot recall coming across any missing features. At this time, there is nothing I would need in a future release. 

Occasionally the licensing is not very clear. They should make it easier to understand. 

One of the areas that we are struggling with is how do we perform the same security level as we had for an NSX solution for the legacy system. For example, if I have a switch, and I am connecting a legacy application on the legacy system that does not support the hyper vision or another feature, is possible to push the security topic to the switches to be compliant, or compliant with an NSX component, and to perform the same security level as we perform for hyper vision side. It would be beneficial for us if there was better integration with legacy systems.

In the future, the solution should be compliant with internet NIC. They could deploy this NIC into some switches, servers, or other product. It would be interesting to have this sort of NIC stamped by VMware, and we could push some security feature into it. It would be a very useful feature. I do understand VMware is virtual and not on a physical device path but this would be a good endeavour.

VMware NSX can improve the migration tools from the older environments to the new environment. For example, the NSX-V has become a legacy solution, it's out of support, but customers are able to keep using it. For migration purposes, it's better for them to provide a proper tool. It will be easy to migrate from an old environment to a new one.

There are always issues integrating with Cisco.

Switching is always a big problem for us because our switch is not supported.

If the integration was more open, then it would be good.

There could be an improvement in regards to security. This solution cannot migrate all assets smoothly and continuously, for example, the host

Sometimes the physical hosts are not able to be converted into virtual ones, which needs to be fixed. 

It could be more user-friendly, but it's manageable. When we add a specific node to this particular NSX and the configuration changes, it won't push through the errors where required, but it'll accept it. However, while using it, we will have issues. It can also be more stable. 

The product is quite complex and that could be an area where improvements could be made. 

VMware NSX should be able to scale for different customers, even the big ones. Its scalability needs improvement. Stability for it should also be improved.

An additional feature I'd like to see in the next release of this product is for it to have more integration with other public clouds.

The technical support could use some improvement.

One drawback is this solution requires a lot of other products in the VMware ecosystem to have a full end-to-end operation orchestration monitoring. You have to buy a lot of add-ons to fully utilize the functionality.

Some additional features in the next release could be for the solution to be more directed toward the end-to-end functions, from physical to virtual monitoring. It should also include streamlined troubleshooting of our operation. 

It isn't easy to deploy.

The solution can improve by making it more straightforward, easier to install and maintain in the environment.

NSX-T supports more platforms, and VMware NSX only supports some platforms like KVM. I want to see support for Hyper-V and other hypervisors.

Their technical support could be faster as well.

VMware NSX needs improvement.

VMware NSX provides a lot of automation capabilities, but there is still room for improvement.

VMware NSX could improve by having more compatibility with other none Window-based operating systems.

The routing functionality needs to be improved, as there are lots of bugs in the system.

I would like to see automation capabilities in the deployment process.

Their licensing model should make it easier to purchase licenses.