Merge pull request #23424 from aburdenthehand/cnv-master-relnot-content

CNV 2.4 rel_not in master cleanup

Author: aburdenthehand

virt/virt-2-4-release-notes.adoc

@@ -1,211 +1,11 @@
-[id="virt-release-notes"]
+[id="virt-2-4-release-notes"]
 = {RN_BookName}
 include::modules/virt-document-attributes.adoc[]
-:context: virt-release-notes
+:context: virt-2-4-release-notes
 toc::[]
 
-== About {VirtProductName} {VirtVersion}
+Do not add or edit release notes here. Edit release notes directly in the branch
+that they are relevant for.
 
-include::modules/virt-what-you-can-do-with-virt.adoc[leveloffset=+2]
+This file is here to allow builds to work.
 
-=== {VirtProductName} support
-
-:FeatureName: {VirtProductName}
-include::modules/technology-preview.adoc[leveloffset=+2]
-
-== New and changed features
-
-* Managing virtual machines is simpler and more efficient due to improvements
-in design and workflow. You can now:
-** Run the virtual machine wizard with less navigation. The wizard now uses
-a comprehensive in-page style and includes a review page for confirming
-configuration details before submission.
-** Import a single VMware virtual machine with less navigation.
-** Edit virtual machine templates as well as virtual machine configurations.
-** Monitor health of virtual machine-backed services as you would for
-Pod-based services.
-** Enable persistent local storage for virtual machine images.
-** Add, edit, and view virtual CD-ROM devices attached to a virtual machine.
-** Add and view network attachment definitions with a graphical editor.
-
-== Resolved issues
-
-* Previously, when you added a disk to a virtual machine via the *Disks* tab in
-the web console, the added disk had a `Filesystem` volumeMode regardless of the
-volumeMode set in the `kubevirt-storage-class-default` ConfigMap. This issue has been fixed.
-(link:https://bugzilla.redhat.com/show_bug.cgi?id=1753688[*BZ#1753688*])
-
-* Previously, when navigating to the *Virtual Machines Console* tab,
-sometimes no content was displayed. This issue has been fixed.
-(link:https://bugzilla.redhat.com/show_bug.cgi?id=1753606[*BZ#1753606*])
-
-* Previously, attempting to list all instances of the {VirtProductName} operator
-from a browser resulted in a 404 (page not found) error.
-This issue has been fixed. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1757526[*BZ#1757526*])
-
-* Previously, if a virtual machine used guaranteed CPUs, it was not scheduled
-because the label `cpumanager=true` was not automatically set on nodes.
-This issue has been fixed. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1718944[*BZ#1718944*])
-
-== Known issues
-
-* If you have {VirtProductName} 2.1.0 deployed, you must first upgrade {VirtProductName}
-to 2.2.0 before upgrading {product-title}. Upgrading {product-title} before upgrading
-{VirtProductName} might trigger virtual machine deletion.
-(link:https://bugzilla.redhat.com/show_bug.cgi?id=1785661[*BZ#1785661*])
-
-// Don't remove: this BZ is probably true for all 2.x releases
-* The `masquerade` binding method for virtual machines cannot be used in clusters with RHEL 7 compute nodes.
-(link:https://bugzilla.redhat.com/show_bug.cgi?id=1741626[*BZ#1741626*])
-
-* After migration, a virtual machine is assigned a new IP address. However, the
-commands `oc get vmi` and `oc describe vmi` still generate output containing the
-obsolete IP address. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1686208[*BZ#1686208*])
-+
-** As a workaround, view the correct IP address by running the following command:
-+
-----
-$ oc get pod -o wide
-----
-
-* Some resources are improperly retained when removing {VirtProductName}. You
-must manually remove these resources in order to reinstall {VirtProductName}.
-(link:https://bugzilla.redhat.com/show_bug.cgi?id=1712429[*BZ#1712429*])
-
-* Users without administrator privileges cannot add a network interface
-to a project in an L2 network using the virtual machine wizard.
-This issue is caused by missing permissions that allow users to load
-network attachment definitions.
-(link:https://bugzilla.redhat.com/show_bug.cgi?id=1743985[*BZ#1743985*])
-+
-** As a workaround, provide the user with permissions to load the network attachment
-definitions.
-+
-. Define `ClusterRole` and `ClusterRoleBinding` objects to the YAML configuration
-file, using the following examples:
-+
-[source,yaml]
-----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: cni-resources
-rules:
-- apiGroups: ["k8s.cni.cncf.io"]
- resources: ["*"]
- verbs: ["*"]
-----
-+
-[source,yaml]
-----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
-  name: <role-binding-name>
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: cni-resources
-subjects:
-- kind: User
-  name: <user to grant the role to>
-  namespace: <namespace of the user>
-----
-+
-. As a `cluster-admin` user, run the following command to create the `ClusterRole`
-and `ClusterRoleBinding` objects you defined:
-+
-----
-$ oc create -f <filename>.yaml
-----
-
-* Live migration fails when nodes have different CPU models. Even in cases where
-nodes have the same physical CPU model, differences introduced by microcode
-updates have the same effect. This is because the default settings trigger
-host CPU passthrough behavior, which is incompatible with live migration.
-(link:https://bugzilla.redhat.com/show_bug.cgi?id=1760028[*BZ#1760028*])
-+
-** As a workaround, set the default CPU model in the `kubevirt-config` ConfigMap,
-as shown in the following example:
-+
-[NOTE]
-====
-You must make this change before starting the virtual machines that support
-live migration.
-====
-+
-. Open the `kubevirt-config` ConfigMap for editing by running the following command:
-+
-----
-$ oc edit configmap kubevirt-config -n openshift-cnv
-----
-+
-. Edit the ConfigMap:
-+
-[source,yaml]
-----
-kind: ConfigMap
-metadata:
-  name: kubevirt-config
-data:
-  default-cpu-model: "<cpu-model>" <1>
-----
-<1> Replace `<cpu-model>` with the actual CPU model value. You can determine this
-value by running `oc describe node <node>` for all nodes and looking at the
-`cpu-model-<name>` labels. Select the CPU model that is present on all of your
-nodes.
-
-* When running `virtctl image-upload` to upload large VM disk images in `qcow2`
-format, an end-of-file (EOF) error may be reported after the data is
-transmitted, even though the upload is either progressing normally or completed.
-(link:https://bugzilla.redhat.com/show_bug.cgi?id=1789093[*BZ#1789093*])
-+
-Run the following command to check the status of an upload on a given PVC:
-+
-----
-$ oc describe pvc <pvc-name> | grep cdi.kubevirt.io/storage.pod.phase
-----
-
-* When attempting to create and launch a virtual machine using a Haswell CPU,
-the launch of the virtual machine can fail due to incorrectly labeled nodes.
-This is a change in behavior from previous versions of {VirtProductName},
-where virtual machines could be successfully launched on Haswell hosts.
-(link:https://bugzilla.redhat.com/show_bug.cgi?id=1781497[*BZ#1781497*])
-+
-As a workaround, select a different CPU model, if possible.
-
-* If you select a directory that shares space with your operating system,
-you can potentially exhaust the space on the partition, causing the node to
-be non-functional. Instead, create a separate partition
-and point the hostpath provisioner to that partition so it will not
-interfere with your operating system.
-(link:https://bugzilla.redhat.com/show_bug.cgi?id=1793132[*BZ#1793132*])
-
-* The {VirtProductName} upgrade process occasionally fails due to an interruption
-from the Operator Lifecycle Manager (OLM). This issue is caused by the limitations
-associated with using a declarative API to track the state of {VirtProductName}
-Operators. Enabling automatic updates during
-xref:install/installing-virt.adoc#virt-subscribing-to-the-catalog_installing-virt[installation]
-decreases the risk of encountering this issue.
-(link:https://bugzilla.redhat.com/show_bug.cgi?id=1759612[*BZ#1759612*])
-
-* {VirtProductName} cannot reliably identify node drains that are triggered by
-running either `oc adm drain` or `kubectl drain`. Do not run these commands on
-the nodes of any clusters where {VirtProductName} is deployed. The nodes might not
-drain if there are virtual machines running on top of them.
-The current solution is to put nodes into maintenance.
-(link:https://bugzilla.redhat.com/show_bug.cgi?id=1707427[*BZ#1707427*])
-
-* If you navigate to the *Subscription* tab on the *Operators* -> *Installed Operators*
-page and click the current upgrade channel to edit it, there might be no visible results.
-If this occurs, there are no visible errors.
-(link:https://bugzilla.redhat.com/show_bug.cgi?id=1796410[*BZ#1796410*])
-+
-** As a workaround, trigger the upgrade process to {VirtProductName} {VirtVersion}
-from the CLI by running the following `oc` patch command:
-+
-----
-$ TARGET_NAMESPACE=openshift-cnv HCO_CHANNEL=2.2 oc patch -n "${TARGET_NAMESPACE}" $(oc get subscription -n ${TARGET_NAMESPACE} --no-headers -o name) --type='json' -p='[{"op": "replace", "path": "/spec/channel", "value":"${HCO_CHANNEL}"}, {"op": "replace", "path": "/spec/installPlanApproval", "value":"Automatic"}]'
-----
-+
-This command points your subscription to upgrade channel `2.2` and enables automatic updates.