| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Strange (???) xl behavior for save, migrate and migrate-
|
To: |
Daniel Kiper <dkiper@xxxxxxxxxxxx> |
|
Subject: |
Re: [Xen-devel] Strange (???) xl behavior for save, migrate and migrate-receive |
|
From: |
Olaf Hering <olaf@xxxxxxxxx> |
|
Date: |
Mon, 17 Oct 2011 21:12:05 +0200 |
|
Cc: |
jeremy@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, konrad.wilk@xxxxxxxxxx, ian.jackson@xxxxxxxxxxxxx, v.tolstov@xxxxxxxxx, ian.campbell@xxxxxxxxxxxxx |
|
Delivery-date: |
Mon, 17 Oct 2011 12:13:24 -0700 |
|
Dkim-signature: |
v=1; a=rsa-sha1; c=relaxed/relaxed; t=1318878766; l=1610; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=DfthFbqfU3+dfSdwakVG5177qGY=; b=B+fSfsDhYLweKfnNOBDY15EtKa30Pk7h5PdfEUu8DX7zliE/IORY2sHI+h+nqSSp2B6 QOs8N6lJsX1mGou+Oe5CvJg0aJgOwsTsLZs0hh3y3ltGSWu++Okk+DKIxmkgKnJ6+xddG /RnUQg9CKMqWpDiRPuZWNctDip4topD2uRk= |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<20111017174036.GD29445@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
References: |
<20111017174036.GD29445@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Mutt/1.5.21.rev5535 (2011-07-01) |
On Mon, Oct 17, Daniel Kiper wrote:
> During work on memory hotplug for Xen I have received some notices
> that it breaks machine migration. I had some time and I done some
> tests a few days ago. It looks that source of this problem is
> xl command itself. I discovered that generic save/restore mechanism
> is used for machine migration. xl save store machine config which
> was used at machine startup with current machine state. It means
> that it does not take into account any config changes which were made
> during machine run. This behavior does not allow migrating domain,
> on which memory hotplug was used, to restore on destination host
> because current size of memory allocated for machine is larger than
> size of memory allocated at startup by memory option. Yes, it is
> memory option not maxmem option. However, it is not important here
> because I think that generic behavior of xl save, migrate and migrate-receive
> should be changed (fix for memory hotplug case is workaround for the
> generic problem which will return sooner or later). I think that xl save,
> migrate and migrate-receive should use current machine state and __CURRENT__
> config (from xenstore ???) to do their tasks. However, I am aware that
> this change could have large impact on current users. That is why I decided
> to ask you about your opinion and suggested solutions in that case
> (in general not memory hotplug only).
Its easy to implement in xl by throwing some xenstore watches into the
code.
http://lists.xensource.com/archives/html/xen-devel/2011-10/msg00778.html
Olaf
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home