The following table provides the supported attributes for the KVM/QEMU hypervisor.

The following table provides the supported attributes for the ESXI hypervisor.

The following table provides the supported attributes for the Vagrant hypervisor.

You can deploy the Cisco Nexus 9000v platforms through the KVM/QEMU hypervisor. The following table lists the supported parameters for the Cisco Nexus 9000v deployment on KVM/QEMU.

The Cisco Nexus 9500v platform runs in two different modes: sequential and mac-encoded mode. The Nexus 9300v and Nexus 9500v sequential mode deployment steps are the exact same on KVM/QEMU hypervisor. The maximum interfaces for both platforms in this case are 401 interfaces (1 management or 400 data ports).

The Nexus 9500v emulates interface traffic on multiple line cards. The virtual switch uses a single VM on KVM/QEMU for up to a total number of 400 interfaces. Based on the Nexus 9500v mac-encoded schema, specify each network adapter MAC address with the encoded slot and port number when the KVM/QEMU CLI command is invoked.

Interconnecting between Nexus 9000v platform instances or any other virtual platform is based on Linux bridges and taps. Prior to invoke any CLI commands, make sure that the following is available (example configuration provided).

In the configuration example below, you can create bridges and tap interfaces along with two N9Kv swicthes with one management and one data interface each. Management interfaces “interface mgmt0” are connected to management network with the bridge “mgmt_bridge. The data port interfaces “interface Eth1/1” from both switches are connected back to back by using the bridge “interconnect_br”.

Note	The minimum QEMU version required is 3.0.0 from Cisco NX-OS Release 9.3(3) and higher.

• Bridges (similar to vSwitch in ESXi hypervisor) are created and set to the "up" state.

  Linux commands to create bridges and bring them up:

  sudo brctl addbr mgmt_bridge

  sudo brctl addbr interconnect_br

  sudo ifconfig mgmt_bridge up

  sudo ifconfig interconnect_br up

• Tap interfaces are created based on number of interfaces the Nexus 9000v is using.

  Linux command to create tap interfaces:

  sudo openvpn --mktun –dev tap_sw1_mgmt

  sudo openvpn --mktun –dev tap_sw2_mgmt

  sudo openvpn --mktun –dev tap_sw1_eth1_1

  sudo openvpn --mktun –dev tap_sw2_eth1_1

• Bridges are connected to tap interfaces.

  Linux commands to connect bridges to tap interfaces:

  sudo brctl addif mgmt_bridge tap_sw1_mgmt

  sudo brctl addif mgmt_bridge tap_sw2_mgmt

  sudo brctl addif interconnect_br tap_sw1_eth1_1

  sudo brctl addif interconnect_br tap_sw2_eth1_1

• All tap interfaces must be in the "up" state.

  Linux commands for bringing tap interfaces up:

  sudo ifconfig tap_sw1_mgmt up

  sudo ifconfig tap_sw2_mgmt up

  sudo ifconfig tap_sw1_eth1_1 up

  sudo ifconfig tap_sw2_eth1_1 up

• Verify that all tap interfaces are connected to bridges

  Linux commands to confirm that tap interfaces are connected to bridges:

  brctl show

  bridge name        bridge id            STP enabled        interfaces
  interconnect_br    8000.1ade2e11ec42    no                 tap_sw1_eth1_1
                                                             tap_sw2_eth1_1
   
  mgmt_bridge        8000.0a52a9089354    no                 tap_sw1_mgmt
                                                             tap_sw2_mgmt
  

To bring up two Nexus 9000v platforms, connecting one interface each back to back, you can use the following commands as examples. The connection can be a socket-based or bridge-based connection. In this example, bridges are used to connect instances of management interface and one data port. Similarly, more Nexus 9000v data ports can be connected in the same way by adding more net device in the command line options. In this example, two interfaces each (interface mgmt0 and interface eth1/1) on both the Nexus 9000v instances are mapped.

For a Nexus 9000v first instance:

sudo qemu-system-x86_64 -smp 2  -m 8196 -enable-kvm -bios bios.bin 
-device i82801b11-bridge,id=dmi-pci-bridge 
-device pci-bridge,id=bridge-1,chassis_nr=1,bus=dmi-pci-bridge
-device pci-bridge,id=bridge-2,chassis_nr=2,bus=dmi-pci-bridge
-device pci-bridge,id=bridge-3,chassis_nr=3,bus=dmi-pci-bridge
-device pci-bridge,id=bridge-4,chassis_nr=4,bus=dmi-pci-bridge
-device pci-bridge,id=bridge-5,chassis_nr=5,bus=dmi-pci-bridge
-device pci-bridge,id=bridge-6,chassis_nr=6,bus=dmi-pci-bridge
-device pci-bridge,id=bridge-7,chassis_nr=7,bus=dmi-pci-bridge
-netdev tap,ifname=tap_sw1_mgmt,script=no,downscript=no,id=eth1_1_0 
-device e1000,bus=bridge-1,addr=1.0,netdev=eth1_1_0,mac=00:b0:b0:01:aa:bb,multifunction=on,
romfile= 
-netdev tap,ifname=tap_sw1_eth1_1,script=no,downscript=no,id=eth1_1_1 
-device e1000,bus=bridge-1,addr=1.1,netdev=eth1_1_1,mac=00:b0:b0:01:01:01,multifunction=on,
romfile= 
-device ahci,id=ahci0 -drive file=test1.qcow2,if=none,id=drive-sata-disk0,id=drive-sata-disk0,
format=qcow2 
-device ide-drive,bus=ahci0.0,drive=drive-sata-disk0,id=drive-sata-disk0 
-serial telnet:localhost:9000,server,nowait -M q35 -daemonize 

For a Nexus 9000v second instance:

sudo qemu-system-x86_64 -smp 2  -m 8196 -enable-kvm -bios bios.bin 
-device i82801b11-bridge,id=dmi-pci-bridge 
-device pci-bridge,id=bridge-1,chassis_nr=1,bus=dmi-pci-bridge 
-device pci-bridge,id=bridge-2,chassis_nr=2,bus=dmi-pci-bridge 
-device pci-bridge,id=bridge-3,chassis_nr=3,bus=dmi-pci-bridge 
-device pci-bridge,id=bridge-4,chassis_nr=4,bus=dmi-pci-bridge 
-device pci-bridge,id=bridge-5,chassis_nr=5,bus=dmi-pci-bridge 
-device pci-bridge,id=bridge-6,chassis_nr=6,bus=dmi-pci-bridge 
-device pci-bridge,id=bridge-7,chassis_nr=7,bus=dmi-pci-bridge 
-netdev tap,ifname=tap_sw2_mgmt,script=no,downscript=no,id=eth1_1_0 
-device e1000,bus=bridge-1,addr=1.0,netdev=eth1_1_0,mac=00:b0:b0:02:aa:bb,multifunction=on,
romfile= 
-netdev tap,ifname=tap_sw2_eth1_1,script=no,downscript=no,id=eth1_1_1 
-device e1000,bus=bridge-1,addr=1.1,netdev=eth1_1_1,mac=00:b0:b0:02:01:01,multifunction=on,
romfile= 
-device ahci,id=ahci0 -drive file=test2.qcow2,if=none,id=drive-sata-disk0,id=drive-sata-disk0,
format=qcow2 
-device ide-drive,bus=ahci0.0,drive=drive-sata-disk0,id=drive-sata-disk0 
-serial telnet:localhost:9100,server,nowait -M q35 -daemonize 

The qemu-system-x86_64 or above KVM command is equivalent depending on how Linux is deployed. After successful invocation, you should be able to access both instances of the serial console via “telnet localhost 9000” or “telnet localhost 9100 respectively.

To pass traffic for LLDP and LACP multicast-specific packets through a Linux bridge, set the following values on all bridges connecting to each instance:

• Set LLDP and LACP communication between the VMs:

  echo 0x4004 > /sys/class/net/br_test/bridge/group_fwd_mask

• Allow Multicast packet flow through the Linux bridge:

  echo 0 > /sys/devices/virtual/net/br_test/bridge/multicast_snooping

The Cisco Nexus 9500v runs in two different modes: sequential and mac-encoded mode. Nexus 9300v and Nexus 9500v sequential mode deployment steps are the exact same on ESXi hypervisor. The maximum number of interfaces for both platform types is 10 (one management port and nine data ports); this is a hypervisor limitation.

The Nexus 9500v emulates multiple-line-card interface traffic in single VM on ESXi hypervisor even though the total number of interfaces is limited to 10. If you choose to use the Nexus 9500v mac-encoded schema, change each network adapter MAC address to match slots and ports that are being emulated.

Networking between Nexus 9300v and Nexus 9500v, or any other virtual platform, is based on vSwitch as the bridge on the ESXi hypervisor. You can have any topology as designed to simulate various customer use cases.

You can't deploy the Cisco Nexus 9300v in the Vagrant/VBox environment. The virtual artifacts .box file is only available on distribution.

Deploy the nexus9300v.9.3.3.IDI9.0.XXX.box on a VirtualBox. See the following customization guidelines and caveats for using Vagrant/Vbox:

• The user customization in Vagrant file isn't required.

• There's no need to change named pipe for Windows. Access the serial console using default port 2023, for both Mac or Windows. If needed, use this serial console via telnet localhost 2023 to monitor the switch boot up process.

• The standard box process is used as any other appliance distribution. You can simply bring up a VM using the base box name.

• The box name can be changed to a different name other than "base" using the config.vm.box field from the Vagrant file.

• The bootstrap configuration is possible if you want to apply a different configuration on the switch, other than the existing generic configuration in .box from the release image file. In this case, use vb.customize pre-boot. For example:

  vb.customize "pre-boot", [ 
               "storageattach", :id, 
               "--storagectl", "SATA", 
               "--port", "1", 
               "--device", "0", 
               "--type", "dvddrive", 
               "--medium", "../common/nxosv_config.iso",
  

• Customize the VM interface MAC address by using the config.vm.base_mac field. This modification must be performed prior to entering the vagrant up CLI command and after entering the vagrant init CLI command. If you want to modify the MAC address after entering the vagrant up CLI command, or after the VM is created, use the box commands to modify the VM.

Networking between Nexus 9300v and other virtual platforms, is based on VBox Internal Network. See the following connection diagram:

Depending on the environment, use the appropriate virtual artifact and refer to one of the following sections to deploy the VM:

• Nexus 9000v Deployment Workflow for KVM/QEMU

• Nexus 9000v Deployment Workflow for ESXi

• Nexus 9000v Deployment Workflow for Vagrant

Nexus 9300v upgrades are only allowed from a VM created with virtual artifacts from Cisco Nexus 9000v, Release 9.3(1) and onwards. Before upgrading, ensure there's 400Mb + of new NX-OS binary image on the bootflash. To upgrade, copy the new binary to the bootflash and then upgrade using the standard NX-OS workflow (for example: ‘install all nxos bootflash:///<nxos.bin>’).

Nexus 9500v upgrades aren't supported as this is the first release of the platform.

For Nexus 9300v and 9500v lite, ISSU from earlier binary image to lite binary image is not supported. Even if you can bring up the image using cold boot, delete the previous configuration first, and then install the lite binary.