The Atomic Unit of Compute

This post is part of a series based on a presentation I did to the London VMware User Group on February 25th, 2010 about the reality of Enterprise scale internal cloud platforms. To find other posts in the series, just look for the tag “Bringing the Cloud Down to Earth”.

Bonus content When I first started putting together my VMUG presentation, it was actually solely focused on this particular topic. I’ll link to the original presentation at the end, as I think it’s better if you read the post first.

Another of the challenges you’ll face along the way of Cloud is that of how to measure exactly what it is you are offering. But having a look at what the industry is doing won’t give you much help… as with so many things in IT, there is no standard. Amazon have their EC2 unit, and state that it is roughly the equivalent of 1.0-1.2GHz of a 2007 Opteron or Xeon CPU. With Azure, Microsoft haven’t gone down the same path – their indicative pricing/sizing shows a base compute unit of 1.6GHz with no indication as to what is underneath. Rackspace flip the whole thing on it’s head by deciding that memory is the primary resource constraint, therefore they’ll just charge for that and presumably give you as much CPU as you want (but with no indication as to the characteristics of the underlying CPU). Which way should you go? IMHO, none of the above.

Engage Support Early

This post is part of a series based on a presentation I did to the London VMware User Group on February 25th, 2010 about the reality of Enterprise scale internal cloud platforms. To find other posts in the series, just look for the tag “Bringing the Cloud Down to Earth”.

Last post I talked about challenging convention, but you can go too far in doing so. Depending on the depth of your operational knowledge of the environment you work in, it’s easy to do just that and if you don’t consult with the ops teams until the last minute you could be in for a nasty surprise. And so the best thing to do, even if you think you know how things run, is to get operational representation onboard early. Like day one of the project early.

Challenge Convention

This post is part of a series based on a presentation I did to the London VMware User Group on February 25th, 2010 about the reality of Enterprise scale internal cloud platforms. To find other posts in the series, just look for the tag “Bringing the Cloud Down to Earth”.

In the previous post, I talked about some of the things that you should think about before going ahead with an internal Cloud project. And I ended saying you should challenge the way things are done currently if they are impossible or very difficult to automate. But there are other things you should also challenge that aren’t directly related to automation, and I’ll cover some of those now.

Garbage In / Garbage Out

This post is part of a series based on a presentation I did to the London VMware User Group on February 25th, 2010 about the reality of Enterprise scale internal cloud platforms. To find other posts in the series, just look for the tag “Bringing the Cloud Down to Earth”.

The notion of GIGO is of course much older than I am, but it’s one of those concepts that is timeless. In relation to Cloud, it’s more pertinent than ever. The marketing hype would have you believe that Cloud is a panacea, and many people hawking their wares artfully dodge the subject of your existing tools and processes. But ignore these at your own peril. The COO of the company I work for has a great quote, which goes something like “God made the earth in 6 days, because he started with a clean slate.”. The same is true of internal Cloud (or whatever you want to call it – I’m going to call it that for the sake of convenience) – you could probably nail down the platform code and functionality that you want to launch with in a few weeks, but making the requisite changes to existing processes and integrating with existing tools in your environment is what will take the lion’s share of time to address.

Bringing the Cloud Down to Earth

Well the London VMUG has come and gone, and I’ve had my 15 minutes of fame… actually maybe a little bit less, time was a bit short and I rushed it a little bit. As with most VMUGs, it’s hard to gauge the level of experience and size of environments in the room. To some people, 1000 VM’s is a lot. Others have ESX host counts around that number. So I wasn’t sure how relevant people would find my presentation, but I felt the information was worthwhile presenting anyway.

As the title suggests, I was talking about some practical considerations (10 of them to be precise) that you should think about if you’re looking to develop an Enterprise scale internal compute cloud – which I am very proud to say I can speak about with experience as our first platform release went into code freeze 2 weeks ago and is currently in UAT. I am hoping at some point we’ll be able to go public with what we have, time will tell.

But in the meantime, have a read of my presentation and let me know your thoughts (I’m still closing comments on here 2 weeks after each post due to the high amount of spam, but you can always get me on twitter or email vinternals at gmail dot com). The presentation is suitably minimalistic, and so I will embark on a series of posts talking to each slide in order to bring some clarity to the points. So if anything in there interests you, be sure to keep an eye out on Twitter for post announcements over the next few weeks!

vSphere 4.0 Quick Start Guide PDF Edition!

A shameless self promotional post, but I never blogged about this when it was released and it’s never too late to do the right thing :D.

I personally have a huge preference for reading books in PDF format, a little while ago one of my favourite publishers APress had a deal whereby if you had a physical copy of the book, you could get the PDF version for a ridiculously low price. But we’ve gone one better… you don’t even need to own the physcial book, you can still get the PDF from lulu for a mere $10 USD / £6 – that’s less than 2 pints!

vSphere 4.0 Quick Start Guide PDF version

And don’t forget to grab the PowerShell scripts via Duncans site, even if you don’t have the book or PDF they are totally free!

Next London VMUG, Feb 25th 2010 – I'm Presenting!

Yes that’s right, I was very flattered to be asked to present at the next London VMUG and just couldn’t say no to Piglet (illustrious London VMUG co-ordinator). The more people there, the more nervous I am bound to be so let’s have a massive showing and try to give me a nervous breakdown! If you haven’t been before, be sure to register by sending an email to as per the announcement. And a personal thankyou to Pano Logic for sponsoring the event this time round – it couldn’t happen without the sponsors, it is very much appreciated.

As for the topic, I’ll be talking about real world Enterprise Cloud but in a sufficiently generic way – I’m talking as ‘stu the blogger at vinternals’, not ‘stu the employee of Company X’ (Company X’s competitive advantage will remain safe! You hear that, senior managers at Company X who don’t even know about let alone condone this blog? No need for alarm!). I will not be mentioning any products either, so regardless of the technology platform or what stage you are at with your own Enterprise Cloud implementations, hopefully you’ll find the discussion useful. Or not, you might think I’m talking complete shit. But you won’t know unless you go, so why not come along and tell me what you think in person (over a beer afterwards :D).

ESXi 4.0 Security

I’ve been wanting to put up a post on ESXi security for some time now, and 2 recent posts have kicked me into action – this one from Scott Lowe about setting the root password on ESX and this announcement about the vSphere blogging contest :D. So have your caffeinated beverages and pizzas at the ready, we might be here a while!

Strangely, and disappointingly might I add, there is no vSphere 4 Security Hardening Guide available currently (UPDATE: A draft version has now been published – I’d like to think the release had something to do with this post, but in reality I’m sure it is merely a coincidence!) – the only published security guidance we have from VMware is the old one for VI 3.5 and the Security section in the ESXi Configuration Guide. While this situation sends a negative message to security types who may wonder if this lack of documentation is indicative of VMware’s approach to security (vSphere has been out for nearly 9 months now), when it comes to ESXi 4 not a lot has changed so most of the ESXi parts in the old 3.5 document apply equally to ESXi 4 and are covered in the ESXi Config Guide anyway. Before anyone flames me about that comment, I don’t believe VMware has a weak stance with regards to security and I am NOT one of the aforementioned security types – I have had to deal with them however, so I am speaking from experience.

Useful Linux VM Tweaks, Part 1

I’ve called this Part 1 because as I mess around more with Linux VM’s I have no doubt there will be more posts like this one. Don’t expect anything earth shattering in them either… this is all easily obtainable info, it wouldn’t surprise me if I get comments suggesting better ways to do what I have done (and I encourage such comments so I can learn!).

For this first installment, I’m going to cover a very small customisation I make to the startup scripts on my Linux template machine, which is currently based on Ubuntu 8.04.3 JeOS edition.

At this point in time, I basically only make 2 small changes. First, to save me from having to login and run ifconfig to find out what IP address the VM has, I modify /etc/issue to display the IP address above the login prompt. The other thing that really bothers me is the PC speaker beep. Yes I know you can disable this by adding an option to the .vmx file, but I would rather do it within the VM so I (or other people) can deploy via OVF and get a consistent result without needing to modify .vmx files. So I remove the module that is responsible for enabling the PC speaker.

So here is what I add just above the exit 0 line of /etc/rc.local

# Clear screen
clear

# Build /etc/issue
HEADER="Ubuntu 8.04.3 LTS \l"
KERNEL=`uname -sr`
IP=`ifconfig eth0 | grep 'inet addr:' | cut -d: -f2 | awk '{ print $1}'`
echo "$HEADER :: $KERNEL :: $IP" > /etc/issue
echo >> /etc/issue

# kill pc speaker
rmmod pcspkr


Which produces the following nice looking screen, ready for me to SSH into the box

If you have any similar favourite small tweaks for Linux VM’s, please share them in the comments!

Get Only ESXi 4 Updates in VUM 4

One of the (many) things that bugs me about VMware Update Manager is the fact that I can’t specify to only pull down ESXi updates. I doubt there are many large enterprises that will run both fat and thin ESX in production for any length of time, I know I wouldn’t. And sure it’s “only” metadata if I never actually scan an ESX host, but it pollutes the VUM interface with millions of entries for fat ESX that I will never care about. So maybe I’m a little bit OCD about stuff like that, but there you go. Luckily I can do something about it though, via the use of a custom patch source and a little XML hacking.