Share This:

Literally. Where the VMLMAT tool goes, and what it does going forward are defined by the people that use it, just as what it is so far was defined by the needs of the people that created it.


Background, in case this is the first post you have ever read about VMLMAT. VMLMAT is not a product of BMC's R&D organization. As we are organized internally, R&D Support is actually in the IT department, and VMLMAT was designed and built by Ron Michael, the man charged internally to support all of R&D Linux images on the mainframe. It expressly is written for the needs of our internal environment, and some of those parameters are:


  • All Mainframe Linux images run under z/VM. While we have      LPAR's, we do not use them for Linux.

  • We made an arbitrary design decision to use Active Directory      as our repository for users and passwords. VMLMAT stores the      metadata about what each user can do, and which Linux images they      own, but not the actual userids / passwords themselves

  • Our R&D community was needing to treat MainFrame Linux as      "Just Another Linux": the same as the Linux on the X86      server, the one in VMware, or the one on their desktop or laptop. As      developers, they know Linux, but they may not know much or      even anything about z/VM or the mainframe.

  • Related to that: We had no idea what platform the R&D      people would be using when they were managing their Linux images.      Could be AIX, Solaris, Linux, HP-UX, OS.X, Tru64, VMS, MS Windows      from 2000 thru 2008...

  • With terrific z/VM system programmers in the support      organization, we were not looking to do anything that either got in      their way, or add any system z/VM management features.

  • We have no MF attached SAN devices, therefore no MF Linux      running on FCP devices.


Because of Whurley and the new direction he represented for BMC, and discussions with same, we knew from a fairly early point that VMLMAT might become one of BMC's first Open Source projects. However, that did not translate into making VMLMAT the be-all, end-all of Linux on the mainframe management tools. We needed VMLMAT to do certain things internally, and that was all we could justify from a time / cost point of view of Ron's efforts. All of VMLMAT's features are funded by IT, therefore they had to meet IT's needs, and in this case, that meant R&D's needs. The good news is that Ron knew this might go Open Source, and so he was very judicious about the codes documentation both inline and via the Wiki. This serves us well internally for anyone that might come along behind Ron, and it serves the Open Source community as well, since they were going to get clean, well documented code from the start.


Being well documented was key: We knew that there were missing features, and we knew we might not be the ones adding them. We made the leap of faith that any submissions back to the project from the community at large that were based off the codebase stood a better chance of being equally well documented and written. We will not accept anything into the main code tree that is not so (or that we can easily make so).


Taking my list above in order then, here are the implications about what VMLMAT could be made to do in future:


  • VMLMAT can be thought of, at least in part, as a cold      provisioning tool. It takes Virtual Machines and makes them into any      version of Linux in the archive. It can also be used to store      particular configurations so that they can be promoted from Alpha to      Beta to pre-GA / release candidate, then to to production. But if      Production is in an LPAR... not so much. Not yet anyway. We think      adding LPAR support is very do-able though.

    • Related to that: VMLMAT is a stand alone tool right now, but           what if you already have a provisioning tool in house? Something           like BladeLogic? Could VMLMAT be made to interoperate? Again, we           think the answer is yes.

  • David      Boyes, over on the VM      Linux mailing list made a great suggestion, that VMLMAT use PAM      rather than our Samba code, so that authentication could be made      pluggable, and therefore it would not matter what the target shop      has for userid / password authentication. LDAP, NIS, NIS+, AD...      whatever.

  • In a production environment, not everyone and their cat      should have full access to the production versions of Linux. VMLMAT      already has a pretty good security model for this, since it allows      one to many, many to one, and many to many groupings of users to      Linux VM's. But I can see how some shops might want to tie this is      to something like RACF or VM:Secure. For our part, we would just      like to store all this is something like PostGres or MySQL in the      future, rather than in locked down flat files.

  • Our choice about the user interface was Web 2.0ish (even      though it is pure HTML right now). We assumed everyone would have a      web browser, even if we did not know what the web browser might be.      Other shops may prefer a Curses or an X interface. We have no      internal demand for that, and I can not see us adding those other      interfaces right now. What I can see us doing is getting far more      sophisticated over time with the web interface. It is currently      designed to be about as fast and simple as it can be: Real Web 2.0      technology Open Standards (such as AJAX) could make it much more      active in nature. Whatever is done here, Open Standards will be at      the core though. If we learned nothing from the web browser wars of      the 1990's it is that using proprietary browser extensions is a      "very bad idea" (tm).

  • There is an API in z/VM called System Management API, or      SMAPI, and not to be confused with Microsoft's Simple Messaging API,      also called SMAPI. Other than name, and being an API, not even      similar. Via VM's SMAPI, VMLMAT could be extended to "talk"      to the host OS, and have it do things like create and destroy VM's,      add mini-disks, change memory parameters, add Diag permissions...      whatever is needed. While VMLMAT has steered pretty clear of most of      the features of BMC's original cloning tool, such features would put      it squarely back in that realm. We don't need such things, so they      would more than likely not be added unless something extraordinary      happened, or they were added by the community at large.

    • Such features could also be added by having VMLMAT make           calls to whatever the shops systems management tool is. This is the           way the the BMC Cloning tool went about it. VMLMAT shares no code           with that tool though, so adding such a feature set would more than           likely be a community endeavor.

  • A key design point of VMLMAT was device and file system      independence. The way that the systems are archived and restored      does not care about what the underlying device is. It does not care      if it is EXT2, EXT3, or (probably, but not tested) XFS, JFS, or      Reiser. We take whatever device VM gives us, and we are glad to have      it. Thus should it ever be. While we have never tested it, adding      SAN devices should not be that hard: Mostly a matter of dealing with      the device names themselves.

    • Related to that: We built the archive feature to match a           resource that we had: that being our spiffy Linux NAS servers.           Other shops might prefer to archive to FCP devices, CIFS, or even           to MF DASD, leveraging at least the fact that the archives are           gzipped and still saving space. All of this should be easy to add.

    • Further related to that: We internally use only VM presented           Mini-disks as "raw" devices for Linux. No LVM or EVMS           layer. Since VMLMAT is device independent, adding support for a           Logical Volume Manager(s) should not be that difficult. In fact,           installing Redhat without LVM has gotten more and more difficult,           so this is something we may have to add for internal reasons.


Those are just some of the obvious things we have talked about (and we have talked about other, more esoteric things still), and to some degree they are based purely on our projections of what others needs might be. I freely admit that I have no idea all the possible things others might need or want from a tool such as VMLMAT. We tend to have a very BSM mindset internally for some reason, so that may color what we think about when we consider what we might do to VMLMAT.


In its current form, it has more than paid us back for the time Ron spent creating it. How it might be extended to be of similar help to others is an "Open" question.