You must be at least > < smart to work in IT, pt1

2010-03-31 15:17:25 by chort

Today is has yielded a bumper-crop of FAIL from various organizations out there. Here is a sampling of the head-scratching stupidity.

Is the your VMware virtual appliance certified for XYZ hardware?
A company is asking if a particular virtual appliance, designed to run in VMware, has been certified with their particular hardware. HELLO, the hardware seen by the appliance's OS is VIRTUAL, it doesn't know what fscking SAN you're using, it shows up as a VMware hard drive.

Have you ever looked at a BSD or Linux OS boot up on a VMware console? Notice how pretty much every device is either identified as "virtual somethingorother" or a totally different vendor than what the actual device is? THAT'S BECAUSE THEY'RE VIRTUAL DEVICES YOU NINCOMPOOPS! The whole point is that the OS doesn't have to have distinct support for thousands of devices, it only needs to support VMware it will work on anything that VMware works on.

If your shiny new hardware works for VMware, it will work for any virtual machine in VMware. The virtual appliance couldn't identify your hardware even if it tried to, because VMware won't tell the VM what it is. If you're too dumb to understand this, perhaps you should deploy your apps on Lego Mindstorm(tm). That sounds like more your speed.

Why is stupidity incompatible with high-availability?
A company is deploying a web app service that requires session-persistence. As part of the HA strategy the vendor has two datacenters, each with their own VIP and multiple servers behind each VIP. The company is supposed to create a DNS A record with both IPs and a TTL of greater than the length of the session time-out, but short enough that clients will fail-over to the second datacenter if the first is down. Usually this is set to an hour, but this company sets it to one day.

Soon after deployment, the company complains that the app is unusable. Their sessions keep timing-out. On investigation it's revealed that their clients issue a new DNS request before every HTTP request, effectively meaning their browsers bounce back and forth between the datacenters during a session. Well of course a service that relies on DNS is not going to work if you ignore DNS standards. Hi, the TTL is there for a reason. It's how long you're supposed to use that answer for.

The company refuses to address the non-standard behavior by their clients, and insists on a work-around. The obvious solution is to simply remove one IP from their DNS record, so there's only one left. Now they complain that they don't have any fail-over. Really, it's unacceptable that the vendor doesn't support your broken DNS resolution, but you were willing to accept a one-day wait to fail-over via DNS (that's the TTL you picked)?

But it works in BillyBobLinux 11.0! Yours must have a bug.
A few companies trying to deploy a virtual appliance on vSphere 4.0 with certain virtual switch configurations have noticed that the VM is unable to restart it's networking service due to IP conflicts, because the switch is holding onto the ARP cache entry improperly.

When it is pointed out to them that this problem only exists on specific configurations of vSphere 4.0, several have insisted it's a bug with the virtual appliance vendor's OS, stating that restarting the network succeeds on Windows, or some obscure consumer distribution of Linux. The virtual appliance vendor explained that their OS is just a re-branding of a popular enterprise Linux distribution with no modifications to the networking, so it's not their bug. Some of the companies have even admitted that they have other enterprise Linux VMs with the same problem (which only started in vSphere 4.0).

Excuse me for a few minutes while I bash my forehead on this desk here.

Add a comment:




max length 1000 chars