ESXi 5 and Nexus 1000v

Similar Questions

• VM - FEX and Nexus 1000v relationship

  Hello

  I'm new in the world of virtulaization and I need to know what the relationship between Cisco Nexus 1000v and Cisco VM - FEX? and when to use VM - FEX and when to use Nexus 1000v.

  Concerning

  Ahmed,

  Nexus 1000v is a Distributed Switch that allows you to manage your VEM, see this relationship as a supervisor-LineCard relationship.

  VM - FEX gives you the opportunity to bypass the vSwitch embarked on each host ESXi (VEM) for example.

  With VM - FEX, you see the virtual machines as if they were directly connected to the Parent switch (N7K / 5K for example), making it the parent spend management (cause there is more no vSwitch in the middle).

  This is a good topic that can be discussed and is difficult to summarize in a few lines, you read something in particular? any questions or doubts we can help clarify?

  -Kenny

• How change 1010 Nexus and Nexus 1000v IP address

  Hi Experts,

  We run two VSM and a NAM in the Nexus 1010. The version of Nexus 1010 is 4.2.1.SP1.4. And the Nexus 1000v version is 4.0.4.SV1.3c. Now we need to change the IP address of management in the other. Where can I find the model SOP or config? And nothing I need to remember?

  If it is only the mgmt0 you IP address change, you can simply enter the new address under the mgmt0 interface. It automatically syncs with the VC.

  I guess you are trying to change the IP address of the VC and the management VLAN. One way to do this is:

  -From the Nexus 1000v, disconnect the connection to the VC (connection svs-> without logging)

  -Change the IP address of the VC and connect (connection-> remote ip address svs)

  -Change the address for mgmt0 Nexus 1000v

  -Change the mgmt VLAN on the 1010

  -Change the address of the 1010 mgmt

  -Reconnect the Nexus 1000v to VC (connection-> connect svs)

  Therefore, to change the configuration of VLANS on the switch upstream, more connection to the VC as well.

  Thank you

  Shankar

• vCenter Converter support for dvSwitch and Nexus 1000v

  Nothing changed since it was published in May 2009:

  http://www.VMware.com/support/vSphere4/doc/vsp_vcc_41_rel_notes.html

  VMware vCenter Converter vCenter Server 4.0 | May 21, 2009 | Build 161418

  Document last updated: May 21, 2009

  Import and export tasks fail when a vNetwork Distributed Switch is selected as the network for the virtual machine target

  When you create an import or export tasks and select a vNetwork Distributed Switch in the choice of the network for the virtual machine target, the task begins but does not immediately with the following error message: unknown error returned from agent vCenter Converter. This problem appears when you use the wizards to import or export or the convert Command Line Interface (CLI) tool to create the task.

  Solution: Select a network to the computer virtual target that is not a vNetwork Distributed Switch.

  We had this problem a few weeks back and see how this problem exists since last year, vCenter 4.0 Update 1 or 2 this address?  Thank you.

  Hi Terran0925,

  According to the "Known issues" section in the release notes for "VMware vCenter Converter vCenter Server 4.0 Update 1 | November 19, 2009 | Build 206170 "to http://www.vmware.com/support/vsphere4/doc/vsp_vcc_41u1_rel_notes.html#resolvedissues , the question was always present.

  There is no mention of the issue on the VMware vCenter Converter vCenter Server 4.1 release notes. The release notes can be found at http://www.vmware.com/support/vsphere4/doc/vsp_vcc_42_rel_notes.html

  The details of this version are;

  VMware vCenter Converter 4.2 | July 13, 2010 | Generation 254483

  vCenter Server 4.1 | July 13, 2010 | Build 258902

  Note: in order to get this version of VMware vCenter Converter vCenter Server, you must upgrade your vCenter server for "vCenter Server 4.1 | July 13, 2010 | Build 258902.

  I hope this helps.

  Kind regards

  Graham Daly

  Champion of knowledge

  VMware Inc.

• 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.

• VXLAN on UCS: IGMP with Catalyst 3750, 5548 Nexus, Nexus 1000V

  Hello team,

  My lab consists of Catalyst 3750 with SVI acting as the router, 5548 Nexus in the vpc Setup, UCS in end-host Mode and Nexus 1000V with segmentation feature enabled (VXLAN).

  I have two different VLAN for VXLAN (140, 141) to demonstrate connectivity across the L3.

  VMKernel on VLAN 140 guests join the multicast fine group.

  Hosts with VMKernel on 141 VLAN do not join the multicast group.  Then, VMs on these hosts cannot virtual computers ping hosts on the local network VIRTUAL 140, and they can't even ping each other.

  I turned on debug ip igmp on the L3 Switch, and the result indicates a timeout when he is waiting for a report from 141 VLAN:

  15 Oct 08:57:34.201: IGMP (0): send requests General v2 on Vlan140

  15 Oct 08:57:34.201: IGMP (0): set the report interval to 3.6 seconds for 224.0.1.40 on Vlan140

  15 Oct 08:57:36.886: IGMP (0): receipt v2 report on 172.16.66.2 to 239.1.1.1 Vlan140

  15 Oct 08:57:36.886: IGMP (0): group record received for group 239.1.1.1, mode 2 from 172.16.66.2 to 0 sources

  15 Oct 08:57:36.886: IGMP (0): update EXCLUDE group 239.1.1.1 timer

  15 Oct 08:57:36.886: IGMP (0): add/update Vlan140 MRT for (*, 239.1.1.1) 0

  15 Oct 08:57:38.270: IGMP (0): send report v2 for 224.0.1.40 on Vlan140

  15 Oct 08:57:38.270: IGMP (0): receipt v2 report on Vlan140 of 172.16.66.1 for 224.0.1.40

  15 Oct 08:57:38.270: IGMP (0): group record received for group 224.0.1.40, mode 2 from 172.16.66.1 to 0 sources

  15 Oct 08:57:38.270: IGMP (0): update EXCLUDE timer group for 224.0.1.40

  15 Oct 08:57:38.270: IGMP (0): add/update Vlan140 MRT for (*, 224.0.1.40) by 0

  15 Oct 08:57:51.464: IGMP (0): send requests General v2 on Vlan141<----- it="" just="" hangs="" here="" until="" timeout="" and="" goes="" back="" to="">

  15 Oct 08:58:35.107: IGMP (0): send requests General v2 on Vlan140

  15 Oct 08:58:35.107: IGMP (0): set the report interval to 0.3 seconds for 224.0.1.40 on Vlan140

  15 Oct 08:58:35.686: IGMP (0): receipt v2 report on 172.16.66.2 to 239.1.1.1 Vlan140

  15 Oct 08:58:35.686: IGMP (0): group record received for group 239.1.1.1, mode 2 from 172.16.66.2 to 0 sources

  15 Oct 08:58:35.686: IGMP (0): update EXCLUDE group 239.1.1.1 timer

  15 Oct 08:58:35.686: IGMP (0): add/update Vlan140 MRT for (*, 239.1.1.1) 0

  If I do a show ip igmp interface, I get the report that there is no joins for vlan 141:

  Vlan140 is up, line protocol is up

  The Internet address is 172.16.66.1/26

  IGMP is enabled on the interface

  Current version of IGMP host is 2

  Current version of IGMP router is 2

  The IGMP query interval is 60 seconds

  Configured IGMP queries interval is 60 seconds

  IGMP querier timeout is 120 seconds

  Configured IGMP querier timeout is 120 seconds

  Query response time is 10 seconds max IGMP

  Number of queries last member is 2

  Last member query response interval is 1000 ms

  Access group incoming IGMP is not defined

  IGMP activity: 2 joints, 0 leaves

  Multicast routing is enabled on the interface

  Threshold multicast TTL is 0

  Multicast designated router (DR) is 172.16.66.1 (this system)

  IGMP querying router is 172.16.66.1 (this system)

  Multicast groups joined by this system (number of users):

  224.0.1.40 (1)

  Vlan141 is up, line protocol is up

  The Internet address is 172.16.66.65/26

  IGMP is enabled on the interface

  Current version of IGMP host is 2

  Current version of IGMP router is 2

  The IGMP query interval is 60 seconds

  Configured IGMP queries interval is 60 seconds

  IGMP querier timeout is 120 seconds

  Configured IGMP querier timeout is 120 seconds

  Query response time is 10 seconds max IGMP

  Number of queries last member is 2

  Last member query response interval is 1000 ms

  Access group incoming IGMP is not defined

  IGMP activity: 0 joins, 0 leaves

  Multicast routing is enabled on the interface

  Threshold multicast TTL is 0

  Multicast designated router (DR) is 172.16.66.65 (this system)

  IGMP querying router is 172.16.66.65 (this system)

  No group multicast joined by this system

  Is there a way to check why the hosts on 141 VLAN are joined not successfully?  port-profile on the 1000V configuration of vlan 140 and vlan 141 rising and vmkernel are identical, except for the different numbers vlan.

  Thank you

  Trevor

  Hi Trevor,

  Once the quick thing to check would be the config igmp for both VLAN.

  where did you configure the interrogator for the vlan 140 and 141?

  are there changes in transport VXLAN crossing routers? If so you would need routing multicast enabled.

  Thank you!

  . / Afonso

• Question about license for Nexus 1000v and it time to stand not licensed ESXi

  Hello

  I have the license for 12 cpu that are 3 popular ESXi with 4 processors each

  so if I add an another ESXi, which will support 60 days

  I'm pretty sure but wanted confirmation

  Thank you

  What version do you use? 2.1 they went to a model free and advanced, depending on the features you need, you can be able to upgrade and continue without additional licenses.

  No doubt, you can convert your current license VSG, contact your engineer.

  http://blogs.Cisco.com/tag/nexus-1000V/

• 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

• How to check and confirm the Nexus 1000V secondary work if primary goes off

  Hello

  I installed Nexus 1000V Primarry and secondary on different ESXis

  but I have to turn off the primary, how to ensure that the school will be in charge and usually have any disconnection

  the module displays them and seem to be ok

  any other checks to do before continuing?

  Thank you

  Use "show system redundancy status. You can also manually failover

  http://www.Cisco.com/en/us/docs/switches/Datacenter/nexus1000/SW/4_2_1_s_v_1_4/high_availability/configuration/guide/n1000v_ha_3system.html

  The output from the example:

  n1000v# show system redundancy status
  

  Redundancy role
  ---------------
  administrative: primary
  operational: primary
  

  Redundancy mode
  ---------------
  administrative: HA
  operational: HA

  This supervisor (sup-1)
  -----------------------
  Redundancy state: Active
  Supervisor state: Active
  Internal state: Active with HA standby
  

  Another supervisor (sup-2)

  ------------------------
  Redundancy state: Standby
  Supervisor state: HA standby
  Internal state: HA standby
  

• 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, 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

• Nexus 1000v and vmkernel ports

  What is the best practice to put on the nexus 1000v vmkernel ports? Is it a good idea to put all the ports of vms and vmkernel on nexus 1000v? switch or dvs or some vmkernel as management ports must be on a standard?  If something happens to the 1000v, all management and vms will be unreachable.

  any tips?

  Yep, that's correct. Port system profiles don't require any communication between the MEC and VSM.

• Replacement of failing on Nexus 1000v VEM

  I was curious how others accomplish the replacement of a failed ESXi host who is an on the Nexus 1000v VEM. I did this procedure once and it seemed endless. The goal is to make the swap of the transparent to the Nexus 1000v (VEM even #, just different VMware UUID)

  -Transition to the standard vSwitches home

  -Remove the switch distributed via vCenter host (host of right click and delete)

  -Swap physically on the chassis

  -Find the UUID for new host (got esxcfg-info)

  -Install new MEC in the 1000v with this UUID

  -Host of replacement over 1000v that assumes the number of Vincent who was installed just to migrate

  Ben,

  Note - 1000v in relationship issues are better posted in the «Server network» forum  This forum is specific to the UCS.

  https://supportforums.Cisco.com/community/NetPro/data-center/server-network?view=discussions

  The procedure that you use is the right.  Another method is to remove the host of 1000v with elegance, then issue a 'no vem X"that removes the MEC does record from the MSM.  Exchange your hosts, then add back to the 1000v.  Is there a reason that you need the same UUID?

  Kind regards

  Robert

• Nexus 1000v VSM compatibility with older versions of VEM?

  Hello everyone.

  I would like to upgrade our Nexus 1000v VSM 4.2 (1) SV1 (5.1) to 4.2 (1) SV2(2.1a) because we are heading of ESXi 5.0 update 3 to 5.5 ESXi in the near future. I was not able to find a list of compatibility for the new version when it comes to versions VEM, I was wondering if the new VSM supports older versions VEM, we are running, so I must not be upgraded all at once. I know that it supports two versions of our ESXi.

  Best regards

  Pete

  You found documentation, transfer of the station from 1.5 to latest code is supported in a VSM perspective.  Which is not documented is the small one on the MEC.  In general, the VSM is backward compatible with the old VEM (to a degree, the degree of which is not published).  Although it is not documented (AFAIK), verbal comprehension is that MEC can be a version or two behind, but you should try to minimize the time that you run in this configuration.

  If you plan to run mixed versions VEM when getting your upgraded hosts (totally fine that's how I do mine), it is better to move to this enhanced version of VEM as you upgrade the hypervisor.  Since you go ESXi 5.0 5.5, you create an ISO that contains the Cisco VIBs, your favorite driver async (if any), and the image of ESXi 5.5 all grouped together so the upgrade for a given host is all of a sudden.  You probably already have this cold technique, but the links generated by the Cisco tool below will show you how to proceed.  It also gives some URLS handy to share with each person performing functions on this upgrade.  Here is the link:

  Nexus 1000V and ESX upgrade utility

  PS - the new thing takes clones your VSMs offline.  Even if they are fairly easy to recover, having a real pure clone will save some sauce secret that otherwise you may lose in a failure scenario.  Just turn off a VSM, then right click and clone.  Turn on again this MSM and failover pair HA, then take to the bottom of it and get a clone of it.  So as a security measure, this upgrade, get your clones currently out of the current 1.5 VSMs, then some time after your upgrade some clones offline, saved from the new version.

• Change the maximum number of ports on Nexus 1000v vDS online with no distribution?

  Hello

  Change the maximum number of ports on Nexus 1000v vDS online with no distribution?

  
  

  I'm sure that's what the link

  VMware KB: Increase in the maximum number of vNetwork Distributed Switch (vDS) ports in vSphere 4.x

  not to say that

  I have 5.1 ESXi and vcenter

  Thank you
  Saami

  There is no downtime when you change quantity "vmware max-ports" a port profile. It can be done during production.

  You can also create a new profile of port with a test of the virtual machine and change the "vmware max-ports' If you want warm and ferrets.