There may be better ways to do this, and if there are, please let me know. But lately I've been "hacking around" with cloud-init on AIX and trying to make it behave the way I want it to. There were two problems I faced and solved.

My first challenge. The AIX /etc/hosts file isn't updated with the IP address and hostname of the new AIX VM after deployment from PowerVC.

To work-around this niggle*, I added the following short but effective shell script to the Activation Input in the PowerVC GUI. 

#!/bin/ksh
myip=`lsattr -El en0 -a netaddr | awk '{print $2}'`
myname=`hostname`
echo Adding $myip $myname to /etc/hosts >> /tmp/mycloud.log
/usr/bin/hostent -a $myip -h $myname
date >> /tmp/mycloud.log

It's ugly but hey, it does the job!

And the second niggle. In my customers lab environment, where there's no DNS at all. Everything is /etc/hosts only. Every time they deployed an AIX VM, there was a significant delay for ssh sessions, even with netsvc.conf set to hosts=local4, the dodgy**, default, resolv.conf (search localdomain) forced DNS first....and ssh connections would hang for a minute or so before a login prompt appeared....waiting on name resolution to complete.

Some people told me that I could change "manage_resolv_conf" to false in my cloud-init config file and this would prevent the resolv.conf file from being managed (over-written) by cloud-init. But changing that option did nothing. And I really didn't want a resolv.conf file at all anyway!

What I really wanted was for cloud-init to deploy the AIX VM and to NOT create an /etc/resolv.conf file. But how? Well, I managed to fudge it***. I made a change to the aix.py python script. With this change, the script now writes out an /etc/resolv.conf.cloud file instead. This works OK.

root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros # cat /etc/resolv.conf.cloud
search localdomain

root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros # mkdir cg
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros # cd cg
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros/cg/
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros/cg # cp ../aix.py .
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros/cg # vi aix.py

Change    resolve_conf_fn = "/etc/resolv.conf"
To        resolve_conf_fn = "/etc/resolv.conf.cloud"

root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros # diff aix.py /tmp/cg/aix.py
35c35
<     resolve_conf_fn = "/etc/resolv.conf.cloud"
---
>     resolve_conf_fn = "/etc/resolv.conf"

root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros/cg # python -m compileall .
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros/cg # cp -p * ..
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros/cg # cd ..
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros # rm -r cg

Now the customer can connect to new AIX VMs immediately after deployment.

# ls -ltr /etc/resolv.conf.cloud
-rw-r--r--    1 root     system           19 Aug 03 12:47 /etc/resolv.conf.cloud

It's a hack but it was fun. 

And I guess the next time I install the latest release of cloud-init for AIX, I'll need to modify the script again. But I'm OK with this, as I expect the newer release may actually provide me with a fix to each of the problems I faced.

*niggle: To cause slight but persistent annoyance, discomfort, or anxiety.

**dodgy: dishonest or unreliable, of low quality.

***fudge it: put together clumsily. Perhaps an alteration of fadge "make suit, fit".