IBM Power Ideas Portal
This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
There is a general concern that a watchdog might expire during migration as a result of how the migration is implemented.
A previous comment as well mentions if it would be acceptable that the watchdog would be disabled for a time and if that would be acceptable.
If used by something like SBD (not just as convenience to avoid manual interaction with a hanging instance but with a hard requirement that an instance has to be isolated withing a given timeout) a watchdog that can be migrated seamlessly has to have a feature that prior to waking up the migrated instance it would have to check if an expiration would have happened in between (leftover-time on the watchdog + time the instance was halted during migration). If yes instead of waking up the instance a reboot or shut-down (depending on the configuration of the watchdog) would be triggered.
This was discussed during the initial design of the watchdog functionality. At that time, the assessment was that live migrating the state of a watchdog would be challenging and it would be difficult to guarantee that the watchdog would not expire in all scenarios. For this reason, it was decided to not try to migrate the state of the watchdog and leave it up to the user to disable the watchdog during an LPM. There are a couple of approaches that could be done to accomplish this. One is via a userspace implementation hooked into the LPM notification framework to disable the watchdog during the LPM. The other possible solution would be to integrate this functionality directly in the watchdog driver itself. For both approaches, there would be a small period of time where the watchdog would be disabled during LPM. Would this be an acceptable? If so, we can further evaluate feasibility of both of these options.
The topic not only is of interest for Db2 HA clusters, but applies in general to pacemaker clusters using SBD (STONITH Block Device) fencing together with the pseries_wdt watchdog on IBM Power servers - When the pseries_wdt watchdog driver is active, a Live Partition Mobility operation gets prevented.