From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hongyang Yang Subject: Re: [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory Date: Tue, 14 Apr 2015 17:40:24 +0800 Message-ID: <552CE088.1060401@cn.fujitsu.com> References: <1428941353-18673-1-git-send-email-dslutz@verizon.com> <552BEDF1.7070209@citrix.com> <552C5683.1040903@one.verizon.com> <552CD5A7.4080803@citrix.com> <552CDC57.1020107@cn.fujitsu.com> <20150414092937.GO17670@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150414092937.GO17670@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: Ian Campbell , Stefano Stabellini , Andrew Cooper , Ian Jackson , Don Slutz , "xen-devel@lists.xen.org" , Shriram Rajagopalan List-Id: xen-devel@lists.xenproject.org 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.