Replies: 2 comments 3 replies
|
The Java stack trace is only wrapping the real failure. The useful line is A cross-zone template copy is handled by the Secondary Storage VMs (SSVMs). I would check the following before touching the storage contents:
Do not manually rsync the two secondary-storage directory trees as the first fix. CloudStack tracks template state in its database and expects the SSVM to perform/register the copy; out-of-band file copies can leave the database and storage inconsistent. The fact that one earlier copy succeeded and both template and snapshot operations now fail points especially to an SSVM, route/firewall, or destination-store service that changed after that successful run. The management-server lines immediately before the refusal, plus the affected SSVM log, should identify which endpoint is rejecting the connection. |
|
All the agents are in running state and agent state is up, here is the image for your reference. |
|
Thanks — the screenshot is useful. Both SSVMs are indeed Running / Up, so the management-server agent channel is connected. That rules out one failure mode, but it does not verify that secondary storage is mounted/writable or that the two SSVMs can reach each other for the cross-zone copy. The destination-zone SSVM appears to be ssh -i /root/.ssh/id_rsa.cloud -p 3922 root@169.254.234.9
/usr/local/cloud/systemvm/ssvm-check.shPlease paste the complete output. That script checks DNS, whether secondary storage is mounted and writable, connectivity to the management server on port 8250, and the SSVM Java process. It would also be useful to run the same check on the source-zone SSVM, ssh -i /root/.ssh/id_rsa.cloud -p 3922 root@169.254.243.217
/usr/local/cloud/systemvm/ssvm-check.shIf both checks pass, the next likely area is the SSVM-to-SSVM copy path, not the agent state. Immediately after reproducing the failure, please also provide:
grep -C 30 -E 'd62e7587|1fb812b7' /var/log/cloudstack/management/management-server.logThose lines should expose the exact URL/host/port that returned |
|
i think i got the issue both the ssvm health is good the second one while copying snapshots i got this error in the destinantion ssvm and the same error in management server |
|
Thanks for sharing the outputs. Both SSVM health checks look good, and connectivity to the management server on port 8250 is working. Since the issue occurs specifically while copying the template between zones, could you please check the connectivity between the source and destination SSVMs? From the destination SSVM, please test whether the source SSVM is reachable on the port used for the template copy (HTTP/HTTPS), and perform the same test in the reverse direction. Also, please reproduce the template copy once and share the corresponding management.log entries from the time of the failure. If possible, please include the CopyCommand / template-copy URL and the exact error returned by the SSVM. This will help determine whether the failure is caused by the SSVM-to-SSVM copy path, firewall/routing, or the actual template copy request. Regards, |
Uh oh!
There was an error while loading. Please reload this page.
I am facing this error during copying a template from zone a to zone b
We get this same kind of error during copying the snapshot but previously we have tried to copy the template and one of them worked but now it is failing....but before doing the copy we have synced both the secondary storage from zone a to zone b. So do we need to sync again from zone a to zone?
All reactions