It’s very interesting that sometimes things work not in a way you expect. Well, it happens a lot in computer networking! By the way, using Microsoft Network Load Balancing in a VMware environment is one of them. In specific, when you intend to deploy Microsoft NLB in Unicast mode, you should be cautious. The reason for NLB not to work properly is well explained in the following Link:
Microsoft NLB not working properly in Unicast mode
In brief, NLB mechanism is based on hiding common, shared MAC address it assigns to all involved hosts from switch (by special kind of encapsulation I suppose) but ESX/ESXi hosts expose this common MAC address in certain conditions that will enable switch to learn the location and sends all the traffic to that specific port (ESX/ESXi host) which is against purpose of load balancer! There is a work around though which is suggested in the link above.
I’ve got some design considerations about creating Volumes in storage which supposed to be used by virtualization infrastructure (VMware 5.1) as datastore; I ended up reading this great article by Michael Webster which saved my day and I would like to share:
The Case for Larger Than 2TB Virtual Disks and The Gotcha with VMFS
Overall, it seems that VMware vSphere 5.5 has good advantages and improvements over 5.1.
Since VMware vCenter uses ports 80, 443 to provide access to management console (for both vSphere Client and Web Console), it’s important to secure these ports. Having said that, it can be limiting access to specific IP addresses in your internal network. If there is no firewall between your internal network and Cloud infrastructure, at least configure Firewall in Windows machine (if vCenter is installed on Windows) to restrict access.
Also, for a complete list of tasks to harden vCenter Security, you can see Security Advisories, Guides document from VMware.