Bug 1859198

Summary:	[v2v] [doc] VM import RHV to CNV Data Volume Creating Failure Trouble Shooting
Product:	Container Native Virtualization (CNV)	Reporter:	Amos Mastbaum <amastbau>
Component:	Documentation	Assignee:	Avital Pinnick <apinnick>
Status:	CLOSED NOTABUG	QA Contact:	Amos Mastbaum <amastbau>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	2.4.0	CC:	apinnick, aspauldi, cnv-qe-bugs, istein
Target Milestone:	---
Target Release:	2.5.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:	2020-07-23 10:44:30 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 Amos Mastbaum 2020-07-21 12:22:57 UTC

Document URL:
https://importing_rhv_cnv--ocpdocs.netlify.app/openshift-enterprise/latest/virt/virtual_machines/importing_vms/virt-importing-rhv-vm.html#virt-troubleshooting-vm-import_virt-importing-rhv-vm


Section Number and Name: 

Describe the issue: 

Suggestions for improvement:

Please add the following Under the Trouble Shooting Section:

DV create failure may occur due to those possible known reasons:
1. long VM name Bug 1858578 - [v2v] [ui] VM import RHV to CNV Target VM Name longer than 63 chars should not be allowed
2. no space left on storage Bug 1858595 - [v2v] VM import RHV to CNV The import should not fail when there is no space left by the ceph provider
3. Using Block based storage like ceph - rbd -  Bug 1857926 - [v2v][RHV to CNV VM import] VM import using Ceph - Block based fail to bound PVC
RHV to CNV / ceph-rbd may sometimes start, and then fail on DV creation, 
and sometimes VM import is stuck @10% - because the import pod is pending pvc bind. 
 

Additional information:

Comment 1 Avital Pinnick 2020-07-21 14:48:39 UTC

I'm not sure that these bugs are targeted correctly.

The long VM name bug is for 4.6.

The storage bugs are for Ceph, which isn't relevant now because RHV to CNV import only works with NFS.

Please create separate bugs for each change and target them to the correct CNV versions.

Comment 2 Audrey Spaulding 2020-07-21 14:57:08 UTC

As for the bugs within this bug:

1858578 is targeted for 4.6 (as Avital says)
1858595 is targeted for CNV 2.5
1857926 is targeted for CNV 2.5

Can you please close this bug and create a separate bug for each change, targeted for the correct versions?

Comment 3 Ilanit Stein 2020-07-21 15:47:58 UTC

Clarification:

During our tests we found that the 3 bugs mentioned above lead to the exact same error, seen in the VM import resource status - Create DV failure.

This doc bug purpose is to document, for CNV-2.4, that if such error occurs, 
it might be caused by one of these known issues:
bug1
bug2
bug3

Indeed all those bugs are planned to be fixed at a later version.
This is the exact reason to why we need this doc bug for CNV-2.4.

Comment 4 Avital Pinnick 2020-07-23 10:23:40 UTC

Ilanit, I think I understand what you're trying to say. 

DV failure needs to be added to the 2.4 known issues because the 3 bugs causing DV failure will not be resolved until 2.5.

I will add it and post a link to the preview.

Comment 5 Avital Pinnick 2020-07-23 10:31:11 UTC

Or it might be better to put this in the Release Notes for 2.4.

Comment 6 Avital Pinnick 2020-07-23 10:40:28 UTC

Update: No need to provide logs. I can see the original bugs.

Since we are very close to GA, I will add this to the docs. In the future, we may decide to document known issues in the release notes.

Comment 7 Avital Pinnick 2020-07-23 10:44:30 UTC

Only the target VM name bug needs to be in 2.4 docs. Ceph is not supported in 2.4, so the other two bugs (insufficient storage, block-based storage) are irrelevant.

Target VM name is already in this docs release.

Please target the Ceph bugs for 2.5 Release Notes if they are not resolved by then.

Closing this bug because the target VM name is already in docs.