|
| 1 | +// Module included in the following assemblies: |
| 2 | +// |
| 3 | +// * documentation/doc-Release_notes/master.adoc |
| 4 | + |
| 5 | +:_mod-docs-content-type: REFERENCE |
| 6 | +[id="ref_known-issues-2-12_{context}"] |
| 7 | += Known issues |
| 8 | + |
| 9 | +[role="_abstract"] |
| 10 | +{project-first} {project-version} has the following known issues. |
| 11 | + |
| 12 | +VM migrations with XFS v4 file systems fail during conversion:: |
| 13 | +Migrating a virtual machine (VM) with an XFS v4 file system uses a Red Hat Enterprise Linux 9 `virt-v2v` image. This image does not support the `virt_v2v_memsize` and `virt_v2v_smp` parameters. As a consequence, the migration fails during the conversion phase if you set these parameters with `xfsCompatibility: true`. |
| 14 | ++ |
| 15 | +To work around this problem, do not combine `xfsCompatibility: true` with the `virt_v2v_memsize` or `virt_v2v_smp` parameters. As a result, you avoid unexpected conversion failures. |
| 16 | ++ |
| 17 | +link:https://redhat.atlassian.net/browse/MTV-5595[MTV-5595] |
| 18 | + |
| 19 | +Inactive migration plans incorrectly display as running:: |
| 20 | +The `max_vms_inflight` parameter sets a limit for concurrent virtual machine (VM) migrations or migrating disks. When migrations exceed this limit, the migration process queues the excess migration plans. As a consequence, the user interface (UI) incorrectly displays the status of these inactive, queued plans as *Running*. |
| 21 | ++ |
| 22 | +No known workaround exists. |
| 23 | ++ |
| 24 | +link:https://redhat.atlassian.net/browse/MTV-1736[MTV-1736] |
| 25 | + |
| 26 | +Deploying many User Defined Networks simultaneously causes node failures:: |
| 27 | +Migrating from VMware to OpenShift Virtualization or deploying User Defined Networks (UDNs) can cause heavy resource contention. This contention occurs if you create more than 72 UDNs and their attached resources simultaneously. Open vSwitch (OVS) becomes starved for CPU time. Additionally, there is no way to determine if a UDN is fully created before attaching resources. As a consequence, high pod ready latency occurs, and nodes might enter a `NotReady` state. |
| 28 | ++ |
| 29 | +To work around this problem, limit simultaneous UDN creation to 72 or fewer. For larger deployments, create the UDNs upfront. Wait for Open Virtual Network Kubernetes (OVNK) utilization to settle before you deploy attached resources. As a result, you maintain stable pod ready latency and prevent node failures. |
| 30 | ++ |
| 31 | +link:https://redhat.atlassian.net/browse/MTV-5695[MTV-5695] |
| 32 | + |
| 33 | +Warm migrations of NBDE VMs fail during preflight inspection:: |
| 34 | +A warm migration of a Network-Bound Disk Encryption (NBDE) virtual machine (VM) uses a DI pod. This pod cannot connect to the Tang server. As a consequence, the preflight inspection fails, and the migration plan fails. |
| 35 | ++ |
| 36 | +To work around this problem, disable the preflight inspection step by adding `runPreflightInspection: false` to the migration plan `spec`: |
| 37 | ++ |
| 38 | +[source,yaml] |
| 39 | +---- |
| 40 | +spec: |
| 41 | + ... |
| 42 | + runPreflightInspection: false |
| 43 | + ... |
| 44 | +---- |
| 45 | ++ |
| 46 | +As a result, the migration proceeds without the preflight inspection. Potential issues in the plan might not be caught before execution. |
| 47 | ++ |
| 48 | +link:https://redhat.atlassian.net/browse/MTV-5750[MTV-5750] |
0 commit comments