Rich, you don't still have that old 1980's VM poster "The Wave of the
Future" do you? Every time I hear someone speak about this new concept
of virtualization as "the wave of the future", I just chuckle and think
of that poster!
That said, one of the concerns on mainframe VM that I'm certain holds
true on x86 VMs is the overhead of virtual-to-real address translation.
Since each I/O is affected, this can add up in a hurry ---
particularly on a high activity DB server. On the mainframe, DAT
(dynamic addr translation) was available starting on S/370 iirc, and was
a key for MVS. But mainframe VM never utilized it for reasons I no
longer recall. Instead, there were processor I/O assists, as well as
VM's ability to dedicate fixed blocks of memory to V=R (virt=real) and
V=F (virt=fixed) guests. These allowed for near-native speeds on even
the highest I/O bound apps. I even heard rumours that sometimes native
throughput could be surpassed in a properly configured VM system.
On today's x86 VMs, I've been told that something that sounds
suspiciously akin to DAT is being added to the newer Intel processors
very soon. This may push today's virtualization far beyond what many
think is possible.
BTW, on the mainframe VM listserve, there was a pointer to an article
about IBM's plans to "go green(er)" by consolidating its data centers
and migrating its thousands on Linux servers onto a handful of mainframe
z/VM systems:
http://www.networkworld.com/community/node/17998
http://www-03.ibm.com/press/us/en/pressrelease/21945.wss
Richard Wiggins wrote:
> My colleagues are going to get tired of me saying this, but it is amazing to
> see in 2007 on small systems the exact same issues we faced in 1987 on our
> VM mainframes.
>
> Of course, in 2007 we can acquire systems with massively large real
> memories. And of course disks are much faster and more capacious, but
> anytime you start paging to disk you're slowing down dramatically.
>
> One mainframe performance maverick back in the 80s said "If it is in your
> machine room and if it rotates, page to it." Now you want sufficient real
> memory so you don't need your virtual memory to hit the disk at all. Then
> you can hit the disk for other kinds of I/O.
>
> (Of course I am citing hard-learned lessons from 20 years ago, with
> zero experience with modern VM systems....)
>
> /rich
>
>
|
