Skip to Main Content
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
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. 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.

Status Submitted
Created by Guest
Created on Jul 2, 2026

Add a "Try Again" button to prevent synchronization issue between the Discover and Verify stages when dealing with large partition volumes

See Case TS021897288.

When you go in the GUI Menu to do a Failover Rehearsal, the GUI runs 3 commands which are 'ksysmgr discover', then 'ksysmgr verify' and then 'ksysmgr move' (where the 'move' actually performs the WG failover). The problem is that the 'ksysmgr discover' ends while the discover is in reality still running in the background. But since the 'ksysmgr discover' commands ends with return code 0 (success), the GUI moves on to the next step ('ksysmgr verify'). But 'ksysmgr verify' fails because it realizes that the previous 'discover' in reality is not finished yet. This is why you need to press the GUI button 'Try again', and when you press 'Try again' while 'discover' has finally really finished then the GUI can move on successfully to the next steps 'verify'.

The feedback of the VMRM Developers is that fixing this problem is very complicated.

A complete solution of this problem will be possible only in some future VMRM release.

However the Developers are willing to explore the possibility to provide some sort of 'relief', which however may only solve the problem in certain cases and not in all scenarios.

The time between 'ksysmgr discover' ending, and the time when the 'discover' still runs in the background can vary a lot. There're different factors which determine how long this 'time' can be, for ex some are:

are we doing rehearsal for a WG or a HG

how many VMs the WG includes

how many disks the VMs have

the response time received back from SAN / Storage

how long SAN / Storage need to complete certain tasks

etc.

To provide some sort of 'relief', based on the logs we've got, we can guess how much extra 'time' the GUI has to wait. But this will be only a best effort guess / assumption, it could resolve for some WGs/VMs sometime but not in all cases (so you would have to still manually press 'Try again').


 

Idea priority Medium