The Importance of Knowing the Internals

I know things have been a bit quiet around here of late, most of my spare time is going to my recent editorial duties! But once that is over, things will be taking a slightly different turn around here. I’ll be going back to my roots. Back to the internals. Why? Well the thought kinda kicked off after something Massimo said a few weeks back on Twitter. I completely agree with that on many levels. But on others, I don’t. And the grounds for the “don’ts” are pretty much based in laziness, much in the same way that scripting guru’s are generally the laziest people to be found (yes Lam and Dekens, I’m looking squarely at you :P).

Private Cloud: Build or Buy?

I totally forgot about this… a few months back Jo Maitland asked if i was interested in doing a webcast for SearchCloudComputing on the subject of Private Cloud: Build or Buy. Although I do sound like a broken record in places, and I’m not sure if I actually addressed the subject that well (I interpreted the question as build = internal and buy = external, but didn’t actually say that), it’s not a bad listen if you have a spare 30 minutes and you’re a large shop about to embark on the private cloud journey.

Check it out here.

Boot a VM from iSCSI? Yes. We. Can!

I was having a chat with someone the other day and we got onto the subject of that most excellent open source project, Etherboot/gPXE. For the uninitiated, gPXE is basically a replacement for the ancient PXE ROM found in pretty much all NICs today, and brings network booting into the 21st century. It gives us the ability to use alternative protocols for the boot media, instead of being restricted to TFTP as the current PXE ROMs generally are. If you want to know more about why this A Good Thing, check out this video.

Anyway, the question was asked if it was possible to boot a VM from iSCSI directly without any involvement from VMFS. Having actually done this quite some time ago, I knew it was possible so I said “yes”, but unfortunately I couldn’t access the memory region that held the answer to the logical next question (how?), and I had to say “I’ll get back to you”.

The only way to do this on physical hardware without using chain loading (ie PXE booting some other program and loading gPXE via it) is to burn the gPXE ROM onto the NIC (I’m conveniently throwing gPXE boot via CD/floppy/USB into the chain loading bucket). Obviously this is not something you would want to entertain with VM’s. But luckily for us, VMware gives us the ability to actually specify a separate file to use for the NIC BIOS! So it’s really quite straightforward, here’s how to do it:

1. Go to the ROM-o-Matic website and create a boot rom with the following options:

2. You should now have a file named gpxe-1.0.1-8086100f.rom.

3. Create a VM with an e1000 NIC.

4. Upload the gPXE ROM file into the same directory as the .vmx file of the VM you just created.

5. Add the following line to the .vmx file:

e1000bios.filename = "gpxe-1.0.1-8086100f.rom"

6. You’re done – you can now take advantage of everything gPXE has to offer.

I tested this out on ESXi 4.1, and it still works like a treat. Why do you need to use an e1000? gPXE doesn’t currently have support for VMXNET3. Since it’s an open source project, perhaps someone from VMware could make that contribution?

Eating Your Own Dog Food

This is a post I’ve been meaning to write for a while now, but for one reason or another I kept putting it off. So when Mike Laverick asked me about what subjects I wanted to cover in my Chinwag, I finally got around to talking about it in public. I say in public, because this is something I and many others been saying to VMware behind closed doors for a bloody long time now. And as Mike pointed out during the Chinwag, there’s certain sense of irony in applying this phrase to VMware, given that Paul Maritz is credited with inventing it (or at the very least popularising the saying in the IT world) over 20 years ago.

I’m not writing this post to be inflammatory. Nor do I feel the need to justify my comments any more than what was said in the Chinwag. I just feel that a little more clarity and elaboration is needed – when we started on the topic the conversation was skirting around several things at once, all of which were pretty negative. And although I wouldn’t go as far to label those first 20 or so minutes as “VMware bashing”, I can understand how it might be seen that way. So let’s get that straight – when I say VMware should eat their own dogfood, I mean it constructively. I’m not talking about stuff like vCloud Director 1.0 requiring a database from the least-VMware-friendly company on the planet, or that the vSphere Client isn’t supported as a ThinApp package. I’m talking about something much more fundamental than that. I’m talking about glass houses and throwing stones.

Chinwag With Mike!

It was long overdue, but a few weeks ago I finally got around to having a chinwag with Mike Laverick. I say long overdue, because he asked me ages ago and I just never got around to it! This is the second video I’ve been in lately, the other was the very last VMworld TV recording in San Francisco (which ironically also had Mike in it, and Justin).

I wanted to have a post ready to go to elaborate more on the whole VMware / dogfood bit, but as you’ve noticed I’ve been pretty busy lately (ie very quiet on the blogging front). And I guess it’s OK for me to say why… I am very proud to say I am the technical editor for the upcoming PowerCLI book from Al, Luc, Glenn, Arnim and Jon! And let me tell you, it ain’t easy when you’re dealing with masters like those guys.

Anyway, I hope you find the chinwag entertaining / interesting, and big thanks to Mr Laverick for asking me on. As I say at the end, if it wasn’t for Mike I might not have gotten far in this field and even this blog might not have gotten far – he was the first one to give me a shout out way back in the day, and my readership grew exponentially for a while after that. So again, Mike, thanks for everything.

I'm Not One to Drink the Kool-Aid, But…

You all know me – I’m not the kind of person to be swooned by hype and marketing bullshit. But I have to say, the Maritz / Herrod keynote at VMworld this morning was an absolute blinder. Never before have VMware delivered a keynote that was so clear in it’s message and so visionary on so many levels. And once again, VMware are leaping miles ahead of the competition right when it looked like they were in danger of being caught. Sure, there were a few laughable claims regarding open standards (hows that LLDP and LACP support in the networking stack coming along?) but aside from that it was very, very refreshing to hear Paul Maritz saying things like “this is gonna happen with or without VMware” when talking about Cloud. If only all the vendors in this industry could be so mature.

Of course, the big announcement (for me anyway) was around the release of VMware vCloud Director. And while it looks completely awesome, the devil is in the implementation detail and I’ll be putting up some posts next week to talk about some of the not-so-shiny aspects of the product – someone’s gotta talk about the other side of the coin (why is it always me though!). But for now, I’m just gonna enjoy the Kool-Aid 🙂

While I’m here, I have been completely blown away at the number of people I have met, had really, really good conversations with, revealed my identity to, and had them come back with stuff like “NO WAY! You’re vinternals!?!?!” and then punched me in the face given me a big ol’ slap on the back. Seriously people, thank you all very much for the kind words. As a blogger, it’s really hard to tell how engaged your audience is – you can’t really tell that from “number of unique visitors” type metrics. So thanks for reading, and I’m really flattered that you guys appreciate what I have to say – it makes it all worthwhile.

PowerShell and Proxy Auto Detect Problem

Just a quick one about this issue that has been plaguing me for ages. Like many people in corporate world, the browser on our corporate build is configured to point to an “automatic configuration script”. But perhaps unlike many corporates, the script at the place I work is f_huge_. And for some reason, this has introduced a problem for a particular .NET assembly that is associated with the System.Web namespace… the same namespace that is used by PowerShell when making web connections, such as when you invoke Connect-VIServer in PowerCLI.

The result is that powershell.exe starts chewing up memory like there’s no tomorrow… basically until your entire machine hangs. Lucky for me I don’t need to use PowerShell in anger on a daily basis, but this problem was enough for me to resort to running a vanilla XP VM whenever I needed to do stuff with PowerShell. But thankfully, someone took the initiative and looked into the problem with Microsoft, discovered the root cause, and a workaround. And so let it be known that I don’t get any credit for this post, but the person who should cannot be named for stupid corporate communications policy reasons.

And so here’s the workaround. Basically, you need to add the following to the powershell.exe.config file in the same directory as the powershell executable (both locations if you’re on an x64 machine – just create the file if it’s not there):

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
 <system.net>
  <defaultProxy>
   <proxy autoDetect="false"/>
  </defaultProxy>
 </system.net>
</configuration>


Et voila! Problem solved. Not sure if any other .NET apps are affected by this, but any PowerShell scripts that directly invoke System.Web.Client (for example) will be – I have a script to grab UUIDs via the iLO interface of HP boxes, and got the same problem whenever I invoked that script. But not anymore, hooray!

VMworld US, Here I Come!

That’s right folks, this time next week I’ll be en route to San Francisco! I hope to meet many of you in person, and will be at the following social events during the week – if you are at any of these and want to shake hands (or punch me in the face), please seek me out! I’ll be sporting a vinternals t-shirt at the VMunderground and VMworld parties for easy identification (yes, I have 2 of them :)).

Saturday 28th
7pm onwards : vBeers San Francisco

Sunday 29th
7pm onwards : VMunderground Party

Monday 30th
4 – 7pm : VMworld Welcome Reception
9pm onwards : VMworld 2010 Tweetup

Tuesday 31st
5:30pm onwards (probably, but not necessarily in this order)
NetApp Virtualisation Community Party
EMC Customer Appreciation Party
Veeam Partay

Wednesday 1st
5:30 – 7:30pm : vExpert Party
7:30pm onwards : VMworld Party

Thursday 2nd
8pm onwards : v0dgeball (go vSquirrels! :D)

Really looking forward to meeting all the vFriends I have made over the years in person!

Removing Complexity from the Orchestration Layer

I’m pretty sure that most people have figured out by now that the Cloud really has fuck all do with technology. Or at the very least, the technical challenges are the least of your concerns – it’s really all about the operating model. The implications of this new operating model stretch to pretty much every part of your IT organisation as it exists today, however I would argue that most of the changes are things worth doing anyway even if you have zero intention of moving to the Cloud. I like to collectively term these things “The Art of Cloud Without Cloud”. In this post, I’ll take a look at the orchestration layer.

Favourite Vim Colorscheme?

First of all, yes that spelling is correct because it is a Vim keyword – not English 😛

I’m sure you’ve noticed things have been a bit quiet around here lately… no I didn’t get attacked by sharks on my holiday, but I did decide to take the plunge and turn my attention to learning Python in more depth. Actually, that’s just a small part of where I’m going – I’ve started to wean myself off Windows! That’s right, no more PowerShell, no more C#, no more Visual Studio… in fact if it all works out, the only thing I’ll need Windows for in the future is gaming.

Of course you can learn Python just as easily on Windows as you can any other platform, but I like to develop in the same environment I plan on deploying to. Which means getting familiar with a terminal based development environment, which basically means getting familiar with Vim. But alas, the standard Vim colour schemes just didn’t cut the mustard for me, and after trying a few on it came down to a choice between darkburn, and BusyBee.