Virtual Containerization

AlexGr alerts us to a piece by Jeff Gould up on Interop News. Quoting: "It's becoming increasingly clear that the most important use of virtualization is not to consolidate hardware boxes but to protect applications from the vagaries of the operating environments they run on. It's all about 'containerization,' to employ a really ugly but useful word. Until fairly recently this was anything but the consensus view. On the contrary, the idea that virtualization is mostly about consolidation has been conventional wisdom ever since IDC started touting VMware's roaring success as one of the reasons behind last year's slowdown in server hardware sales."

Isn't this bad for performance?

[Anonymous Coward]

If you're "containerizing" every aspect of your system, doesn't this have big performance problems? CPU cache, message passing, memory management, DMA, IRQs, whatever?

What was wrong with traditional privilege isolation in Linux systems (running processes as different users, chroot, etc)?

VM's just allow so many opportunities

[inflex]

As a software developer, being able to take snapshots, clone, pause, rewind (via snapshots) and backup makes VM'ing worth the cost in CPU/performance.

It's proved so useful that I'm sincerely considering doing the same for my actual WWW server so that if at any given time things go -bad- on the device I can just either roll back or transparently transfer to another machine, the latter, due to the (mostly) hardware agnostic nature of the VM setup makes disaster recovery just that much simpler (sure, you still have to setup the host but at least it's a simpler process than redoing every tiny little trinket again).

Node Locking

[Pvt_Ryan]

I use vmware servers for software that is node locked.. Node locked software is usually done by a machines MAC address, I find that using VMs reduces downtime in the event of either host or client failing. In the case of the host if we can recover the VM we just copy it to another host and run it. In the case of the client dying the great thing is I just create a new VM and change its mac address to match the dead one then reinstall my licence files, saving me from having to reregister all of the licences to the "new" machine.. Hardware consoladation also plays a large part of my use of VMs, but the main reason is recoverability so much so that all my DCs are on VMs so if their host dies (hardware other than HDD) then i can either pull the disks and put them in another machine, or if my replication has succeeded more recently then I just start my backup copy of the DC and let it update from the domain. Total downtime is about 15min tops.

Whatever happened to "Sandboxing?"

[JonTurner]

Isn't this de facto evidence that the sandboxing, which was supposed to be a key component of both Java and .Net's security models, has either failed to deliver on their promises, or simply isn't adequately well engineered to provide protection against rogue applications?

As has been said before, we need a way to grant applications permissions to use resources. We have that, to some degree, with firewalls and apps like ZoneAlarm/LittleSnitch which ask you for permission before an application is allowed to "call home", but what about other resources -- for example, being able to access only a particular directory or install a system-level event hook which acts as a keylogger? etc.

Re:I'd say it's both

[good soldier svejk]

In fact I'd say that in my data center the driver used to be containerization and is increasingly consolidation. The reasons are radically increased power costs and increasingly complex disaster recovery issues. Virtualization offers significant advantages in both areas.

Also for QA.

[antdude]

Many QA people, including myself, use VM as well. Very useful with buggy builds. The best part is sharing the image. I can send a copy of my image to a developer with the reproduced issues without having him/her to come over to see it on my real machine. We still use real machines for testing, but VM is useful.