Cisco Nexus 1000V in VMware vSphere API

While working at VMware, I always wondered what Cisco Nexus 1000V looked like from VMware vSphere API. Because I didn’t have access to such a system, I had no way to investigate further. This remained a myth to me until I joined VCE where I found many Vblock systems with Cisco Nexus 1000V as part of standard configuration.

Within VMware vSphere API, there are two managed object types defined related to distributed virtual switch:  DistributedVirtualSwitch, and VmwareDistributedVirtualSwitch. As you can guess, the latter type is a subtype of the first one.

Following that logic, you naturally expect another subtype like CiscoDistributedVirtualSwitch to the DistributedVirtualSwitch type for Cisco Nexus 1000V. I know vSphere API has some extensibility built in, but not as advanced as adding new managed object types. For one thing, the API’s WSDL has been defined already.

After playing with MOB (vSphere Client doesn’t help much for finding managed object types) of a vCenter on Vblock, I found that there is no subtype at all for Cisco Nexus 1000V – it just uses the super type DistributedVirtualSwitch.

What does this design mean?

First of all, it means that whatever features defined in the DistributedVirtualSwitch type is implemented by Cisco for the Nexus 1000V. So you can use it to the fullest of what DistributedVirtualSwitch offers.

Secondly, it also means that the Cisco Nexus 1000V exposes less features via vSphere API, thus vSphere Client, than the VMware distributed virtual switch. This is actually not obvious at first glance because the VmwareDistributedVirtualSwitch adds no additional property or method beyond what are inherited from the DistributedVirtualSwitch. You can find the following code snippet from vijava API (http://vijava.sf.net) source code.

public class VmwareDistributedVirtualSwitch extends DistributedVirtualSwitch
{
  public VmwareDistributedVirtualSwitch(ServerConnection sc, ManagedObjectReference mor)
  {
    super(sc, mor);
  }
}

Now what are the tricks?

The tricks actually lie with the property types and parameters to the methods. Let’s first look at the property called config with DVSConfigInfo type. The DVSConfigInfo is extended by VMwareDVSConfigInfo, which does have extra properties like ipfixConfig, linkDiscoveryProtocolConfig, maxMtu, pvlanConfig, vspanSession. So if you have VMware distributed virtual switch, your property config is actually VMwareDVSConfigInfo, not the DVSConfigInfo as defined in the DistributedVirtualSwitch type. This is a bit tricky but works fine.

Same tricks apply for some of the methods as well, for example, ReconfigureDvs_Task, which has DVSConfigSpec typed parameter. The DVSConfigSpec is extended by VMwareDVSConfigSpec which has extra properties defined. So if you configure a VMware distributed virtual switch, you create a VMwareDVSConfigSpec data object as argument, therefore you can change more than with Cisco Nexus 1000V.

With additional features of VMware distributed virtual switch, you can actually do more with vSphere Client, for example, you can set up port mirroring with VMware distributed virtual switch there. This does not mean Cisco Nexus 1000V is inferior to the VMware one. But this is a different topic that I may touch in future posts.

This entry was posted in vSphere API and tagged , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

3 Comments

  1. Fred Hsu
    Posted April 23, 2012 at 1:07 pm | Permalink

    Thanks for the great writeup! I’ve also been curious as to how n1kv and VMware API interact. Looking forward to more!

  2. Joe
    Posted April 24, 2012 at 5:04 pm | Permalink

    I guess I’m missing what the advantages of using the Nexus vs either vDS or just the normal vSwitch’s that VMWare provides. I see some docs out there about it, but nothing really to give me a clear reason for having one vs the other.

  3. Posted November 7, 2012 at 5:47 pm | Permalink

    Off the top of my head a distributed virtual switch provides more typical l2 switch functionality including SPAN (port replication), IPFIX (think flow accounting aka NetFlow), VMotion where vms stay on the same virtual switch port, and QoS.

    The N1k offers cisco’s traditional mgmt interfaces and l2 protocols so would appeal to customers invested in tools that work with catalyst/nexus systems consistently. VIM API is a proprietary interface as well and as such is limite a subset of VMware products.

3 Trackbacks

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

  • NEED HELP?


    My consulting helps clients with virtualization and cloud computing, including VMware infrastructure automation and orchestration, vSphere management APIs, and deep product integration with hypervisors. Current training offerings include vSphere APIs training, vCenter Orchestrator training, and etc. Should you, or someone you know, need these consulting services or training, please feel free to contact me: steve __AT__ doublecloud.org.

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.