VSAN WWN

Similar Questions

• Problem with the integration of storage - suspicious on PALO adapters

  Hello

  I connect the UCS system storage with mds9124 between the two.

  So far, I joined 2 systems UCS, everything went smoothly.

  Now, the new system UCS arrived, it's the same as before, the only difference is that now we have PALO for the first time.

  Stanard configuration, service profiles, uplinks, etc and now I have a strange situation

  The MDS ports connected to ports of uplink CF on my 6120xp I don't see pwwn to my profile, only WWNs of ports uplink and vsan wwn connected service.

  NPIV is enabled of course, I tried to recreate the profiles to change wwpn-s pools, but no use UCS,... no configuration issues, the ports are on the rise, the associated service profiles... I'm really confused.

  I checked my setup with cisco guides ("design and deployment of a Cisco Unified Computing System SAN using MDS 9000 family switches Cisco"), but I don't see why it does not work.

  Any idea? In past configurations with MENLO adapters, everything went really good.

  Thank you

  It's the way palo works. You will see not Palo connect on the fabric until the drivers are loaded. In the case of SAN boot you need to create a specific boot strategy that assigns the logical unit number to the vhba and in this case, it is programmed and connection to the fabric for SAN boot.

  If you're just turn the blade and expecting Palo to connect on the fabric as a Menlo or Qlogic it won't do.

  Louis

• a valid wwn/wwwpn should have zero Yes

  Hi all

  In UCS of my lab I have this message 'WARNING no fatal config' whenever I make changes in a profile, but this is only happenning these past weeks... and I worked with the UCS since several months ago. Only suspect have triggered, important change is the recent upgrade to version 1.4 Balboa.

  Could someone help me on this?

  Thank you very much

  Dani,

  This warning is just advise that you use a correct value for the YES of the WWPN block part.  This could lead to problems with some SAN providers.

  When you create a pool, he suggested to follow the format of the industry and suggested using the prefix YES of Cisco.  Here's a breakdown of the WWN requirements.

  

  When you create a new WWN pool, suggested in the entry screen.

  

  Your pool WWPN is 20:00:00:00:00:DB:01.

  If you change your pool WWPN to match this recommendation, the alert will stop. As suggested by the caveat, it can be run in subsequent revisions of software.  Better to change it sooner than later.

  Kind regards

  Robert

• Global vs FIC VSAN specific on NGC

  What is the difference and therefore the impact of the creation of a global VSAN (VSAN noticeable to both fabric interconnect) rather than creating a VSAN FIC - A and FIC - B-specific?

  I create Global and then assign one to vHBA - a FIC - A and the other to vHBA-b on FIC - B.

  Also, with the FC Switching (UCS 1.4) this (set) get worse?

  Aida,.

  This comes down to design.  Most people like to keep their completely separate SAN fabrics.  Unlike in the passage where the uplinks are crisscrossed every way imaginable for redundancy, in the CF world, that's all that separates your fabrics.  For this you would normally connect a FI to a single switch SAN (fabric-A) upstream and the other END to their other (fabric (B).  You would create the VSAN on the fabric of interconnection rather than overall as you do not need two available on the two FI VSANS.

  Another approach is to create in the world, but in this design, need you either a link between each FI and SAN EACH switch or use VSAN circuits (assuming the two VSANS exists on both the SAN upstream switches). The complication here is when you set your vHBAs, you must assign them to a VSAN on A or b.  It is a hard hairpin and offers benefits without hot spare. There is no failover with CF as there is for the Ethernet (aka Fabric Failover).  All CF redundancy is managed at the level of the BONE by multipathing drivers.

  The first design keeps your CF much more simple and deterministic access.  You know that all vHBAs connected to the fabric Interconnect-A go to VSAN X, and all the vHBAs related to the fabric Interconnect-B go to VSAN Y.  This is assuming that you're only using two VSANS for your environment.

  The only time wherever you need FC switch mode is if you plan use direct attach FC/FCoE tables with your interconnections.  There is no increase in complexity here regarding the VSAN design, same best practices apply.

  Kind regards

  Robert

• ID OF THE VSAN UCS

  Hello

  I have a small question on the VSAN ID and hope you guys have an answer for that.

  When you create a VSAN in UCS FI, ability I use the same VSAN ID created in the MDS switch upstream or can I use a different ID?

  See you soon,.

  Kisanka

  Yes, the VSAn Id should be the same as the MDS upstream.

  . / Afonso

• trunk VSAN 6248 uplink interface

  Hi all

  I'm new to the UCS platform,

  I want to master multiple VSANs in FI 6248 on the single interface / portchannel. to 5548 upstream switch. Since the location of different heterogeneous storage 2.

  Ask let me know opportunities, configurations or any recommendations are available for configuring it.

  Hello Christine,.

  You can enable port FC port trunking and create port channels for FI of UCSM CF (SAN tab > SAN clouod).

  On N5K, you must enable fport-channel-trunk feature and create CF port-channel.

  Padma

• VSAN, MDS, areas... and many doubs

  Hello

  After reading lots of documentation, I'm very confuse and it is very difficult for me to do a picture in my head of how this work.

  For example. I have a table of storage, 2 MDS 9148 and 3 servings (independent, no blades) with 2 HBAS each. Each HBA has 2fc ports of 8G each.

  So on the final configuration, each server will have own OS ESX and virtual machines, all within the storage Bay (serves him didn't have HDs).

  Topology of connection: I have 2 MDS for redundancy. So I guess that's Connect ports FC 2 (combination mode) from the server to each MDS switch. But what I need to connect 2 MDS using an ISL trunk?

  Design VSAN. VSAN is as VLAN but what are the criteria that I should follow to assign VSAN? A VSAN by ESX and the other by virtual machines. Or a VSAN by MDS switch, server...

  Area, pwwn and nwwn: if I understand correctly. nwwn is the address of my adapter HBA and the MDS and the pwwn is an address of each port on the HBA and SDM.  But dissing the areas, what are the criteria?

  And finally. The Vswitch on the sphere and on the storage array logical unit number. they have their own pwwn? Can I assign them to areas?

  Thank you very much.

  Best regards

  Check figure 4 of the

  http://www.Cisco.com/c/en/us/products/collateral/interfaces-modules/Stor...

  you do not have a core - edge, but only the kernel.

  All devices, storage and ESXi hosts have two hosted this 9148 2.

  NO ISL links between the 2 MDS. The CF philosophy is double fabric, A and B.

  You create 2 separate VSANS, for example 10 to fabric and 20 for fabric B.

  Zoning is directed by VSAN.

  Single initiator - single target areas: port hba - storage controller port pwwn pwwn.

  Your ESXi will then discover the FC LUNs.

  VM can't see CF, they see peripheral scsi (RDM is an exception).

  CF Multipathing driver may be installed on the host allowing failover and load balancing.

  See, for example.
  http://www.Cisco.com/c/en/us/TD/docs/solutions/Enterprise/Data_Center/VM...

• YES for the WWN and Mac

  When I create pools of wwn and Mac for a service profile template, is there a block of addresses that start with a YES that are specific to UCS?  In this guide: http://www.ciscosystems.sc/en/US/products/ps10281/products_configuration_example09186a0080af7515.shtml, I see a trick in the window of this picture: http://www.cisco.com/image/gif/paws/110297/create-sp-ucsblade-11.gif that specifies the use of the prefix 20:00:00:25:B5:xx:xx:xx will ensure uniquiness in WWN name, but when I'm in the same screen on our UCS, I don't see this trick.  The same goes for MACs, there at - it a block with certain values that I should start with?  The MAC of the guide section shows 02:25:B5:00:00:00 in the configuration window: http://www.cisco.com/image/gif/paws/110297/create-sp-ucsblade-09.gif but it is this unique UCS?

  Thank you.

  For the MACs Cisco recorded the program YES 00: 25:b5 the last three bytes are to you. You can either some arbitrary numbers of makeup or you can put a logic behind it. Here's what I recommend for MACs.

  • Create two clusters of MAC; one for the fabric and the other for fabric B
  • For the last three bytes, use the first for the site/cluster and the other for fabric or B. Example site 1, group 1 and fabric would be this 00:25:b5:11:a0:00 and go up from there. Fabric B would be this 00:25:b5:11:b0:00 and this 00:25:b5:12:a0:00 cluster 2.

  For the WWNNs and the WWPN, you want three pools; one for the node WWN and two for the port WWN (vHBA).

  Same concept here for the WWNNs use something like 20:11:00:25:b5:00:00:00 for the site 1 cluster 1 and 20:12:00:25:B5:00:00:00 for cluster 1 2 site.

  For the WWPN pools do one for fabric and a fabric b like this

  • Fabric of the 1 Group 1 site - 20:00:00:25:b5:11:aa:00
  • Fabric B 1 Group 1 - 20:00:00:25:b5:11:bb:00 of the site

  By creating pools MAC and WWPN for each tissue, you can easily identify what fabric on a MAC or WWN comes when you look at the MAC table on a switch or what zoning, you can easily select WWN. might be useful when troubleshooting as well.

• VSAN membership down on the CF mapped uplink port

  Hello

  Since I upgrade Cisco UCS Manager, all frame and fabric of interconnections of version 2.2 (1), I have a few minor flaws.

  I configure ports 31 and 32 as FC uplink ports and mapped each port to a vsan:

  Port 31 = VSAN 'blue '.

  32 port = "red" VSAN

  (I know, it is not common to map two different VSAN to the same fabric, but I have to)

  Since the update, I get minor flaws:

  31--> FCoE or FC uplink port is broken on 'red' VSAN / membership-down

  32--> FCoE or FC uplink port is broken on 'blue' VSAN / membership-down

  I have no channels of port FC or FC enabled link mode. Interconnection of fabric is EHM.

  Even in other tissues.

  Can anyone help me or is it the same cosmetic problem as stated in the quote?

  FCoE Uplink vsan membership fault for any vsan not configured upstream Symptom:
  
  Fabric Vsan Membership Down fault message on FCoE uplink ports
  Severity: Major
  Code: F1083
  Name: Fabric Vsan Membership Down
  Conditions:
  Observed with UCSM 2.1 and when FCoE uplink port is configured on the Fabric Interconnect
  Workaround:
  None.Error message is cosmetic.
  

  Thanks in advance

  / Danny

  Hello Danny,

  Yes, it is a cosmetic issue in UCSM 2.2.1

  the question is followed by

  https://Tools.Cisco.com/bugsearch/bug/ CSCum89468

  The one that you cited ( CSCud81857 ) is specific to the rising FI FCoE in version 2.1 of UCSM.

  HTH

  Padma

• FCoE uplink is down on vsan

  Hello, I have a problem connecting nexus switches in the fabric of the interconnections.

  I created of vsan, vlan mappings of vsan unified uplinks, vfc interfaces on nexus, but I still see this flaw in the registry.

  Models of HBA and HBA is created.

  I have 2 5548up nexus switches connected to the UCS 6324 FI.

  I hope your 500 vsan has FC zoning "disabled".

  Before you setup zoning, your blades won't see any logical unit number.

  Make the zoning on the N5k, and activation areas will repel the active zone to FI information.

• Different VSAN on different PO.

  Hi, just to confirm, is this a valid design have a CF port-channel on the UCS carrying different VSANS?

  Yes, you can have separate FC port channels carrying VSAN separated and it is a good design, if you have enough resources for the same. Otherwise, you can even have only one FC port channel carrying VSAN multiple using trunking channel for the port f as long as your SAN switch supports.

• Help - profile change Service models and policies without changing the existing MAC or WWN vNIC and vHBAs

  Hello

  I would like to know if there is a way to preserve existing vNIC MACs and WWN vHBA if I change the model of a Service profile?

  To clarify, our Service profiles have been created since an initial model, and now we'd like as these Service profiles to point to a - model - update to simplify management.

  Initial-template originally provided manually created vNIC and vHBAs and used no LAN or SAN connectivity political, but the new updated model made.

  VNIC names and vHBA names, as well as the MAC and WWN used in connectivity pools policies update-model are the same as those currently used by the Service profiles.

  To rephrase the question:
  Is it possible to change initial-model a Service profile to a template update with essentially the same everything, without changing the UUID currently in use MACs of the profile Service, WWN and perhaps?
  If the answer is that they are not the same when this happens, then someone know of any workaround?

  Thanks for your help!

  RR

  Hi RR

  With respect to the Central of the UCS and sequential allocation:

  https://supportforums.Cisco.com/discussion/12006286/UCS-Central-sequenti...

  http://www.Cisco.com/c/en/us/TD/docs/unified_computing/UCS/release/notes...
  New features in version 1.1(2a)
   
  Allocation of ID sequential for pools, such as addresses MAC, WWN, IP and UUID

  The procedure I would use:

  -Create the update model

  -remove the link 1. Initial model EP

  -delete this 1. SP (this helps to release all the values in the pool)

  -create new MS to model update (it will inherit above pool values)

  -Repeat for all AOCS

  I did this several times without problem (for example, no need to change the zoning of FC). Of course it is disruptive, by blade and SP.

  Don't know if this unbind / bind procedure works without reserves.

  See you soon

  Walter.

• Minor Vsan warning

  Hello world

  I have an error in my domain UCS - M name is my VSAN is out of service. Any idea of what is the cause?

  Thank you

  Hi Jeff,

  Walter, a photograph would be extremely useful to restrict your question. However, if the error you receive is a minor alert the bug that you run is;

  https://Tools.Cisco.com/bugsearch/bug/CSCuj71400/?reffering_site=dumpcr

  In the workaround in the bug, you can check if it is indeed the bug. If the alert is not a minor warning and not the bug listed please include a picture of the error message, so we can gather a better understanding of your issue.

  Kind regards

  Qiese Sa'di

• Question of design around VSAN

  We left the Nexus 5 K for our CF to switching to start our UCS blades. I wonder what the best design is for the following situation.

  Active / Active NetApp HA pair.

  FC 2 ports target of each head of NetApp in the HA pair to the SAN (Nexus 5 K in our case) switches.

  1 port of each head of NetApp to each of the 5010 s nexus.

  Should I 1 VSAN on each 5010 with each head of NetApp in there or should I have 1 common VSAN between the 5010 s?

  Any comments on this would be appreciated.

  A recommended good is to use different numbering on each fabric VSAN.

  Fabric (or 1) odd numbered VSAN use (3, 5, etc.)

  Fabric B (or 2) use even mumbered VSAN (2, 4, etc.)

  It provides a visual cue for the operator to let them know what fabric, they make changes. In addition, in the case of inadvertence ISL to connect between the two fabrics that you merge your A and B fabric zonesets (I saw it happen). Do not "put any active trading in VSAN 1 for the same reason.

• VMkernel for VSANs

  Hello

  I have a question about Vsan

  1 can. 1 vcenter cause 2 vsan cluster? Each vsan cluster will have its own separate cluster by cluster (in VMware vCenter).

  2. for clusters VSAN, they will use same physical switch uplink. How can we separate these clusters? Is - this same correct range of IP addresses with the same multicast address? or we have to separate the IP address range and the multicast address?

  I use vSAN 6.2.

  Thank you.

  Hi, to comment further on your second question, if you have multiple clusters VSAN, best practices is to provide these more separate network segments (say, different VLAN). I'm not sure what you mean by "same multicast address"; each VSAN node performs the multicast, so all vmkernels VSAN are multicast addresses.

  For more help with this kind of considerations, please consult the Virtual SAN 6.2 Networking Design Guide.