When can I get bailed out?  I’ve made several bad decisions in my life and I’d like to be compensated for them. And by “compensated” I mean “massively compensated, like dump trucks full of cash.” After all, why should I be responsible for my own actions and decisions?

If I were Honda or Toyota I’d be getting my lawyers ready to sue a lot of people.

Question/Issue:
Is ESX server VMotion supported with SAV and SEP?

Solution:
Symantec does not support ESX server VMotion at this time.

Vendors are shameless. They charge you a ton for support, then they’ll do whatever they can to point the finger at somebody else when you call.  It’s one thing to put a disclaimer in for performance issues. Virtualization sometimes exposes weird performance issues, and if it’s a performance issue you’re having you might need to do some work to troubleshoot it on your own if it isn’t a blatant, completely reproduceable problem with the vendor’s software (like CPU-sucking spin locks).

It’s another thing to say that their software isn’t supported at all, or to say that a problem must be reproduced on physical hardware. Most of the problems I’ve ever called a vendor about are explicit functionality problems (bugs).  Physical hardware, virtual hardware, it doesn’t matter: their software just doesn’t do what it’s supposed to.  A vendor’s support staff should be competent enough, and professional enough, to sort out a bug report from a performance problem and act accordingly.

Oracle doesn’t support anything in VMs (as per an Oracle employee last week to me). Lyris doesn’t support anything in VMs (last time I checked, a few months ago). Symantec doesn’t support anything in VMs (technically they said VMotion, but for an enterprise VMotion goes hand in hand with VMs). What other vendors are as clueless as these three? I think I’m going to start making a list.

Example #1: a web site with a blog, where the blog is at /wordpress instead of /blog. What happens in five years when you have 50,000 readers and want to switch to another software package? Do you really want to maintain clumsy redirects from /wordpress/feed/ for the rest of your natural life? Don’t name your service after the software brand name or manufacturer, name it after what the service is. It’s a blog, not Wordpress. It’s the payroll system, not Kronos.

Example #2: naming a server “payroll.company.com” because it runs the payroll software. What happens when you want to replace that server? Do you create a machine as payroll2.company.com and have everybody switch their clients? Do you stay up all night or all weekend sometime building a new machine as payroll.company.com? Wouldn’t it be easier to give the machine another name, maybe based on its location, maybe based on nothing at all (”terminator.company.com”), and just use payroll.company.com as a service CNAME in DNS? That way you can build the new machine in parallel, and run the old machine for a while after you’ve cut over, in case you need something from it.

Example #3: not using DNS to abstract services all the way through an implementation. It isn’t just the front door to a service that can take advantage of abstraction. The guts of implementations benefit, too. Instead of telling your payroll software that its database is on terminator.company.com, register a CNAME for payroll.db.company.com. Or payroll-db.company.com. Or something, anything, so that when you replace terminator.company.com with alien.company.com you don’t have to hunt down and change every obscure script that might refer to the database. Just move the CNAME to the new machine and everything will continue to work.

So get with it, people. Every time you create a new system or implement new software ask yourself what sorts of abstraction you can add to make your life better. Think five years ahead to when the system or software will need replacing. Similarly, it’s never too late to add abstraction to a system if you didn’t do it from the start. The few minutes it takes to set up things like CNAMEs in DNS will often save lots of time later, even if you didn’t build it in originally. Consider it an investment.

[Interesting side alley: I was talking to a friend yesterday and encouraged her to speak at an upcoming conference. She said, "No way. I don't know enough." I explained that volunteering to speak was the best way to be sure that she'd end up knowing enough by the time she was through.]

I agree completely — the best way to learn something is to teach it. Not only does it force you to be prepared, but the questions you’ll get from the audience are often more enlightening than anything you’d ever read.

Because AMD was late to release its quad-core processor, Barcelona, Intel has dominated the hardware market with their Xeon quad-core CPUs. “As such, AMD basically locked themselves out of the virtualization market, because there wasn’t any cross-compatibility, and everybody who built a virtual environment did so with Intel CPUs,” Plankers said.

I’ve never been a big fan of AMD hardware because every time I try using it I’ve been bitten by some problem. Large page table support was hosed on the Athlons I had, making Linux installs hard. I had weird driver issues on a desktop I built a few years ago. And there’s the broken caches on Barcelona. The devil is always in the details, and AMD doesn’t seem to sweat the details.

On the other hand, AMD is very innovative. They find their way out of marketing and technical problems pretty well, such as how to get themselves back in the game when they’re locked out. They find a lot of ways to keep Intel honest, force pricing down, and be a better value. If they’d just mind the details once in a while and do some better testing they could use their innovations to push the technology forward (like they did with their 64-bit instruction set), rather than just trying to catch up with Intel all the time.

Future versions of VMware ESX/ESXi will only run on 64-bit-capable CPUs.

You will still be able to run 32-bit guest OSes, but the ESX console OS will only work on CPUs capable of Intel VT & EM64T. This is a big deal for two reasons:

1. Dell doesn’t let you enable VT on anything but the PowerEdge 6850, and all ninth-generation servers (x9xx) and beyond. There are a lot of Dell PowerEdge 1850/2850s out there that will still be in use over the next few years. I suspect equipment from other manufacturers, like HP, is similarly affected. This means a lot of people will be stuck at current ESX levels (ESX 3.5.x) for a while until they can get new hardware. That also means that if you want to use some of the new features, like Continuous Availability, you might have to budget for an upgrade.

2. It’s pretty common to recycle old hardware down into test environments, but now you might not be able to do that in the next replacement cycle. If you have, or will have, hardware capable of Intel VT in production make sure you’ve done something to make your VMware test environment VT-capable, too. Even just budgeting now for a VT-capable test server is a good proactive move, to be purchased once the software is actually released.

I have no idea when the next version of ESX will ship, but it’s worth thinking about this sort of stuff now so you can budget for it and have a plan[0]. Even if you decide that the plan is to do nothing and wait.

If you want to test your CPUs to see if they will support 64-bit OSes you can use the VMware CPU Identification Utility. It’s a bootable ISO image that will tell you what you need to know.

To reiterate: ESX console OS going 64-bit, you will still be able to run 32-bit guest OSes, you will need recent hardware to support the 64-bit console OS, and VMware has a tool to tell you where you stand.

——————–

[0] While you’re getting things added to your company’s budget have them add a trip to VMworld 2009 in San Francisco.

Some of my photos are below for you folks to enjoy while I get my act together here. :-)

MySQL documentation states that replicating from a 5.0 master to a 5.1 slave should work. This is very different from stating that it does work. That section of the manual should enter the 5.1 no-use case competition.

Frankly, I hate the word “should.” To see it in vendor documentation like this is terrible, because it’s a weasel word. It puts the onus of testing and support on the end user, and gives the vendor a cop-out when it doesn’t work. “Well, we only said it should work, not that it does.” Not saying that MySQL does that, but other vendors certainly do.

For me, seeing “should” in this situation always translates to “does not” when I start thinking about the reasons for the hedging. Have they not tested it? Maybe they have tested it but it fails sometimes and they haven’t figured out quite why. Maybe they want to say it “does” work, but they just need to qualify it with more criteria they haven’t documented yet.

Regardless of the reasons, and for most people who need to rely on features like this for production systems, having “should work” in your documentation is functionally identical to not having the feature at all.