Top
Search

Categories
Navigation
Twitter Updates

Twitter Updates

    follow me on Twitter
    Archives
    Tuesday
    Mar022010

    VMware ESXi Is Awesome (and Free)

    DateTuesday, March 2, 2010 at 12:52AM | AuthorKevin Rohrbaugh

    First a disclaimer: This post is mainly geek porn for myself. Since most of the content below has been captured elsewhere, it’s not really adding anything new to the corpus of ESXi knowledge on the Internet. Oh well.

    Why Am I Doing This?

    Throughout my career, I’ve always worked at organizations large enough that systems administration and IT operations were handled by a different group from the development organization. I have always been on the development side of the fence, which means I run into basic sysadmin work from time to time but my first-hand knowledge is limited. In an attempt to fix this (and satisfy my need to buy new hardware constantly), I decided to buy a beefy home server to run VMware ESXi on.

    If you haven’t heard of ESXi, it is a free (as in beer) bare metal hypervisor, which basically means it runs virtual machines without the need for a traditional host OS. Essentially, I can setup multiple virtualized servers on one physical server and learn as much about systems administration as I’d like.

    The Machine

    Using the excellent unofficial hardware compatibility lists on Dave Mishchenko’s vm-help site, I spent a bunch of time sorting out whether I wanted to build a machine or buy a whitebox server. Eventually, a sale on Dell’s Small Business site led me to decide that the whitebox option was the way to go. I ordered a Dell PowerEdge T110 with the following configuration details and costs:

    Total cost ended up being just shy of $1655, including shipping. Note that I cheated a bit because I already had one 1.5TB Barracuda that I had picked up for this project at a recent Microcenter sale so its purchase price isn’t included. Through NewEgg, the fourth drive would add about $120 more for a grand total of $1775.

    While $1800 is not exactly cheap, 16GB of RAM and 6TB of drive space is a bit excessive, so it’d be possible to build a more reasonable config for quite a bit less. The biggest downfall for this setup is the lack of RAID, so my 4x 1.5TB drives are four discrete drives within ESXi (JBOD). Not a huge deal to me, but not ideal, admittedly.

    Putting It All Together

    The process of putting all the pieces together was pretty mundane, with the only real delighter being the two internal USB ports on the T110’s motherboard. Since my plan was to install ESXi on the USB flash drive, this allowed me to avoid having it stick out the back of the machine permanently. Overall, the internal design of the T110 is nice. The rest was uneventful, so I won’t bore you with details; only pictures!

    6TB of Awesome! Internal USB with 8GB Boot Disk

    The Setup Process

    I went into the ESXi setup process thinking it was going to be this big battle that would take me all weekend. It actually took about an hour, and was so straight-forward I was kind of disappointed. This is all I did:

    • Downloaded and burned the ESXi 4.0 Update 1 Dell Customized ISO from VMware
    • Enabled “Virtualization Technology” under “Processor Settings” in the T110’s BIOS to turn on Intel’s VT-x
    • Changed boot order to flash drive first (the USB drive was recognized by BIOS without issue)
    • Installed ESXi 4 U1 from the disc to the flash drive, which the installer saw as a drive without any changes

    That’s really all there was to it. Based on VMware forum posts, this process was harder before Update 1 of ESXi 4, but it’s pleasantly uneventful now.

    Creating Servers

    Statler & Waldorf from The Muppet Show Once ESXi booted up, I was able to configure TCP/IP and host name settings using the text-based menu system on the machine. I christened the new box kermit (all my PCs are named after Muppets) and then installed the VMware vSphere client on my main Windows 7 machine to finish configuration settings and start making virtual machines. I ran into some issues cloning my base Windows Server 2008 R2 VM, but due to the length of this post, I’ll leave the details for another day.

    So far, I’ve got primary and secondary Active Directory controllers (affectionately named statler and waldorf), along with the accompanied DNS servers, running my home network name resolution. Unified logins and not having to mess with IP addresses or hosts files is pretty cool.

    Was It Worth It?

    With two servers performing networking duties and a third ready for configuration, I can easily say I’ve learned more about running servers in the past two weeks than I have in the last two years at work. I’ve had the need to dig into sysinternals a few times, learned quite a bit about Active Directory and was up until 3AM one night reading about DNS record types. I’m still not an expert, and probably never will be with such a small network to manage, but I’ve been having a ton of fun along the way. It’s been an effective learning tool for me so far, and I’m just getting started with what I want to do.

    In fact, ESXi is one of the coolest things I’ve played with in quite a while, so my only regret is that I didn’t look into it sooner.

    Comment3 Comments | |
    tagged in ,
    Friday
    Dec042009

    Adrenaline Junkies and Template Zombies

    DateFriday, December 4, 2009 at 1:00PM | AuthorKevin Rohrbaugh

    I’m a big fan of patterns, as I find that codebases employing well-known patterns (such as MVC) are much more approachable for developers new to a project, making them easier to maintain over their lifetime. Of course, patterns aren’t limited to just code, but are also found and applied in other fields, from architecture to medicine, because they help quickly communicate a shared understanding of a situation or approach. This allows discourse to more quickly move to the relevant bits, rather than just getting up to speed.

    My predisposition to patterns is one reason I enjoyed Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior by Tom DeMarco, Peter Hruschka, Tim Lister, Steve McMenamin, James Robertson and Susan Robertson.

    If you don’t recognize those names, it’s the Atlantic Systems Guild, the same group of people that wrote Peopleware. In Adrenaline Junkies and Template Zombies, the guild outlines common project and organizational patterns that they’ve observed throughout their careers. Many of the patterns tend to be anti-patterns, rather than traditional patterns you would want to emulate. This is also why so much of the book struck me as humorous, if only because they may be familiar from your own experience.

    My favorite pattern in the book happens to be the first one, which is Adrenaline Junkies. From the book:

    You probably recognize the characteristics of the adrenaline junkie organization: Priorities are constantly shifting; everything is needed “yesterday;” there’s never enough project time before delivery; every project is urgent; and the urgent projects just keep coming. Everybody is frantically busy . . . all the time.

    People in these organizations do not think strategically. Work gets done on the basis of its urgency alone. Unless a project’s “frantic factor” is high, it will be ignored – even though it promises a significant long-term advantage. It will remain ignored until it suddenly (surprise, surprise) becomes urgent. Adrenaline junkies believe that the best way to work is not by planning but by running as fast as possible.

    BMX rider jumping through the air - Photo by: Jesus Presley (Flickr) Most of us have probably seen individuals, teams or entire organizations exhibiting this behavior. It’s all too often to find an adrenaline junkie developer, as they tend to be the types who see their entire job as the act of writing code. If they aren’t writing code, they’re wasting time, since planning, design and research are more strategic actions and not directly related to that urgent bit of deliverable they’ve just been asked for. The pattern even highlights the fact that adrenaline junkie organizations tend to “enthusiastically embrace the customer service ethic: They confuse responding to urgency with admirable responsiveness.” The truth, of course, is that treating all requests equally based only on urgency, without thinking about the larger value (or even usefulness), is actually a disservice to your customer.

    The book’s goal is to capture and identify common patterns, and there are dozens of other patterns which are equally interesting. It only glosses over what can be done to fix projects or teams that exhibit anti-patterns, but understanding the behavior is the first step to addressing it in any event. It’s a good read that is likely to give you a better understanding for behavior you may encounter during your career, while also entertaining you. If you’re at all interested in the soft skill side of IT project work, I recommend checking it out.

    CommentPost a Comment | |
    tagged in
    Wednesday
    Nov112009

    When It Comes to Unit Tests, Names Are Important

    DateWednesday, November 11, 2009 at 2:00PM | AuthorKevin Rohrbaugh

    Like many developers, when I first started writing unit tests, I didn’t approach it with much discipline. It’s just test code, after all; no user is going to look at it. This led me to write test methods like this:

    [Test]
public void IdTest()
{
    // Test code here
}

    It’s easy to see how woefully inadequate this naming structure is, not to mention that appending “Test” to the end of every test method (when it already has an attribute declaring as much) is obnoxious. When I wrote unit tests like this, I typically used my unit tests (which often ended up actually being integration tests) only until I had a functional UI and then reverted to browser-based manual testing.

    Flash forward to the present, where I make sure that all my unit test methods are named using a pattern that I’ve picked up from the likes of Roy Osherove and others:

    [Test]
public void MethodUnderTest_ExpectedResult_GivenCondition()
{
    // Test code here
}

    Using this convention, each part of the test method name carries specific information:

    • MethodUnderTest: Specifies what method of the test class we’re exercising, scoping the test to a specific aspect of the class being tested.
    • ExpectedResult: Specifies what the test expects the results of calling the MethodUnderTest should be and scopes what our asserts for the test will be checking.
    • GivenCondition: Outlines the environmental or argument conditions that the test should run within.

    All three elements of this naming structure help to tightly define what it is that the test should be doing. This is critical as the primary consumer of unit tests is almost always the future developer, not the present one. In other words, we write unit tests to help us today, but a lot of their benefit comes when we make changes to the application in the future and can prove that individual components still work after those changes are implemented. If you’re like most people, using a test method naming convention that serves as a cheat sheet for what you were thinking when you wrote the test six months ago will come in handy and help make sure you preserve the intent of that test if/when it starts to fail.

    Here’s an example of a real unit test using the naming convention:

    [Fact]
public void Go_RedirectsToIndex_WithEmptySearchTerm()
{
    var searchTerms = string.Empty;

    var result = Controller.Go(searchTerms);

    var actionName =
        result.AssertActionRedirect().RouteValues["action"].ToString();
    Assert.Equal("Index", actionName, StringComparer.InvariantCultureIgnoreCase);
}

    It seems like such a simple thing to adhere to, but it’s made a world of difference in my test maintainability. It’s even made it easier to write tests, since the naming convention makes me think critically about what I’m trying to test. It’s great when a little change like this makes such a big impact on my day-to-day development.

    CommentPost a Comment | |
    in
    Page 1 2 3 4 5 ... 9 Next 3 Entries »