Skip to main content

Cisco UCS Platform Emulator Installation

To continue my series of posts on building the framework for a functional lab environment, I'd like to talk about the Cisco UCS Platform Emulator (UCSPE). It is a software appliance packaged as a vSphere OVA that approximates a UCS deployment, including the networking components (a pair of switches called the Fabric Interconnects) and both blade and rackmount UCS servers (B- and C-Series, respectively). It can be a great tool for learning and becoming more familiar with the UCS platform. I will be deploying my UCSPE on vSphere 6.7 in my lab, but it should work similarly in other recent versions.

1. Start by downloading the UCS Platform Emulator OVA from https://communities.cisco.com/docs/DOC-71877 - you will need a Cisco Connection Online (CCO) login in order to begin the download. I am using version 3.1(2ePE1) of the emulator for this guide as that appeared to be the latest version available at the time of writing. Side note, I also noticed during the boot process that this version of the UCSPE was called GALVANIZED GORILLA, which I found hilarious.

2. Deploy the OVA template from the vSphere Web Client, following the steps and filling in name and networking information that is relevant to your environment. Below are the settings I used for my emulator VM, but obviously yours will be different.














3. Once the import is complete, you can power on the UCSPE VM. It will boot and run through its inital configuration, after which you'll be presented with a login prompt. The credentials are as follows:

User Name: ucspe
Password: ucspe

Once you log in, you'll be presented with the menu below.


















Note: We'll be using a statically assigned address for our deployment, but the UCSPE can use DHCP addresses as well.

You will need three IPs for the UCSPE deployment - one for the virtual IP (VIP), and one each for the Fabric Interconnect management interfaces. We'll be using the following IPs:

VIP: 10.20.21.115/24
FI A: 10.20.21.116/24
FI B: 10.20.21.117/24
Gateway IP: 10.20.21.1

4. Select the Modify Network Settings option by pressing the n key.
5. When asked if you want to modify the network connections, press y.














6. Select the Custom option by hitting c and then enter the IP information you've chosen for your environment. Once the gateway IP is entered and you hit Enter, the network interfaces will be restarted to make the configuration changes active.















7. After that is complete, the UCSPE will restart and continue its initial configuration. This will take a few minutes (the "Inserting devices..." step in particular), so be patient. Eventually, the configuration will finish and you can return to the menu you saw before.

8. At this point, you can open a Web browser and browse to https://VIP_IP_ADDRESS. You'll be presented with a Hardware Inventory screen like the one below.








9. From there, you can click on the Triforce logo on the Hardware Inventory screen to launch UCS Manager (UCSM) and log in with the ucspe user credentials.







I have been conditioned to hear the "A Link to the Past" SNES intro music when I see this logo.

10. After login, you'll see a UCSM page that looks like the image below.









This concludes the initial UCSPE deployment. That being said, there is a LOT of functionality built into UCSM (and UCS in general) that is much different than managing a traditional rackmount server architecture. For me, the most difficult thing was getting an understanding of the policy-driven way that UCS resources are managed. Once I took the time to dig into the inner workings of Service Profiles though, it all began to make sense. Keep an eye out for future posts that discuss specific features of the UCS platform.

As always, thanks for reading!

Comments

Popular posts from this blog

How To: Unjoin NetApp Nodes from a Cluster

Let me paint you a word picture:

You've upgraded to a shiny new AFF - it's all racked, stacked, cabled and ready to rock. You've moved your volumes onto the new storage and your workloads are performing beautifully (of course) and it's time to put your old NetApp gear out to pasture.

We're going to learn how to unjoin nodes from an existing cluster. But wait! There are several prerequisites that must be met before the actual cluster unjoin can be done.


Ensure that you have either moved volumes to your new aggregates or offlined and deleted any unused volumes.Offline and delete aggregates from old nodes.Re-home data LIFs or disable/delete if they are not in use.Disable and delete intercluster LIFs for the old nodes (and remove them from any Cluster Peering relationships)Remove the old node's ports from any Broadcast Domains or Failover Groups that they may be a member of.Move epsilon to one of the new nodes (let's assume nodes 3 and 4 are the new nodes, in th…

ONTAP Configuration Compliance Auditing with PowerShell and Pester

I have been looking for a way to validate NetApp cluster configuration settings (once a configuration setting is set, I want to validate that it was set properly in a programmatic fashion) and prevent configuration drift (if a setting is different than its expected value, I want to know about it). I needed it to be able to scale out to dozens of clusters as well, so it needed to be something that I could run both automatically and on an ad-hoc basis if necessary.

NetApp PowerShell Toolkit

The core of the solution is the NetApp PowerShell Toolkit, without which this would likely not be possible. It contains 2300+ cmdlets for provisioning and managing NetApp storage components. It can be downloaded from the ToolChest on the NetApp MySupport site (with a valid login). You'll find exhaustive documentation there as well for each of the cmdlets along with syntax examples and sample code. It is a fantastic and easy way to automate common storage tasks - we use it in our environment for e…

Step up your HTTP security header game with NetScaler Rewrite Policies

There are a number of HTTP response headers that exist to increase web site security. If set properly, they can ensure that your site is less exposed to many common web vulnerabilities. By no means are these descriptions exhaustive, so I have included some references that can provide a more in-depth explanation at the bottom of each section. I'd also like to give a shout-out to the OWASP Secure Headers Project and Scott Helme of securityheaders.com - thank you!

Note: Screenshots are from a NetScaler VPX 12.1 - if you are running a different version, the screenshots may look different, but the logic is the same. So that I have something to bind these policies to, I've also already created a load-balancing virtual server named lb_web_ssl and a Service Group for two TurnKey LAMP servers on the back-end.

X-Frame-Options
The X-Frame-Options header is designed to guard against clickjacking (an attack where malicious content is hidden beneath a clickable button or element on a web si…