![\"\"](\"http:\/\/benincosa.com\/blog\/wp-content\/uploads\/2013\/07\/Screen-Shot-2013-07-25-at-10.35.17-PM.png\" "\\"Screen")
<\/a><\/p>\nHere, is what is so great about this configuration. \u00a0The VMware administrator can use things “business as usual” with the first 6 NICs.<\/p>\n
Management A\/B teams up with vmknic0 with IP address 192.168.40.101. \u00a0This is the management interface and used to talk to vCenter. \u00a0This is not controlled by the Nexus 1000v. \u00a0Business as usual here.<\/p>\n
IP Storage A\/B teams up with vmknic1 with IP address 192.168.30.101. This is to communicate with storage devices (NFS, iSCSI). \u00a0Not controlled by Nexus 1000v. \u00a0Business as usual.<\/p>\n
VM Traffic A\/B team up. \u00a0This is a trunking interface and all kinds of VLANs pass through here. \u00a0This is controlled either by a virtual standard switch or using VMware’s distributed Virtual Switch. \u00a0Business as usual. \u00a0You as the VMware administrator don’t have to worry about anything a Jr. Woodchuck Nexus 1000v administrator might do.<\/p>\n
<\/p>\n
Now, here’s where its all good. \u00a0With UCS you can create another vmknic2 with IP address 192.168.10.101. \u00a0This is our link that is managed by the Nexus 1000v. \u00a0In UCS we would configure this as a trunk port with all kinds of VLANs enabled over it. \u00a0This can use the same VNIC Template that the standard VM-A and VM-B used. \u00a0Same VLANs, etc.<\/p>\n
(Aside: \u00a0Some people would be more comfortable with 8 vNICs, Then you can do vMotion over its own native VMware interface. \u00a0In my lab this is 192.168.20.101)<\/p>\n
The difference is that this IP address 192.168.10.101 belongs on our Control & Packet VLAN. \u00a0This is a back end network that the VSM will communicate with the VEM over. \u00a0Now, the only VM kernel interface that we need to have controlled by the Nexus 1000v is the 192.168.10.101 IP address. \u00a0And this is isolated from the rest of the virtualization stack. \u00a0So if we want to move a machine over to the other virtual switch, we can do that with little problem. \u00a0A simple edit of the VMs configuration can change it back.<\/p>\n
Now, the testing can coexist on a production environment because the VMs that are being tested are running over the 1000v. \u00a0Now you can install the VSG, DCNM, the ASA 1000v, and all that good vPath stuff, and test it out.<\/p>\n
From the 1000v, I created a port profile called “uplink” that I assign to these two interfaces:<\/p>\n
port-profile type ethernet uplink
\nvmware port-group
\nswitchport mode trunk
\nswitchport trunk allowed vlan 1,501-512
\nchannel-group auto mode on mac-pinning
\nno shutdown
\nsystem vlan 505
\nstate enabled<\/p><\/blockquote>\nBy making it a system VLAN, I make it so that this control\/packet VLAN stays up. For the vmknic (192.168.10.101) I also created a port profile for control:<\/p>\n
port-profile type vethernet L3-control
\ncapability l3control
\nvmware port-group
\nswitchport mode access
\nswitchport access vlan 505
\nno shutdown
\nsystem vlan 505
\nstate enabled<\/p><\/blockquote>\nThis allows me to migrate the vmknic over from being managed by VMware to being managed by the Nexus 1000v. My VSM has an IP address on the same subnet as vCenter (even though its layer 3)<\/p>\n
n1kv221# sh interface mgmt 0 brief<\/p>\n
——————————————————————————–
\nPort VRF Status IP Address Speed MTU
\n——————————————————————————–
\nmgmt0 — up 192.168.40.31 1000 1500<\/p><\/blockquote>\nInterestingly enough, when I do the sh module vem command, it shows up with the management interface:<\/p>\n
Mod Server-IP Server-UUID Server-Name
\n— ————— ———————————— ——————–
\n3 192.168.40.102 00000000-0000-0000-cafe-00000000000e 192.168.40.102
\n4 192.168.40.101 00000000-0000-0000-cafe-00000000000f 192.168.40.101<\/p><\/blockquote>\nOn the VMware side, too, it shows up with the management interface: 192.168.40.101<\/p>\n