Article number
000004573
Affected Versions
8.0
8.0 Update 1
8.0 Update 1 Patch 1
8.0 Update 2
Source Hypervisor
All
Target Hypervisor
AWS
Recovery To AWS Fails With Error “Timeout While Waiting For New Progress File From zImporter VM”
Viewed 138 times
Summary
This article explains a known issue in zImporter code that is seen with specific types of names on a VM and its VMDKs, leading to failure to recover the VPG.
Root Cause
The zImporter code was initially written to cutoff the incoming string at ".com" due to the URL to the S3 bucket including ".com" in the name. However, since the VM in question and its VMDKs were named with ".com", the actual progress file filenames were shortened and uploaded with the shortened filename that drops the XML extension. This leads to the manifest file being parsed out and mentioning the error as seen in the zImporter log file as the progress file is not in the expected XML file type.
Symptoms
VPG Failover Live/Test, Move, and Offsite Clone all fail with error:
Timeout while waiting for new progress file from zImporter VM
The zImporter log will also contain the following message as well:
2020-07-09 00:19:05,443 INFO 139880240334016 Utilities immediate_exit Message: Exiting program due to: not well-formed (invalid token): line 1, column 11. CorrelationId: 15889a0b-865e-4f76-a3d0-69a7970b117a
Lastly, the VM and its VMDKs that are seeing this failed over have a name similar to an FQDN where ".com" is in the name.
Timeout while waiting for new progress file from zImporter VM
The zImporter log will also contain the following message as well:
2020-07-09 00:19:05,443 INFO 139880240334016 Utilities immediate_exit Message: Exiting program due to: not well-formed (invalid token): line 1, column 11. CorrelationId: 15889a0b-865e-4f76-a3d0-69a7970b117a
Lastly, the VM and its VMDKs that are seeing this failed over have a name similar to an FQDN where ".com" is in the name.
Solution
Workaround
The only known workaround is to clone the affected VM, ensuring to not use ".com" in the VM name as well as the VMDK names, then protecting the newly cloned VM.
Permanent Fix
This issue is resolved in 8.0 Update 3. Upgrading the Zerto environment to 8.0 Update 3 resolves this handling issue.
The only known workaround is to clone the affected VM, ensuring to not use ".com" in the VM name as well as the VMDK names, then protecting the newly cloned VM.
Permanent Fix
This issue is resolved in 8.0 Update 3. Upgrading the Zerto environment to 8.0 Update 3 resolves this handling issue.