Re: Docker on Z - One less lier?
On Wednesday, 10/26/2016 at 11:05 GMT, Paul Flint wrote: > 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. While the *architecture* limits the memory to 16EB, the *machine* may (and will) establish a smaller value based on construction. You can figure it out by setting the MAXSTOR value in your directory entry to 16E and then trying to DEFINE STORAGE 16E. If you exceed the machine maximum, you get an error like this Storage size (16E) exceeds hardware maximum (16T) That's a hardware statement. From a software point of view, z/VM supports virtual machines up to 1TB. You can define larger, but they aren't supported. Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems & Technology Group ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- 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/
Re: Docker on Z - One less lier?
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 Reply-To: Linux on 390 Port 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/
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/
Docker on Z - One less lier?
Greetings Phil, I have a light hearted dialect question: In '86 land the OS, say Linux, essentially eats all the memory, and makes it virtual (as opposed to virtuous :^). The OS then allocates what it can to the docker engine. 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. 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... 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. Sincerely, Flint On Tue, 25 Oct 2016, PHILIP TULLY wrote: Date: Tue, 25 Oct 2016 16:29:07 -0400 From: PHILIP TULLY Reply-To: Linux on 390 Port To: LINUX-390@VM.MARIST.EDU Subject: Docker on Z We are looking to implement Docker on Z, as we have begun the testing part of the issue is to be able to grow a docker engine and growing it dynamically based on it's current needs especially when a node in the Docker cluster fails. So the question is does anyone see a way for the VM system to see the memory resource grow, which would allow me to add more dynamically. phil -- 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/
