[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory
On 04/14/2015 05:29 PM, Wei Liu wrote: On Tue, Apr 14, 2015 at 05:22:31PM +0800, Hongyang Yang wrote: [...]If I understand correctly, the steps are this: * 'xl create' makes a VM of size $FOO * qemu bumps the size to $FOO+$N * 'xl save' writes $FOO+$N of page data, but the xl config file at the start of the image still says $FOO * 'xl restore' creates a vm of size $FOO, then instructs xc_domain_restore() to put $FOO+$N pages into it. I would argue first, that qemu should not play in this area to start with. However, the real bug here is that the domain configuration written by xl save is inaccurate.There's a case like COLO: 1. Both Primary/Secondary VM are created first with the same config file which makes a VM of size $FOO 2. qemu bumps the size to $FOO+$N 3. 'save' writes $FOO+$N of page data 4. 'restore' put $FOO+$N pages into $FOO pages which will cause error Even if you fix the configuration, the bug still exists because the config only been transferred from Primary to Secondary once at the very beginning when you execute 'xl remus' command. The problem is how to let the secondary (restore) side knows the size change? Through a migration command(which is easier in v2 migration) or some other solution?As I said in my reply to Don, the extra memory can be saved during domain creation. That would solve this problem. After migration we'll enter COLO mode, which will continously send migration stream to Secondary. Domain creation only happens before doing live migration. Wei.Form this point of view, I think Don's solution is one way to solve the problem.~Andrew .-- Thanks, Yang.. -- Thanks, Yang. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |