Home > vSphere API > Cisco Nexus 1000V in VMware vSphere API

Cisco Nexus 1000V in VMware vSphere API

April 23rd, 2012 Leave a comment Go to comments

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.

Time to learn how to "Google" and manage your VMware and clouds in a fast and secure


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.

  1. Fred Hsu
    April 23rd, 2012 at 13:07 | #1

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

  2. Joe
    April 24th, 2012 at 17:04 | #2

    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. November 7th, 2012 at 17:47 | #3

    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.

  4. David
    February 26th, 2016 at 19:36 | #4

    How can I start accessing the Cisco 1000V properties through PowerCLI using your handy tricks?

  1. April 27th, 2012 at 16:55 | #1
  2. September 30th, 2012 at 14:23 | #2
  3. May 5th, 2013 at 11:28 | #3