Bug 1893379

Summary:	Clone cephfs PVC to RBD PVC required larger target
Product:	Container Native Virtualization (CNV)	Reporter:	Michael Henriksen <mhenriks>
Component:	Storage	Assignee:	Maya Rashish <mrashish>
Status:	CLOSED ERRATA	QA Contact:	Qixuan Wang <qixuan.wang>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	2.4.2	CC:	alitke, cnv-qe-bugs, mrashish, ngavrilo, yadu, ycui
Target Milestone:	---
Target Release:	2.6.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	hco-bundle-registry-container-v2.6.1-107	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-04-07 08:46:03 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 Michael Henriksen 2020-10-30 22:43:21 UTC

Description of problem:


Version-Release number of selected component (if applicable): 2.4.X


How reproducible:

Very likely


Steps to Reproduce:
1.  Import disk image to cephfs PVC
2.  Clone to RBD PVC of exact same size as source
3.  Observe the uploadserver pod crash

Actual results:

Continuous crash loop

Expected results:

Clone completes


Additional info:

See here for where issue was discovered:  https://bugzilla.redhat.com/show_bug.cgi?id=1893363

Comment 1 Natalie Gavrielov 2020-11-04 13:25:19 UTC

Maya, we think that having that having the global filesystem overhead at 4% would have prevented this issue (source disk would have been smaller and would naturally fit into the target PVC).
cephfs has 0 overhead since it is a shared filesystem whereas cephrbd filesystem mode PV's do have overhead.

Comment 2 Adam Litke 2021-01-11 19:25:55 UTC

Maya, In comment #1 we suggest that repeating the test where a global default fs overhead of 4% was in use would prevent the problem.  Do you agree?

Comment 3 Maya Rashish 2021-01-17 13:41:49 UTC

I suspect it wouldn't prevent the problem before this PR is merged:
https://github.com/kubevirt/containerized-data-importer/pull/1466

This is because, if resized, we will still use the full cephfs PVC size, which is too big.

Comment 4 Maya Rashish 2021-01-26 05:54:12 UTC

The target release of 2.6.1 suggests I should backport it once 2.6.0 is out. So perhaps MODIFIED isn't right.

Comment 5 Adam Litke 2021-02-16 16:27:07 UTC

Maya, can you please create a backport PR and link it to this BZ?

Comment 6 Maya Rashish 2021-02-16 16:46:32 UTC

I can't seem to link GitHub PRs. This is the backport.
https://github.com/kubevirt/containerized-data-importer/pull/1612

Comment 7 Adam Litke 2021-02-18 21:26:05 UTC

Added backport PR link

Comment 8 Qixuan Wang 2021-04-01 02:47:21 UTC

Tested with CDI v2.6.1-9, hco-v2.6.1-114

Images can be cloned from cephfs to ceph rbd with the same requested disk size meanwhile taking default global filesystem overhead into account. The bug has been fixed, thanks.


Here is the test record:
[cnv-qe-jenkins@stg05-qixuan-5slqf-executor ~]$ oc get pvc
NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
clone-dv   Bound    pvc-2420d32c-c9a4-48b4-aa2a-1a30d3057542   5Gi        RWO            ocs-storagecluster-ceph-rbd   2m3s
test-dv    Bound    pvc-b04e8603-8758-48a1-a78f-ad90b5535386   5Gi        RWO            ocs-storagecluster-cephfs     8m3s

[cnv-qe-jenkins@stg05-qixuan-5slqf-executor ~]$ oc get dv
NAME       PHASE       PROGRESS   RESTARTS   AGE
clone-dv   Succeeded   100.0%                118s
test-dv    Succeeded   100.0%                7m58s

Comment 13 errata-xmlrpc 2021-04-07 08:46:03 UTC

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 (CNV 2.6.1 Images), 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/RHEA-2021:1126