Skip to content

CNV-60438: Correct misleading information about vTPM devices #92553

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.

Sign up for GitHub

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

Merged
sheriff-rh merged 1 commit into from
May 13, 2025
Merged

CNV-60438: Correct misleading information about vTPM devices #92553

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 22 additions & 1 deletion modules/virt-about-vtpm-devices.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,28 @@ You can use a vTPM device with any operating system, but Windows 11 requires
the presence of a TPM chip to install or boot. A vTPM device allows VMs created
from a Windows 11 image to function without a physical TPM chip.

A vTPM device also protects virtual machines by storing secrets without physical hardware. {VirtProductName} supports persisting vTPM device state by using Persistent Volume Claims (PVCs) for VMs. You must specify the storage class to be used by the PVC by setting the `vmStateStorageClass` attribute in the `HyperConverged` custom resource (CR):
{VirtProductName} supports persisting vTPM device state by using Persistent Volume Claims (PVCs) for VMs. If you do not specify the storage class for this PVC, {VirtProductName} uses the default storage class for virtualization workloads. If the default storage class for virtualization workloads is not set, {VirtProductName} uses the default storage class for the cluster.

[NOTE]
====
The storage class that is marked as default for virtualization workloads has the annotation `storageclass.kubevirt.io/is-default-virt-class` set to "true". You can find this storage class by running the following command:

[source,terminal]
----
$ oc get sc -o jsonpath='{range .items[?(.metadata.annotations.storageclass\.kubevirt\.io/is-default-virt-class=="true")]}{.metadata.name}{"\n"}{end}'
----

Similarly, the default storage class for the cluster has the annotation `storageclass.kubernetes.io/is-default-class` set to "true". To find this storage class, run the following command:

[source,terminal]
----
$ oc get sc -o jsonpath='{range .items[?(.metadata.annotations.storageclass\.kubernetes\.io/is-default-class=="true")]}{.metadata.name}{"\n"}{end}'
----

To ensure consistent behavior, configure only one storage class as the default for virtualization workloads and for the cluster respectively.
====

It is recommended that you specify the storage class explicitly by setting the `vmStateStorageClass` attribute in the `HyperConverged` custom resource (CR):

[source,yaml]
----
Expand Down