Yes, it's virtual, but that's not the reason...

DigitalZeroOne

For anyone that works with VMs, either VMware or Hyper-V, or whatever your platform. You notice how if something acts up on the guest OS, the immediate reason must be because it's a VM, so they go to the VM guy? I get plenty of people that come to me because they have an issue with a VM, and they come to me because they think since it's a VM, and there is a problem, that I'm the person to fix it.

I always try to delicately let them know that it's probably an OS issue (after I make sure it's not a VM issue), but they always come back to me. These guys are Sys Admins, not regular users, but it's always the same issue. I always ask what changes were made, and invariably there was some database update, or software installed, or some action on the OS that precipitated the problem.

Oh well, no problems, no job.

it_consultant

All the time, especially with people that don't really understand virtualization or are suspicious of it.

cyberguypr

Been there. At my previous job it was either the backups or the virtual servers. 90% of the time it was their buggy in-house applications or incorrectly implemented 3rd party crap.

QHalo

Usually it starts with the network, then it rolls uphill.

Essendon

With our SAN admin within earshot I say - It must be the SAN.

I too have system owners walk up to me complaining of poorly performing VM's and when I have a look it's usually some upgrade they've done to their application.

emerald_octane

My old boss was extreme if someone blamed our VM infrastructure for performance issues. He would pop open VCenter and start whipping up all types of charts and graphs then start calling other guest owners to talk about how awesome their vboxes were running.

undomiel

Yep, countless times I've had a coworker come to me complaining about the performance of their VM only to find that it was something they did to it. Or, I'm having to go back and fix host and network configurations because a coworker didn't understand what they were doing or thought that they could do it better.

Surprisingly enough one of our largest clients never suspects the virtual infrastructure. They always assume that they did something wrong but they're just not quite sure what.

jmritenour

I haven't every really heard anyone blame things on the fact that it's running on a VM, but I've had many a vendor give me the cold shoulder when they find out their application is running in a VM, saying "we don't support virtualized instances of our software." Fun stuff.

Zartanasaurus

People always blame the components they understand the least.

It's always the network or the firewall or the fact it's a VM or the database is sitting on a cluster or.... The fault usually lies with the person asking.

blargoe

Quoted for truth.

My approach lately has been to actively monitor the performance characteristics of my VMs, and when I notice a change or a red flag, I bring it up immediately to the application owner, both as a public service and as a way to keep things from continuing to deteroriate to the point that they are having problems "because it's VM".

My IT director still will not allow any database to be virtualized because "it causes problems", and until recently blamed previous issues on VMs on not having full memory reservations on everything. The tide is slowly turning, though.

Zartanasaurus wrote: »

People always blame the components they understand the least.

It's always the network or the firewall or the fact it's a VM or the database is sitting on a cluster or.... The fault usually lies with the person asking.

Essendon

blargoe wrote: »

My IT director still will not allow any database to be virtualized because "it causes problems"

I get the exact same thing too!!

it_consultant

Oh yes, the great fear of virtualizing databases. I just read some documentation on running SQL in Server 2012 hyper-v, it almost performs better than if it was sitting right on the bare metal.

JBrown

blargoe wrote: »

Quoted for truth.

..
My IT director still will not allow any database to be virtualized because "it causes problems", and until recently blamed previous issues on VMs on not having full memory reservations on everything. The tide is slowly turning, though.

Your Director has a reason for that. There are rules to follow before virtualizing a database, you are looking for a disaster if its not done per the book. Databases tend to love memory and CPU cycles, especially when a database administrator runs a query with a wildcard to find a single row with the data she needs- and does it over and over, instead of selecting the fields she really needs- and uses up 24GHz of CPU cycles for 45 minutes.
She has never been pointed out that doing so -using "select *" on large databases- is a big no no in a database administration field, and she never had this "problem" because nobody monitored their database (physical) server for CPU/Memory problems.

blargoe

JBrown wrote: »

Your Director has a reason for that. There are rules to follow before virtualizing a database, you are looking for a disaster if its not done per the book. Databases tend to love memory and CPU cycles, especially when a database administrator runs a query with a wildcard to find a single row with the data she needs- and does it over and over, instead of selecting the fields she really needs- and uses up 24GHz of CPU cycles for 45 minutes.
She has never been pointed out that doing so -using "select *" on large databases- is a big no no in a database administration field, and she never had this "problem" because nobody monitored their database (physical) server for CPU/Memory problems.

Oh, I know that... his stance seems to be one that VMware and SQL just "don't play nice", nothing to do with potential negligence or admin error. Little out of the box, self contained apps that come from a vendor with a SQL database that does nothing other hold a config are included in this mandate.