get-admin

As we all plug in and geek out with the latest web 2.0 this or social movement that. It is all dependent on one thing connectivity! Try watching a video on utube or attending a recording on ustream amidst some 26% packet loss. Trust me it doesn’t work!

The real problem here is that our ISP’s currently judge service by consumption not reliability. Think about it who cares if 1.21 gigwatts are available ever other minute. How about your water working most of the time? All these would be considered national tragedy. Yet somehow basic connectivity to the internet is still viewed as a luxury!

Well my name is Glenn Sizemore and I am an IT Professional. I hold one of those “high tech” jobs that politicians like to boast about. Last week I stood up a Virtual farm and this morning I helped erect a Citrix farm. This evening I was attempting to attend a weekly podcast recording. The key word there is attempting! You see Ustream doesn’t work with 26% packet loss. It’s sad really because as ideas were tossed around and opinions exchanged I watched as I missed the boat. This evening I missed something that would have made me a better worker.

In haste I contacted my ISP, Hey something’s wrong here!

Well sir I can ping your router is your TV working…. Seriously, is this really 2008? I have to manage a SLA at work that accounts for 15 min of downtime a year! Yet somehow my ISP is allowed to tell me that 26% is acceptable. I wish I had enough money to go directly to level3, but I don’t truth be told I can’t afford a backup. I leverage my bandwidth to carry my phone and other key services. Yet there is no recourse for me when it simply doesn’t work. This is crap…

Enough is enough… the year is 2008 and the internet is just as crucial as power or water. Losing it causes just as much pain to me and my family as those outages. Just like my power and water I’m not asking to run a datacenter or water park. I just want to know that when I turn on the facet or log in it will be there! The Difference is when I call my water company they fix it! My ISV is allowed to answer with well it works for me.

The internet is a utility as much as I’m against government regulation and oversight… the free markets are failing here. That or I’m not important enough to warrant service…..

The internet should be a Utility!

~Glenn

So here I go again… I hit another roadblock and I would like your opinion. As I go through the Netapp OnTap SDK I’m finding a lot of duplication. At first I went the VMware path and was building one Cmdlet for every possible task. This methodology is heavily dependent upon the pipeline for usability sake. For example take the following…

So that’s all great right? Here’s my issue NetApp has several API’s for both Volumes and Aggregates that are identical. Well almost, they perform the same functions, but take different parameters. So would you rather have 25 cmdlets that perform very specific tasks? Or 10 slightly more complicated cmdlets? I’ll elaborate a little further…

etApp has two base storage allocation methods and aggregate, and a volume. For those of you who don’t know a Volume is what you would concider a traditional raid. An Aggregate is a logical unit that contains Flexible Volumes. They perform the same exact function, but maintain different usecases. Therefor the OnTap API treat’s them seperatley even when they are performing the same function. i.e.

Raid Validation:
The process of validating the integrity of a given unit.

Cmdlet Start-NaVolVerify {
    param(
    [Parameter(Position=0,Mandatory=$TRUE,ValueFromPipelineByPropertyName=$TRUE,HelpMessage="Name of the mirrored traditional volume to verify. ")]
    [STRING]
    $volume,

    [Parameter(Position=1,HelpMessage="If provided, this specifies the plex to fix.")]
    [INT]
    $FixPlex,

    [Parameter(HelpMessage="[PSObject]NAserver (New-NAServer)")]
    [Netapp.SDK.NaServer]
    $server
    )

    $request = New-Object NetApp.SDK.NaRequest -ArgumentList @("volume-verify-start")
    if ($volume) {
        $request.AddParam("volume",$volume)
    }
    if ($FixPlex) {
        $request.AddParam("fix-plex",$FixPlex)
    }
    $result = Get-NaResult -request $request -server $server
    return $result.status
}

Cmdlet Start-NaAggrVerify {
    param(
    [Parameter(Position=0,ValueFromPipelineByPropertyName=$TRUE,HelpMessage="Name of the mirrored aggregate to verify")]
    [STRING]
    $Aggregate,

    [Parameter(Position=1,HelpMessage="If provided, this specifies the plex to fix in case the two plexes do not match. The default is to log any discrepancies instead of fixing them")]
    [INT]
    $FixPlex,

    [Parameter(HelpMessage="[PSObject]NAserver (New-NAServer)")]
    [Netapp.SDK.NaServer]
    $server
    )

    $request = New-Object NetApp.SDK.NaRequest -ArgumentList @("aggr-verify-start")
    if ($Aggregate) {
        $request.AddParam("aggregate",$Aggregate)
    }
    if ($FixPlex) {
        $request.AddParam("fix-plex",$FixPlex)
    }
    $result = Get-NaResult -request $request -server $server
    return $result.status
}

As you can see they are identical in use, and indeed perform the same task. The rational for keeping them separate is simple. Per the OnTap API within the Start-NaAggrVerify Cmdlet the target is specified via an “aggregate” parameter. Likewise the Start-NaVolVerify has an identical parameter but named “Volume”. As you can see the simple approach is to keep them separate, but when you consider that there are at least four Cmdlets dealing with verification, and at least five API’s like it. The Cmdlet count quickly get’s bloated and confusing (or at least I think it does). The alternative is to add a param and require more from the admin at runtime. Ala

Cmdlet Start-NaVerify {
    param(
    [Parameter(Position=0,ParameterSetName="vol",ValueFromPipelineByPropertyName=$TRUE,HelpMessage="Name of the mirrored traditional volume to verify.")]
    [STRING]
    $volume,

    [Parameter(Position=0,ParameterSetName="aggr",ValueFromPipelineByPropertyName=$TRUE,HelpMessage="Name of the mirrored aggregate to verify.")]
    [STRING]
    $Aggregate,

    [Parameter(Position=1,HelpMessage="If provided, this specifies the plex to fix.")]
    [INT]
    $FixPlex,

    [Parameter(HelpMessage="[PSObject]NAserver (New-NAServer)")]
    [Netapp.SDK.NaServer]
    $server
    )
    process {
        if ($volume) {
            $request = New-Object NetApp.SDK.NaRequest -ArgumentList @("volume-verify-start")
            $request.AddParam("volume",$volume)
        } elseif ($Aggregate) {
            $request = New-Object NetApp.SDK.NaRequest -ArgumentList @("aggr-verify-start")
            $request.AddParam("aggregate",$Aggregate)
        }
        if ($FixPlex) {
            $request.AddParam("fix-plex",$FixPlex)
        }
        $result = Get-NaResult -request $request -server $server
        return $result.status
    }
}

On the one hand I personaly do not like this approach because it leads to an obscure and misleading syntax, but it is the only way I know to prevent “cmdlet sprawl”. So what do you think is it okay to require one or three extra parameters per, or would you rather see separate perpouse built cmdlets? Keep in mind I’ve only converted Volumes, Aggregates, licenses, Disks, and Snapshots. That is a total of five out of 40+ regions and I’ve already amassed some 46 cmdlets!

Is there such thing as too many cmdlets?

~Glenn

And yes I know that all my code will break with ctp3… I would rather update it for the new syntax in dec. Then wait and be stuck in v1 fuctions, or code cmdlets! 

Your PowerShell session consumes 4GB of ram in less than 3 seconds…

Don't try this at home!

while I didn’t think vista was suppose to allow such things.  My code caused the crash not PowerShell itself!

~Glenn

Update:  okay so a decimal point blew it up!  The Netapp API returns the dtg in the form of a int64.  Without adding an explicit cast powershell treated it as an int.  What does that mean? Well it’s the difference between the following:

My code…
[datetime]::FromFileTime(116444916000000000 + ($_.”last-scrub-timestamp”) * 10000000)

At run time this became:
[datetime]::FromFileTime(116444916000000000 + 1.226210494E+16)

and it blows up VERY quickly, vs:

New code:
[datetime]::FromFileTime(116444916000000000 + [int64]($_.”last-scrub-timestamp”) * 10000000)

at run time:
[datetime]::FromFileTime(116444916000000000 + 12262104940000000)

Sunday, November 09, 2008 6:01:34 AM

I recently had to convert the DTG( Date Time Group ) from NetApp to Windows.  My tool of choice PowerShell! First things first what is the base of get-date.  Turns out that was the easy part.

A quick round of developer speak over at MSDN revealed that the base of datetime was 1 tick. A tick is defined as 100 nanoseconds… put that aside for a second. NetApp records time by the number of seconds that have elapsed since 1/1/1970 12:00 AM. So how do I convert NetApp seconds to ticks… The mathematicians in the room (calling you out Andrew) will certainly know a more elegant methodology, but this poor admin settled on the following.

First, convert 1/1/1970 12:00 AM to ticks!

Okay, so where do we go from here? Remember that number from before 100 nanoseconds… This is where it got fun. Since the NetApp reports in seconds since 1970, and DateTime works in ticks. What we really need is to convert seconds to ticks. Well a quick live search (okay so I used goggle but live is getting better!) revealed that there are approximately 10000000 ticks in a second. Knowing that, the formula should be something like (Ticks to 1970) + ((seconds since 1970) * (number of Ticks in a second)).

Does it work?

I Love this shell! Now my example is not a very general purpose one, but the core logic doesn’t change.

Recap:

[System.Datetime] - core time measurement is a tick.

Tick – a tick is 100 nanoseconds.

Seconds - There are 10000000 ticks in a second.

~Glenn

Oh yeah and PowerShell ROCKS!

PowerShell virtual user group meeting #7 will be on Thursday November 13th 2008!  It’s been a while since Marco has put one of these together.  Understandable given all the work he does.  If you’ve never attended one before I highly recommend it.  Looks to be another all start lineup with Nathan Winters (MVP), Joel ‘Jakul’ Bennett, and a product demo by Ideara (cross your fingers for Tobias!).   Remember these events are participation driven so, Go HERE NOW! 

See you there,
~Glenn

UPDATE:  I’ll be in Chantilly on the 13th  with a little luck I’ll get an (early am|late pm) flight back to Augusta, and be able to attend!

So I basically haven’t slept in two weeks. I thought it would be a good idea to pick up the torch, and contribute on the NetApp Ontap SDK to PowerShell. I’m sure you’ve seen the Codeplex project by now if not here. I have a couple of personal issues with this first swing, and initially I set out to help. Two weeks later I have completely rewrote the whole cha-bang. I’m not a dev, and I don’t pretend to know as much as Adam. I am however an Administrator who uses PowerShell and NetApp’s every day. From that perspective I’m writing what I need the cmdlets to do. Very quickly I ran into a style issue… My question to the mob is simple of the three examples below, what would be your preference?

[1]PS > Get-NaDisk –disk v0.20| Fail-NaDisk –force

[2]PS > (Get-NaDisk –disk v0.20).FailDisk()

[3]PS > Get-NaDisk –disk v0.20 | set-NaDisk –Fail -confirm:$false

What do you think? One is the most intuitive, but will lead to over 500 cmdlets! Option two is the least intuitive, but would produce the tightest code. Finally option 3 per the PowerShell team documentation option 3 is the “correct way of doing it”…  I wan’t to use option 1 but It requires the use of an illegal unaproved verb “Fail”.

Help…

~Glenn

UPDATE: My basis for not using Fail-NaDisk. Although, I believe that Fail-NaDisk is more in line with the spirit of powershell.

We’ve been having some strange issues at work with our email archive solution. The “fix” from the vendor, was to install some software on all of our backend exchange servers…. Yeah that’s how I felt about it as well. Being the kind of change that you must test it was time to set up a lab. I grabbed my white board and wrote down what was needed.

1 Domain Controller
3 Exchange Servers
2 SQL servers
2 WIN2K (email archive)

Without really even thinking about it I opened PowerShell, and went about getting this done. Four commands and 1hr later we were installing exchange!

[28]PS>Get-VirtualSwitch -VMHost (Get-VMHost esx15) -Name DEV04 | New-VirtualPortGroup -name “192.168.232.0″ -VLanId 900

[29]PS>$folder = New-Folder -name DEV04 -Location (Get-Folder vm)

[36]PS>1..8 | % { New-VM -Name “EMAILDEV$($_)” -ResourcePool (get-ResourcePool ADMIN_DEV) -Location $folder `
-Template (get-template WIN2K3_ENT_x86) -OSCustomizationSpec (Get-OSCustomizationSpec WIN2K3_ENT_x86) `
-datastore (get-datastore vmdata0) -VMHost (get-vmhost esx15) -RunAsync }

[263]PS>Get-Folder DEV04 | get-vm | Get-NetworkAdapter | Set-NetworkAdapter -NetworkName “192.168.232.0″

A couple of things to note it took 4 or 5 -whatif attempts to get the new-VM cmd right, and the hour was waiting for the vm’s to deploy.  I know that there is nothing new here, but I often see too many “case studies” with powershell… they overcomplicate things.

yesterday I solved a problem with Powershell.  I didn’t write a script.  I didn’t need v2 remoting.   Just four very simple yet incredibly powerful commands…    Give it a try some time just open posh, and TRY to solve a problem… I’ll admit that it is daunting at first, but after a while the reward is ten fold.

~Glenn

P.S. Did I mention that the VI Toolkit is friggin amazing!

I confess… Sometimes I just need Linux. I’ve tried everything from live disks to running an “Administrative” VM.  The main problem with all of them is the break. What would take 5 min if I could do it from within windows, takes 30min and destroys my thought process along the way.   There are tools that I can run from within windows.  Unfortunately most of them either suck or cost too much.  I don’t have room for another PC/thin client at my desk, and I’m NOT giving up my Vista rig… What to do?

Enter DSL (Damn Small Linux) I stumbled upon this little treat on accident a couple weeks back. They have many versions available and I’ve played with several, but the QEMU VM is simply brilliant.

Not only is It easily configured, but the dang thing just works.  Now when I need to modify a config file on a NetApp, or fix a VMX. I fire up DSL, it launches as a windowed app (on my vista x64 rig!).  90 seconds later I’m logged in and continue working, NO break in work flow!

Couple disclaimers: I still hate it, and think it is beyond legacy, but there is no fighting it anymore. Some form of UNIX will always be in the data center.  So for now I’m using DSL to fill that gap…  Got a better solution?

~Glenn

It just keeps getting better!  I have personally mentioned the need for a PowerShell SDK to NetApp several times.  The funny thing is both their engineers, and professional services guys never understood why I would want such a thing.  This is a weird paradox with POSIX guys.  They seem to think that connecting via ssh and writing bash scripts is all that is needed.  Sometimes Perl is invoked to provide a higher level of abstraction.  I guess their view is only Linux/Unix guys are going to want to automate this stuff.  It’s the classic windows stereotype; Windows guys only know how to drive the GUI. 

We’ll adweigert saw things differently, and has started converting the Perl SDK into a PowerShell SDK.  At this point it is still very early, but he has already added quite a bit of functionality.  The SDK is currently in the form of a single ps1 script.  Which is actual rather cool, because while I’m not a dev.  I am an OnTAP Administrator, and PowerShell scripter. I can actually contribute to this!

I’m very excited to get to work Monday and give this baby a whirl!  Check it out http://www.codeplex.com/PowerShellOnTAP

~Glenn

Short of walking around the Venetian shouting “anyone else like PowerShell”.  I did everything i could to evangelize the product, and find likeminded individuals.  The giant posh sticker on my laptop didn’t hurt in that regard.  The one thing I did find when talking to these guys is they are starved for content.  Sadly most of them knew only of the vmware community forums.  Don’t get me wrong Lucd is amazing, but that is just a small piece of the community.  I was very disappointed that neither Carter nor Dimitri Dmitry mentioned any of the resources out there for people. 

I was however blown away by VMware and their commitment to the product.  Quest manned a booth in VMware’s exhibit.  For three days I never saw that booth empty.  They were also handing out copies of powergui, some stickers, and a card… Hal you’ll be pleased to know that I saw many handed out, but not one on the floor.  After the PowerShell session I was talking to a couple VI admins, and one of them recommended your book to me!

~Glenn

(Update:  Don’t read into my post that I didn’t enjoy/value Carters presentation.  I thought it was easily top five for me, and he made the case why VI admins need to learn PowerShell.  My point was that once they start that journey.  The more tools you provide the likeier they are to succeed!  Oh yeah and sorry I mispelled your name Dmitry!)