-
Bug
-
Resolution: Done
-
Undefined
-
None
-
CNV v4.18.0
Description of problem:
In the section About vTPM devices[1], the documentation incorrectly claims that "You must specify the storage class to be used by the PVC by setting the vmStateStorageClass attribute in the HyperConverged custom resource (CR)." While it is still recommended that the user sets the storage class explicitly, the claim that it must be set is incorrect. Below is an explanation from Alvaro: If no vmStateStorageClass is set, kubevirt will try to use the default virt storage class (storageclass.kubevirt.io/is-default-virt-class). If there's no default virt storage class, it will try to use the k8s default storage class (storageclass.kubernetes.io/is-default-class). [...] it's still recommended to explicitly set a vmStateStorageClass, the behavior to set the storage class if none is defined could change in future releases. Additionally, John made the following comment: "When I look at the documents, there does not appear to be a difference between a defaultĀ k8s storage class and a default virt storage class." For example, the important information about default storage class behavior is hidden in a note in section Storage requirements[2]. If there is a gap or the information is difficult to find, we should improve the docs. ____ [1] https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/virtualization/virtual-machines#virt-about-vtpm-devices_virt-using-vtpm-devices [2] https://docs.redhat.com/en/documentation/openshift_container_platform/4.16/html/virtualization/installing#storage-requirements_preparing-cluster-for-virt
Version-Release number of selected component (if applicable):
4.18 (and probably older, to be determined)
How reproducible:
Always
- links to