I am working on test implementation of UCS API polling. During reading documentation I have found expression Virtual IP. What is realation of Virtual IP to UCS manager ? Is there any limitation with using API over specific Virtual IP ?


 
UCS is always deployed with redundant Fabric Interconnects (6100s) that form a cluster.  Each of those two 6100s has an IP Address.  A third IP Address to be used as the "floating/virtual" management address is also assigned to the system.  The "Primary" device of the two responds to management inquiries, telnet, ssh, etc on that third "floating/virtual" IP Address.  The address will always be "controlled" by the "Primary" 6100 in the system.  The "Subordinate" unit takes over management and that third IP Address if there is a failure on the Primary.
 
You should normally connect to the virtual/floating/third IP Address regardless of your connection type (GUI, SSH, Telnet, etc).  You should not connect directly to the IP Address configured on either of the 6100s unless you are doing something specific that requires it (some form of maintenance or troubleshooting possibly).
 
A quote from the UCS management architecture document:
"A "floating" management IP address is configured
on the active instance so that all GUI and command-line interface (CLI)
connections and management operations are forced to initiate there.
Configuration and operational state changes are then propagated over the
private network from the active instance to the standby instance so
that management information is synchronized."

It is discoverable.  See the ping traces below.  .30 is the VIP, .32 is the Primary, and .33 is the Subordinate.  
 
I have not dug through the MIB to see if you can pull the real addresses.  The virtual will get you to the Primary, so you should almost for sure get the primarys real address.
 
 
 

dhcp-olympia-wa-32-142:~ tigelane$ ping 10.10.50.30
PING 10.10.50.30 (10.10.50.30): 56 data bytes
64 bytes from 10.10.50.30: icmp_seq=0 ttl=63 time=152.892 ms
64 bytes from 10.10.50.30: icmp_seq=1 ttl=63 time=163.818 ms
^C
--- 10.10.50.30 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 152.892/158.355/163.818/5.463 ms
dhcp-olympia-wa-32-142:~ tigelane$ ping 10.10.50.32
PING 10.10.50.32 (10.10.50.32): 56 data bytes
64 bytes from 10.10.50.32: icmp_seq=0 ttl=63 time=156.894 ms
64 bytes from 10.10.50.32: icmp_seq=1 ttl=63 time=106.485 ms
^C
--- 10.10.50.32 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 106.485/131.690/156.894/25.204 ms
dhcp-olympia-wa-32-142:~ tigelane$ ping 10.10.50.33
PING 10.10.50.33 (10.10.50.33): 56 data bytes
64 bytes from 10.10.50.33: icmp_seq=0 ttl=63 time=148.898 ms
64 bytes from 10.10.50.33: icmp_seq=1 ttl=63 time=100.470 ms
^C
--- 10.10.50.33 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 100.470/124.684/148.898/24.214 ms
dhcp-olympia-wa-32-142:~ tigelane$

Brandon - 
 
Should be able to get the physical IP for the FI via xml api  from networkElement class.

You will see sys/switch-A and sys/switch-B with element oobIfIp as the IP address for the Physical