Re: [PATCH v2 1/1] tools: Handle xc_maxmem adjustments

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 15/04/15 11:25, George Dunlap wrote:
> On Wed, Apr 15, 2015 at 11:16 AM, George Dunlap <dunlapg@umich.edu> wrote:
>> Without having actually reviewed the patch, I think this solution is a
>> decent one.  But if we could update it in the libxl domain config in a
>> way that was backwards-compatible, that would be fine too.  I don't
>> think we should change maxmem in the domain config -- I think there
>> should be another field, maxpages or something, which talks about the
>> hypervisor side.
> One other advantage of the solution Don gives here is that it could
> (in theory) handle the case where maxmem changes *while the guest is
> migrating*.  I suspect actually that if you change maxmem during
> migration at the moment, you may get some rather strange effects.
> This would be especially important for things like COLO or remus.

That case will blow up very spectacularly for both PV and HVM domains,
in part because of changes not being reflected in the logdirty bitmap. 
Even a domain which actively changes the size of its balloon while live
migration loop is functioning will blow up.

There is a long thread from 6? months ago which discusses the necessary
steps to make it function, but it is not trivial to fix, and certainly
wasn't something we were going to fix in the first pass of migration v2.

~Andrew