Bug 2033191
| Summary: | Cloning a Block DV to VM with Filesystem with not big enough size comes to endless loop - using pvc api | ||
|---|---|---|---|
| Product: | Container Native Virtualization (CNV) | Reporter: | Jenia Peimer <jpeimer> |
| Component: | Storage | Assignee: | Maya Rashish <mrashish> |
| Status: | CLOSED ERRATA | QA Contact: | Jenia Peimer <jpeimer> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.10.0 | CC: | alitke, cnv-qe-bugs, fuyang, mrashish, ngavrilo, yadu |
| Target Milestone: | --- | ||
| Target Release: | 4.11.1 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | v4.11.1-20 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-12-01 21:10:19 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: | |||
|
Description
Jenia Peimer
2021-12-16 07:34:29 UTC
Created attachment 1846504 [details]
full-log-and-o-yamls-of-pvc-and-vm
Might be related to those bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2001047 https://bugzilla.redhat.com/show_bug.cgi?id=2001038 Hi, Maya, could you please take a look? Maybe the DV condition could have clear messages, so the user will know how to fix it As @brybacki suggested, reproduced on CNV v4.10.0-641, but no relevant events yet: $ oc get dv NAME PHASE PROGRESS RESTARTS AGE target-dv-vm-clone CloneInProgress 18.33% 2 12m $ oc describe dv target-dv-vm-clone ..... Phase: CloneInProgress Progress: 19.35% Restart Count: 2 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Pending 12m datavolume-controller PVC target-dv-vm-clone Pending Normal Bound 12m datavolume-controller PVC target-dv-vm-clone Bound Normal CloneInProgress 12m datavolume-controller Cloning from openshift-virtualization-os-images/cirros-dv into default/target-dv-vm-clone in progress Bartosz, prompted by the opposite problem (failing to clone fs->block because of inexact validation), has already merged a change for this to the 4.11 branch. Now when cloning block->fs with the exact same size the clone will not start (it's staying in CloneScheduled) and emits a warning event "target resources requests storage size is smaller than the source". However, while trying to reproduce this bug, I uncovered a similar issue - if we clone to a slightly larger pvc, the size of the scratch space PVC is too small, resulting in similar "endless loop" behavior. Will backport this once 4.11.1 backports are possible. Verified on version 4.11.1-20.
Steps to verify:
1. Create a DV with Block volume mode, size: 30Gi.
2. Create a VM which source is the DV from step 1, using Filesystem volume mode, specifying size 30Gi and storageClassName hostpath-csi-basic.
3. Check the status of DV from step 2, and check CDI's log.
Results:
$ oc get dv
NAME PHASE PROGRESS RESTARTS AGE
target-dv-vm-clone CloneScheduled N/A 126m
$ oc get pod
No resources found in fuhui namespace.
$ oc describe dv
...
Phase: CloneScheduled
Progress: N/A
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Pending 66s datavolume-controller PVC target-dv-vm-clone Pending
Normal Bound 65s datavolume-controller PVC target-dv-vm-clone Bound
$ oc logs cdi-deployment
...
{"level":"error", ... ,"msg":"Error validating clone spec, ignoring","PVC":"fuhui/target-dv-vm-clone","error":"target resources requests storage size is smaller than the source","errorVerbose":"target resources requests storage size is smaller than the source\n ...}
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Virtualization 4.11.1 security and bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:8750 |