Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backports of 81db7e6 and bc7f240 #879

Merged
merged 2 commits into from
May 2, 2024

Conversation

ahadas
Copy link
Member

@ahadas ahadas commented May 2, 2024

Backport of #848 and #859

ahadas added 2 commits May 2, 2024 12:19
In b0d0a68, we incorrectly dropped a check that skips setting the
"cdi.kubevirt.io/storage.bind.immediate.requested" annotation when
using virt-v2v on el9 - in that case, the conversion pod acts as the
first-consumer of the data volume and thus, there is no need in
artificial first-consumer pod.

Signed-off-by: Arik Hadas <ahadas@redhat.com>
Previously, we assumed all disks of types
VirtualDiskFlatVer1BackingInfo, VirtualDiskFlatVer2BackingInfo and
VirtualDiskRawDiskMappingVer1BackingInfo are located on a datastore. The
only exception was disks of type VirtualDiskRawDiskVer2BackingInfo for
which we didn't assume they are located on a datastore but for them RDM
is set to true and so we have a critical concern saying VMs which such
disks cannot be migrated.

However, the 'Datastore' property is optional and according to the
vSphere documentation: "If the file is not located on a datastore, then
this reference is null.". We noticed that this could actually happen,
even though we were not able to reproduce it on our development
environments, and once it happens forklift-controller crashes while
creating the inventory.

Therefore this PR introduces the following changes:
1. Make the code that builds the inventory more robust in terms of
   handling VMs with disks that are not located on a datastore
2. Add a critical concern for such VMs with disks that are not located
   on a datastore, saying such VMs cannot be migrated (later on we will
   anyway fail the validation of a plan due to unmapped storage in this
   case, even if we don't block migration of VMs with critical concerns)

Signed-off-by: Arik Hadas <ahadas@redhat.com>
Copy link

sonarcloud bot commented May 2, 2024

Quality Gate Passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

@ahadas ahadas merged commit d2e9202 into kubev2v:release-v2.6.1 May 2, 2024
6 checks passed
@ahadas ahadas deleted the release-v2.6.1 branch May 2, 2024 10:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants