Tag Archives: vmware

Wednesday data center tidbits, pt 2: #cloudcomputing security goes stupid.


Just read a piece about a supposed “insider attack” on VMware ESX. Um, duh, you give someone the root password to anything and they can copy data off it and manipulate the log files. The “security vendor” isn’t aware of any “attacks in the wild”, probably because this isn’t an attack at all. It’s not a bug, it’s not a “cloud computing security risk”, it’s giving the root password to the wrong person, duh.

It’s never pretty when someone jumps the shark and doesn’t make it all the way over. BeyondTrust, cloudwashing bozos of the day.

Email or call me or visit the SwiftWater Telecom web site for cloud computing services.

Vern

Advertisements

Thursday data center tidbits:cramming virtual machines, farming clouds


First up today is the piece about Fusion-io running 512 virtual desktops from a VMware server at VMworld 2010. Other than just proving it CAN be done, is running 512 virtuals from a single hardware host REALLY a smart idea? I think not.

From the Twitter stream today, we get this gem:

“Answer to What is #cloudcomputing ? – “If you only need milk, would you buy a cow?””

This is an interesting analogy for cloud computing, at least for the unwashed. You as a consumer buy milk without caring which of thousands of cows in a herd it came from or any of the details around operating a cow :). This brings up a thought, are we cloud computing providers cloud farmers?

Email or call me or visit the SwiftWater Telecom web site for cloud computing services.

Vern

Wednesday data center tidbits: VMware tap dances, RIPE and Duke make excuses


The funniest thing I’ve read all week is the piece about VMware dissing bare metal desktop hypervisors. The sequence sort of goes like this:

1. We promised a bare metal desktop hypervisor.

2. Wow, this is harder than it looks.

3. Well, the hardware on the average PC wouldn’t be compatible anyways so we don’t REALLY need to do this.

4. If we WERE going to do it, we’d do it better than those pansies over at Citrix anyways because we’re the experts.

When you consider I can load a bare metal server class hypervisor on regular PC hardware (Xen) without a problem and Citrix already has their bare metal client hypervisor, VMware comes off sounding like a petulant child.

Next up is a follow on to the RIPE/Duke BGP routing fiasco. It’s nice to know that it was a Cisco router bug that caused this “experiment” to go out of control but it doesn’t change the fact that NOBODY should have been feeding “experimental” BGP announcements out to the live Internet, period. Gives new meaning to the term irresponsible.

Email or call me or visit the SwiftWater Telecom web site for green data center services today.

Vern

swiftwater telecom rcs cloud computing logo

Virtual recovery from real disaster ….


Today I’ve been reading from “Tsunamis and Virtual Disaster Recovery”. With the increase in violent weather around the world in the last few years, this is a subject that bears thinking about.

Obviously, the most effective way to deal with a disaster is to avoid the effects of it. What does this mean? Don’t build your data center in a flood plain, avalanche area, tornado area, etc. If you invite disaster, disaster will come knocking.

But what about the unanticipated ones? The better question would be the unanticipatable ones. Tsunamis on the coast of any country bordering the Indian and Pacific oceans are perfectly anticipatable, just like earthquakes are perfectly anticipatable on the US Pacific coast or tornadoes in the US midwest.

The nature of virtual machines and the fact that they aren’t locked to physical hardware makes the idea of shifting them from a vulnerable data center to a data center that isn’t at risk a very reasonable idea. If you can’t move the data center, move the work.

The problem I have with this idea is, what happens when you have a truly unanticipatable disaster and there simply isn’t time to relocate large numbers of virtual machines? We solve that issue here by mirroring virtual private servers and virtual private workstations between our primary and secondary data centers. This allows us to relocate the virtual machines in circumstances when time allows but also gives protection against the sudden catastrophe. Granted, there is some impact since the mirroring isn’t real time, but it’s far, far less than commissioning replacement hardware servers and restoring backups that are a LOT less than real time.

When it all comes right down to it, the data center disaster recovery plan comes down to the smartest way to insure the business continuity of the customers. Avoid the disaster if you can, minimize the effects if you can’t, and have another basket and a way to get the eggs to it BEFORE things go catastrophic if you can’t avoid or minimize.

Don’t contribute to the disasters, they don’t need any help!

Vern, SwiftWater Telecom

data center, web hosting, Internet engineering