So many NIM resources!
Why don't use mksysb?
Like many other AIX administrators in the world, I use mksysb to deploy AIX. It is easy, fast, and reliable. You must know only one command to capture it. It saves the entire rootvg with all your data. It creates an exact replica of what you captured on a new system. What’s the hell wrong with it, and whydo you write about all these resources, Andrey?
Installation types
It doesn’t matter which operating system or hardware architecture we talk about. Generally speaking, there are always two options for its deployment:
fresh new installation
clone of an existing system
Even if the installation program of your operating system may not propose the second way, you usually can do it by using storage-side snapshots or similar techniques.
What I wrote about in the previous articles was about installing AIX using an lpp_source NIM resource. It is a fresh new installation. It is the same way as I would take a DVD and install AIX from the DVD.
Cloning of AIX is also possible. You can do it by using storage snapshots - this is the way PowerVC uses. Or you can use the AIX native way - mksysb.
Disadvantages of mksysb
I think the advantages of mksysb are clear.
The installation time is usually very short.
It is very easy to produce an mksysb image.
You always get the same system with all the required settings and software you need.
What can be bad in this case?
mksysb is static. It is a snapshot in time. With all the required settings and software you need. If you need to change a setting, add a user to mksysb, or install a new version of software, you must redeploy your image, change it, and then capture it again. If you install a fresh system, you always use tools like Ansible to do it, and it means you usually change only one line in your Ansible playbook. Of course, you can use your Ansible playbook to post-configure the deployed mksysb image. But now we just took off one of the mksysb advantages, didn’t we?
mksysb is static, and not every software likes it. Even AIX has UUIDs in different places, and when you capture an image, these UUIDs can stay the same after the image deployment. Some software requires registration on a central management server, such as monitoring agents. In this case, it doesn’t make any sense to install the software in the image. Or you install it into the image, but don’t configure it, and do it later after the deployment. Using Ansible playbooks or first boot scripts.
mksysb is big. Of course, you may say, that mksysb is not big, and it is only a matter of perception. I tell you, it is a matter of the system administrator, who cares. Or doesn’t care. Yes, there is a good practice to separate the operating system (rootvg) from all other applications and their data. But I can’t count the number of times I saw applications installed into rootvg.
configuration drift in mksysb. Do you document all changes you made to your mksysb? Do you document which systems you installed using the specified version of the mksysb? Do you have any versioning control for your mksysbs? If you always install a fresh system from an lpp_source, and then configure it using Ansible, you usually have your Ansible code in a Git repository, where you have versioning, commits, and diffs. You can’t put mksysb in Git. OK, technically, it is possible. But you don’t get any diffs. Do you remember why your colleague, who left the company three years ago, changed /etc/netsvc.conf in the image before he left?
hardware changes in mksysb. Yes, you can ignore the point if you use only completely virtualized systems. Many of us use completely virtualized systems, and we don’t need specific hardware drivers. But let’s say you migrate from EMC PowerPath to native AIX MPIO, and you don’t have the drivers in your mksysb. Welcome to another mksysb rebuild! During fresh lpp_source installation, you don’t bother with such things. The AIX installation program will install the required drivers.
Support the Power DevOps Newsletter!
If you like reading technical articles about IBM Power, AIX, and Linux on IBM Power, consider upgrading to the paid tier to show your support. As a paid subscriber, you not only get regular posts, but you will get additional posts with the full code and further explanations, access to the whole archive of the blog, and take part in our monthly calls where you can ask your questions and propose topics for future newsletters. Be an active member of our community!
Argh! I installed from mksysb my whole life! Now, I will remove all my mksysb images!
Stop!
Don’t do it!
As I wrote, I use mksysb installations too.
My only point here is that you understand the advantages and disadvantages of both methods.
We still need an mksysb as a system backup (and restore) method.
We still use mksysb to install VIOS.
There are still situations where mksysb is the best deployment method.
If you are hungry and want to eat right now, you can get a frozen pizza from the fridge - it is easy, fast, and has the taste you expect.
Have fun deploying AIX with mksysb!
Andrey
Hi, I am Andrey Klyachkin, IBM Champion and IBM AIX Community Advocate. This means I don’t work for IBM. Over the last twenty years, I have worked with many different IBM Power customers all over the world, both on-premise and in the cloud. I specialize in automating IBM Power infrastructures, making them even more robust and agile. I co-authored several IBM Redbooks and IBM Power certifications. I am an active Red Hat Certified Engineer and Instructor.
Follow me on LinkedIn, Twitter and YouTube.
You can meet me at events like IBM TechXchange, the Common Europe Congress, and GSE Germany’s IBM Power Working Group sessions.