From f998f58eb9b0b907d532179a832c1b07e457148d Mon Sep 17 00:00:00 2001 From: Pan Ousley Date: Thu, 31 Mar 2022 17:21:01 -0400 Subject: [PATCH] BZ2067190: HPP error re: too-long FQDN --- virt/virt-4-10-release-notes.adoc | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/virt/virt-4-10-release-notes.adoc b/virt/virt-4-10-release-notes.adoc index af776e340d0a..aa97b5390a03 100644 --- a/virt/virt-4-10-release-notes.adoc +++ b/virt/virt-4-10-release-notes.adoc @@ -164,6 +164,23 @@ To use the HPP to provide storage for virtual machine disks, configure it with d [id="virt-4-10-known-issues"] == Known issues +* If you deploy the xref:../virt/virtual_machines/virtual_disks/virt-configuring-local-storage-for-vms.adoc#virt-configuring-local-storage-for-vms[hostpath provisioner] on a cluster where any node has a fully qualified domain name (FQDN) that exceeds 42 characters, the provisioner fails to bind PVCs. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2057157[*BZ#2057157*]) ++ +-- +.Example error message +[source,terminal] +---- +E0222 17:52:54.088950 1 reflector.go:138] k8s.io/client-go/informers/factory.go:134: Failed to watch *v1beta1.CSIStorageCapacity: failed to list *v1beta1.CSIStorageCapacity: unable to parse requirement: values[0][csi.storage.k8s.io/managed-by]: Invalid value: "external-provisioner-": must be no more than 63 characters <1> +---- +<1> Though the error message refers to a maximum of 63 characters, this includes the `external-provisioner-` string that is prefixed to the node's FQDN. +-- +** As a workaround, disable the `storageCapacity` option in the hostpath provisioner CSI driver by running the following command: ++ +[source,terminal] +---- +$ oc patch csidriver kubevirt.io.hostpath-provisioner --type merge --patch '{"spec": {"storageCapacity": false}}' +---- + * If your {product-title} cluster uses OVN-Kubernetes as the default Container Network Interface (CNI) provider, you cannot attach a Linux bridge or bonding device to a host's default interface because of a change in the host network topology of OVN-Kubernetes. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1885605[*BZ#1885605*]) ** As a workaround, you can use a secondary network interface connected to your host, or switch to the OpenShift SDN default CNI provider. @@ -237,7 +254,7 @@ $ oc annotate --overwrite -n openshift-cnv hco kubevirt-hyperconverged 'networka * {VirtProductName} links a service account token in use by a pod to that specific pod. {VirtProductName} implements a service account volume by creating a disk image that contains a token. If you migrate a VM, then the service account volume becomes invalid. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2037611[*BZ#2037611*]) ** As a workaround, use user accounts rather than service accounts because user account tokens are not bound to a specific pod. -* * If a VM crashes or hangs during shutdown, new shutdown requests do not stop the VM. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2040766[*BZ#2040766*]) +* If a VM crashes or hangs during shutdown, new shutdown requests do not stop the VM. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2040766[*BZ#2040766*]) * If you configure the `HyperConverged` custom resource (CR) to enable mediated devices before drivers are installed, enablement of mediated devices does not occur. This issue can be triggered by updates. For example, if `virt-handler` is updated before `daemonset`, which installs NVIDIA drivers, then nodes cannot provide virtual machine GPUs. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2046298[*BZ#2046298*]) ** As a workaround: