Whoops,

> It would be cool to see some
Clicked "Send" too early.

It would be cool to see someone write some code to support KVM on z.  Then
KVM and z/VM guests could be supported similarly.  It would be non-trivial,
but not too too much work.

    -Mike

On Sun, Oct 22, 2017 at 4:35 PM, Michael MacIsaac <mike99...@gmail.com>
wrote:

> Gadi,
>
> Effectively, yes z/VM is required.  There is code that hasn't been tested
> for years to support Linux on an LPAR being added to the zoom tree, but no
> support for any hipervisor running in it such as KVM.  It would be cool to
> see some
>
> I have tested zoom servers and clients (managed guests) heavily on SLES,
> and lightly on RHEL and Ubuntu.
>
>     -Mike
>
> On Sun, Oct 22, 2017 at 8:32 AM, גדי בן אבי <gad...@malam.com> wrote:
>
>> Hi,
>>
>> Is z/VM requited, or will it work on zLinux installed in an LPAR?
>> What versions of zLinux are supported?
>>
>> Gadi
>>
>> -----Original Message-----
>> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
>> Michael MacIsaac
>> Sent: Sunday, October 22, 2017 2:41 PM
>> To: LINUX-390@VM.MARIST.EDU
>> Subject: Announcing zoom and zuess 3.0
>>
>> Hello linux-390 and IBMBM lists,
>>
>> zoom (System z object-oriented management) and zuess (System z
>> user-enabled
>> self-service) are
>> open-source packages that provide "Private Cloud" on IBM mainframe
>> hardware, the z/VM hipervisor and the GNU/Linux operating system - arguably
>> the most solid and mature virtualization trio on earth. They provide three
>> interfaces for systems management of Linux on the
>> mainframe:
>>   1) Command line (zoom)
>>   2) Web UI       (zuess)
>>   3) RESTful API  (zuess)
>>
>> Together, they create a "self-service portal", where end users can build
>> new Linux systems*, rebuild*, destroy* power-on and off, add and remove
>> CPUs and memory non-disruptively, and report on these systems. It also has
>> a complete "cookbook" with a user guide and command reference.
>> (* some code has to be written by the user)
>>
>> Also supported are:
>>   -) An authentication/authorization mechanism for operations on data or
>> systems
>>   -) Ability to run Linux or z/VM commands and copy files with
>> "passwordless" SSH
>>   -) Inline Web editing of metadata fields "description" and "owner"
>>   -) Quotas for CPUs and memory used by Linux group
>>   -) A second level arbitrary grouping mechanism below Linux groups
>>   -) A locking mechanism for systems being operated on
>>   -) User preferences
>>   -) z/VM DASD, FCP and OSA device reporting
>>   -) Monitoring, Software as a Service and live guest relocation are
>> works in progress
>>
>> The main Web page is https://sourceforge.net/projects/system-zoom/
>> The document in PDF:
>> https://sourceforge.net/projects/system-zoom/files/zoom.pdf/download
>> The download page is https://sourceforge.net/projects/system-zoom/files/
>>
>> You should see six files available for download:
>>   README.txt             Basic information - this file
>>   zoom-3-XX.s390x.rpm    The "back-end" RPM  - CLI to be installed on a
>> zLinux system
>>   zuess-3-XX.s390x.rpm   The "front-end" RPM - Web UI to be installed on
>> same zLinux system
>>   zoom.pdf               The documentation - if you just want to read
>> about
>> it
>>   zoom.tgz               Tar file with zoom code - if you just want to see
>> the CLI code
>>   zuess.tgz              Tar file with zuess code - if you just want to
>> see
>> the UI code
>>
>> The version was bumped to 3 because of the new "zoom tree" data structure.
>> To create a zoom cluster of multiple z/VM systems, one zoom server on one
>> z/VM system calls the "zaddserver" command to combine another zoom server
>> on a different z/VM LPAR. The first server becomes to be the "primary", and
>> the second server becomes the "secondary". The primary server can then add
>> any number of additional servers on different z/VM LPARs which all become
>> "tertiary". The primary and secondary servers each maintain an identical
>> copy of the complete zoom tree. Each tertiary server only maintains a tree
>> with clients on that z/VM LPAR. Think of this as an active-active
>> configuration. Should the primary server fail, the secondary will be a hot
>> standby. It should be possible to create a Virtual IP address (VIP) that
>> would load balance between the two servers.  For data reliability and
>> operation integrity, when clients (managed guests) are being operated on,
>> they are locked. So if two administrators try to reboot the same client,
>> the first one will succeed, and the second one will get a “system is locked”
>> message. Locks are
>> maintained on the primary sever, but if it is down, they are maintained
>> on the secondary.
>>
>> The zuess Web User Interface was designed with the goal of giving users
>> in an organization Self-Service portal to z/VM and zLinux resources. It
>> requires that a Web server be running on the zoom server (only Apache has
>> been tested).
>>
>> With version 3.0, access to the Web UI is split into two categories
>>  (1) Read-only - the home page and any other page that does not perform
>> operations is in a  directory (usually /srv/www/cgi-bin/) open to all
>> users. No audit trail is needed, so no  user/group information is available.
>>
>>  (2) Read-write - any page that performs any operation or makes any
>> change to the tree is in  a directory that is password protected (usually
>> /srv/www/cgi-bin/zuess/).
>> Once the user
>>  supplies valid credentials, the user name is maintained along with their
>> primary and secondary  groups. An audit trail is maintained in the zoom log
>> file (usually /var/log/zoom.log).
>>
>> OK, that's probably enough description.  Phil Tully and I presented on
>> this at the last SHARE and MVMUA.  Both were pretty well received.
>> Unfortunately, no more presentations are planned at this time.
>>
>> If anyone does get it set up, please let me know.  What would be great is
>> a contribution of some Linux/VM code to do build (clone to new VM), rebuild
>> (clone to
>> existing) and destroy. All
>> of those operations are outlined in the file
>> /usr/local/src/userexits.stubs. It would have to be copied to
>> userexits.local. What we do in house is put a message on the zoom server's
>> console, IBM OpsMgr traps it and calls the appropriate REXX EXEC.  I'd
>> imagine the sample code could use PROP instead.  A free six-pack of the
>> beer of your choice to the first person to do that!
>>
>> A great goal would be to get to a series of three one hour labs where (1)
>> Linux/zoom/zuess are installed, (2) a zoom tree is created and the Web UI
>> set up, and (3) all the teams in the class cluster the zoom servers
>> together.  Wouldn't that be cool to come back from SHARE or VM Workshop and
>> say "Yeah, I set up Private Cloud on the mainframe in three hours with open
>> source tools"?  Simultaneously, that exercise would help drive out the bugs
>> which are certainly there.
>>
>> C'mon community, stop letting "distributed" beat us at Cloud!
>>
>> --
>>      -Mike MacIsaac
>>
>> ----------------------------------------------------------------------
>> 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/
>> לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה
>> קשורה שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג
>> מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את
>> לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך
>> סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום
>> טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please
>> note that in accordance with Malam and/or its subsidiaries (hereinafter :
>> "Malam") regulations and signatory rights, no offer, agreement, concession
>> or representation is binding on the Malam, unless accompanied by a duly
>> signed separate document (or a scanned version thereof), affixed with the
>> Malam seal.
>>
>
>
>
> --
>      -Mike MacIsaac
>



-- 
     -Mike MacIsaac

----------------------------------------------------------------------
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/

Reply via email to