Goal

The VMState PVC was originally introduced to provide persistent storage for a VM's TPM device state. Since then we started exploring the possibility of using it for other purposes such as changed block tracking and migration state synchronization. It is likely that most (if not all) VMs will require VMState persistence as these new features develop.

The current implementation of using one PVC per VM poses some challenges. Adding an additional PVC to each VM significantly increases the number of PVCs the system and the storage must manage which can cause us to reach storage and platform limits much faster and can reduce the number of VMs that a customer can deploy. Many storage vendors have minimum size limits for PVCs (1G or even 50G) but our current VMState data requires only tens of MB. This means we are wasting a lot of storage capacity leading to higher costs.

The goal of this epic is to find a way to store VMState more efficiently by sharing a PVC between multiple VMs.

User Stories

• As a VM admin I want to use TPM-enabled VMs without wasting storage and without reducing workload capacity.
• As a kubevirt developer I want to enable VMState by default for all VMs so that I have storage available to implement changed block tracking and migration state synchronization as first class features.

Non-Requirements

• List of things not included in this epic, to alleviate any doubt raised during the grooming process.

Notes

• The rule for all data stored in the VMState area is that it must be migrated by qemu during live migration. This ensures that RWO/Filesystem storage may always be used for VMState.