In turn, this will dispense with the notion of assigning emulated CPU and RAM limits to VMs and instead set minimum, maximum, and burst limits -- like paravirtualization, but completely OS-agnostic, without relying on the core host OS to play the middleman and fixed kernel. Each VM may know it's running as a VM, but will also run its own kernel and be able to address hardware directly, with the hypervisor managing the transaction.
We're talking about fixed-purpose servers that have embedded hypervisors, probably redundant, with the ability to upgrade on the fly by upgrading a passive hypervisor, transitioning the load nearly instantly, then upgrading the other. While we're at it, we're also talking about small-footprint physical servers that are essentially CPU and RAM sockets with backplane-level network interfaces completely managed in software.
Are these advanced virtual servers virtual servers at all? Or are they services? If they evolve to become software services like databases and application servers that understand their environment, there may be no need to run more than one or two instances -- period.
Rather than dozens of Web server VMs, you might have just two -- but two that can grow from, say, 500MHz to 32GHz in an instant as the load jumps, from consuming 6GB RAM to 512GB in the same timeframe, but without the need to assign any fixed value. With a suitably high-speed backplane, it's conceivable that a single server instance could span two or more physical servers, with the hypervisors divvying up prioritized tasks, keeping RAM local to the individual process, wherever that happens to be. Naturally, we're talking about massively multithreaded apps, but isn't that the whole idea behind virtualization and multi-core CPUs?
Perhaps, at some point in the future, we'll look at a blade chassis or even several racks of them, and instead of seeing a few dozen physical servers running our hypervisor du jour, we instead view them as a big pile of resources to be consumed as needed by any number of services, running on what might be described as an OS shim. If there's a hardware failure, that piece is easily hot-swapped out for replacement, and the only loss might be a few hundred processes disappearing from a table containing tens of thousands, and those few hundred would be instantly restarted elsewhere with no significant loss of service.
Maybe, if we ever get to a reality such as this, those stalwarts who are still nursing a decrepit physical data center might have finally warmed up to the idea of running more than one server per physical box. Heck, at that point, they won't have a choice. There will be no other alternative.
This story, "Beyond virtualization: Envisioning true cloud computing," was originally published at InfoWorld.com. Read more of Paul Venezia's The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.