Repository navigation
Copy template between zones fails with md5 mismatch #3191
Description
ISSUE TYPE
- Bug Report
COMPONENT NAME
SSVM
CLOUDSTACK VERSION
4.11.2
CONFIGURATION
1 region, 2 zones, template registered/exists in zone1
OS / ENVIRONMENT
Issue confirmed on both KVM and VMware as Hypervisors
SUMMARY
When copying existing template from Zone1 to Zone2 (copyTemplate API call), md5 checksum between source and destination (copied/downloaded to Zone2) template fails
STEPS TO REPRODUCE
Register a template in Zone1, wait until Ready, thy to copy to Zone2 via GUI/API
EXPECTED RESULTS
Template copy works (did work in some of 4.5 or 4.6)
ACTUAL RESULTS
Copy operation is shown as success (in GUI at least), but actually fails with errors (visible in GUI), from SSVM cloud.log "Failed post download script: checksum "{MD5}f916328a9273c511b36e7062a1b12262" didn't match the given value, "{MD5}a92d0b7882f9c3660bb6536206f1ee2a""
Further analysis, show that we are comparing destination md5 with a wrong source md5 - check the image https://pasteboard.co/I2eJYPb4.png or in other words:
In case of VMware env, when we register the template with Zone1, there are 2 OVA files created on Secondary Storage in Zone1 i.e.
f960f054-2be3-3431-b876-72b2814fdeb3.ova
and
202-2-cac71084-dacc-35e8-9404-f72660bec1c3.ova
(both identical sizes)
Checking cloud.log in SSVM in Zone2 during copyTemplate API call, we can see we are copying over 202-2-cac71084-dacc-35e8-9404-f72660bec1c3.ova file to Zone2 – BUT we are then comparing md5sum (of downloaded file) to the wrong source file f960f054-2be3-3431-b876-72b2814fdeb3.ova.
I did not capture logs from KVM env, but as far as I recall, it failed with same error message.
Activity
yadvr commentedon Jun 7, 2019
@shwstppr can you pick this one?
DaanHoogland commentedon Dec 3, 2019
here are two different checksums:
In the case of downloading a regular image these are the same, but when downloading some sort of archive, the archive will be unpacked on arrival and the result will not match the initial checksum. The checksum can not be updated as it may be used for a re-download.
the original design has not taken this into account.
I propose to implement the following:
-+ checksum is copied to 'original_checksum' and a new checksum is stored
-+ error
There is a caveat to this, if there is multiple copies around and they don't all have the same checksum..?
Alternative also involves an extra data field but proactively always add an afterdownload checksum (after checksum ok and unpack) to the DB
the caveat to that one is "When use which?"
@andrijapanicsb any thoughts?
template: copy md5 mismatch (#3383)
template: copy md5 mismatch (apache#3383)