On 02.08.19 10:29, Christian Borntraeger wrote: > > > On 02.08.19 10:04, David Hildenbrand wrote: >> On 29.07.19 16:52, Igor Mammedov wrote: >>> While looking into unifying guest RAM allocation to use hostmem backends >>> for initial RAM (especially when -mempath is used) and retiring >>> memory_region_allocate_system_memory() API, leaving only single hostmem >>> backend, >>> I was inspecting how currently it is used by boards and it turns out several >>> boards abuse it by calling the function several times (despite documented >>> contract >>> forbiding it). >>> >>> s390 is one of such boards where KVM limitation on memslot size got >>> propagated >>> to board design and memory_region_allocate_system_memory() was abused to >>> satisfy >>> KVM requirement for max RAM chunk where memory region alias would suffice. >>> >>> Unfortunately, memory_region_allocate_system_memory() usage created >>> migration >>> dependency where guest RAM is transferred in migration stream as several >>> RAMBlocks >>> if it's more than KVM_SLOT_MAX_BYTES. >> >> So if I understand it correctly, we only call >> memory_region_allocate_system_memory() in case the guest initial memory >> size exceeds KVM_SLOT_MAX_BYTES - ~8TB. > > We always call it. We just call it twice for > 8TB
Yeah, that's what I meant. >> >> Do we *really* care about keeping migration of systems running that most >> probably nobody (except Christian ;) ) really uses? (especially not in >> production). >> >> I am fine keeping migration running if it's easy, but introducing hacks >> (reading below) for such obscure use cases - I don't know. >> >> @Christian: Please prove me wrong. :) > > For the time being we can block migration for guests > 8TB if that helps (it > should not > fail in a guest killing fashion), but we should > 1. continue to be able to migrate guests < 8TB > 2. continue to be > > On the other hand I find "and suddenly it fails if you go beyond this" really > unpleasant. So it would be interesting to see the next round of patches to > check how "hacky" those really are. I mean migration will work perfectly fine once we fixed it for new QEMU versions. It's only the older QEMU versions to/from the > fixed one. Looking at the log I can see that this was introduced with v2.12.0. I would document this in the next release notes: "Migration of unusual big VMs (>= 8TB) will not work from/to previous QEMU versions (up to v2.12, before that starting such guests didn't even work)." -- Thanks, David / dhildenb
