[PATCH 1/1] formatdomain.html.in: mention pSeries NVDIMM 'align down' mechanic

Andrea Bolognani abologna at redhat.com
Wed Jul 22 08:05:55 UTC 2020


On Mon, 2020-07-20 at 13:51 -0300, Daniel Henrique Barboza wrote:
> +              <li>the remaining size (total-size - label-size), also called guest
> +                area, will be aligned to 4KiB as default. For pSeries guests, the
> +                guest area will be aligned down to 256MiB, and the minimum size
> +                of the guest area must be at least 256MiB plus the label-size.</li>

The last part of the sentence seems contradictory: earlier you define
the guest area to be the total size minus the label size, but then
you say that the guest area must be at least 256MiB plus the label
size.

I suggest remove the trailing "plus the label-size". Are you okay
with me doing that before pushing? If so, then

  Reviewed-by: Andrea Bolognani <abologna at redhat.com>

Anyway, while it's good to have these requirements documented, I
believe we need to rethink our approach to NVDIMMs a bit, as the
current behavior is confusing and full of potential pitfalls.

Ideally, we'd drop the automatic alignment step which happens at
guest startup time and replace it with an upfront check on the
constraints: if the user tries to use a NVDIMM module that's not
sized or aligned properly, they'd get an error telling them that the
value they're trying to use is not good and suggesting a rounded up
alternative.

This way the size seen in the guest XML will reflect the one used at
runtime, which is much less confusing than the existin behavior, and
also the user will be able to create the backing file for the NVDIMM
to be the exact size it needs to be instead of oversizing it.

If we can't get this to work without impacting existing guests, then
at the very least we should try to reflect the rounded down size in
the inactive guest XML instead of waiting for guest startup. This is
not as nice as the alternative, because it requires the user to
actively seek the adjuste value, but still better than what we have
right now.

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list