I recommend use of the term "insertion loss" instead of "overhead".
The term comes from telecomm. The affect arises from any number of
JUSTIFIED additions to a transmission line which naturally introduce
attenuation of the signal.
Add a noise filter? It will reduce noise (which you want)
but it will also weaken the DESIRED signal (which you don't want).
Usually the weakening of the desired signal is negligible,
so we write it off and employ the solution.
Add a spliter? It will let you hook-up two receivers where you
previously could only connect one (which you want) but it will also
reduce the total signal slightly more than simply spreading it
across the two consumers (which you don't want). Same story here
that the "value add" of having that second receiver far outweighs
the loss of the spread signal or of the tiny loss in the splitter.
http://www.answers.com/topic/insertion-loss
http://en.wikipedia.org/wiki/Insertion_loss
Insertion loss with z/VM could be measured as decreased throughput
or as increased single system complexity. See postings by Alan Altmark
for other ideas on how to translate into business objectives. Most of us
find the insertion loss with z/VM to be quite small. (Numbers I recall
are much smaller than the overhead numbers that have been posted here.)
Compare a Linux worload in LPAR to the same workload in a v-machine.
By contrast, VMware has a not insignificant insertion loss.
(Spoken by a VMware fan: I LIKE VMware!) The insertion loss,
including host system complexity and overhead and maint and storage
(of the hypervisor support itself), on PC systems is high enough that I
stopped doing any V12N on my PC class machines until getting introduced
to Xen. Xen has a lower insertion loss than VMware (on my older boxes).
On Sat, 1 Nov 2008, Alan Ackerman wrote:
...
> The person who asked the question has been asked to review
> virtualization options (VMWARE, p-series, and z/VM) and determine
> which workloads should go where. Since th midrange folks have
> so far decided "we don't need z/VM, we have VMWARE",
> this is actually progress.
Amen!
And it sounds like this reviewing of V12N options is
NOT leading to one grand all-encompassing V12N scheme.
There is no silver bullet. (But z/VM comes close!) :-)
-- R; <><
