I have a very different situation here. I have created a N1KV switch based on vSphere 5.1 U1 test environment
1. VSM installed perfectly and working fine.
2. VEMs wont install using VUM or Install applet on ESXi 5.1 U1
3. VEMs installed on ESXi 5.0 but wont communicate to VSM.
1. Does N1KV supports 5.1 U1? If not is this the reason VEMs dont install on ESXi 5.1 U1
2. Will Distributed switch based on 5.1 works fine with vSphere 5.0 hosts? I can create Eth and vEth port-groups on ESXi 5.0 hosts but cannot make communication btwn VSMs and VEMs.
1. Yes N1K version 4.2(1)SV1(5.2b) and later is supported on ESX 5.1 U1.
2. Yes the 1000v is backwards compatible. The appropriate VEM version with either push from VUM or will be manually installed on each host.
Do you have any firewalls between the hosts and VSM and/or vCenter?
Is VUM pushing other updates/patches successfully?
You're likely missing the VEM software vib for ESX 5.1 U1 from your VUM respository. Try installing pulling the appropriate VIB from the VSM and installing manually on a test ESX 5.1 U1 host. If this works, then you have a VUM repository issue.
Thanks for clarifying!!
1. I am using this version 4.2(1)SV2(1.1a). i am assuming this is later version than what you mentioned.
2. If its backward compatible, then I should look for VSM and VEM communication troubleshooting.
I am using it in my homelab so there are no firewals and VSM and vcenter communicate properly. SVS connection says Connected.
Yes, I have updated the repository in VUM from the N1KV software that I downloaded from Cisco site. Both VUM as well as Java instaler applet failed to install VEMs on 5.1 U1 hosts but worked with 5.0 hosts. They go upto 74% in tasks when I trigger VEm installs and then throw generic error message when googled shows wide range of solutions. I didnt tried manually but will give a try and let you know on that.
The generic error message you mentioned is it "(vim.fault.PlatformConfigFault)"
If so you would need to tail the hostd logs in ESXi when you are adding your uplinks and have a look at the reason it gives for failing to apply the config.
To tail the hostd log:
* tail -f /var/log/hostd.log
Once you have that output, we should be able to tell what is stopping the config from pushing through.