This week I was asked in an email the following question:

[By the way I hate WordPress - even when I put paragraph returns in this post it ****ing well removes them!]

Hope you been doing well. I have been busy, busy, busy.

Got a question for you. Preparing to start a new vSphere farm and trying to decide do I use stand switches or start with the DVS. Especially when I see this: http://www.ntpro.nl/blog/archives/1283-vSphere-DvSwitch-caveats-and-best-practices!.html So the main question is do we think this is mature enough to go forward with yet? Can I use Host profiles with DVS safely?

Just appreciate your thoughts.

Apologises for my tardiness in getting back to you. Snowed under. You get the picture. So I’ve written you this lovely long email to make up for that. Gee, this could be blog post! [How ironic - it did become a blogpost!]

A couple of things come to mind. Firstly, Eric’s blog post – I do respect Eric’s blog (and others). Things have gotten so big in VMware – that it would impossible to know of all the known/unknown issues – after all no man is an island, and no-one ever see’s all the possible configurations and screw-ups….

BUT. (you could tell that was coming). Untimely, ripping an ESX host out of vCenter (right-click disconnect/right-click remove). Isn’t the recognised procedure. Yes, I know tardy/slapdash admins might have done this in vCenter1/2 but isn’t something that’s recommended or recognised as the right way. It should always be regarded as the LAST resort.

So if people first removed ESX from the DVS, before removing the ESX host this problem would NOT happen. Basically, what Eric is saying is if you don’t step A followed by Step B followed by Step C then problems can occur. But problems will always occur if you not aware of relationships.

So Eric post would not put me off using DVS for Service Console/Management Network traffic or vmkernel traffic for that matter. I think there’s tendency when people read blog post about new technology that we focus on the bad news, rather than the good. Also people forget (rather conveniently) about what was awful about the previous technology (in this case Standard vSwitches) which they moaned and complained about before the advent of the new. So there’s tendency to re-write the past as some golden period before all this new stuff came about….

I’ve used host profiles with DvS without a problem. For me the bigger question is not whether they can be “depended on” or “safely” used in production- but the reality of what they are like to use on daily basis…. Do they make your admin/configuration any easier. Whilst I love DvSwitches, I’m not at all armoured of Host Profiles. Neither are helped by being shackled to the most expensive SKU of vSphere you can buy!

I like DvS… I especially like them for virtual machine networking. But I see them as being less useful for Management and Vmkernel Ports (not bad, just less useful) because you still have to configure the IP configuration of the ESX host.

Of course, VMware’s answer to that would be to use host profiles. For me – I look at the different ways I might get that IP configuration on to the ESX host. I know the more I manually have to do stuff, the more errors I’m likely to make thru fat-finger-syndrome. Also, If I have to hand the build process to someone less experienced I want to automate as much possible to prevent accidental errors…. This is also tempered by what type of ESX the customer is using. If they using ESXi it rules out kickstart %post scripting and using my UDA appliance…

So lets say I’m doing bulk admin. Building 100′s of ESX hosts, do I really want to sit there apply the host profile to each and every host. As I applied the host profile to N host, it would stall as it asked for my management, VMotion, iSCSI, FT logging, HA Address IP addresses. If you think about the number of IP’s you need for an ESX box (if you follow to the recommendations to letter you end up with quite a lot). Five IP addresses (and their associated subnet masks!)

So when I think of bulk admin & host profiles –  I don’t think they add up. Have I ever created an IP conflict by applying the host profile to many ESX hosts? Yes, an I only have 4 bloody ESX hosts!

I have PowerCLI scripts which automates EVERYTHING I would want to do (and more) than Host Profiles are current capable off. It did take some time to learn PowerCLI and test my scripts. But time is something I have plenty of when I’m not teaching. I wouldn’t say I was the most gifted of scripters – but I don’t care as long as it works, and works reliably.

My PowerCLI script will add a host into vCenter and completely configure it – include things that host profiles cannot do… such as iSCSI and DPM settings. The other thing I don’t like about host profiles – is the fact the host has to be maintenance mode to apply them.   So they can’t really be used as a reconfiguration tool – because who wants to move 20-30 VMs just to add a port group – when something like PowerCLI could do that infinitely quicker with just a couple of lines of script. That more or less relegates the host profiles to being a “consistency” check too – like ConfigControl without the licensing (another product that should be included in the core vSphere4 product!!!).

What’s irritating about host profiles – is that I think if you did have 100′s of ESX hosts you would want something that was more automated than host profiles. The smaller/medium shops won’t buy enterprise+ so they won’t benefit. When I teach VMware, it’s at this moment that I mime to my students – taking a gun from the wall – loading it up – and then firing it at my own foot. It always makes my students laugh.

Can you see what I’m doing here? I’m not arguing against DvS/Host Profiles per se. I’m looking at the technologies and what I might trying to achieve with them – and seeing if they help or hinder. Like anything it depends on the environment and the skills of the person involved. So here’s what I’m recommending in the book:

• New to Product/Admin with no time/aptitude for Scripting
  ESXi+vCenter4+DvS+Host Profiles. Essentially, drag-and-drop management strategy….
• Admin with plenty of time/aptitude for scripting/100′s of Servers
  ESXi or ESX “Classic”+vCenter+DvS+PowerCLI. I know this guy would not be disappointed with PowerCLI. They are adding another 60 cmdlet in time for vSphere4.1….
• ESX 2/3 Admin who has an existing kickstart scripted environment” –
  Don’t re-invent the wheel. Use ESX Classic+KickStart (UDA)- with a view to moving over to PowerCLI, ready for the demise of the COS in vSphere5 (circa 1012?).

  R.I.P. COS

I don’t know what category you fall into. You see host profiles could benefit everyone – the more ESX hosts – the more benefits they are. But then you have to buy this damn + product to get them. It’s just madness.

As for DvS. You could take a hybrid attitude on that. This appears to be the consensus view at the moment. That you use Standard vSwitches for management & vmkernel – and leave DvS just for VMs. This seems to be because Standard vSwitches are more of a “known quantity” than DvSwitches. I had hoped that host profiles would see of end of scripting and scripted installation, but nothing seems offer the same flexibility of things like the EDA/UDA and PowerCLI…. If you really mad about scripting then PowerCLI is the way to go. Hence my recent move away from “Classic” to ESX4i, and using PowerCLI.

And Finally…. I’ve been using DvSwitches for everything since the beta. I’m firm believer in using new technology in lab environments like my own – the more exposure you get to technology the more comfortable/confident you become with it. Plus it gives you the edge on folks who might be more production/conservatively minded. I’ve had no problems until I make an admin error. Like the day I removed vmnic0 from DvSwitch0. But hey, I could have done that with Standard vSwitches as well.

I now know how to fix both it they get broken, and that does impress my students.

This entry was posted on Friday, November 6th, 2009 at 5:53 pm and is filed under ESX, vCenter. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.