Bug 1858622
| Summary: | Volume metadata is not copied from source volume | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Benny Zlotnik <bzlotnik> | ||||
| Component: | BLL.Storage | Assignee: | Benny Zlotnik <bzlotnik> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Shir Fishbain <sfishbai> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 4.4.0 | CC: | aoconnor, bugs, dfodor, eshenitz, tnisan | ||||
| Target Milestone: | ovirt-4.4.1-1 | Keywords: | Regression | ||||
| Target Release: | --- | Flags: | pm-rhel:
ovirt-4.4+
aoconnor: blocker+ |
||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | No Doc Update | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-08-05 06:28:18 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Note: The description will be handled separately in bug 1841183 Almost verified, the copied template disk has a LEAF volume but the description is still missing (look at the screenshot- there is a description )
The volume of the template disk before "copy disk" operation:
# vdsm-client StorageDomain dump sd_id=bcdfdd99-eb20-4cd6-a787-e8002ba95d86
"volumes": {
"5148c988-2ed1-4894-a0dc-a5be4bc66736": {
"apparentsize": 10737418240,
"capacity": 10737418240,
"ctime": 1595716300,
"description": "None",------> missing the description that appears in the screenshot attached
"disktype": "DATA",
"format": "RAW",
"generation": 1,
"image": "ee0df603-caf4-4db6-8ef7-703af46015e4",
"legality": "LEGAL",
"mdslot": 4,
"parent": "00000000-0000-0000-0000-000000000000",
"status": "OK",
"truesize": 10737418240,
"type": "PREALLOCATED",
"voltype": "LEAF"
},
The same volume just after copy disk operation:
"volumes": {
"5148c988-2ed1-4894-a0dc-a5be4bc66736": {
"apparentsize": 10737418240,
"capacity": 10737418240,
"ctime": 1595716300,
"description": "None",-------> still missing the description after copy template disk operation
"disktype": "DATA",
"format": "RAW",
"generation": 1,
"image": "ee0df603-caf4-4db6-8ef7-703af46015e4",
"legality": "LEGAL",
"mdslot": 4,
"parent": "00000000-0000-0000-0000-000000000000",
"status": "OK",
"truesize": 10737418240,
"type": "PREALLOCATED",
"voltype": "LEAF"
},
The volume of the copy disk:
"e15dfda6-4c25-48ec-848a-5ff923c56309": {
"apparentsize": 10737418240,
"capacity": 10737418240,
"ctime": 1595716483,
"description": "None",
"disktype": "DATA",
"format": "RAW",
"generation": 1,
"image": "2d089bec-ba4c-4f6a-872f-dbdd072250a4",
"legality": "LEGAL",
"mdslot": 5,
"parent": "00000000-0000-0000-0000-000000000000",
"status": "OK",
"truesize": 10737418240,
"type": "PREALLOCATED",
"voltype": "LEAF"
},
Benny, tell me if you need an environment to look at this issue.
Created attachment 1702416 [details]
screenshot
The missing description fix is part of a different bug 1841183. The fix for this bug include only the "voltype". Verified The description will be verified on https://bugzilla.redhat.com/show_bug.cgi?id=1841183 Versions: vdsm-4.40.22-1.el8ev.x86_64 ovirt-engine-4.4.1.10-0.1.el8ev.noarch After talked with Benny and understood the verification scenario flow, this is the right verification for this bug:
Verified
Before copy disk:
# vdsm-client StorageDomain dump sd_id=85c54e79-7ad9-4750-9a67-faba395ca3d3
"c1291088-42f4-4205-aacd-d6152fbea422": {
"apparentsize": 4294967296,
"capacity": 4294967296,
"ctime": 1595513636,
"description": "{\"DiskAlias\":\"shir_verification_vm_Disk1\",\"DiskDescription\":\"\"}",
"disktype": "DATA",
"format": "RAW",
"generation": 0,
"image": "4a48b8bb-b3e5-4401-84b7-3f6148d8cc4b",
"legality": "LEGAL",
"parent": "00000000-0000-0000-0000-000000000000",
"status": "OK",
"truesize": 4222976,
"type": "SPARSE",
"voltype": "SHARED"
},
After copy disk:
"c1291088-42f4-4205-aacd-d6152fbea422": {
"apparentsize": 4294967296,
"capacity": 4294967296,
"ctime": 1595755284,
"description": "None",
"disktype": "DATA",
"format": "RAW",
"generation": 2,
"image": "4a48b8bb-b3e5-4401-84b7-3f6148d8cc4b",
"legality": "LEGAL",
"parent": "00000000-0000-0000-0000-000000000000",
"status": "OK",
"truesize": 4222976,
"type": "SPARSE",
"voltype": "SHARED"
},
This bugzilla is included in oVirt 4.4.1.1 Async release, published on July 13th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.1.1 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. |
Description of problem: When performing operations that use SDM.copy_data (copy template, move/copy disk) the target disk does not have the original metadata. This happens because SDM.copy_data does not handle creation and updating like copyImage used to, now engine has to handle it. For example, a copied template disk will have a LEAF volume type instead of SHARED, and the description will always be empty Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Copy template's disk Actual results: Original volume: $ vdsm-client StorageDomain dump sd_id=84d6d137-49c2-4b02-86eb-ef31a126abd9 | jq '.volumes | .[] | select(.image=="9280f5cb-1154-4ac5-a065-4c55a32126a8")' { "apparentsize": 1073741824, "capacity": 1073741824, "ctime": 1595159063, "description": "{\"DiskAlias\":\"ka_Disk1\",\"DiskDescription\":\"\"}", "disktype": "DATA", "format": "RAW", "generation": 0, "image": "9280f5cb-1154-4ac5-a065-4c55a32126a8", "legality": "LEGAL", "parent": "00000000-0000-0000-0000-000000000000", "status": "OK", "truesize": 4096, "type": "SPARSE", "voltype": "SHARED" } Target volume: $ vdsm-client StorageDomain dump sd_id=1d8cd36e-0fc6-4c67-a737-3ca9dd81176b | jq '.volumes | .[] | select(.image=="9280f5cb-1154-4ac5-a065-4c55a32126a8")' { "apparentsize": 1073741824, "capacity": 1073741824, "ctime": 1595164276, "description": "None", <---- missing description "disktype": "DATA", "format": "RAW", "generation": 0, "image": "9280f5cb-1154-4ac5-a065-4c55a32126a8", "legality": "LEGAL", "parent": "00000000-0000-0000-0000-000000000000", "status": "OK", "truesize": 4096, "type": "SPARSE", "voltype": "LEAF" <---- incorrect } Expected results: Target volume: $ vdsm-client StorageDomain dump sd_id=84d6d137-49c2-4b02-86eb-ef31a126abd9 | jq '.volumes | .[] | select(.image=="9280f5cb-1154-4ac5-a065-4c55a32126a8")' { "apparentsize": 1073741824, "capacity": 1073741824, "ctime": 1595159063, "description": "{\"DiskAlias\":\"ka_Disk1\",\"DiskDescription\":\"\"}", "disktype": "DATA", "format": "RAW", "generation": 0, "image": "9280f5cb-1154-4ac5-a065-4c55a32126a8", "legality": "LEGAL", "parent": "00000000-0000-0000-0000-000000000000", "status": "OK", "truesize": 4096, "type": "SPARSE", "voltype": "SHARED" } Additional info: