VMware: If a dedicated VNIC for Management/OAM is desired, add another vNIC of type vmxnet3. You must repeat the previous step, which is to click OK and then Edit Settings again so you can make a note of the vNIC MAC address. KVM: If a dedicated VNIC for Management/OAM is desired, make sure you have a libvirt network named oam-network. When the guest OS boots, it typically uses DHCP to get an IP address. VirtualBox will field this DHCP request and tell the guest OS its assigned IP address and the gateway address for routing outbound connections. In this mode, every vm is assigned the same IP address (10.0.2.15) because each vm thinks they are on their own isolated network. A port is a connection point for attaching a single device, such as the NIC of a server, to a network. The port also describes the associated network configuration, such as the MAC and IP addresses to be used on that port. VNICs have unique MAC addresses. To modify these addresses, use one of the following commands as appropriate to your specific circumstances: dladm modif-vnic -m mac-address vnic Use this command to assign a specific MAC address to a specific VNIC.
14 August 2012 Karim ElatovI was recently using the UCS Manager CLI and I wanted to share my findings. You can SSH to the UCSM (UCS Manager) and then run commands to figure out information about your hardware configuration. Whenever working with Cisco UCS Servers, the first thing we need to figure out is how Service Profiles are used in a UCS Environment. Cisco has an excellent article about this entitled “Cisco UCS Manager CLI Configuration Guide, Release 2.0”, I like their definition:
Service profiles are the central concept of Cisco UCS. Each service profile serves a specific purpose: ensuring that the associated server hardware has the configuration required to support the applications it will host.
Vnic Mac Addresses Manualquotesdigital Addresses
The service profile maintains configuration information about the server hardware, interfaces, fabricconnectivity, and server and network identity. This information is stored in a format that you can manage through Cisco UCS Manager. All service profiles are centrally managed and stored in a database on the fabric interconnect.
Every server must be associated with a service profile.
Service Profiles consist of Policies:
Policies determine how Cisco UCS components will act in specific circumstances. You can create multiple instances of most policies. For example, you might want different boot policies, so that some servers can PXE boot, some can SAN boot, and others can boot from local storage.
Policies allow separation of functions within the system. A subject matter expert can define policies that are used in a service profile, which is created by someone without that subject matter expertise. For example, a LAN administrator can create adapter policies and quality of service policies for the system. These policies can then be used in a service profile that is created by someone who has limited or no subject matter expertise with LAN administration.
You can create and use two types of policies in Cisco UCS Manager:
- Configuration policies that configure the servers and other components
- Operational policies that control certain management, monitoring, and access control functions
So first find out what is the name of the server that you are working with. You can either look at the UCSM Web Page or if you know the name of the server you can find out what chassis your blade is in. To see all the available servers you can do the following:
Each Server has a Service Profile Attached to it. I will be working with p2-b200-1 Service Profile, which corresponds to Chassis 1, Server 2. So let’s check out the HBAs that are available for this server:
We can see we have two HBAs on the server and their corresponding WWPNs. We can also check out the available NICs:
You can see that there are different MACs and WWPNs assigned for this server. To see the distinguished name of you adapters you can run the following:
The WWPNs and the MACs are assigned to the devices, this is actually defined in the pools. From the config guide:
Pools are collections of identities, or physical or logical resources, that are available in the system. All pools increase the flexibility of service profiles and allow you to centrally manage your system resources.
You can use pools to segment unconfigured servers or available ranges of server identity information into groupings that make sense for the data center. For example, if you create a pool of unconfigured servers with similar characteristics and include that pool in a service profile, you can use a policy to associate that service profile with an available, unconfigured server.
If you pool identifying information, such as MAC addresses, you can pre-assign ranges for servers that will host specific applications. For example, all database servers could be configured within the same range of MAC addresses, UUIDs, and WWNs.
To see what pool your vHBA belongs to, you can run the following:
You can see that vHBA1 (fc0) is from WWPN_Pod2_A and vHBA2 (fc1) is from WWPN_Pod2_B. To see a list of defined pools you can run the following:
We are using the bottom two. Just to see the pattern of the pool let’s check out one of them:
So our range is defined as follows; 20:00:00:25:B5:02:0A:00 to 20:00:00:25:B5:02:0A:02. To get a list of all the WWPNs assigned from this pool in a concise manner you can run the following:
You can check similar setting for the mac pools as well. If you have two IO Modules in the enclosure/chassis then you define two fabrics; a and b. We had two modules:
You can also check if the server is connected to both IOMs:
We can see our connection path is to A and B, both of our fabrics. For each Fabric we usually have a fabric-interconnect:
Usually you setup “pinning” to pin you HBAs and NICs to a certain IO module, for load balancing. From the Config Guide:
Pinning in Cisco UCS is only relevant to uplink ports. You can pin Ethernet or FCoE traffic from a givenserver to a specific uplink Ethernet port or uplink FC port.
When you pin the NIC and HBA of both physical and virtual servers to uplink ports, you give the fabricinterconnect greater control over the unified fabric. This control ensures more optimal utilization of uplink port bandwidth.
Cisco UCS uses pin groups to manage which NICs, vNICs, HBAs, and vHBAs are pinned to an uplink port. To configure pinning for a server, you can either assign a pin group directly, or include a pin group in a vNIC policy, and then add that vNIC policy to the service profile assigned to that server. All traffic from the vNIC or vHBA on the server travels through the I/O module to the same uplink port.
To check which HBA goes to which fabric we can run the following:
Each Fabric usually has a vSAN defined for it. To see the definition of each fabric we can check out the settings for each vHBA:
To check the NIC pinning we can run the following:
For each of the interfaces you can define a set of allowed VLANs, to see what they are you can run the following:
That is a list of allowed VLANs for that Nic.
To see how the physical ports correspond to the virtual ports on the Fabric Interconnect we can run the following:
So let’s connect to FI (Fabric Interconnect) A and see if we can confirm the virtual port of fc0 (remember the WWPN of that vHBA is the following 20:00:00:25:B5:02:0A:02). There are two ways to go about it. First we can find the interface our self and make sure it corresponds with 720:
That actually looks good, we see that it corresponds to vfc720 and it’s on vSAN 205. We can go further and make sure the config matches our server and the interface is up:
That all looks good and we can see that it’s actually bound to Vethernet8912, so let’s check out that interface to make sure it’s good:
We can see that the description matches our port “server 1/2, VHBA fc0” which is what we were trying to track down.
We can do a similar thing for eth0 (vNic1) as well.
The description fits and the appropriate VLANs are allowed.
We can also check out the local disk policy:
You can also check the boot order defined for the host:
We can see that the boot order is the following:
- CD-ROM
- Boot From SAN, first fc0 then fc1
- PXE Boot from eth0
If you want to see what WWPNs are used for the boot from SAN you can run the following:
Now we can see that we will connect to first “50:0A:09:83:8D:1F:72:B5” using fc0 and then to “50:0A:09:84:8D:1F:72:B5”. If that doesn’t work we will use fc1 to either connect to “50:0A:09:83:8D:1F:72:B5” or “50:0A:09:84:8D:1F:72:B5”. To see the available boot-order policies you can run the following:
Internet safetyslcsd educational technology resources internships. Then you can drill further down to see what the policy is made up of:
If I find any more interesting commands, I will definitely update this post.
More stuff I found, here is how you can check what LUNs an HBA is connecting to:
First list the available adapters on a blade:
Then Connect to the adapter and confirm the model and do the rest
Please enable JavaScript to view the comments powered by Disqus.blog comments powered by
Mac Addresses Lookup
Disqus