There are certainly a number of ISV and other service vendors
who are looking at (or already employing!) z/VM to host
multiple Linuxen, one or more for each customer.
> Once again, lots of variables. Feel free to comment on
> *what* variables are the key ones to control (and in what way) to
> create/manage a scalable workload.
While CPU is not a zSeries strength,
context switching *is* a strength, or seems to be.
The insertion loss when putting z/VM between the hardware
and the workload OS is very small compared to that for VMware.
I always blame the INTeL chip more than VMware (inc, now EMC).
Z/VM lets multiple Linux instances share:
CPU, but total CPU capacity is not increased
disk, where 90% or more is not unrealistic for OS content
memory, with idle "guests" paged out
network, either isolated, "bridged", or routed
Yet as David hinted, the majority of Linux sysadmin talent
is still unfamiliar with admin-for-sharing, and most Linux coders
are still unclued about build-for-sharing. They're used to having
a farm of discrete PCs, like the Windows folk.
Sharing /usr, for example, means being disciplined about
not writing to files or directories held under /usr.
A second point about shared memory: NSS and DCSS.
Linux can share disk, and that's easy to picture.
But Linux on z/VM can share memory too, leveraging more
of your zSeries RAM. But here too, the bulk of memory sharing
skill is focused on application-level sharing, and here we must
do it in the kernel. So there's some learning to do.
But some people *are* sharing parts of the kernel already.
-- R;
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
