On Thu, Aug 13, 2026 at 04:09:00PM +0200, Peter Krempa wrote:
On Tue, Aug 11, 2026 at 13:58:07 +0100, John Levon wrote:
For NVRAM storage specifically, the guest-visible size is critical to correct handling of the OVMF address space. Allow specifying storage slices for NVRAM storage when the underlying file/block may be larger
This explanation doesn't make sense for the 'file' backed NVRAM because file size can be arbitrary.
I can correct the explanation so that it mentions offset instead for files, as that still seems useful even for file backend?
due to alignment/allocation restrictions.
For block devices we support 'qcow2' formatted nvram block device for this reason so that the size can be embedded.
Yes, I'm aware of that, it's not a good fit for the way we manage this storage for a few reasons. FWIW it was Nutanix who introduced this restriction in the first place, so this is just correcting a previous patch of ours.
For _BLOCK this patch is incomplete. Theoretically use of a storage slice still allows the qcow2 image format to be present. The code in `qemuPrepareNVRAMBlock` tries to probe the qcow2 format in the block device to see if it needs to be populated. That will not work with a storage slice (if e.g. offset is populated). So either `qemuPrepareNVRAMBlock` needs to have an exception if a slice is present or the slice needs to be refused for qcow2 ... or rather allowed only for 'raw' nvram block device.
Thanks, good spot, before I prepare one, would you accept a patch that does this? Allows the slice for file+block but only if qcow2 is not configured? regards john