Another guest post from Tech Support Engineer Mike Bean speaking casually about a few observations and a couple of tips.
Good morning lords and ladies, I know I missed last week, but what can I say, you can’t keep a good technical support engineer (or me!) down! First and foremost: I absolutely MUST call attention to something that crossed my twitter feed a few days ago.
Great day in the morning, why is this not on the front page of the VMware support page in bold lettering? I’m sure you can probably imagine, this is a frequently requested thing. I don’t know if it was only recently automated, or if we just didn’t know it was there, but rest assured I’ll be talking to the building manager about having a 4 story banner sign hung on the side of the building overlooking US36 (in Colorado). (I’m kidding, we don’t actually need a 4 story sign, two stories will do just fine!)
On a side note, one of our employees fairly high in the knowledge base chain of command came to my humble cubicle this afternoon! VMware management has been nothing but supportive of my efforts, but it became clear fairly quickly that neither she nor I had a clear picture what, if any impact these blogs are having. I’ve said it before, I’ll say it again, I read my fair share of technology blogs and listen to quite a few podcasts, and generally, the best give the public what they want.
ESX or diet ESX
Since my arrival at VMware, I can say safely that a fair amount of time and energy has been put into the distinction between ESX, and ESXi, and I’ve had at least a few conversations with various customers to that effect. The unwelcome truth, is that it’s not an overly simple subject. Usually by the time a customer arrives in my queue, they have a few preconceptions, and it’s usually because their managers told them “X”, or our sales force told them “Y”; but it’s a subject worth exploring in greater detail. When you have a clear picture of how ESX is supposed to look, it’s generally a lot easier to fix when something’s wrong.
I alluded briefly to the service console in a previous blog. What, IS, the service console? We’ll let our product design engineers hash out a specific definition. For our purposes, it’s enough to think of the service console as a linux virtual machine that exists to help your manage your host. Think of it, like a maintenance hatch. Don’t confuse the service console with VMkernel, or vice versa. Usually, if you need to call global support services, it’s almost always a good idea to have some form of root access to the service console ready first! Learn how to enable root SSH login here.
Which more or less brings me to my first point, the primary difference between ESX, and ESXi, from an operations point of view, is that ESXi has no service console. It doesn’t take a specialist to see that poses certain security and footprint size advantages. The service console, is a potential point of weakness, and without it, ESXi can sometimes be considered inherently more secure. At least, that’s the typical argument for using ESXi over ESX. Why then, use ESX over ESXi? You may well have heard rumors by now, that VMware’s focus is on ESXi. To the best of my knowledge, those rumors are completely true. Why then, would anyone choose ESX?
Simple, the service console is a linux derivative. Generally, anyone who’s familiar with Red Hat, will probably feel right at home. That means that ESX (classic) is SUBSTANTIALLY easier to maintain. Commands and techniques that work on ESX, don’t work on ESXi, and vice versa. Ultimately, when customer asks me on the phone, “What should I use?”, I generally tend to advise my customers to plan according to our commitments, not our conversations. For the time being, we are committed to and supporting, both ESX and ESXi. So most of the time, a consumer should choose between ESXi’s enhanced security benefits, and smaller memory profile, and ESX’s ease of use.
Please be aware, some men and women far smarter than myself are working very hard to bring ESX’s ease of use to ESXi, and I have every confidence that they WILL succeed. In the meantime however, when customers choose ESXi, I usually try to suggest to them that they familiarize themselves with certain tools.
ESXi lives almost COMPLETELY in RAMdisk!
This is relevant because EVERYTHING inevitably enters an error state sooner or later. It’s the nature of software. If ESXi does enter an unrecoverable state that forces you to reboot – it loses the contents of RAM, and becomes VERY difficult to diagnose. For this reason, I ALWAYS recommend the use of an external syslog server! (Syslog is a redhat protocol that ESXi can be configured to use.)
See our Knowledgebase article: Enabling syslog on ESXi
This isn’t the easiest thing in the world to configure, but when you do enter an error state that forces a reboot, you’ll have your system logs to fall back on, and that, is a substantial advantage! It only takes one outage incident for a syslog server to pay for itself in spades!
vMA
Familiarize yourself with the vMA (vSphere management assistant). Think of it as a portable service console for your ESX host. The vMA, and the CLI interface it contains, understands many of the same commands as the ESX service console. Use it to connect to your ESXi host, and you’ll regain a great many of the commands ESXi lost.
Check out: vSphere Management Assistant (vMA) [appliance for vSphere CLI, vSphere SDK for Perl, and SMI-S]
-AND-
vSphere Command-Line Interface Installation and Reference Guide
Feel free to hate me while you’re learning it ;). I’ve been working in ESX administration & troubleshooting for years now, and even I still find the vMA/CLI a little challenging. That said, trust me, you might not like using it today or tomorrow, but there will come a day when you won’t know how you lived without it. Syslog and the vMA are essential tools, practically the Batman and Robin of ESXi administration, and your environment will almost certainly be better off for it!
That’s all for this week, to reiterate, in conclusion, don’t be shy about letting the knowledge base team know what you like! If we’re doing things right, let us know so we can keep on trucking! More importantly, there’s an awful lot of possible subjects out there, so if there are topics you feel are weak or just flat want to know more about, send us a shout-out/ping.
Live well!
