From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: reliable live migration of large and busy guests Date: Tue, 6 Nov 2012 23:18:06 +0100 Message-ID: <20121106221806.GA1813@aepfle.de> References: <20121106202816.GA29655@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Keir Fraser Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Tue, Nov 06, Keir Fraser wrote: > It's known that if you have a workload that is dirtying lots of pages > quickly, the final stop-and-copy phase will necessarily be large. A VM that > is busy dirtying lots of pages can dirty pages much quicker than they can be > transferred over the LAN. In my opinion such migration should be done at application level. > > Should 'xm migrate --live' and 'xl migrate' get something like a > > --no-suspend option? > > Well, it is not really possible to avoid the suspend altogether, there is > always going to be some minimal 'dirty working set'. But could provide > parameters to require the dirty working set to be smaller than X pages > within Y rounds of dirty page copying. Should such knobs be exposed to the tools like x[lm] migrate --knob1 val --knob2 val? Olaf