Why zVM? Let¹s take some very simple examples, all of which come up way too
often:
User says they need 20 gig for their application. Your zOS folks (the ones
actually in control of the physical hardware) use IOCDS to build an LPAR for
the Linux image, and give it two 3390 mod 27¹s, and you generate the system
on one, creating a filesystem on the other for the user¹s application. The
user begins installing, and ³discovers² that they didn¹t figure on the
actual code, or the configuration database for the product in their
estimate, and now need 35 gig in order to complete their install and begin
using their application.
You have no access to any other DASD, because your IOCP people are
zOS-centric, and don¹t give you any more of anything than you actually ask
for. So, you have to wait for the IOCDS to be changed again, before you can
even begin to address your user¹s problem.
Now, had you been using zVM, and building the Linux guest beneath it, you¹d
likely have a pool of DASD assigned to zVM and already in the IOCP so that
you can use it. (The zOS folks have already marked you on their list as a
large consumer of disk, and give you much larger blocks of devices, viewing
you as a huge ³black box² which sucks DASD as part of its function.) Solving
the problem is just a matter of creating an additional minidisk for the
Linux image, linking it in, formatting it and placing it in the filesystem
somewhere.
It¹s your choice; several days to address the issue, or several minutes.
Note too that the user only needs an additional 15 gig to satisfy their
request. In an LPAR, you get physical DASD, in whatever increment they come
in. Ours are generally 3390 mod 27 right now, but they¹re talking about
making them bigger. With zVM in the middle, you can carve out a 15 gig
minidisk, even if you¹re running on mod 54¹s or whatever. You have more
control of your DASD allocation.
-----
Another example: Your user wants to upgrade from SuSE SLES 9 to SuSE SLES
10. But they want to test first to be sure their application doesn¹t break.
In the LPAR world, you have two choices, neither simply implemented: You can
create another LPAR (which in our case, involves going back to those same
zOS-centric people) and waiting for the new LPAR to be created. You have to
deal with where the memory is going to come from, so you may even take a hit
in your production Linux just to get the LPAR defined, and may impact the
production LPAR¹s resources to do your test. The LPAR alternative is to
schedule the production Linux image for some downtime, and bring up the test
image in its LPAR, assuming you have access to sufficient DASD within the
LPAR to build the test image along-side the production image. A couple of
weekend or deep night outages, and you should have your new Linux tested and
ready to go.
In a zVM world, you simply create another userid, and build your new Linux
image. Test it without impacting production at all, and then when everyone
is happy and ready, bring down the production image, change some IP
addresses in the test image, and bring it up as the production. You can even
slide application filesystems from the old userid to the new one, to cut the
amount of data copying you need to do.
Again, your choice: Begin working nights and weekends, or use zVM and do it
when you want to, not when they¹ll let you.
-----
But, what about when you get a new zVM? Or need to make some major change to
zVM¹s configuration? Or apply and test a PTF to zVM? Well, it¹s just as
simple to make a second-level zVM system as a guest as it is to make a Linux
guest. And you can run third-level Linux guests in the second-level zVM in
order to test them with that shiny new PTF. After all, that¹s what zVM is
all about: Running operating systems.... And in the long run, zVM itself is
just another operating system, right?
-----
Given the flexibility of running Linux beneath zVM, there are only a couple
of reasons you¹d ever not want to do it: You can¹t talk your management into
footing the bill for zVM. Or, you really need to squeeze every ounce of CPU
resource out of the system for the Linux image.
We run around fifty Linux guests on four IFLs and 32 gig of memory in two
CECs here, and it¹s seriously entertaining to hand over a running Linux
image to a user within a day of their request, when they¹re used to waiting
for six to eight weeks for hardware to arrive. The only downside to it is
that the users begin expecting every new implementation in about a day...
We could not do this if we attempted to implement the same load within
individual LPARs. The logistics would be nightmare¹ish.
--
.~. Robert P. Nix Mayo Foundation
/V\ RO-OC-1-13 200 First Street SW
/ ( ) \ 507-284-0844 Rochester, MN 55905
^^-^^ -----
"In theory, theory and practice are the same, but
in practice, theory and practice are different."
> From: Jan Vanbrabant <[EMAIL PROTECTED]>
> Reply-To: Linux on 390 Port <LINUX-390@VM.MARIST.EDU>
> Date: Mon, 19 Feb 2007 21:56:01 +0000
> To: <LINUX-390@VM.MARIST.EDU>
> Subject: Re: zLinux : pro's & con's for running zLinux natively in a LPAR or
> under VM
>
> Re. Mark Post saying:
> After using z/VM to run Linux guests, trying to do it in an LPAR feels
> like I'm blindfolded with both hands tied behind my back.
> &
> Re. this http://www.marist.edu/linuxvm/FAQ.html quote:
> Q: Why are we using VM?
> A: Several reasons: VM presents a "less hostile environment" to Linux (or
> any guest operating system) than the real hardware. VM allows
> concurrent execution of multiple Linux instances. VM simplifies early
> development by providing short-cuts to many S/390 operations and
> services. VM has strong debugging facilities. And because we think
> it's way cool.
>
> Well, Mark, thanks in the first please for your post.
> But I would like to know precisely in what "blindfolded" & "less hostile
> environment" consists of.
> Is that described somewhere?
> Has kind of a benchmark/experience or some exercise been done to differentiate
> the 2 environments?
> Or has everybody to learn it by himself the hard way:
> start natively in an LPAR & end up with VM ?
> (I've heard of several such roadmaps...)
> Jan
>
> PS
> You should know that besides z/OS, we are partially VM. But that platform is
> not strategic within our company. And after many years the management has
> finally decided to get rid of it and to migrate it to MVS. Should be realized
> by the 2-nd half of next year.
> And now, zLinux is peeping around the corner ... with VM sitting & laughing
> on it's shoulder.
>
> ----------------------------------------------------------------------
> 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
----------------------------------------------------------------------
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
