A couple of things come to mind. Things have gotten so big in VMware – that it would be 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, 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 it isn’t something that’s recommended or recognized as the right way. It should always be regarded as the
So if people first removed ESX from the DVS, before removing the ESX host this problem would
NOT happen. Basically, if you don’t do step A followed by Step B followed by Step C then problems can occur. But problems will always occur if you're not aware of relationships.
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 a daily basis…. Do they make your admin/configuration any easier? Whilst I love DvSwitches, I’m not at all armored 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 through fat-finger-syndrome. Also, If I have to hand build the 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 are 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 and 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.
ever created an IP conflict by applying the host profile to many ESX hosts?
, and I only have 4 ESX hosts!
I have PowerCLI scripts which automate
EVERYTHING I would want to do (and more) than Host Profiles are currently 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 100s 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 try 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:
I don’t know what category you fall into. You see host profiles could benefit everyone – the more ESX hosts – the more benefits there are. But then you have to buy this + 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 the end of scripting and scripted installation, but nothing seems to offer the same flexibility of things like the EDA/UDA and PowerCLI…. If you're 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 a 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.