Issue/Introduction

This article troubleshoots an empty destination ZSphere resource list after changing the platform or migration-service time zone, even though ZMigrate can list VMware source resources.

Symptoms

• The ZMigrate service is healthy and VMware source resources can be selected, but no resources are available at the ZSphere destination step.
• Restarting only the management node or migration service, or toggling API time-zone check, does not restore the resources.
• In the recorded case, the destination resources became visible immediately after the ZSphere AK was updated again in the native ZMigrate UI.

Environment

• Product: ZVF ZSphere
• Version: 5.0.2 (reported environment)
• Components: ZSphere management node, ZMigrate console, and ZSphere resource connection
• Deployment: After ZMigrate is installed, the management-node or ZMigrate time zone is changed, and the saved ZSphere AK is used to query destination resources

Possible causes

• The confirmed trigger is changing the ZMigrate or management-node time zone after installation. The product requires the time and time zone on both sides to remain consistent.
• The confirmed site recovery action was updating the ZSphere AK again. This evidence shows that the saved authentication-connection context needed refreshing, but does not by itself prove the specific code-level cause that signature timestamps use local time zones.
• Interface errors, request and signature logs from before and after the time-zone change, and a verified fixed version are currently unavailable.

Resolution

1. Reconstruct the time-zone change timeline

1. Run timedatectl on the ZSphere management node and ZMigrate console. Record Time zone, System clock synchronized, local time, and UTC time.
2. Record when ZMigrate was installed, when each side's time zone was last changed, and when the resource list last worked.
3. Check whether the trigger sequence was "install the migration service, then change the platform or migration-service time zone."

• Expected result: The ZSphere management node and ZMigrate have synchronized time and matching time zones, and you can determine whether the problem immediately followed a time-zone change.
• Exception handling: If the time or time zone still differs, first align both sides to the site's time standard. Record the original values and business window before the change so that running migration tasks do not span a time adjustment.

2. Distinguish no resources from an authenticated query failure

1. In the native ZMigrate UI, open the configured ZSphere resource connection and check only the connection address, AK identifier, and connection state. Do not copy or display the Secret Key.
2. During the same time window, save ZMigrate access logs, ZSphere audit logs, and management-node logs. Check whether resource-query requests show authentication failure, signature time drift, connection failure, or an explicit empty result.
3. Sign in to ZSphere directly with the same account and confirm that destination clusters, data storage, and other resources exist and are visible to the account.

• Expected result: If ZSphere has resources but ZMigrate requests show authentication or connection errors, continue by refreshing the connection context. If the interface successfully returns a genuinely empty list, check account permissions and resource scope.
• Exception handling: If the logs contain no request or the UI suppresses the error response, preserve the request time, connection identifier, and complete server error for support. Do not infer the time-zone signing algorithm from a blank page.

3. Refresh the ZSphere AK connection context

Workaround

Applicability: ZSphere and ZMigrate time and time zones are aligned, destination resources exist in ZSphere, but the ZMigrate request still shows an authentication/connection-context exception or the resource list is empty. This does not apply when the interface genuinely returns no permission or no resources.

Verified site workaround: After the time and time zones are aligned, open the ZSphere resource-connection edit page in the native ZMigrate UI, enter the still-valid AK/Secret Key again, and save. Before the operation, confirm that no migration task created through this connection is running. Obtain credentials from the password-management system; never copy a key from logs or historical screenshots.

• Expected result: Connection validation succeeds, ZSphere destination resources reappear, and they remain visible after a page refresh.
• Exception handling: If the list remains empty after saving, restore the original connection configuration, stop repeatedly restarting services or changing the time zone, and collect evidence in step 4.
• Restarting only the management node or migration service did not work in the recorded case and must not be presented as the workaround.

4. Verify resource queries and a migration task

1. Refresh the destination resource list repeatedly and confirm that the same cluster, data storage, and network resources remain visible.
2. First create a migration task for one small non-production virtual machine and confirm successful source selection, destination selection, and task submission.
3. Check timedatectl on both sides again and confirm that no time jump occurred during verification.

• Expected result: Resource queries and the small task both work without updating the AK again.
• Exception handling: If the issue recurs after a time/time-zone change, save the before-and-after output, request time, and error response and submit them to Technical Support. Do not claim that a release fixes the problem without build and regression evidence.

Additional information

• Support information must include ZSphere/ZMigrate versions, timedatectl output from both sides, the time-zone change time, resource-connection identifier, and redacted request errors. It must not include the Secret Key.
• The exact signing algorithm, time-tolerance window, and root cause remain unconfirmed. Do not repeatedly change the system time or time zone to maintain the connection.