Nexus 1000v Vmotion

Similar Questions

• Nexus 1000v and vMotion/VM traffic?

  Hello

  We are moving our servers of VM production to a new data center.

  There is a willingness to use the ports of 2 x 10 giga on each ESX host for the uplinks (etherchannel) Nexus 1000v for vMotion traffic and traffic VM.

  I don't know if that's even possible/supported? To devote nexus 1000v for vMotion and VM traffic ports at the same time? I think each guest will need an address unique IP for vMotion be able to operate.

  Best regards

  / Pete

  Info:

  vCenter/ESXi - 5.0 Update 3

  Yes - the characteristics of vmotion still apply if you use a virtual switch Standard or Distributed Virtual Switch as the Nexus 1000v - you should have a network for vmotion and each port vmkernel will need a unique IP address on the subnet of vmotion

• Several vmk vMotion using Nexus 1000v?

  Hello

  We would like to use several for vMotion vmkernel ports in an environment with a Nexus 1000v dVS.

  We work in an environment where the vMotion traffic crosses a dVS VMware and it works surprisingly well. We would like to use this new feature cool vSphere5 using the vmk vmotion ports attached to a Nexus 1000v? Is this possible? Someone has it in production?

  Thanks in advance.

  Œuvres multi-NIC with any active VMotion VMkernel portgroup vMotion, no matter if it is using standard, vDS switches VMware or a third party such as the Cisco Nexus 1000v vDS.

  -Andreas

• Design/implementation of Nexus 1000V

  Hi team,

  I have a premium partner who is an ATP on Data Center Unified Computing. He has posted this question, I hope you can help me to provide the resolution.

  I have questions about nexus 1KV design/implementation:

  -How to migrate virtual switches often to vswitch0 (in each ESX server has 3 vswitches and the VMS installation wizard will only migrate vswicht0)? for example, to other vswitchs with other vlan... Please tell me how...
  -With MUV (vmware update manager) can install modules of MEC in ESX servers? or install VEM manually on each ESX Server?
  -Assuming VUM install all modules of MEC, MEC (vib package) version is automatically compatible with the version of vmware are?
  -is the need to create port of PACKET-CONTROL groups in all THE esx servers before migrating to Nexus 1000? or only the VEM installation is enough?
  -According to the manual Cisco VSM can participate in VMOTION, but, how?... What is the recommendation? When the primary virtual machines are moving, the secondary VSM take control? This is the case with connectivity to all virtual machines?
  -When there are two clusters in a vmware vcenter, how to install/configure VSM?
  -For the concepts of high availability, which is the best choice of design of nexus? in view of the characteristics of vmware (FT, DRS, VMOTION, Cluster)
  -How to migrate port group existing Kernel to nexus iSCSI?... What are the steps? cisco manual "Migration from VMware to Cisco Nexus 1000V vSwitch" show how to generate the port profile, but
  How to create iSCSI target? (ip address, the username/password)... where it is defined?
  -Assuming that VEM licenses is not enough for all the ESX servers, ¿will happen to connectivity of your virtual machines on hosts without licenses VEM? can work with vmware vswitches?

  I have to install nexus 1000V in vmware with VDI plataform, with multiple ESX servers, with 3 vswitch on each ESX Server, with several machinne virtual running, two groups defined with active vmotion and DRS and the iSCSI storage Center

  I have several manuals Cisco on nexus, but I see special attention in our facilities, migration options is not a broad question, you you have 'success stories' or customers experiences of implementation with migration with nexus?

  Thank you in advance.

  Jojo Santos

  Cisco partner Helpline presales

  Thanks for the questions of Jojo, but this question of type 1000v is better for the Nexus 1000v forum:

  https://www.myciscocommunity.com/Community/products/nexus1000v

  Answers online.  I suggest you just go in a Guides began to acquire a solid understanding of database concepts & operations prior to deployment.

  jojsanto wrote:
  Hi Team,
  I have a premium partner who is an ATP on Data Center Unified Computing. He posted this question, hopefully you can help me provide resolution.
  I have questions about nexus 1KV design/implementation:
  -How migrate virtual switchs distint to vswitch0 (in each ESX server has 3 vswitches and the installation wizard of VMS only migrate vswicht0)?? for example others vswitchs with others vlan.. please tell me how...
  [Robert] After your initial installation you can easily migrate all VMs within the same vSwitch Port Group at the same time using the Network Migration Wizard.  Simply go to Home - Inventory - Networking, right click on the 1000v DVS and select "Migrate Virtual Machine Networking..."   Follow the wizard to select your Source (vSwitch Port Groups) & Destination DVS Port Profiles
  -With VUM (vmware update manager) is possible install VEM modules in ESX Servers ??? or must install VEM manually in each ESX Server?
  [Robert] As per the Getting Started & Installation guides, you can use either VUM or manual installation method for VEM software install.
  http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0_4_s_v_1_3/getting_started/configuration/guide/n1000v_gsg.html
  -Supposing of VUM install all VEM modules, the VEM version (vib package) is automatically compatible with build existen vmware version?
  [Robert] Yes.  Assuming VMware has added all the latest VEM software to their online repository, VUM will be able to pull down & install the correct one automatically.
  
  
  -is need to create PACKET-MANAGEMENT-CONTROL port groups in ALL esx servers before to migrate to Nexus 1000? or only VEM installation is enough???
  [Robert] If you're planning on keeping the 1000v VSM on vSwitches (rather than migrating itself to the 1000v) then you'll need the Control/Mgmt/Packet port groups on each host you ever plan on running/hosting the VSM on.  If you create the VSM port group on the 1000v DVS, then they will automatically exist on all hosts that are part of the DVS.
  -According to the Cisco manuals VSM can participate in VMOTION, but, how? .. what is the recommendation?..when the primary VMS is moving, the secondary VSM take control?? that occurs with connectivity in all virtual machines?
  [Robert] Since a VMotion does not really impact connectivity for a significant amount of time, the VSM can be easily VMotioned around even if its a single Standalone deployment.  Just like you can vMotion vCenter (which manages the actual task) you can also Vmotion a standalone or redundant VSM without problems.  No special considerations here other than usual VMotion pre-reqs.
  -When there two clusters in one vmware vcenter, how must install/configure VSM?
  [Robert] No different.  The only consideration that changes "how" you install a VSM is a vCenter with multiple DanaCenters. VEM hosts can only connect to a VSM that reside within the same DC.  Different clusters are not a problem.
  -For High Availability concepts, wich is the best choices of design of nexus? considering vmware features (FT,DRS, VMOTION, Cluster)
  [Robert] There are multiple "Best Practice" designs which discuss this in great detail.  I've attached a draft doc one on this thread. A public one will be available in the coming month. Some points to consider is that you do not need FT.  FT is still maturing, and since you can deploy redundany VSMs at no additional cost, there's no need for it.  For DRS you'll want to create a DRS Rule to avoid ever hosting the Primar & Secondary VSM on the same host.
  -How to migrate existent Kernel iSCSI port group to nexus? .. what are the steps? in cisco manual"Migration from VMware vSwitch to Cisco Nexus 1000V" show how to generate the port-profile, but
  
      how to create the iSCSI target? (ip address, user/password) ..where is it defined?
  [Robert] You can migrate any VMKernel port from vCenter by selecting a host, go to the Networking Configuration - DVS and select Manage Virtual Adapters - Migrate Existing Virtual Adapter. Then follow the wizard.  Before you do so, create the corresponding vEth Port Profile on your 1000v, assign appropriate VLAN etc.  All VMKernel IPs are set within vCenter, 1000v is Layer 2 only, we don't assign Layer 3 addresses to virtual ports (other than Mgmt).  All the rest of the iSCSI configuration is done via vCenter - Storage Adapters as usual (for Targets, CHAP Authentication etc)
  -Supposing of the licences of VEM is not enough for all ESX servers,, ¿will happen to the connectivity of your virtual machines in hosts without VEM licences? ¿can operate with vmware vswitches?
  [Robert] When a VEM comes online with the DVS, if there are not enough available licensses to license EVERY socket, the VEM will show as unlicensed.  Without a license, the virtual ports will not come up.  You should closely watch your licenses using the "show license usage" and "show license usage " for detailed allocation information.  At any time a VEM can still utilize a vSwitch - with or without 1000v licenses, assuming you still have adapters attached to the vSwitches as uplinks.
  I must install nexus 1000V in vmware plataform with VDI, with severals Servers ESX, with 3 vswitch on each ESX Server, with severals virtual machinne running, two clusters defined with vmotion and DRS active and central storage with iSCSI
  I have severals cisco manuals about nexus, but i see special focus in installations topics, the options for migrations is not extensive item, ¿do you have "success stories" or customers experiences of implementation with migrations with nexus?
  [Robert] Have a good look around the Nexus 1000v community Forum.   Lots of stories and information you may find helpful.
  Good luck!
  

• UCS environment vSphere 5.1 upgrade to vSphere 6 with Nexus 1000v

  Hi, I've faced trying to get the help of TAC and internet research on the way to upgrade to our UCS environment, and as a last thought resort, I would try a post on the forum.

  My environment is an environment of UCS chassis with double tracking, tissue of interconnections, years 1110 with pair HA of 1000v 5.1 running vsphere.  We have updated all our equipment (blades, series C and UCS Manager) for the supported versions of the firmware by CISCO for vSphere 6.

  We have even upgraded our Nexus 1000v 5.2 (1) SV3(1.5a) which is a support for vSphere version 6.

  To save us some treatment and cost of issuing permits and on our previous vcenter server performance was lacking and unreliable, I looked at the virtual migration on the vCenter 6 appliance.  There is nowhere where I can find information which advises on how to begin the process of upgrading VMWare on NGC when the 1000v is incorporated.  I would have thought that it is a virtual machine if you have all of your improved versions to support versions for 6 veil smooth.

  A response I got from TAC was that we had to move all of our VM on a standard switch to improve the vCenter, but given we are already on a supported the 1000v for vSphere version 6 that he left me confused, nor that I would get the opportunity to rework our environment being a hospital with this kind of downtime and outage windows for more than 200 machines.

  Can provide some tips, or anyone else has tried a similar upgrade path?

  Greetings.

  It seems that you have already upgraded your components N1k (are VEM upgraded to match?).

  Are your questions more info on how you upgrade/migration to a vcenter server to another?

  If you import your vcenter database to your new vcenter, it shouldn't have a lot of waste of time, as the VSM/VEM will always see the vcenter and N1k dVS.  If you change the vcenter server name/IP, but import the old vcenter DB, there are a few steps, you will need to ensure that the connection of VSM SVS corresponds to the new IP address in vcenter.

  If you try to create a new additional vcenter in parallel, then you will have problems of downtime as the name of port-profiles/network programming the guestVMs currently have will lose their 'support' info if you attempt to migrate, because you to NIC dVS standard or generic before the hosts for the new vcenter.

  If you are already on vcenter 6, I believe you can vmotion from one host to another and more profile vswitch/dVS/port used.

  Really need more detail on how to migrate from a vcenter for the VCA 6.0.

  Thank you

  Kirk...

• Remove the ' system VLAN "Nexus 1000V port-profile

  We have a Dell M1000e blade chassis with a number of Server Blade M605 ESXi 5.0 using the Nexus 1000V for networking.  We use 10 G Ethernet fabric B and C, for a total of 4 10 cards per server.  We do not use the NIC 1 G on A fabric.  We currently use a NIC of B and C fabrics for the traffic of the virtual machine and the other card NETWORK in each fabric for traffic management/vMotion/iSCSI VM.  We currently use iSCSI EqualLogic PS6010 arrays and have two configuration of port-groups with iSCSI connections (a physical NIC vmnic3 and a vmnic5 of NIC physical).

  We have added a unified EMC VNX 5300 table at our facility and we have configured three VLANs extra on our network - two for iSCSI and other for NFS configuration.  We've added added vEthernet port-profiles for the VLAN of new three, but when we added the new vmk # ports on some of the ESXi servers, they couldn't ping anything.   We got a deal of TAC with Cisco and it was determined that only a single port group with iSCSI connections can be bound to a physical uplink both.

  We decided that we would temporarily add the VLAN again to the list of VLANS allowed on the ports of trunk of physical switch currently only used for the traffic of the VM. We need to delete the new VLAN port ethernet-profile current but facing a problem.

  The Nexus 1000V current profile port that must be changed is:

  The DenverMgmtSanUplinks type ethernet port profile

  VMware-port group

  switchport mode trunk

  switchport trunk allowed vlan 2308-2306, 2311-2315

  passive auto channel-group mode

  no downtime

  System vlan 2308-2306, 2311-2315

  MGMT RISING SAN description

  enabled state

  We must remove the list ' system vlan "vlan 2313-2315 in order to remove them from the list" trunk switchport allowed vlan.

  However, when we try to do, we get an error about the port-profile is currently in use:

  vsm21a # conf t

  Enter configuration commands, one per line.  End with CNTL/Z.

  vsm21a (config) #-port ethernet type DenverMgmtSanUplinks profile

  vsm21a(config-port-Prof) # system vlan 2308-2306, 2311-2312

  ERROR: Cannot delete system VLAN, port-profile in use by Po2 interface

  We have 6 ESXi servers connected to this Nexus 1000V.  Originally they were MEC 3-8 but apparently when we made an update of the firmware, they had re - VEM 9-14 and the old 6 VEM and associates of the Channel ports, are orphans.

  By example, if we look at the port-channel 2 more in detail, we see orphans 3 VEM-related sound and it has no ports associated with it:

  Sho vsm21a(config-port-Prof) # run int port-channel 2

  ! Command: show running-config interface port-canal2

  ! Time: Thu Apr 26 18:59:06 2013

  version 4.2 (1) SV2 (1.1)

  interface port-canal2

  inherit port-profile DenverMgmtSanUplinks

  MEC 3

  vsm21a(config-port-Prof) # sho int port-channel 2

  port-canal2 is stopped (no operational member)

  Material: Port Channel, address: 0000.0000.0000 (bia 0000.0000.0000)

  MTU 1500 bytes, BW 100000 Kbit, DLY 10 usec,

  reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation ARPA

  Port mode is trunk

  Auto-duplex, 10 Gb/s

  Lighthouse is off

  Input stream control is turned off, output flow control is disabled

  Switchport monitor is off

  Members in this channel: Eth3/4, Eth3/6

  Final cleaning of "show interface" counters never

  102 interface resets

  We can probably remove the port-channel 2, but assumed that the error message on the port-profile in use is cascading on the other channel ports.  We can delete the other port-channel 4,6,8,10 orphans and 12 as they are associated with the orphan VEM, but we expect wil then also get errors on the channels of port 13,15,17,19,21 and 23 who are associated with the MEC assets.

  We are looking to see if there is an easy way to fix this on the MSM, or if we need to break one of the rising physical on each server, connect to a vSS or vDS and migrate all off us so the Nexus 1000V vmkernel ports can clean number VLAN.

  You will not be able to remove the VLAN from the system until nothing by using this port-profile. We are very protective of any vlan that is designated on the system command line vlan.

  You must clean the canals of old port and the old MEC. You can safely do 'no port-channel int' and "no vem" on devices which are no longer used.

  What you can do is to create a new port to link rising profile with the settings you want. Then invert the interfaces in the new port-profile. It is generally easier to create a new one then to attempt to clean and the old port-profile with control panel vlan.

  I would like to make the following steps.

  Create a new port-profile with the settings you want to

  Put the host in if possible maintenance mode

  Pick a network of former N1Kv eth port-profile card

  Add the network adapter in the new N1Kv eth port-profile

  Pull on the second NIC on the old port-profile of eth

  Add the second network card in the new port-profile

  You will get some duplicated packages, error messages, but it should work.

  The other option is to remove the N1Kv host and add it by using the new profile port eth.

  Another option is to leave it. Unless it's really bother you no VMs will be able to use these ports-profile unless you create a port veth profile on this VLAN.

  Louis

• Installation of Nexus 1000v / vCenter user privilege level

  Good afternoon

  I had a question about the necessary privilege concerning the installation of a Nexus 1000v.

  Last week, we install last version of the Nexus1000v on ESXi 5.0.0 Releasebuild-721882 switch.

  After a first installation, we noticed we could not establish the connection between the Nexus1000v and the vCenter [error = > the vCenter Extension key was not saved before use].

  The key was present on the Nexus 1000v but was not registered under the vCenter MOB (Extension Manager).

  We had to increase the privilege level of the service (to vCenter admin) account and re-install to get registred the extension key.

  Cisco said that we must use vCenter user with administrator-level privileges to install the Nexus 1000v, but please find my questions:

  1 / is it possible to install a Nexus 1000v with administrator privileges "Data center" (no admin vCenter). In general, what is the minimum level of privileges possible to install a Nexus 1000v?

  2 / once the privilege is passed to vCenter admin and the installation, it is possible to reduce to a privilege of lower level without affecting the Nexus 1000v?

  I'm a network guy, not a guy of sorry server if I'm unclear in my questions :-)

  Thanks in advance for your answers.

  Kind regards.

  Kara

  You cannot change the privilege level after the initial connection. He needs to remain at the same level of private.

  One of the things to keep in mind is that there is a constant back and forth between the MSM and vCenter. We are pulling and pushing data into vcenter. Every time a VM vmotions, gets turned on, destroyed or changed requires communication between the MSM and vCenter.

  Louis

• Nexus 1000v

  Hey guys,.

  Hope this is the right place to post.

  IM currently working on a design legacy to put in an ESXi 5 with Nexus 1000v solution and a back-end of a Cisco UCS 5180.

  I have a few questions to ask about what people do in the real world about this type of package upward:

  In oder to use the Nexus 1000v - should I vCenter?  The reason why I ask, is there no was included on the initial list of the Kit.  I would say to HA and vMotion virtual Center, but the clients wants to know if I can see what we have for now and licenses to implement vCenter at a later date.

  Ive done some reading about the Nexus 1000v as Ive never designed a soluton with that of before.  Cisco is recommended 2 VSM be implemented for redundancy.  Is this correct?  Do need me a license for each VSM?  I also suppose to meet this best practice I need HA and vMoton and, therefore, vCenter?

  The virtual machine for the VSM, can they sit inside the cluster?

  Thanks in advance for any help.

  In oder to use the Nexus 1000v - should I vCenter?

  Yes - the Nexus 1000v is a type of switch developed virtual and it requires vcenetr

  Ive done some reading about the Nexus 1000v as Ive never designed a soluton with that of before.  Cisco is recommended 2 VSM be implemented for redundancy.  Is this correct?  Do need me a license for each VSM?  I also suppose to meet this best practice I need HA and vMoton and, therefore, vCenter?

  I'm not sure the VSMs but yes HA and vMotion are required as part of best practices

  The virtual machine for the VSM, can they sit inside the cluster?

  Yes they cane xist within the cluster.

• Nexus 1000v and vSwitch best practices

  I am working on the design of our vDS Nexus 1000v for use on HP BL490 G6 servers. 8 natachasery is allocated as follows:

  vmnic0, 1: management of ESXi, VSM-CTRL-PKT, VSM - MGT

  vmnic2, 3: vMotion

  vmnic4, 5: iSCSI, FT, Clustering heartbeats

  vmnic6, 7: data server and Client VM traffic

  Should I migrate all the natachasery to 1000v vDS, or should I let vmnic 0.1 on a regular vSwitch and others migrate to the vDS? If I migrate all the natachasery at the very least I would designate vmnic 0.1 as system so that traffic could elapse until the MSM could be reached. My inclination is to migrate all the natachasery, but I've seen elsewhere on comments in forums that the VSM associated networks and, possibly, the console ESX (i) are better let off of the vDS.

  Thoughts?

  Here is a best practice-how-to guide specific to 1000v & VC HP might be useful.

  See you soon,.

  Robert

• Nexus 1000v - this config makes sense?

  Hello

  I started to deploy the Nexus 1000v at a 6 host cluster, all running vSphere 4.1 (vCenter and ESXi). The basic configuration, license etc. is already completed and so far no problem.

  My doubts are with respect to the actual creation of the uplink system, port-profiles, etc. Basically, I want to make sure I don't make any mistakes in the way that I want to put in place.

  My current setup for each host is like this with standard vSwitches:

  vSwitch0: 2 natachasery/active, with management and vMotion vmkernel ports.

  vSwitch1: natachasery 2/active, dedicated to a storage vmkernel port

  vSwitch2: 2 natachasery/active for the traffic of the virtual machine.

  I thought that translate to the Nexus 1000v as this:

  System-uplink1 with 2 natachasery where I'm putting the ports of vmk management and vMotion

  System-uplink2 with 2 natachasery for storage vmk

  System-uplink3 with 2 natachasery for the traffic of the virtual machine.

  These three system uplinks are global, right? Or I put up three rising system unique for each host? I thought that by making global rising 3 would make things a lot easier because if I change something in an uplink, it will be pushed to 6 guests.

  Also, I read somewhere that if I use 2 natachasery by uplink system, then I need to set up a channel of port on our physical switches?

  At the moment the VSM has 3 different VLAN for the management, control and packet, I want to migrate the groups of 3 ports on the standard switch to the n1kv itself.

  Also, when I migrated to N1Kv SVS management port, host complained that there no redundancy management, even if the uplink1 where mgmt-port profile is attached, has 2 natachasery added to it.

  While the guys do you think? In addition, any other best practices are much appreciated.

  Thanks in advance,

  Yes, uplink port-profiles are global.

  What you propose works with a warning. You cannot superimpose a vlan between these uplinks. So if your uplink management will use vlan 100 and your uplink of VM data must also use vlan 100 which will cause problems.

  Louis

• Restoration of Cisco Nexus 1000V - Host-ID fingerprint

  Someone find some information about how to restore a Cisco Nexus 1000V?

  The license is the result of a fingerprint of the identifier of the VSM. In case we lose the VM with VSM or host ESX Server must be reinstalled, this print is different. So that would mean the licensekey need, it's be regenerated.

  Has anyone found information on it?

  Tom

  Q: can you a VSM manage it's own VEM?

  R: Yes

  ...

  Can Q: you a VSM vMotion?

  A: we do not recommend it.

• What does Nexus 1000v Version number Say

  Can any body provide long Nexus 1000v version number, for example 5.2 (1) SV3 (1.15)

  And what does SV mean in the version number.

  Thank you

  SV is the abbreviation of "Swiched VMware"

  See below for a detailed explanation:

  http://www.Cisco.com/c/en/us/about/Security-Center/iOS-NX-OS-reference-g...

  The Cisco NX - OS dialing software

  Software Cisco NX - OS is a data-center-class operating system that provides a high thanks to a modular design availability. The Cisco NX - OS software is software-based Cisco MDS 9000 SAN - OS and it supports the Cisco Nexus series switch Cisco MDS 9000 series multilayer. The Cisco NX - OS software contains a boot kick image and an image of the system, the two images contain an identifier of major version, minor version identifier and a maintenance release identifier, and they may also contain an identifier of reconstruction, which can also be referred to as a Patch to support. (See Figure 6).

  Software NX - OS Cisco Nexus 7000 Series and MDS 9000 series switches use the numbering scheme that is illustrated in Figure 6.

  Figure 6. Switches of the series Cisco IOS dial for Cisco Nexus 7000 and MDS 9000 NX - OS

  

  For the other members of the family, software Cisco NX - OS uses a combination of systems independent of the platform and is dependent on the platform as shown in Figure 6a.

  Figure 6 a. software Cisco IOS NX - OS numbering for the link between 4000 and 5000 Series and Nexus 1000 switches virtual

  

  The indicator of the platform is N for switches of the 5000 series Nexus, E for the switches of the series 4000 Nexus and S for the Nexus 1000 series switches. In addition, Nexus 1000 virtual switch uses a designation of two letters platform where the second letter indicates the hypervisor vendor that the virtual switch is compatible with, for example V for VMware. Features there are patches in the platform-independent code and features are present in the version of the platform-dependent Figure 6 a above, there is place of bugs in the version of the software Cisco NX - OS 4.0(1a) are present in the version 4.0(1a) N1(1a).

• The Nexus 1000V loop prevention

  Hello

  I wonder if there is a mechanism that I can use to secure a network against the loop of L2 packed the side of vserver in Vmware with Nexus 1000V environment.

  I know, Nexus 1000V can prevent against the loop on the external links, but there is no information, there are features that can prevent against the loop caused by the bridge set up on the side of the OS on VMware virtual server.

  Thank you in advance for an answer.

  Concerning

  Lukas

  Hi Lukas.

  To avoid loops, the N1KV does not pass traffic between physical network cards and also, he silently down traffic between vNIC is the bridge by operating system.

  http://www.Cisco.com/en/us/prod/collateral/switches/ps9441/ps9902/guide_c07-556626.html#wp9000156

  We must not explicit configuration on N1KV.

  Padma

• Cisco Nexus 1000V Virtual Switch Module investment series in the Cisco Unified Computing System

  Hi all
  I read an article by Cisco entitled "Best practices in Deploying Cisco Nexus 1000V Switches Cisco UCS B and C Series series Cisco UCS Manager servers" http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/white_paper_c11-558242.html

  A lot of excellent information, but the section that intrigues me, has to do with the implementation of module of the VSM in the UCS. The article lists 4 options in order of preference, but does not provide details or the reasons underlying the recommendations. The options are the following:

  ============================================================================================================================================================
  Option 1: VSM external to the Cisco Unified Computing System on the Cisco Nexus 1010

  In this scenario, the virtual environment management operations is accomplished in a method identical to existing environments not virtualized. With multiple instances on the Nexus 1010 VSM, multiple vCenter data centers can be supported.
  ============================================================================================================================================================

  Option 2: VSM outside the Cisco Unified Computing System on the Cisco Nexus 1000V series MEC

  This model allows to centralize the management of virtual infrastructure, and proved to be very stable...
  ============================================================================================================================================================

  Option 3: VSM Outside the Cisco Unified Computing System on the VMware vSwitch

  This model allows to isolate managed devices, and it migrates to the model of the device of the unit of Services virtual Cisco Nexus 1010. A possible concern here is the management and the operational model of the network between the MSM and VEM devices links.
  ============================================================================================================================================================

  Option 4: VSM Inside the Cisco Unified Computing System on the VMware vSwitch

  This model was also stable in test deployments. A possible concern here is the management and the operational model of the network links between the MSM and VEM devices and switching infrastructure have doubles in your Cisco Unified Computing System.
  ============================================================================================================================================================

  As a beginner for both 100V Nexus and UCS, I hope someone can help me understand the configuration of these options and equally important to provide a more detailed explanation of each of the options and the resoning behind preferences (pro advantages and disadvantages).

  Thank you
  Pradeep

  No, they are different products. vASA will be a virtual version of our ASA device.

  ASA is a complete recommended firewall.

• Nexus 1000v, UCS, and Microsoft NETWORK load balancing

  Hi all

  I have a client that implements a new Exchange 2010 environment. They have an obligation to configure load balancing for Client Access servers. The environment consists of VMware vShpere running on top of Cisco UCS blades with the Nexus 1000v dvSwitch.

  Everything I've read so far indicates that I must do the following:

  1 configure MS in Multicast mode load balancing (by selecting the IGMP protocol option).

  2. create a static ARP entry for the address of virtual cluster on the router for the subnet of the server.

  3. (maybe) configure a static MAC table entry on the router for the subnet of the server.

  3. (maybe) to disable the IGMP snooping on the VLAN appropriate in the Nexus 1000v.

  My questions are:

  1. any person running successfully a similar configuration?

  2 are there missing steps in the list above, or I shouldn't do?

  3. If I am disabling the snooping IGMP on the Nexus 1000v should I also disable it on the fabric of UCS interconnections and router?

  Thanks a lot for your time,.

  Aaron

  Aaron,

  The steps above you are correct, you need steps 1-4 to operate correctly.  Normally people will create a VLAN separate to their interfaces NLB/subnet, to prevent floods mcast uncessisary frameworks within the network.

  To answer your questions

  (1) I saw multiple clients run this configuration

  (2) the steps you are correct

  (3) you can't toggle the on UCS IGMP snooping.  It is enabled by default and not a configurable option.  There is no need to change anything within the UCS regarding MS NLB with the above procedure.  FYI - the ability to disable/enable the snooping IGMP on UCS is scheduled for a next version 2.1.

  
  
  This is the correct method untill the time we have the option of configuring static multicast mac entries on
  
  the Nexus 1000v.  If this is a feature you'd like, please open a TAC case and request for bug CSCtb93725 to be linked to your SR.
  
  This will give more "push" to our develpment team to prioritize this request.
  Hopefully some other customers can share their experience.
  Regards,

  Robert