Bye, bye Service Console

This isn’t just another article about vSphere 5. It’s not my aim simply to rattle off a list of new and improved features. There are probably a plethora of those posts out there already, some better than others – use Google to find them. Smile

I was inspired to write this after I saw white paper linked to on Twitter about the differences between ESX and ESXi written by Global Knowledge. Actually it was the responses to that article that prompted me.

Of all of the many changes announced today, it is the departure of the Service Console that is perhaps the most significant in my view. It may not be a new, super-whizzy feature and many people are already using ESXi and might be thinking “so what”. For me, removing the COS / SC / Service Console is significant for two reasons.

Firstly, no longer can the unenlightened refer to vSphere as “Linux based” or “Unix based”. ESX never really was that and it wound me up more than it should have done when people got it wrong. I have a strong Microsoft background (although I can hold my own when it comes to Unix / Linux OSs) but in some companies that seemed to exclude me from touching VMware infrastructure even though I knew all about it. Ok, that’s more of a pet peeve than a significant reason.

My other one though is that to me this signifies the direction in which VMware are taking virtualisation. It may even be more accurate to say that dropping the Service Console marks the completion of a transition or a journey. ESX was an excellent way for enterprises to make efficient use of powerful hardware amongst many other benefits but there was always a glass ceiling there.

Some say that ESXi isn’t as flexible because it doesn’t have a command line. Perhaps they don’t realise that it really doesn’t need one. Occasionally, when things go wrong, SSH access is useful and ESXi does provide that. But for day to day usage there are better and more efficient ways to manage a Virtual Infrastructure (PowerCLI, vCenter or one of the many VMware and 3rd party products) and dropping the Service Console is both recognition and reinforcement of that. ESXi turns the hypervisor into commodity or utility platform, it’s not a management interface in its own right. ESXi is a foundation stone for building a dynamic, automated infrastructure so forget about the Service Console now.

In some ways I’ll be sorry to see it go but ESX was a means to an end and it has reached its end.

Creating VLANs in DD-WRT (Part 3)

In the second part of this post I completed the setup of VLANs on my WNR3500L router. To make them available to hosts (and VMs) I now have to configure my Cisco SLM2008 switches.

Fortunately that turns out to be fairly simple. The SLM 2008 has a web-based GUI that does the job nicely. Once logged in it’s a matter of opening the VLAN >> VLAN Settings page. Then just tap in the VLAN ID that you want to create and click “Add”.

This then drops you into an additional page where you choose which ports to associate the VLAN with. I picked all of the ports on this switch (where my ESX hosts are located). Then I clicked “Save”.

It’s just then a case of repeating for the other VLANs that are required. And that’s the switches done. The default configuration of them doesn’t require any further tweaking.

Within vSphere, the configuration required should be obvious. Here’s a screenshot from my ESX host with a portgroup called “Test” defined.

It has a VLAN ID of 6 and one VM in it with an IP Address of It can reach the router’s primary network, the internet and be contacted from my main network and wireless clients.

Exactly what I want for now.

CloudCamp – The Return

It’s been about a year since I last went to CloudCamp. In honour of my return and as an homage to CloudCamp London’s compere, Simon Wardley, I have adorned this post with a suitable image. Ta-da! (For those who are bewildered, Simon has a fixation with kittens in his presentations.)

The reason that it’s been so long since I attended a meeting (that sounds bad but you know what I mean) is that I found them to be a bit similar and not really relevant to what I was doing at the time. A few changes in personal circumstances also had an effect. But, having recently started a new job where cloud computing is very much a part of it, I felt the time was right to go again. It also helped that the venue for this meeting was in the crypt at St James Church, Clerkenwell – just a 5 minute walk from my office.

Armed with a beer and in the company Mr Radnidge (@vinternals) what follows is a brief overview of the evening (partly at the request of Ed Grigson (@egrigson) and Simon May (@simonster), neither of whom could be there).

Things kicked off with Simon Wardley’s presentation. His thoughts about what had recently been bothering him about cloud included a number of slides, themes and thought streams from his presentation to OSCON 2010 (you can see that presentation here or view the slides here) but it wasn’t nearly as long. He spent a couple of minutes explaining cloud in terms of Everett Rogers‘ theories around the “Diffusion of Innovations”. Essentially this boils down to new technologies being adopted in a fairly predictable way over time as they evolve and mature.

Assuming that I’ve interpreted him correctly (remember the beer), cloud services were presented as being at the top end of this curve (i.e. computer consumption is fairly ubiquitous and mature).  The screenshot on the right is the slide that I’m referring to here (the y-axis is ubiquity).

Whilst from a computing perspective that’s probably true, if you consider cloud as a separate product type then I’d argue that it is much further down the curve. There is still debate about what cloud is and there is a great deal of innovation still going on. Add to that the adoption of cloud services is fairly low (at least as far as enterprises are concerned) and I think that you end up with a different picture.

That’s just my opinion. I could be wrong and I’d be happy to talk at length with anyone on the topic. Don’t get me wrong or shoot me though, I still enjoyed the presentation and it’s given me a lot to think about on its own.

After that warm up, things moved on to the lightning talks. For the un-initiated these are 5 minute presentations on cloud related subjects that are supposed to be vendor neutral, not about consulting and should avoid lots of speculation about the future.

One of the talks (that got laughs for the wrong reasons – problems with the slide deck) was about trust and security in the cloud. Another was about the Cloud Legal Project, a Microsoft funded but independent study into cloud service contracts. I found this one very interesting not because I’m a closet lawyer or anything but because it’s something that’s often over-looked and could have quite significant consequences at some point. It could also be a barrier to entry for some enterprises where the cloud is concerned. In fact, it was so well received that it actually ran over its 5 minute slot.

After the lightning talks came the “un-panel”, chaired by Joe Baguley (recently appointed Chief Cloud Technologist at VMware) and featuring volunteers from the audience. Discussion and questions focused heavily on cloud legalities (further evidence that the CLP presentation struck a chord), agility in the cloud, trust / security and the barriers to cloud adoption presented by the older generation.

I’m not going to give a blow-by-blow account of the discussions. I came away though with several things to think about it more depth though. Well worth the time spent in my opinion.

Once the meeting was wrapped up it was beer and pizza time. Time to chat with other attendees and presenters. I got to chat for a while with two alumni (Dan Young and  Dimitri Koutsos) from a hosting company that I used to work for as well as having a long chat with Guy Chapman about a whole range of topics.

Cloud services and solutions are about more than just the technology and it’s those bits, the thinking bits, that CloudCamp is for. An evening well spent in my opinion.

Creating VLANs in DD-WRT (Part 2)

In the first part of this post I created some VLANs on my NetGear WNR3500L router that I’ve flashed with DD-WRT firmware. In this second part of the post I will be assigning IP address ranges to those VLANs and configuring the router’s firewall.

I want the VLANs that I setup previously to use separate IP Address ranges. To do this it’s back into to the telnet session and enter the following command:

nvram set rc_startup='
ifconfig vlan6 netmask
ifconfig vlan7 netmask
ifconfig vlan8 netmask
ifconfig vlan9 netmask
ifconfig vlan10 netmask
ifconfig vlan11 netmask
ifconfig vlan12 netmask
ifconfig vlan13 netmask
ifconfig vlan14 netmask
ifconfig vlan15 netmask

ifconfig vlan6 up
ifconfig vlan7 up
ifconfig vlan8 up
ifconfig vlan9 up
ifconfig vlan10 up
ifconfig vlan11 up
ifconfig vlan12 up
ifconfig vlan13 up
ifconfig vlan14 up
ifconfig vlan15 up

(There is actually a way to do this step through the router’s GUI too.)

Reboot the router again for the changes to take effect.

The final configuration that needs to be made is to the internal firewall of the router. With all of these new interfaces created, we need to define some rules to permit (or deny) traffic between them.

Now I could have just turned the firewall off but that wouldn’t be a very good idea. Instead I modified the rules. For a single VLAN (VLAN 6 for example) the following commands were required:

iptables -I INPUT -i vlan6 -j ACCEPT
iptables -I FORWARD -i vlan6 -o br0 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan6 -o ppp0 -m state --state NEW -j ACCEPT

The first line allows traffic from VLAN6 to talk to the router. The second line allows VLAN6 to talk to the default LAN network (VLAN1). The final line allows VLAN6 to access the WAN interface (internet).

There are two ways of applying these rules. The first is by executing the following on the router’s telnet interface:

nvram set rc_firewall='
iptables -I INPUT -i vlan6 -j ACCEPT
iptables -I FORWARD -i vlan6 -o br0 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan6 -o ppp0 -m state --state NEW -j ACCEPT'

The other method is to use the GUI. Under Administration >> Commands there is a text are to enter the commands. Then all you need to do is click the “Save Firewall” button to have the commands take effect at the next reboot of the router. Additionally you can click the “Run Commands” button to execute them immediately. (Bear in mind though that commands run immediately are not persistent across a reboot.)

I thought that would sort everything out so I made the same changes for all of the VLANs. However, when it came to using those VLANs I discovered that although the could “talk” to the internet and to wireless clients, they could not “talk” to each other. This meant a revision to the firewall rules that I set out above was required.

Whilst working out what I needed, I discovered that a wildcard character exists and that what I wanted to achieve could be done in just 4 lines:

iptables -I INPUT -i vlan+ -j ACCEPT
iptables -I FORWARD -i vlan+ -o br0 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan+ -o vlan+ -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan+ -o ppp0 -m state --state NEW -j ACCEPT

Line 1 accepts input from any of the VLAN interfaces into the router.

Line 2 allows any traffic coming from the VLAN interfaces to access the bridge (this is connected to the RJ45 ports and the wireless)

Line 3 allows traffic to come from any VLAN and go to any VLAN (this was the rule I was missing the first time around)

Line 4 allows traffic coming from any of the VLANs to go to the internet.

However, a quick word on the internet (WAN) interface, ppp0, and security in general. The WNR3500L router does not have an ADSL modem in it. (I have a separate one of those (Draytek Vigor 120)). Configuration of the WAN for my environment is therefore completed using the PPPoE protocol and hence the WAN interface gets called ppp0. If you use this router with cable broadband (e.g. Virgin Media) you may end up with a different WAN interface name. Not only will you have to adjust the rules above accordingly, you need to make sure that you don’t inadvertently open up a gaping security hole!

Which is why it might be best to stick the following rules into the router instead of the ones above:

iptables -I INPUT -i vlan6 -j ACCEPT
iptables -I FORWARD -i vlan6 -o br0 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan6 -o vlan+ -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan6 -o ppp0 -m state --state NEW -j ACCEPT
iptables -I INPUT -i vlan7 -j ACCEPT
iptables -I FORWARD -i vlan7 -o br0 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan7 -o vlan+ -m state --state NEW -j ACCEPT
iptables -I INPUT -i vlan8 -j ACCEPT
iptables -I FORWARD -i vlan8 -o br0 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan8 -o vlan+ -m state --state NEW -j ACCEPT
iptables -I INPUT -i vlan9 -j ACCEPT
iptables -I FORWARD -i vlan9 -o br0 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan9 -o vlan+ -m state --state NEW -j ACCEPT
iptables -I INPUT -i vlan10 -j ACCEPT
iptables -I FORWARD -i vlan10 -o br0 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan10 -o vlan+ -m state --state NEW -j ACCEPT
iptables -I INPUT -i vlan11 -j ACCEPT
iptables -I FORWARD -i vlan11 -o br0 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan11 -o vlan+ -m state --state NEW -j ACCEPT
iptables -I INPUT -i vlan12 -j ACCEPT
iptables -I FORWARD -i vlan12 -o br0 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan12 -o vlan+ -m state --state NEW -j ACCEPT
iptables -I INPUT -i vlan13 -j ACCEPT
iptables -I FORWARD -i vlan13 -o br0 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan13 -o vlan+ -m state --state NEW -j ACCEPT
iptables -I INPUT -i vlan14 -j ACCEPT
iptables -I FORWARD -i vlan14 -o br0 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan14 -o vlan+ -m state --state NEW -j ACCEPT
iptables -I INPUT -i vlan15 -j ACCEPT
iptables -I FORWARD -i vlan15 -o br0 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan15 -o vlan+ -m state --state NEW -j ACCEPT

Whilst it’s not as elegant a solution as the one with the wildcards, it is more specific and hence more secure and I’m not an iptables expert so I’m going for the safer option. Also note that in the above example, I’ve only given VLAN6 access to the ppp0 (internet / WAN) interface.

That’s just the simple firewall changes that can be made. More complex setups can be achieved but you need to know what you’re doing. There’s an introduction to IPTABLES that can be found on the DD-WRT site.

That’s it for the router’s configuration. In the third and final part of the post I describe how the VLANs are defined on the Cisco SLM2008 switches that I have connected to the router.

vExpert 2011… Surely not?

“Don’t call me Shirley!”

I love that joke but “surely not” was my response when John Troyer’s email popped into my inbox this morning.

Since that time I’ve had a veritable deluge of congratulations from all quarters. Along with the award itself that means a lot to me so this is a big public thank you to everyone really, especially John Troyer and vExpert panel.

Obviously the bar has been set now. Time to get my bottom in gear.