Skip to main content

DR Solutions and the Need to Keep Pace

Chris Gibson recently updated his blog post about using the ghostdev and clouddev flags in the disaster recovery process.

"AIXchange" in white against a purple banner, white chat bubble in righthand corner, with black and green technological texture below.

Chris Gibson recently updated his blog post about using the ghostdev and clouddev flags in the disaster recovery process.
In his original post, Chris replicated rootvg via his SAN. But since this was written in 2012, an update was needed. Here's what Chris heard from IBM:

Since one or more of the physical devices will change when booting from an NPIV replicated rootvg, it is recommend to set the ghostdev attribute. The ghostdev attribute will trigger when it detects the AIX image is booting from either a different partition or server. Ghostdev attribute should not trigger during LPM operations (Live Partition Mobility). Once triggered, ghostdev will clear the customized ODM database. This will cause detected devices to be discovered as new devices (with default settings), and avoid the issue with missing/stale device entries in ODM. Since ghostdev does clear the entire customized ODM database, this will require you import your data (non-rootvg) volume groups again, and perform any (device) attribute customization. To set ghostdev, run "chdev -l sys0 -a ghostdev=1". Ghostdev must be set before the rootvg is replicated.

This is from his update:
If ghostdev is set to 1 and you attempt to use SRR (or offline LPM), the AIX LPAR will reset the ODM during boot. This is (most likely) not desired behavior. If the ODM is cleared the system will need to be reconfigured so that TCP/IP and LVM are operational again. If you require a "ghostdev like" behavior for your AIX disaster recovery (DR) process, I would recommend you set the sys0 attribute, clouddev, to 1, immediately after you have booted from your replicated rootvg. Rebooting your AIX system with this setting enabled will "Recreate ODM devices on next boot" and allow you to reconfigure your LPAR for DR. Once you've booted with clouddev=1 and reconfigured your AIX LPAR at DR, immediately disable clouddev (i.e. set it to 0, the default), so that the ODM is not cleared again on the next system reboot. Some more details on clouddev [follow].

Chris concludes with:
If you are looking for a more modern and automated solution for your AIX DR, I would highly recommend you take a look at the IBM VM Recovery Manager for IBM Power Systems. Streamline site switches with a more economical, automated, easier to implement high availability and disaster recovery solution for IBM Power Systems.

Many admins struggle with disaster recovery. Some enterprises roll their own solutions, while others rely on IBM offerings. Frequently admins aren't up to speed on the latest solution designs and implementation techniques. Quick example: simplified remote start. Are you aware of this capability? Read this and scroll to the bottom of the page for links to related and more detailed videos.
Disaster recovery solutions are important, but creating and adhering to a DR plan is critical. Regular testing is the only way you'll know that what you have will work should the need arise.
IBM Systems Webinar Icon

View upcoming and on-demand (IBM Z, IBM i, AIX, Power Systems) webinars.
Register now →