Telematique, water and fire.

VirtSec ... the real issue is Management (... maybe.)

Jon Oltsik at the CNET News blog may be oversimplifying the issue of virtsec.  Nope.  Take that back.  He's DEFINITELY oversimplifying the issues of virtual server security.  It's not that he isn't correct in laying the issue squarely at the feet of management and security controls, but it's just too facile to make that the one and only issue of virtualization security.  I'm rather certain that I'm not the only other person in the industry with this point of view.  (... and I'm not referring only to the vendors of v12n security technologies like Blue Lane or Catbird Networks. )

Update:  Guess I was right about the reaction.  Here's one.

The real issue around server virtualization security | Tech news blog - CNET News.com

... So what is it about server virtualization that should really keep chief information security officers up at night? A more pedestrian worry--lack of control. In a virtual server world, IT administrators can clone virtual hosts, move them around, or turn them on and off by accident or with malicious intent. What happens when an IT administrator moves a critical database server instance without re-configuring application servers or the network? How about when someone mistakenly adds a test server to the production network? The security "uh-oh" possibilities are endless.

The real threat here is that server virtualization takes on a life of its own without proper management and security controls. This is why VMware is investing in its virtual infrastructure, Citrix is keen on its Citrix Delivery Center, and Microsoft is pushing its System Center Virtual Machine Manager (SCVMM) architecture. Systems and operations management vendors like BMC Software, CA, Hewlett-Packard, and IBM are also paying close attention and adding virtualization capabilities to tools, processes, and services. Given its 30-plus years with mainframe virtualization, IBM for one has seen this movie before.  ...

MSFT to Craft it's own VMsafe?

Virtualization.info has a short but interesting post, which refers to a parenthetical comment from Chris Hoff which might imply that MSFT is considering / working on a VMsafe-like framework.

Is Microsoft working on a VMsafe-like framework? | virtualization.info

...
So far Microsoft didn't took an official position about the topic but virtualization.info had the opportunity to speak with several representatives who clearly stated how carefully the company is evaluating the security implications of a VMsafe-like approach.

Nonetheless Microsoft may be working to build the internal know-how needed to achieve the task.

Just two months ago in fact Microsoft acquired a small security firm focused on rootkit detection called Komoku.

As Christopher Hoff, Chief Security Architect at Unisys, recently discovered, Komoku did some research in the past, presenting a solution for Xen where virtual machines can do self-diagnosis and self-healing as well as learning to protect against subsequent attacks. ...

Power Sources and OpEx Savings

Tim Oren hasn't been slowed down by a broken pin. And he's dead on when pointing out the fact that management overhead for virtualization in the data center could hinder virtualization's ability to reduce both capex and opex. We at Replicate are signing up to address the network side of the problem.

Tim Oren's Due Diligence

Aluminum smelters and data centers. Are alike in needed abundant and reliable electrical power. So the Columbia River valley is growing a crop of server farms. The Economist article notes that virtualization technology can be applied to migrate processing to where the juice is cheaper, as well as optimize the number of servers powered up to handle the given workload. Indeed, virtualization management startups are being reflagged as 'green' as fast as the PPT decks and web sites can be rewritten. Remapping the network connections, storage and other resources used by virtualized processes could sink any savings into a sea of management overhead if not optimized as well.