Virtualisation and vendor support 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 …
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.
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.
This post has been deleted by its author
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.
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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
