Bug 1889295
Summary: | [v2v][VMware to CNV VM import API] diskMappings: volumeMode Block is not passed on to PVC request. | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Container Native Virtualization (CNV) | Reporter: | Ilanit Stein <istein> | ||||||||||||
Component: | V2V | Assignee: | Sam Lucidi <slucidi> | ||||||||||||
Status: | CLOSED ERRATA | QA Contact: | Amos Mastbaum <amastbau> | ||||||||||||
Severity: | high | Docs Contact: | |||||||||||||
Priority: | high | ||||||||||||||
Version: | 2.5.0 | CC: | amastbau, cnv-qe-bugs, fdupont, pvauter, slucidi | ||||||||||||
Target Milestone: | --- | ||||||||||||||
Target Release: | 2.6.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: | 2021-03-10 11:18:56 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: |
|
Description
Ilanit Stein
2020-10-19 10:27:10 UTC
Created attachment 1722611 [details]
vmimport.v2v.kubevirt.log
Created attachment 1722612 [details]
vm-import-controller.log
Created attachment 1722613 [details]
oc_describe_pvc
Created attachment 1722614 [details]
oc_get_pvc
Created attachment 1722615 [details]
cdi-deployment.log
Currently, the AccessMode is always ReadWriteOnce and the VolumeMode is not set, which means it's always Filesystem. This is the least common configuration that will always succeed. The AccessMode is currently decided based on the ability for the source VM to live migrate. In my opinion, it should be ReadWriteMany for all storage providers that support it. This brings us to the question of having a feature matrix that we maintain in VMIO. This has not been decided yet, but I'm in favor of this solution and with each release we'll need revisit that matrix to ensure it's aligned with Kubernetes / Kubevirt / CDI capabilities. The VolumeMode is Filesystem by default because it works with all storage backends, and that's a Kubernetes choice. However, block storage backends allow using block mode (since k8s 1.9) to avoid the filesystem overhead. Again, the storage provider doesn't tell whether the backend is filesystem or block, so in theory a user could request block mode even on a NFS storage class and the migration would fail. And I'll pull again the feature matrix card :) Because the solution has not been flushed out, we can't commit to implement it before CNV 2.6.0. So, I'll set the Target Release to 2.6.0. Implemented in https://github.com/kubevirt/vm-import-operator/pull/438 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 2.6.0 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-2021:0799 |