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.