Bug 2088220
| Summary: | DV remains in cloneScheduled while the source dv is HPP and the target dv is OCS | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Container Native Virtualization (CNV) | Reporter: | Guohua Ouyang <gouyang> | ||||||||
| Component: | Storage | Assignee: | Bartosz Rybacki <brybacki> | ||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Yan Du <yadu> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | high | ||||||||||
| Version: | 4.11.0 | CC: | alitke, brybacki, cnv-qe-bugs, gouyang, yadu | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | 4.11.0 | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2022-06-28 15:00:26 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 1881156 [details]
rhel9
Created attachment 1881157 [details]
vm
There is error showed in cdi deployment pod : Error validating clone spec, ignoring","PVC":"default/rhel9-smoggy-bear","error":"target resources requests storage size is smaller than the source workaround: set the disk size larger Bartosz can you please take a look? Bartosz, do you have any updates for this bug? Yes, it is now in review waiting to be merged and backported to correct version (UPSTREAM). The problem is with the validation method we use in the webhook. It is not working correctly for block to filesystem clones. The fix removes the validation and improves the validation that is done later in the controller logic. Well, after looking at the actual yaml dumps I can see that the source is 109G while the target is 30G. This will not work. This is actually not related to the other bug that is being fixed by the PR I mentioned. Who creates the template? Is it a manual template or something created by UI. If by UI then there is another question: how it was created? Was the source PVC resized in the meantime? There is a new way of specifying DVTemplate. A template without size. I think it will be available in 4.12 @gouyang can you provide some more info on my questions? Who creates the template? Is it a manual template or something created by UI. If it is created by UI then there is another question: how it was created? Was the source PVC resized in the meantime, between template creation and creating a VM? (In reply to Bartosz Rybacki from comment #8) > @gouyang can you provide some more info on my questions? > > Who creates the template? Is it a manual template or something created by > UI. The templates are creating by common-templates component: https://github.com/kubevirt/common-templates > If it is created by UI then there is another question: how it was created? > Was the source PVC resized in the meantime, between template creation and > creating a VM? From what I can see (by looking at the few templates here: https://github.com/kubevirt/common-templates/tree/master/templates) the target size is hardcoded in the template. In that case it will only work if the source is smaller. Bartosz, In this case the templates are on HPP and have been expanded due to fs overhead but the VM wants to use block. Shouldn't we accept a smaller size because fs overhead does not apply to block? It seems that the rhel9 template is 30G in size so it really should work. You are right Adam, in that case it is exactly the fix I did in kubevirt/containerized-data-importer/pull/2299. I am backporting it right now. *** This bug has been marked as a duplicate of bug 2084122 *** |
Created attachment 1881155 [details] dv Description of problem: DV remains in cloneScheduled while the source dv is HPP and the target dv is OCS Version-Release number of selected component (if applicable): v4.11.0-369 How reproducible: Steps to Reproduce: 1. on web console, create a VM and change the storageClass from HPP(default) to OCS 2. the dv remains in cloneScheduled. 3. Actual results: Expected results: Additional info: