Greetings Rick,
Never thought of the implications of using zLinux "heavy", and then lotsa
dockers... Very interesting, and saves the cost of a zVM (or ifL)
license.
Nice!
Regards,
Flint
On Wed, 26 Oct 2016, Rick Troth wrote:
Date: Wed, 26 Oct 2016 09:15:48 -0400
From: Rick Troth <r...@casita.net>
Reply-To: Linux on 390 Port <LINUX-390@VM.MARIST.EDU>
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Docker on Z - One less lier?
On 10/26/2016 07:05 AM, Paul Flint wrote:
In '86 land the OS, say Linux, essentially eats all the memory, and
makes it virtual (as opposed to virtuous :^). ...
Linux does the same on z: it just parks on all memory it sees.
In zVM land you have a kick ass memory manager that essentially lies
to each Virtual Machine and tells it that the memory limit is in the
Exabytes (gee, I love that word :^). The guest operating system on
the Virtual Machine in turn uses this lie to set the limit the docker
engine can operate a docker instance based upon the lie it got from zVM.
z/VM is a hypervisor.
All hypervisors "lie" to their guests about how much memory is installed.
You see the same thing with VMware, KVM, VirtualBox, Hyper-V, ... any of
them.
Kinda makes you wonder how hard it would be to make the docker engine
talk directly to zVM and get the lie directly from the lier...
Trivial.
And conceptually the same for any hypervisor because they all "lie"
about memory for the sake of establishing a fake "machine" which the
guest sees. (z/VM provides a direct interface which the bare metal
doesn't have, but the guest could use either that or the bare metal
method to figger it out.)
If I had a zVM account somewhere or an emulator that legally ran the
current zVM I could look into this, right now I just want to know if I
am following the your issue correctly. I likely need to find out more
about docker clusters, but right now I have a hunch the answer to
better clustering is on the zVM side.
I should probably reply on the other thread.
I /think/ what Phil is trying to do is get some measurements from Docker
on z for the sake of sizing "production" hosting with Docker. So if I am
understanding, Phil needs to incrementally scale up the memory seen by
this one specific z/VM guest. But adding memory on-the-fly to a guest
usually requires a reboot of the guest. So others on the list have
suggested a couple of the usual tricks for tweaking memory w/o rebooting
the guest.
Docker is a good candidate for running Linux "heavy". That is, Docker
could use Linux in its own LPAR and without z/VM. (KVM is another such
candidate.) Even so, LPARs get lied to by PR/SM about how much memory is
present. (Seems these lies abound!) So Phil will want to continue his
measurements to know how big the Docker LPAR(s) should be.
-- R; <><
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Kindest Regards,
☮ Paul Flint
(802) 479-2360 Home
(802) 595-9365 Cell
/************************************
Based upon email reliability concerns,
please send an acknowledgement in response to this note.
Paul Flint
17 Averill Street
Barre, VT
05641
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
