On Wed, 1 Apr 2020 13:01:43 +0200 Christian Borntraeger <borntrae...@de.ibm.com> wrote:
> On 01.04.20 12:13, Cornelia Huck wrote: > > On Wed, 1 Apr 2020 04:50:14 -0400 > > Christian Borntraeger <borntrae...@de.ibm.com> wrote: > > > >> Older QEMU versions did fixup the ram size to match what can be reported > >> via sclp. We need to mimic this behaviour for machine types 4.2 and > >> older to not fail on inbound migration for memory sizes that do not fit. > >> Old machines with proper aligned memory sizes are not affected. > >> > >> Alignment table: > >> VM size (<=) | Alignment > >> -------------------------- > >> 1020M | 1M > >> 2040M | 2M > >> 4080M | 4M > >> 8160M | 8M > >> 16320M | 16M > >> 32640M | 32M > >> 65280M | 64M > >> 130560M | 128M > >> 261120M | 256M > >> 522240M | 512M > >> 1044480M | 1G > >> 2088960M | 2G > >> 4177920M | 4G > >> 8355840M | 8G > >> > >> Suggested action is to replace unaligned -m value with a suitable > > > > "to replace any unaligned -m value" ? > > > >> aligned one or to use a machine version >= 5.0 as future versions might > >> remove the compatibility handling. > > > > I'm confused by the second part of the sentence. Warning about possible > > future removal of the compat stuff is fine, but I don't understand the > > suggestion to use a machine type >= 5.0. If I create a new machine that > > does not need be migrated to an old QEMU, using the latest machine type > > always seems like the best idea, right? And for a migration target it's > > not like we can choose the version freely anyway. > > > My point was that - when you redefine your guest, which is disruptive anyway > you could also change the machine version to 5.0 and keep the strange memory > size. Ah, ok. That depends however on whether you still need compatibility, so it might not be advisable. What about: "...or to switch to a machine version >= 5.0 if migration to older machine types is not needed; future versions might remove the compatibility handling." ?
