When upgrading UCS firmware, it’s important to periodically check the state of the HA clustering service running between the two Fabric Interconnects. The infrastructure portions of UCS are generally redundant due to these two FIs but only if the clustering service has converged - so it’s important to use the “show cluster state” command to verify this is the case. During a firmware upgrade to 2.2(1b), I checked this:
6296FAB-A# connect local-mgmt 6296FAB-A(local-mgmt)# show cluster state Cluster Id: 8048cd6e-5d54-11e3-b36c-002a6a499d04 Unable to communicate with UCSM controller The error message - “unable to communicate with UCSM controller” worried me, and it was given when I ran the “show cluster state” command as well as the “cluster lead” command - the latter of which is necessary to switch an FI’s role in the cluster from subordinate to primary.
When upgrading UCS firmware, it’s important to periodically check the state of the HA clustering service running between the two Fabric Interconnects. The infrastructure portions of UCS are generally redundant due to these two FIs but only if the clustering service has converged - so it’s important to use the “show cluster state” command to verify this is the case. During a firmware upgrade to 2.2(1b), I checked this:
6296FAB-A# connect local-mgmt 6296FAB-A(local-mgmt)# show cluster state Cluster Id: 8048cd6e-5d54-11e3-b36c-002a6a499d04 Unable to communicate with UCSM controller The error message - “unable to communicate with UCSM controller” worried me, and it was given when I ran the “show cluster state” command as well as the “cluster lead” command - the latter of which is necessary to switch an FI’s role in the cluster from subordinate to primary.
One of the (sadly numerous) issues I’ve run into while upgrading to Cisco UCSM version 2.2(1b) is this little error message indicating that a service failed to start:
This gives us an error code of F0867 and it’s letting us know that the UCSM process httpd_cimc.sh failed on one of our Fabric Interconnects.
For those that don’t know, you can get a list of processes within UCSM by connecting to local management and running “show pmon state”.
One of the (sadly numerous) issues I’ve run into while upgrading to Cisco UCSM version 2.2(1b) is this little error message indicating that a service failed to start:
This gives us an error code of F0867 and it’s letting us know that the UCSM process httpd_cimc.sh failed on one of our Fabric Interconnects.
For those that don’t know, you can get a list of processes within UCSM by connecting to local management and running “show pmon state”.
One of the (sadly numerous) issues I’ve run into while upgrading to Cisco UCSM version 2.2(1b) is this little error message indicating that a service failed to start:
This gives us an error code of F0867 and it’s letting us know that the UCSM process httpd_cimc.sh failed on one of our Fabric Interconnects.
For those that don’t know, you can get a list of processes within UCSM by connecting to local management and running “show pmon state”.
When making the leap to adopting FCoE as a storage medium, there are a few things to consider in order to be successful. Many of these concepts are foreign to the storage administrator who has been operating a native Fibre Channel SAN for the better part of the last decade or more - this is because while Fibre Channel networks are costly, they are purpose-built. There is no concept of a loop in Fibre Channel - with Ethernet we deal with these all the time.
When making the leap to adopting FCoE as a storage medium, there are a few things to consider in order to be successful. Many of these concepts are foreign to the storage administrator who has been operating a native Fibre Channel SAN for the better part of the last decade or more - this is because while Fibre Channel networks are costly, they are purpose-built. There is no concept of a loop in Fibre Channel - with Ethernet we deal with these all the time.
When making the leap to adopting FCoE as a storage medium, there are a few things to consider in order to be successful. Many of these concepts are foreign to the storage administrator who has been operating a native Fibre Channel SAN for the better part of the last decade or more - this is because while Fibre Channel networks are costly, they are purpose-built. There is no concept of a loop in Fibre Channel - with Ethernet we deal with these all the time.
Over the past few months I’ve heard a lot about vendor lock-in, specifically with respect to new SDN/Network Virtualization products that have come out last year. It appears that no matter what product you look at, there’s some major factor that will cause you to be severely locked in to that vendor until the end of time. Unless, of course, you’re a proponent of that vendor, in which case, that vendor is NOT locking you in, but that other guy totally is.
Over the past few months I’ve heard a lot about vendor lock-in, specifically with respect to new SDN/Network Virtualization products that have come out last year. It appears that no matter what product you look at, there’s some major factor that will cause you to be severely locked in to that vendor until the end of time. Unless, of course, you’re a proponent of that vendor, in which case, that vendor is NOT locking you in, but that other guy totally is.
I’ve been hearing a lot about libvirt, so I figured I’d check it out, and see if I could play around with it in my own home lab.
According to the wiki, libvirt is a ”collection of software that provides a convenient way to manage virtual machines and other virtualization functionality, such as storage and network interface management.” Okay that’s pretty cool - basically if I have a multi-hypervisor environment, I can build my operational policies around libvirt, so that no matter what hypervisor a workload is being instantiated on, the process is the same.
I’ve been hearing a lot about libvirt, so I figured I’d check it out, and see if I could play around with it in my own home lab.
According to the wiki, libvirt is a ”collection of software that provides a convenient way to manage virtual machines and other virtualization functionality, such as storage and network interface management.” Okay that’s pretty cool - basically if I have a multi-hypervisor environment, I can build my operational policies around libvirt, so that no matter what hypervisor a workload is being instantiated on, the process is the same.
I’ve been hearing a lot about libvirt, so I figured I’d check it out, and see if I could play around with it in my own home lab.
According to the wiki, libvirt is a ”collection of software that provides a convenient way to manage virtual machines and other virtualization functionality, such as storage and network interface management.” Okay that’s pretty cool - basically if I have a multi-hypervisor environment, I can build my operational policies around libvirt, so that no matter what hypervisor a workload is being instantiated on, the process is the same.
Wow - this one snuck up on me. Seriously, when I think of how 2013 went, I’m amazed at how much happened this year but also how fast it flew by.
As per the tradition I started last year, I thought it prudent to write a post summarizing how terribly I was able to forecast 2013 in terms of personal goals, and make another feeble attempt at planning out 2014.
Wow - this one snuck up on me. Seriously, when I think of how 2013 went, I’m amazed at how much happened this year but also how fast it flew by.
As per the tradition I started last year, I thought it prudent to write a post summarizing how terribly I was able to forecast 2013 in terms of personal goals, and make another feeble attempt at planning out 2014.
I see a lot of articles and even vendor whitepapers that like to throw the term “best practice” around like it’s pocket change. Truth be told, while there are plenty of general best practices that are recommended in any case, many of what a vendor will call “best practices” are usually just the most common response to an If/Then statement that represents the surrounding environment.
Here’s a good example. I’ve heard on multiple occasions regarding the standard vSwitch in VMWare vSphere that it is a “best practice” to set the load balancing policy to “route based on the originating virtual port ID”.
I see a lot of articles and even vendor whitepapers that like to throw the term “best practice” around like it’s pocket change. Truth be told, while there are plenty of general best practices that are recommended in any case, many of what a vendor will call “best practices” are usually just the most common response to an If/Then statement that represents the surrounding environment.
Here’s a good example. I’ve heard on multiple occasions regarding the standard vSwitch in VMWare vSphere that it is a “best practice” to set the load balancing policy to “route based on the originating virtual port ID”.
I was troubleshooting an MTU related issue for NFS connectivity in a Flexpod (Cisco UCS, Cisco Nexus, and Netapp storage with VMware vSphere, running the Nexus 1000v). Regular-sized frames were making it through, but not jumbo frames. I ensured the endpoints were set up correctly, then moved inwards….in my experience, the problem is usually there.
The original design basically included the use of CoS tag 2 for all NFS traffic, so that it could be honored throughout the network, and given jumbo frames treatment.