My day job is to be an advocate for Cisco UCS in my customer’s data center. Its a great gig. Its much easier to back a product when you actually believe in it. I thought I’d write down some of the ideas that I talk about with my customers on this blog.
Rainbows In the Data Center
Rack mount servers are still all the rage in many organizations. And so is Gigabit Ethernet. VMware best practices suggest that you have separate networks for management, vMotion, I/O, and VM traffic. Using NIC Teaming you get something that looks like this beautiful picture:
(source: Not sure, some Cisco person’s power point I stole)
You’ll notice that people color code these cables so they can tell which network goes to what. The result is a beautiful rainbow flowing out of each server. Then, Rainbow Brite and her sprite buddy Wink and her stallion Starlite can aid you in managing this big mess.
The account team at Cisco responsible for selling you switches loves this because for every cable you buy, you need to connect it to a switch port. This is why we tell everybody that going with UCS is a strategic decision. Do you want to continue investing in lots of Gigabit Ethernet Switches or consolidate with 10GbE? UCS gets rid of the rainbows. Yes, rainbows are pretty, but you don’t want them to get out of hand. Rainbows do strange things to people (especially if you have more than one). Sometimes they can be just too much, and too intense.
UCS gets you instant 10GbE as well as consolidation. I did a comparison for a customer who was looking to buy a “pod” of rack mount servers and compared it to what it would take to buy the equivalent UCS. Each “pod” consisted of 44 2-socket CPU servers. Each server had 6 Gigabit Ethernet ports required as well as 2 HBAs to connect to the SAN. The comparison was pretty eye opening. By going with a UCS strategy the following benefits were realized:
- 10% reduction in acquisition cost (some of this had to do with not having to buy new network switches)
- 57% reduction in physical rack space
- A dramatic difference in Ethernet cables required: 28 compared to 308
- A dramatic difference in Fibre Channel ports required: 4 compared to 88
Think this can happen with Legacy Non-UCS blades? Not so much. There is a savings still, but nothing as dramatic. So if you like dealing with more infrastructure, stringing cables, and configuring port policies on your network switches for every server in your environment, UCS may not be for you.
UCS is the new Catalyst 6000
I get the chance to walk into the belly of many data centers. One common feature that we see there is the venerable Cisco Catalyst 6000 switch. Cisco has been milking this baby since 1999.
What makes this thing so successful? Removable line cards and supervisor line cards. As people have migrated from fast ethernet to gigabit Ethernet to 10 Gigabit Ethernet they’ve just upgraded the line cards or supervisor modules. They made the strategic decision years ago to go with this and its working out great.
UCS Fabric Interconnects have a similar value proposition in the compute space. You buy them as part of your strategy and then adding blades is just like adding remote line cards instead of fixed line cards in a 6509. Going with this strategy provides several benefits:
- Cost effective way of getting servers on line. These Cisco servers are extremely price competitive and very attractive. Once you have the infrastructure, adding blades is so cost compelling its hard to see the rational of not going with another blade when you have the chance. This isn’t to say you’re necessarily locked into Cisco. You still have options. Its just that the other options are not as attractive any more.
- Let’s suppose that 5 years from now Cisco decides it wants to start selling some esoteric micro servers in a new chassis or something. (Full disclosure: I have no idea if they are planning this and have seen nothing on the roadmap). Let’s suppose that this new chassis has 100 slots for these servers. If you bought any other blade, you’d need to throw out the old architecture and buy the new chassis. With UCS, you just buy the new chassis and add these fun esoteric servers. The Fabric Interconnects and the Fabric Extenders on the back will still work the same way. In essence: You’ve future proofed your architecture.
So what if everything goes 100GbE? Fine, swap out Fabric Interconnects just like you swap out supervisor line cards on the 6500. The architecture is brilliant. What do you do with competitor solutions? You have to throw out, start over. The Fabric Interconnect architecture is just something that builds and has the ability to build as time goes on.
The Soul of a Server
In addition to the nice architecture of UCS, another compelling feature is how we manage UCS servers. The idea is a bit different than how you did things in the past. Back in the day, when you wanted to set up a new server, you would plug it in, hook it up to a crash cart, turn it on and then press F2 and do cool things like:
- Tune BIOS settings
- Set boot order
- Program iSCSI interfaces
- configure RAID
Then you might go through and do several updates. Of course you wrote it all down right? Its not hard for these things to get out of sync. And guess what causes problems in application performance? When the infrastructure you thought was homogeneous is not homogeneous. This is a pain and takes a lot more time than people readily admit.
With UCS we do it differently. Gone are the days of pressing F2. I’ve never pressed F2 while a machine is booting on UCS Blades. Here’s the new way: There is a place in UCS Manager where all your wildest dreams and fantasies can come true. This is where we logically define what we want our servers to look like. We go through and say to ourselves: In my fantasy world, if I could have a server, I’d want it to PXE boot, then boot to hard drive. I’d want its BIOS settings to have hyperthreading. I’d also like its firmware level to be 2.0(2) and I’d like its RAID to be set to RAID1 mirroring.
That’s exactly how you do it. You define a template that has all the characteristics of the server you want and then spawn instances of it (called Service Profiles). You then take those spawns, or service profiles and possess the hardware of the physical blade you assign it to. Its like you create the soul of the server then give that soul a body.
This is pretty cool because now if you want to change something, you change it at the template and it can in turn update all the spawns of it. You can create multiple templates for different types of servers, each optimized for the application that the server is supporting. So you might have a service profile template for ESXi, a template for Oracle, a template for Windows bare metal, or a template for RHEV. You are in the business of managing server souls. Its more nobel.
These are just a few of the many benefits of UCS that I thought I’d write down. There’s always situations where other products may be more applicable. But UCS is definitely one to check out. And just in case you missed it: UCS is the 3rd best selling x86 blade server world wide after HP (1) and IBM (2). In the US, UCS is ranked #2 behind HP. Not bad for a server that’s only been on the scene since 2009.
Cisco UCS Role Based Access Control
One of the cool things that UCS allows you to do is create a place where different users of different organizations can go to to configure their pools of resources. Its a common goal for many organizations to reduce duplication and allow agility and flexibility. A multi-tenant solution that has been talked about can actually become a reality with UCS in the form of Role Based Access Control (RBAC).
Let’s suppose that a local county has decided it wants to consolidate its IT infrastructure into its IT department as opposed to every department having its own IT instances. It can start off slowly, by say, starting with one or two organizations like the department of Superior Courts and the department of Executive Services.
Here’s how the main IT organization might configure RBAC for the Superior Courts and the Department of Executive Services.
1. Create suborganizations
Log in as admin and navigate to the Servers tab. From there you can expand the Service Profiles and see “root” and “Sub-Organizations”. Right click on “root” and add an organization:
2. Create Locale
A locale in UCSM is designed to reflect the location of a user in an organization. By default all users are at the ‘root’ level locale, but if we are creating sub-organizations, we want them to use their own stuff and not modify existing resources that exist at the root level, or with other organizations.
Navigate to the Admin Tab in navigation pane, filter by User Management, expand User Services and right click on Locales.
From here we can create a local named Superior_Court and bind it to the Superior_Court organization we created.
Next, to assign the organization, we just expand the Organizations menu and drag the Superior_Court into the pane on the right.
Clicking finish gives us our new locale bound to its sub organization.
3. Create a User for the Organization
Now let’s create a user called sc-admin that has all the rights in the Superior_Court local, but can’t change things in the root locale or any other locales.
On the navigation pane in the same place you were on the previous step, right click Locally Authenticated Users and select ‘Create User’.
The first fields are pretty self-explanatory. We created the user and password and left out some of the other information. The important part is that the locale is set to Superior_Court. This confines the powers of this user into Superior_Court. We can then select all the roles except the following:
- aaa: Authentication, Authorization, and Accounting. This can only be done in the root locale
- admin: this can only be given in the root locale
- operations: can only be given to root locale.
Now that sc-admin is created. Give him to your local friendly Superior Court tenant and let them have access to the system.
Now then… What can sc-admin do?
If you now log in as sc-admin, you can see that he can create service profiles, pools, and policies, but only in his superior_court suborg. If sc-admin tries to create a resource in the root organization, he is blocked from doing so because all of the options are greyed out:
Here’s what else he can do:
- He can create sub organizations within his own Sub-organization.
- He can create VLANs in the LAN and enable and disable network ports on the Fabric Interconnects. (because he was given network access… if you don’t want this take away the network privilege)
- He can create VSANs and disable and enable FC interfaces. (take away the storage privilege if you don’t want him to do this)
An interesting scenario I ran across is that if you remove a role from a user while that user is still logged in, it doesn’t seem to take effect until the user logs in later. For example, I disabled sc-admin’s network role and he was still able to create VLANs and turn ports off and on. When I logged him out and logged him back in again, the role acted how it should have.
One of the disadvantages of disabling the network role is that sc-admin can’t create VNIC Templates. This is something we might want to allow him to do in his own org. We can change this by creating a new role in the user management entitled Network_SP. For this role, we just check:
- Service Profile Network
- Service Profile Network-Policy
- Service Profile Qos
- Service Profile Qos Policy
Next, add this role into the sc-admin account (click on locally authenticated users and right click sc-admin and add a check to the Network_SP role we created)
Now sc-admin can create vNIC templates in his own sub org, but he isn’t allowed to create external VLANs and disable/enable ports on the Fabric Interconnect. For this to take affect, have sc-admin log out and log back in again after you apply the role.
You can do something very similar on the Storage tab in order to allow a suborg to create and modify its own vHBA Templates but not be able to disable FC ports on the Fabric Interconnects.
Once this is in place, you can repeat the operation for the department of Executive Services. As other departments join the consolidated data center their users are simply added to the locales and given roles.
App crazy
I’ve been going a little app crazy to start out this year, and I’m very pleased with the results. With the help of others, I’ve released updates to the two Cisco based apps: UCS Tech Specs, and FlexPod Tech Specs. And I’ve finally released the xCAT iOS client! Hurray!
I’ve been doing all this for the past several months during that precious moments I have after the kids go to bed and I drift off to sleep. Lucky for me, my wife has enough interesting projects going on in her life that she doesn’t miss me… too much! Don’t get me wrong: We still find time to go out and have a great time. And for those times when my day job also becomes my night job, you can see why it takes a long time for many of these projects to get done. Whew!
There are also many other projects cooking. With my coworker Tige Phillips at Cisco, we are slowly creating SiMU HD, an iPad version of SiMU pro that will manage UCS systems. …Well, I should restate that: He’s doing most of the work and I’m lending a hand!
I’ve also thought about starting a little game development? How about a game for managing clusters? A game for managing UCS that gives you prizes for learning how to do certain cool features? Ha! Yes, I have a lot of bad ideas! Hope you have a great February!
I’ve always found a good way to get started with a new language is to just go head into it trying to solve some problem you’re working on, then ask the Internet via a search engine how to do something you want to do.
Today I started for the first time with PowerShell. Here’s the problem I was trying to solve:
I have a lot of VMs that I want to bring up for a class that I’m giving. There could be between 10-50 people at any given class. What I need to do is clone a master VM from a template, change its MAC address to something I have reserved in my DHCP server, and then power it up.
All of this can be done via vCenter. But its a slow and painful point-and-click-yourself-to-death process. Automation is the way to get this done.
All of this can be done via xCAT. But I figured why not give it a try. Other people can live without xCAT. Maybe I can too.
I have a history of perl. Yes, I have lots of skeletons in the closet with that language. So I was going to do all of this with Perl. But I figured that since I was going to be doing power shell scripts anyway for the UCS emulator portion, why not just do it all with the same thing? So I gave it a shot.
First off, the Windows editors suck. I had to stick with VIM because there’s nothing better for me. Let’s not even argue about that. +1 for me for retaining my dignity.
Next, after installing the VMware PowerCLI tool it was pretty easy.
CreateVMs.ps1
Here’s the script to clone 9 VMS from a template called UCSPEMaster. I just change it depending on how many I need.
1..9 | foreach {
# pad each name with 0s so we have: ucspe08,ucspe09,ucspe10,...
$strNum = [Convert]::ToString([int]$_)
$suffix = $strNum.padLeft(2,"0")
New-VM -VMHost 192.168.1.4 -datastore datastore1 -Template UCSPEMaster \
-Folder 'UCS-Name UCSPE0$suffix -diskstorageFormat Thin \
-Location 'UCS Emulators' -runAsync
}
Notice that each machine will be called UCSPEXX, where XX is the range I specify. That way if
4 more people walk into the class after I’ve configured 14, then I can do 15..8.
I also put all of them on the same host (192.168.1.4), the same datastore (datastore1), the same Folder (UCS Emulators), and made them thin clones.
If you have a cluster running Storage DRS (vSphere 5.0+) then you don’t have to specify the datastore and DRS will put it where it sees fit.
ConfigVMs.ps1
The only thing I need to do now is change the MAC address to something that I have reserved. That way, I can tell the user to just log into the IP address that I’ve set up beforehand. I’ve configured 60 IP addresses so that I’m ready for a big class.
get-vm UCSPE* | foreach {
$number = $_.name.Replace("UCSPE","")
$hexNumber = [Convert]::ToString([int]$number, 16)
$lastPart = $hexNumber.PadLeft(2,"0")
$adapter = Get-NetworkAdapter $_
write-host "Changing MAC address for $_"
Set-NetworkAdapter -NetworkAdapter $adapter \
-MacAddress 00:50:56:00:01:$lastPart -Confirm:$false
}
Most of the script is made up of getting the last number part of the VM name. Since each VM is named UCSPE01-UCSPE60 then it grabs the 60, converts it to hex, then adds that as the last part of the MAC address of the adapter. This will work as long as I don’t have more than 255 VMs.
I could have put a Start-VM on the end of this. Generally, that’s just a powershell one-liner:
Get-VM UCSPE* | Start-VM
removeVMs.ps1
The last script will just remove these VMs. As I tweak around with them, or as people in the class tweak around with them, I just want to erase them and start fresh for the next class. This is fairly easy:
Get-VM UCSPE* | foreach {
Stop-VM $_ -confirm:$false
Remove-VM $_ -DeleteFromDisk -confirm:$false
}
The only thing I need to update this with is to not power it off if it isn’t on. It throws some nasty errors if it’s not powered on. But I’ll do that some other time.
I’ll get this lab working with PowerShell. It’s not a bad language. It’s another tool in the handbag. I still prefer command line scripting with Bash or Perl. But every now and then its fun to go over and see how the other side lives. Now, back to xCAT.
SSH: The ultimate firewall poker
I’m in a hotel tonight and my internet connection is slow. My friend sent me some cool YouTube videos that I wanted to check out and I was wondering if the hotel was limiting the bandwidth of YouTube? A few days ago a friend of mine and I were talking about how to bypass corporate firewalls where companies block facebook/gmail/twitter access. The way to check the YouTube problem and to bypass corporate firewalls can be done using the same solution: SSH.
SSH encrypts data in and out of networks. It is the ultimate firwall poker. If you have SSH capabilities on at least one server on the internet and you can get to it then you can let any traffic in and out of a network. Traffic is all encrypted so no sniffers know anything other than the fact that you have a connection from your machine (inside the corporate firewall / hotel wireless) on port 22 to some remote server that you have access to outside of the network you are on.
So here’s a quick test to see if YouTube was being throttled on this network, provided you have a Mac. I’m doing this on OSX Lion.
1. SSH to some remote internet server. I have one, so I open a port to it:
ssh -D 2011 vallard@myserver.com
This essentially turns your ssh connection into a SOCKS server.
2. Open chrome and navigate to:
chrome://settings/advanced
From here select ‘Change Proxy Settings’ and your Mac settings will come up. Change the Socks settings as shown below:
That’s it. Now you can visit http://whatismyip.com and see that the IP address changed. You can also go to google maps and it will think you are in the city where the server is getting its network access from.
So, what about the YouTube video? Seemed to be a bit better actually… but was hard to tell. Probably was the same…
The other cool thing about this is how if you were in an airport then you can skip annoying adds that come on your web browser then this is how you could do it.
I’ve written in the past about all the cool tunnels you could make with SSH. (See Trick 5 and Trick 6)
The point is: There are ways around corporate policies that block you from checking sites you like, and ways to stop service providers from limiting your bandwidth based on the sites you visit. Now obviously, you have to trust that the machine you SSH into allows you access to all that. But that server is your choice!
SSH through proxy
Problem of the day is I have a computer that is on some local intranet that can not SSH out into the real world. There is however a proxy server on my network that I can configure in my browser to get outside internet access…
But I want ssh. So… after a bit of internet searching and then finally some nagging to a friend who knows this stuff better than I do, we came up with the following:
1. Download connect.c
2. Compile connect.c on your Linux server:
gcc connect.c -o /usr/bin/ssh-proxy-connect
3. Edit /etc/ssh/ssh_config by appending this last line:
ProxyCommand /usr/bin/ssh-proxy-connect -5 -S <proxy-server-goes here>:1080 %h %p
4. SSH normally to where you need to go.
ssh joe@smith.com
That’s it! Once you get SSH through then anything can happen. Its the ultimate firewall poker. Back doors, etc. You just opened up Pandora’s box.
UCS Dashboard
UCS dashboard is a read only tool that came out a couple of months ago. It’s prime objective is to make it easy to manage multiple UCS domains. Today it is read only. Tomorrow… I’m sure it will be able to do more. :-)
It is a free download from Cisco. You can get it here.
The installation instructions are there as well. Here’s my instructions on how I did it that I hope will provide you hints.
Installation
The first instruction of UCS_Dashboard is to unzip the file. There are three files that you have to download. Now all of you may find that easy, but as a Linux user I’m looking around trying to figure out how to unzip those three files.
Turns out that once you download them, you need to cat them together and then unzip them. So for me it was:
cat UCS_Dashboard_v1_0.z01 UCS_Dashboard_v1_0.z02 UCS_Dashboard_v1_0.zip >UCS_Dashboard.zip
then
unzip UCS_Dashboard.zip
You’ll then get the following nice message:
Archive: UCS_Dashboard.zip warning [UCS_Dashboard.zip]: zipfile claims to be last disk of a multi-part archive; attempting to process anyway, assuming all parts have been concatenated together in order. Expect "errors" and warnings...true multi-part support doesn't exist yet (coming soon). warning [UCS_Dashboard.zip]: 650117120 extra bytes at beginning or within zipfile (attempting to process anyway) file #1: bad zipfile offset (local header sig): 650117124 (attempting to re-compensate) creating: UCS_Dashboard_v1_0/ inflating: UCS_Dashboard_v1_0/UCS_Dashboard_v1_0-disk1.vmdk.gz file #3: bad zipfile offset (local header sig): 241444728 (attempting to re-compensate) inflating: UCS_Dashboard_v1_0/UCS_Dashboard_v1_0.mf inflating: UCS_Dashboard_v1_0/UCS_Dashboard_v1_0.ovf
They’ve been saying coming soon since 2003 (at least!). Anyway, don’t worry about the errors. They’re fine.
The next thing to do is deploy this OVF file. This can be done from vCenter. I ran into a problem when I did this:
Unable to load DLL 'zlib1.dll': the specified module could not be found
I then googled this and found a free zlib1.dll file that I could download and install on the vCenter server. It looked like very cheezy software and I really didn’t want to install it. The alternative would have been to unzip it from the linux command line and then figure out a way to modify the ovf file. But, I just installed the zlib and things went fine.
The host then booted up and I saw a familiar CentOS splash screen. My file was up.
Log In
The Login User is root, the password is cisco123. But you won’t need that. Cisco likes to make it easy for you. I couldn’t help myself so I immediately went in and configured the IP address in /etc/sysconfig/network-scripts/ifcfg-eth0.
But the right way is to just login as ‘ucsadmin’ with password ‘ucsadmin’. It will immediately start a script and ask you for the admin password. Here you enter ‘admin’.
Then you can configure the IP address. Nice.
Configuration
You’ll have to create a read-only account on UCS for the Dashboard to log into. You have to do this in good old fashion UCSM java client or the command line. (Note: This threw me for a loop. Don’t try to check the “read-only” box. All users by default are read-only 
). (Note2: command line is left as exercise to the reader)
Navigate your web browser to the IP address of the UCS Dashboard. From here you’ll be tempted to immediately add your UCSM. Don’t! First create a domain and group from the configuration menu. Its not as obvious at first. Took me a while to find it, but then you’ll get it. From there you can add your UCSM back on the “Manage Inventory” side.
Now what?
Well, now you’ve got a way to view your service profile information and all the details of multiple UCS systems. Not bad right? Its read-only, but we’re just getting started!
Hope that helps!
xCAT r* commands with UCS
xCAT out of the box works on UCS. Or UCS out of the box works with xCAT? Whichever way you look at it, it works. All of the cool things you can do with xCAT like provision nodes, KVM, vSphere, stateless computing, etc, can all be done with UCS. In fact, you can even run most of the r* commands on UCS.
Cisco UCS allows this through IPMI. And configuring IPMI on UCS is easier than any other system I’ve ever used. While I still plan on furthering my xCAT UCS plugin to get more capabilities into xCAT, most xCAT functions can be used with UCS managing the servers with IPMI. For most people, this is good enough.
Using IPMI this is what seems to work with xCAT 2.6.6 and UCSM 2.0(1): (See the end of this for sample output)
- rpower on|off|stat|boot
- rbeacon on|off
- reventlog [clear]
- rvitals (this is quite thorough)
rinv seems to hang on me. This I think is due to the nature of service profiles, where UUIDs and MAC addresses are transient. I’ll investigate this further.
So how do you do it?
Configuring an IPMI machine with xCAT has been well documented. What I haven’t seen documented so much is configuring IPMI inside UCS. This is surprisingly easy. Here’s how its done:
1. Create a Service Profile Template that you will apply to your blades. This is documented very well in various places so I won’t go into it here. Creating a Service Profile Template is UCS 101. After you’ve created your service profile, assuming its an updating template you can proceed to the next step. (Don’t worry, any changes made for doing IPMI don’t require a reboot)
2. From the Servers tab, filter by Service Profile Templates, and navigate to your service profile template.
3. Click on the policies table and look at the IPMI Access Profile Policy
4. Create a new policy. In this policy you’ll give the name of the user and give it a password. Make sure they have admin privileges. For simplicity, I just made my user and password the same as my UCSM user and password.
5. Apply the setting and click save.
From here on out you can just run IPMI commands. The only issue now is to know which IP address corresponds to the IPMI interface of which blade.
This can be found in UCSM under the Admin tab, Communication Management, Management IP pool. If you click on the IP addresses tab on the left hand side, you’ll see all the IP addresses.
Ok my friend, you now have it. xCAT running rpower commands.
And now, here is a sample output running rvitals on a UCS B200 M1:
# rvitals lucky01 lucky01: BIOSPOST_TIMEOUT: N/A lucky01: BIOS_POST_CMPLT: 0 lucky01: CATERR_N: 0 lucky01: CPUS_PRCHT_N: 0 lucky01: DDR3_P1_A1_ECC: 0 error lucky01: DDR3_P1_A1_PRS: 0 lucky01: DDR3_P1_A1_TMP: 26 C (79 F) lucky01: DDR3_P1_A2_ECC: 0 error lucky01: DDR3_P1_A2_PRS: 0 lucky01: DDR3_P1_A2_TMP: 25 C (77 F) lucky01: DDR3_P1_B1_ECC: 0 error lucky01: DDR3_P1_B1_PRS: 0 lucky01: DDR3_P1_B1_TMP: 26 C (79 F) lucky01: DDR3_P1_B2_ECC: 0 error lucky01: DDR3_P1_B2_PRS: 0 lucky01: DDR3_P1_B2_TMP: 27 C (81 F) lucky01: DDR3_P1_C1_ECC: 0 error lucky01: DDR3_P1_C1_PRS: 0 lucky01: DDR3_P1_C1_TMP: 24 C (75 F) lucky01: DDR3_P1_C2_ECC: 0 error lucky01: DDR3_P1_C2_PRS: 0 lucky01: DDR3_P1_C2_TMP: 25 C (77 F) lucky01: DDR3_P2_D1_ECC: 0 error lucky01: DDR3_P2_D1_PRS: 0 lucky01: DDR3_P2_D1_TMP: 22 C (72 F) lucky01: DDR3_P2_D2_ECC: 0 error lucky01: DDR3_P2_D2_PRS: 0 lucky01: DDR3_P2_D2_TMP: 22 C (72 F) lucky01: DDR3_P2_E1_ECC: 0 error lucky01: DDR3_P2_E1_PRS: 0 lucky01: DDR3_P2_E1_TMP: 22 C (72 F) lucky01: DDR3_P2_E2_ECC: 0 error lucky01: DDR3_P2_E2_PRS: 0 lucky01: DDR3_P2_E2_TMP: 22 C (72 F) lucky01: DDR3_P2_F1_ECC: 0 error lucky01: DDR3_P2_F1_PRS: 0 lucky01: DDR3_P2_F1_TMP: 21 C (70 F) lucky01: DDR3_P2_F2_ECC: 0 error lucky01: DDR3_P2_F2_PRS: 0 lucky01: DDR3_P2_F2_TMP: 22 C (72 F) lucky01: ECC_STROM: 0 lucky01: FM_TEMP_SENS_IO: 21 C (70 F) lucky01: FM_TEMP_SEN_REAR: 22 C (72 F) lucky01: HDD0_PRS: 0 lucky01: HDD1_PRS: 0 lucky01: HDD_BP_PRS: 0 lucky01: IOH_THERMALERT_N: 0 lucky01: IOH_THERMTRIP_N: 0 lucky01: IRQ_P1_RDIM_EVNT: 0 lucky01: IRQ_P1_VRHOT: 0 lucky01: IRQ_P2_RDIM_EVNT: 0 lucky01: IRQ_P2_VRHOT: 0 lucky01: LED_BLADE_STATUS: 0 lucky01: LED_FPID: 0 lucky01: LED_MEZZ_FAULT: 0 lucky01: LED_MEZZ_TP_FLT: 0 lucky01: LED_SAS0_FAULT: 0 lucky01: LED_SAS1_FAULT: 0 lucky01: LED_SYS_ACT: 0 lucky01: MAIN_POWER: 0 lucky01: MEZZ_PRS: 0 lucky01: P0V75_DDR3_P1: 0.7644 Volts lucky01: P0V75_DDR3_P2: 0.7644 Volts lucky01: P12V_BP: 11.948 Volts lucky01: P12V_CUR_SENS: 10.78 Amps lucky01: P1V05_ICH: 1.0486 Volts lucky01: P1V1_IOH: 1.078 Volts lucky01: P1V1_VCCP_P1: 1.0192 Volts lucky01: P1V1_VCCP_P2: 0.931 Volts lucky01: P1V1_VTT_P1: 1.1368 Volts lucky01: P1V1_VTT_P2: 1.1564 Volts lucky01: P1V2_SAS: 1.2152 Volts lucky01: P1V5_DDR3_P1: 1.5288 Volts lucky01: P1V5_DDR3_P1_IMN: 5.13 Amps lucky01: P1V5_DDR3_P2: 1.5386 Volts lucky01: P1V5_DDR3_P2_IMN: 14.25 Amps lucky01: P1V5_ICH: 1.5092 Volts lucky01: P1V8_IOH: 1.813 Volts lucky01: P1V8_P1: 1.7836 Volts lucky01: P1V8_P2: 1.7836 Volts lucky01: P1_PRESENT: 0 lucky01: P1_TEMP_SENS: 39.5 C (103 F) lucky01: P1_THERMTRIP_N: 0 lucky01: P2_PRESENT: 0 lucky01: P2_TEMP_SENS: 37.5 C (100 F) lucky01: P2_THERMTRIP_N: 0 lucky01: P3V3_SCALED: 3.2548 Volts lucky01: P3V_BAT_SCALED: 3.102 Volts lucky01: P5V_SCALED: 4.9405 Volts lucky01: POWER_ON_FAIL: 0 lucky01: POWER_USAGE: 126 Watts (430 BTUs/hr) lucky01: SAS0_FAULT: N/A lucky01: SAS1_FAULT: N/A lucky01: SEL_FULLNESS: 0 lucky01: VR_P1_IMON: 1.75 Amps lucky01: VR_P2_IMON: 3.5 Amps
UCSM: Changing IP addresses
You just got a UCS system and now you want to install it. You configured it, but now you realize you need to change the IP addresses. You could rerun setup and it would take about 15 minutes to reboot and reconfigure. Not the most efficient use of your time. What do you do?
You just change the IP addresses silly! Normally you can just do this via the web interface. But for fun, you want to do it via the command line. Here is how its done:
scope fabric-interconnect a set out-of-band ip ip-address netmask netmask gw gateway-ip-address scope fabric-interconnect b set out-of-band ip ip-address netmask netmask gw gateway-ip-address scope system set virtual-ip vip-address commit-buffer
Too easy!
UCS Login Banner
One of the cool things in UCS 2.0 is the ability to display custom banners (or MOTDs) when people log into the system. How to do this?
- Admin Tab
- User Services
- Banner Tab
- Create Banner
Now when the user logs in they see a fun message from you. Pretty simple, but thought I’d share anyway.
