Tuesday, September 30, 2014

Interop New York 2014

As luck would have it, I once again find myself traveling to New York City for yet another Tech Field Day Extra event: Interop New York!

Helpful sign is helpful.
I've not attended Interop before, so I'm excited to see what a conference that isn't focused solely on virtualization has to offer. I'll admit that I'm already regretting bringing my VMware laptop bag; maybe I'll put a black Sharpie to good use and remedy that situation. But maybe I don't need to obscure my virtualization vendor of choice; a quick glance at Wednesday's session listing reveals titles such as "'Parley!' - The Rules of Network Automation" and "Network Function Virtualization." At this rate, one day we'll no longer be able to distinguish between network- and virtualization-centric conferences. They'll both be directed at programmers. Those of us who don't learn to program and script will be relegated to cranking out "Pepperidge Farm Remembers" memes while we lament the end of the sysadmin as we knew it.

Until then, and certainly for the next two days, I'm going to be learning as much as possible from my fellow delegates for TFDx. And of course, tomorrow afternoon's presentations from HP and Cisco promise to be intriguing, with possible topics that include intelligent WAN and the launch of the SDN App Store. Throw in a little roundtable discussion with friends, and you've got the recipe for TFDx!

My editor (ok, it's me) just pointed out that three exclamation marks punctuate this humble blog post. That's a good indication that I need sleep. So I'm off to find coffee instead. If you see me wandering around this week, grab me and say hello!

Friday, September 19, 2014

Hamlet & Coffee Cup Sleeves

“Seems,” madam? Nay, it is. I know not “seems.”

Remember that Marathon level? Yeah.
With these words, Prince Hamlet gives us a glimpse into his grand deception. Hamlet is, among many things, a play about seeming versus being. Is he truly mad with loss and anger, or is he acting mad in order to exact revenge? And does it even make a difference?

I'm not sure why, but this is one of those lines that goes through my mind on a daily basis. Being vs. seeming. Seeming vs. being. It's partially a remnant of the many wonderful literature courses I took at Maryland so long ago. But it's also because I go to the same shitty coffee shop every morning to get a cup of "coffee." And I have ritualized the process so effectively that I don't think about what I'm doing. I just get the largest cup in the stacks, grab a coffee cup sleeve, pour in some half&half (before the coffee so I don't have to stir it), then fill up with "coffee." Pop on a lid (careful to align the sipping portal with the cup's edge opposite of the seam). Pay and I'm off.

But the sleeve is worth a bit of consideration. Because it looks like a sleeve at Starbucks. It seems like a sleeve at Starbucks. But it is not a functional equivalent.

Close?

How Coffee Cup Sleeves Work


Sleeves are made from cardboard. But cardboard is a terrible insulator on its own. That's why you'll notice that Starbucks uses sleeves that are corrugated. And it's the corrugation that provides insulation via the trapped air within the fluting. It's the same principle as fiberglass insulation: glass is a terrible insulator (that's why glass coffee mugs never took off), but fiberglass traps a big layer of dead air that is a wonderful insulator. Air is the insulator. The corrugated cardboard just creates a layer of air.

But the shitty coffee shop that I frequent stocks coffee cup sleeves that are just a thin layer of cardboard; there's no corrugation. It's worth noting that, when cardboard is in direct contact with the coffee cup, it acts as a conductor, not an insulator. So using a sleeve that has no corrugation (or any other means of trapping a layer of air) has zero functional value. It seems to be a coffee sleeve, but it certainly is not.

What's the Point?

The point is that, in a rush to imitate, many products end up mimicking the form of a similar product, but completely miss the function. Seeming and being are very, very different states. Be mindful of mistaking one for the other.

And the other point is that the temperature of the coffee is too damn high.

Sunday, September 14, 2014

UCS M-Series: The Server, Deconstructed

Last week, I attended the Cisco #UCSGrandSlam product launch in NYC as a member of the Tech Field Day delegation. I'm sure you followed the excitement on social media; the @CiscoDC team really knows how to promote their events! And you've likely read some great blog posts from some of the other delegates, including Chris Wahl and Jason Edelman.

To sum up the event, Cisco unveiled two new breeds of server hardware: the M-Series and the C-Series. The C-series server is a beast of a rack-mounted server with enough drive bays that you'd be forgiven for calling it a drive tray. And the M-series represents, in Cisco's terms, the "dis-aggregated server." While the products were certainly provocative and riddled with innovation, I left the press event with one question: what is a server?

For some reason, the first thing that popped into my head during the press event was the Scion xB. Well, not just the Scion xB, but this dead-on review of the auto from slate.com. Specifically, the article correctly correlates the existence of the xB with the "[complete] deconstruction of the SUV." Briefly, the Scion xB has most of the attributes that those bulky boat-show SUVs have, but the sum of the parts is somehow not an SUV.

That's what the M-series is to me. It's the complete deconstruction of a server. Servers are no longer autonomous sheet metal monsters that have static and rigid identities. You can no longer walk into any modern data center and point to your server. It could be anywhere, including... not in your data center. So the M-series takes this notion to heart with its decoupling of CPU and memory from drive controllers and vNICs & vHBAs. Take a look at this thing with the cover off. You'll marvel at it and wonder what the hell is going on here. Where are the VICs? (Hint: there's only one, and it's a monster.) What are those four SSDs? (Hint: they're presented to the nodes as local storage.) How the hell am I going to manage this thing? (Hint: UCSM.)

Sorry I'm late getting this post out. But I was sidetracked when the latest TechReckoning arrived in my Inbox this week, and it was coincidentally titled "Not Your Grandmas x86 Box." Sidetracked, because that's pretty much what I wanted to say, too. Maybe Troyer is  right; maybe the term "server" is dead. Cisco calls them "nodes" and "cartridges" now. We've colloquially referred to them as boxes for years. Maybe it's time to put the "server" out to pasture.

Thursday, September 11, 2014

Query NTP Settings on ESXi 5.x Hosts

Short and sweet today. We needed to report on the NTP settings for our ESXi 5.0 hosts. We've got enough hosts to justify wrestling with PowerCLI a few minutes (okay, more like 30 minutes), as opposed to clicking through the dozens of screens necessary in the vSphere client.

Specifically, we wanted a list of the hosts, the NTP servers they were using for time sources, how the service was set to start (the Policy), and whether the service was running. Here it is:

The command will output a report with Name, NTP Server, Policy, and ServiceRunning columns for each VMHost in your vCenter. It's perfect if you're looking to verify that each host has been set identically.

Wednesday, September 10, 2014

Syslog on ESXi 5.0 Hosts

So you want to enable syslog on your ESXi 5.0 hosts? Or you just want to read a blogpost about doing that? Either way is cool with me.

Setting up syslog is easy to do. But doing so requires some attention to detail, because this change is enabled in several places via the vSphere Client. In short form:
  1. Configuring syslog in the host's Advanced Options screen
  2. Configuring the firewall rules for your ESXi hosts
I'll show you the click-happy way to do this, then we'll do a little PowerCLI that will do the same thing while you go get some coffee.

Configuring syslog in the host's Advanced Options screen

The Config.HostAgent.log.level screen
You'll need to configure, at a minimum, three advanced options for each host that will be sending syslog: the hostAgent log level, the Vpxa config log level, and the remote syslog host. Start by selecting your host, then clicking the Configuration tab, and dig into the juicy advanced settings.

Your first stop is to set your logging level for the Config.HostAgent.log.level property. See the image to the right for available options. I suggest using warning; info might be more logging information than you need. However, some environments may elect to capture as much data as possible and filter it at the syslog server level. That's fine, too. Just be prepared for a non-trivial increase in logging when you go to info or higher.
The Vpx.Vpxa.config.log.level screen

Next, we need to do the same for the vCenter agent (aka Vpx.Vpxa.config.log.level) logging level. Check the screenshot to the right for the exact location. The same advice applies here: set it to warning, unless you really need more logging information.

You'll be tempted to check your syslog host for log data at this point. Don't. You'll only be disappointed, and perhaps slightly confused. Because the trusty ESXi firewall is dutifully blocking syslog traffic. So let's fix that.

Configuring the firewall rules for your ESXi hosts


The trusty ESXi Firewall settings screen
On your Configuration tab, click the Security Profile option, and select the Firewall's Properties. Scroll down a bit, and you'll see that the option for syslog is unchecked. Easy fix: click the empty box to the left of syslog, and then click OK. You'll see a task in the vSphere client that says, "Opening firewall port." And when it's done, you're done. Easy. But damn that's a lot of clicking. There's got to be an easier way, right? Right?

The Easier Way - PowerCLI

You're damned right there's an easier way. Just launch PowerCLI (or alt-tab to it, since you shouldn't ever close PowerCLI anyway) and let's see how easy this is.

Here's the command you'll want to use to configure syslog. It will configure every host in your vCenter Server (via the get-vmhost cmdlet) to use the "warning" log level for your Host and vCenter agent logging, and will send syslog to the host at 10.0.0.1 (probably not what you want, so make sure to change this to your syslog server).


Now, we just need a one-liner to open up that firewall rule for syslog. Easy.



Aaaaaaand you're done. But did you notice that warning in PowerCLI about the set-VMHostAdvancedConfiguration cmdlet being deprecated? Yeah, me too. But I'll write that up tomorrow. It's time for baseball practice.