Thursday, February 6, 2014

An ESXi host, a NAS and NFS

When you're an IT guy tinkering is part of your lifestyle.  There has to be at least a modicum of curiosity about how things work.   We drive department heads crazy because just keeping stuff working isn't good enough for us.  We want that extra Megabit of throughput or another free Gigabyte out of the SAN.

Sadly, most of us can't afford to set up an server farm in a spare bedroom just to satisfy our need to tinker; but with virtualization you can come very close.

That is of course the promise.  Being able to harness the same capabilities of a small enterprise with a lot less hardware is undeniably a good thing.  Letting us run wild in our own little enterprise is even better.

VirtualBox, VMWare Workstation and their kind is fine for taking a new OS out for a spin but they fall a bit short for giving you real world skills.

ESXi, however, is another story.  Maybe more than any other platform, it's probably the most useful and relevant virtualization lab platform you can experiment with.  Don't confuse this with your grandpa's ESXi, though. 

Starting with version 5, VMWare decided that ESXi is the one hypervisor to rule them all instead of just being ESX's little brother.  That means anything you do with ESXi translates to what you can do in the enterprise.

It's one thing to play with virtual servers in VMWare but it's quite another to play with the platform itself.   After all, the more you tinker with it the better it works right?  Well, at least till we blow something up...

So this time around I decided I wasn't satisfied just locking myself out of the VSphere Client because I forgot the password.  I wanted to get some external storage online but I didn't have a spare ISCSI array laying around.   So I decided to venture into the wonderful world of NFS.

In ESXi you've basically got 2 options for storage.

1. Local - meaning it's either physically attached to the host or on a dedicated backbone via ISCSI

2. NFS - Which is pretty much "other"

Local's easy, if your storage controller can see it so can VMWare.  ISCSi  adds a wrinkle but so long as your target's on the network it's not a big deal.

NFS, ah, that's a different story.  A lot of Sys Admins can go an entire career without having to deal with it.   Like SMB, NFS is designed to offer up access to files on a network.  Those shares are usually hosted on Unix servers but unlike SMB, NFS is designed to fool your local PC into thinking a network resource is local.  An impressive feat compared to the clunky "Map Network Drive" or CLI "Net Use" commands in Windows.

Ok, so we know what NFS is but why do we care about it for VMWare?  Simple, most NAS storage devices will have support for the protocol to allow UNIX clients to access their shares.  Set up NFS on your NAS and you've given ESXi another potential datastore to play with.

NFS has it's quirks but most NAS management interfaces make it a relatively painless process to set up.  Once that happens just be sure you have a solid network connection between your virtual host(s) and the NAS.


Follow along with the video as I set up an NFS share for ESXi 5.5, play with a VM that lives on it and even break it!





Saturday, February 1, 2014

CLI-nging ON



Imagine if you had to do the following  just to start your car every morning...

1.    Pull the choke adjacent to the right fender while engaging the crank lever under the radiator at the front of the car, slowly turning it a quarter-turn clockwise to prime the carburetor with fuel.
2.     Get into the car. Insert the ignition key, turning the setting to either magneto or battery. Adjust the timing stalk upward to retard the timing, move the throttle stalk downward slightly for an idle setting, and pull back on the hand brake, which also places the car in neutral.
3.     Return to the front of the car. Use your left hand to crank the lever (if the engine backfires and the lever swings counterclockwise, the left arm is less likely to be broken). Give it a vigorous half-crank, and the engine should start.

Chances are, your great grandparents were very familiar with the procedure if they owned a Model T.  Mind you, all that bother just starts the car, you haven't even tried to drive anywhere yet.  A complicated procedure to be sure but it beat shoe leather, barely.

Times changed and eventually somebody figured out how to take all those manual processes and mechanically automate them.  Soon, starting your car was just a turn of a key and driving it was more about where you wanted to go than how to control a mass of cantankerous machinery.  It also made the act of driving more accessible to more people.

That's called progress....

So as I stare at my open PowerShell window with a line of gobbledygook that to my dismay is my only means of finding out how much space my email users are hogging I have to wonder...

[PS] C:\>Get-MailboxDatabase "Mailbox Database 1" | Get-MailboxStatistics | Sort totalitemsize -desc | Export-CSV C:\mailboxes.csv

What's up with this command line stuff? 

Go into just about any forum or social media discussion even remotely related to IT and the flame wars will start with the mere mention of the command line.

"Go play with Windows if you want to click buttons"

countered with...

"You know, nobody uses punch cards anymore"

On and on ad infinitum. 

I had just such an exchange the other day with an open source devotee.  He was one of those grizzled admin types who clings to the mantra that nothing real happens in IT without a CLI (Command Line Interface)
He went on and on about his numerous accomplishments with his mastery of cursor and alphabet.  He also bemoaned the lack of functionality in all those "buttons."

It brought me back to the story a friend told me of an old CPA who refused to use a computer with Windows on it because all those kinds of OS's were just "Game" machines.

Anyway, apparently support for his favorite open source R&D project was callously left out of the latest VMWARE Vsphere client.  There was no doubt that to him such an omission doomed VMWare's GUI.

I was quick to point out that the Vshpere client is the preferred method (or the Web client for 5.5) to manage VMWare.  Actually, it's one of the more complete GUI management interfaces available and there aren't a lot of "buttons" to it.

He didn't think so...

To my mind, if it isn't officially supported then you take your lumps and have no right to complain.  But it's pointless to argue with someone like that.  As far as I was concerned he could just go back to his cave...

So it should be no surprise that I hate the command line but only because it's frequently a requirement instead of an option and to me that's all kinds of wrong.  A throwback to carrying around a crank to start your car and the Charleston.

But I have to admit that my console loving friend does have a point.  Far too often Graphical User Interfaces (GUIs) let us down.  They only contain the bare minimum of functionality often forcing you to stare into the inky blackness of a console.

 After 30 years of interface development why is it that CLI's are still so prevalent even in operating systems called "Windows?"  Why, for instance, do I have to execute scripts to select multiples of anything instead of just selecting what I want as a group and clicking "OK"

What my troglodytic friend doesn't seem to understand with all his mastery of the blinking cursor is that he's being forced to do more work than he needs to.  System Administration is frequently bogged down by syntax.  I shouldn't need to be a closet code monkey just to efficiently manage an enterprise.

Microsoft, the entity that made the whole concept of a GUI interface acceptable to most of the corporate world seems to be at odds with its own history. (BTW, Yes I know MAC was first with GUI's)

With every new version of windows it seems simple functions are being relegated to scripts and command lines.  Only the most rudimentary controls are left behind.  Spend any time managing Windows Server 2008 or 2012 and it starts to feel like you've entered some twisted Twilight Zone version of Linux.

I'm not saying the command line should be abolished.  Just like you occasionally need to roll up your sleeves and get a little dirty to get your car started in the morning; there's times you need to drop to that nasty old CLI.

That's ok, I have a right to get a little dirty if I need to BUT it shouldn't be a requirement.  That's my problem with the CLI. 

There's an assumption among the CLI elitists that if you're not comfortable with the command line then you must not know what you're doing.

I can assure you, I know exactly what I'm doing.  I'd just rather do it than get bogged down in a layer of abstraction to get to it. 

Yes, I said it, the CLI is an abstraction almost to the point of a DIStraction.  Even more so than a GUI, the convoluted syntax and cryptic commands do more to separate you from the task at hand than any click ever could.

Is your DNS server more secure and better optimized than mine because you configured it with your arsenal of scripts?  Or is it really an indication of a lazy GUI development team that's given you inadequate tools.

Microsoft introduced the concept of a modular GUI interface called the MMC (Microsoft Management Console) back in the NT 4 days.  It was designed to be customizable and more flexible than the standalone applets that accompanied every service.  It was a step in the right direction but unfortunately began the trend of minimizing GUI functionality by neutering the available commands within the MMC applets.

I submit that both the GUI and CLI devotees are right.  I should never have to go to a command line or call up a script to perform management functions.  I should, however, have a robust CLI that doesn't require me to understand the intricacies of of the Microsoft Foundation Classes.  Interfaces should be complete or at least offer the option to be that way regardless of their presentation.. 

What's wrong about the CLI guys is all the arrogance.  So what if you can dash out 30 line scripts from memory or poke holes through VMWARE to support the latest R&D cloud project. 

Don't assume that because I choose not to waste my time on hand cranked cars to get where I'm going that I don't know how to get there. 

I just expect...no...I demand better and at this stage in the game it's just developer laziness that I don't have it.