Share This:

VMLMAT ( comes in handy for something it was never originally intended for

I assume any reader of a technical blog has come across the "Law of Unintended Consequences". A decision, or path that leads to unexpected places. It usually has negative connotations, as in


"We (the generic we) decided not to spend any money on a new firewall, and with our savings we fought off a series of virus and malware incursions that cost us 100 times what the new firewall would have"




"We (still the generic we) designed the car to be light weight so it would get good fuel economy, and with the money we saved by not using higher strength materials we paid for all the lawsuits we were served with when it turned out the cars fold up like lawn chairs when hit by a Vespa.".


There are lessor and greater examples of the law than this, and I totally made those two up (although I am willing to bet my first example has happened someplace to someone). The law is well known though: It has a Wikipedia entry even, and as noted there, when there is an upside to the law, it is called a serendipity or a windfall. VMLMAT provided us with a windfall recently.

Rote Work


Computers are supposed to help us out with repetitive tasks. That is what they are good at, and we... at least I.. am not.


We had a situation not that long ago where we were re-doing some internal TCP/IP addresses, and all the Linux guest on the mainframe needed to have new IP addresses and new subnets. We were going to have to go manually through over 100 VM guests and change their IP settings.


The chances for error were high, and boredom even higher. Ron and I talked about it, and a little light went on for us. VMLMAT could be made to do this in very short order. Not only was it Open Source, it was *our* Open Source. VMLMAT had been written to be easy to extend. Ron thought he could add the feature in a fraction of what it would take to re-IP all the VM's manually.


The secret sauce was in the module Ron had already written that preserves  the TCP/IP identity of each Virtual Machine, regardless of which actual version of Linux was running at the time. VMLMAT had allowed us to treat VM's Virtual machines more like they were group or personally owned assets. Once we had set up the VM in the directory, VMLMAT updated to know whose VM this was, then we were pretty much done. The end user, or group of people could go into the web page and make the virtual machine into any version of Linux in our archive. No matter what they did, the identity code would chain through all the right places and set up the new Linux VM as having the same IP address, Subnet, Default Route, and DNS settings as it did before it was changed.


Since VMLMAT could do that, why couldn't we slightly change it so that it could be handed a list of VM names, IP addresses, and Subnets, and have it chain through *all* the guests, and reset them to the new IP? This module already knows all the different places the information is kept for each distro, so all it had to do was detect the distro, change the IP to the *new* one, and then run on to the next VM. VMLMAT could do in minutes what would take us days to do by hand.


And so it came to pass that we could schedule one short outage, pull the trigger on the re-IP mod, and be done. No mistakes. No long outages. R&D went home Friday night and their VM's had one IP address, came back Monday and they had another, and never knew anything had changed.

VMLMAT already had the habit of returning over 80% of Ron's time versus pre-VMLMAT days.


This was a bonus.


UPDATE: Ron has now posted an in depth look at the re-IP module over in his blog:  Open for Mainframe. Have a look!