You may be playing around with virtualisation on the edges of your IT environment or be well down the road to making it part of the furniture. But what happens when something goes wrong and it’s not immediately obvious what the problem is? If the issue looks as though it is related to a software application provided by a third …
Never had any problem as long as it was a supported software stack.
But then again I don't use x86.
Simple fear of the unknown
I've repeatedly hit the brick wall of "Oh, you're using virtualization? Replicate the problem on physical hardware and then we'll talk." And every single time, the problem has been with their software and not the virtual environment. The short of it is that if the problem where the environment it would be experienced by several, if not all, applications.
@Jamin W. Collins.
Over and over and over and over. Of the the biggest banes of my existance, that.
Not just virtualization
I see the same 'unsupported' issues with virtualized servers - but it isn't just virtualization that highlights this, it's any excuse that they can throw up in the hope you'll give up and go away.
Why does financial software or other business applications, clearly not intended for use anywhere except a corporate environment, still expect that the users running it every day have full administrator rights when that has not been good practice for some time? Typically this is only because it's been (badly) written to store some config file in 'Program Files' or worse still, the Windows directory and is simple enough to get round (although I still don't like having a chunk of filesystem writeable by end users) but try arguing that with the support monkey following a scripted list of questions.
The vendors constantly lie when they say "It's the virtualization." Too many vendors have "support" staff paid to come up with excuses to do nothing, rather like health "insurance" companies here in the Ce Sha Ah. Given that fact, I've for years known better than to even tell them that we're virtualizing anything, particularly when it's gobsmackingly obvious that virtualization has zero relationship to the problem at hand. If they find the kernel modules when they run their support tools, then they're smart enough to have a reasonable discussion with. Otherwise, to hell with them.
more supportable when virtualized
Virtual hardware is more generic and standardized, and more insulated from hardware quirks. Plus you have options for cloning and snapshotting (that aid in patching, trouble-shooting, upgrading, etc.) that aren't available to physical servers. Virtual servers are more apt to be single-purpose, so there's usually less interaction with other third-parties.
Software is not only easier to support in a virtualized environment, but more stable to from the get-go.
BTW, is it because you mispronounce it "zed" that you Brits drop z from so many words?
The most frustrating experience for me is the repeated "sorry virtualisation is only supported in version xx.x.x" argument. What a load of twaddle 99.9% of applications don't get anywhere near the real hardware and it's just another attempt to push you to pay for the upgrade.
A VM is essentially new hardware
From a certification perspective a VM is essentially new hardware, and new hardware certification isn't something that is just done in 5 minutes. Running software on a VM is -NOT- the same thing as running that same software on a non-virtualised machine, no matter how accurate the VM emulation is, and it is not possible for software vendors to guarantee that software designed for a non-virtualised environment will work equally well in a virtualised environment, especially when you start doing things with the VM that you can't do in a non-VM like pause the machine and wake it up again several days later: from the software's perspective the clock just jumped forward by several days for no obvious reason and any time-dependent software (job scheduler etc) will need extra testing to make sure it still works fine and does what it's supposed to do when that sort of thing happens like catching up with jobs it might have missed while it wasn't awake, or if it was in the middle of a job when the clock jumped forward that the sudden time change doesn't have any adverse effects.
What, you mean like when the user adjusts the clock, or it syncs with an external time server?
Lie. It saves time.
Too many times in the recent past I've had vendors play the 'we don't support xxx virtualisation' for this app 'card' (this includes MS Office, with a telephone re-activation issue after a 'VMware Converter' migration - was told they wouldn't support office activation under VMware Workstation, only ESX!! Ended up just renaming the %allusers%\application data\microsoft\office\data.dat file, as per normal, and it activated fine).
Nowadays I don't mention that it's running in a virtual environment *at all* unless the vendor asks the question as part of the troubleshooting. eg "Hey, is this, by any chance, running on ESXi 3.5?"
F*ck them and their shoddy excuses to get off the phone. So far I've yet to have an application issue actually relate to virtualisation.
Don't give them the excuse
I have to say it's not often I've met flat out rejection from vendors when logging issues on VM's, but as a general rule I don't volunteer the info that their system is running on ESX. If they ask, or it's required info, I say so, but I never bring it up because they tend to latch on to it too easily. Usually they can be quickly persuaded to look beyond that and at the actual problem, though.
- Vid Antarctic ice THICKER than first feared – penguin-bot boffins
- Hi-torque tank engines: EXTREME car hacking with The Register
- Review What's MISSING on Amazon Fire Phone... and why it WON'T set the world alight
- Product round-up Trousers down for six of the best affordable Androids
- Antique Code Show World of Warcraft then and now: From Orcs and Humans to Warlords of Draenor