xm save fails to save all pages

xm save fails to save all pages

[Juergen Gross]

Hi,

in preparation to support live migration for BS2000 I'm testing my domU (HVM
with PV-drivers) with xm save/restore. I'm running xen 4.0.2 (from SLES11 SP1).

During xm save I see the following line in xend.log:

[2011-10-25 13:25:25 31519] INFO (XendCheckpoint:484) Saving memory pages: 
iter 1   0%type fail: page 510 mfn 000011fe

I added some diagnostic code to the hypervisor (in arch/x86/domctl.c) and found
that the hypervisor believes gmfn 11fe of the domU is part of the xen heap.

The problem is always reported for gmfn 11fe, regardless of the memory size of
the domU: I tried 1, 2 and 8 GB. The memory page isn't used for anything
special in the domU, there is no problem accessing it or mapping it to dom0
before doing the xm save (or after xm save -c).

When I try to restore the saved domain I can't map gmfn 11fe of the domU any
longer in dom0 (this was the first hint there is a problem at all).

How can a domU memory page be part of the xen heap?


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

Re: xm save fails to save all pages

[Keir Fraser]

On 25/10/2011 14:15, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:

> in preparation to support live migration for BS2000 I'm testing my domU (HVM
> with PV-drivers) with xm save/restore. I'm running xen 4.0.2 (from SLES11
> SP1).
> 
> During xm save I see the following line in xend.log:
> 
> [2011-10-25 13:25:25 31519] INFO (XendCheckpoint:484) Saving memory pages:
> iter 1   0%type fail: page 510 mfn 000011fe
> 
> I added some diagnostic code to the hypervisor (in arch/x86/domctl.c) and
> found
> that the hypervisor believes gmfn 11fe of the domU is part of the xen heap.
> 
> The problem is always reported for gmfn 11fe, regardless of the memory size of
> the domU: I tried 1, 2 and 8 GB. The memory page isn't used for anything
> special in the domU, there is no problem accessing it or mapping it to dom0
> before doing the xm save (or after xm save -c).
> 
> When I try to restore the saved domain I can't map gmfn 11fe of the domU any
> longer in dom0 (this was the first hint there is a problem at all).
> 
> How can a domU memory page be part of the xen heap?

It could be the domain's shared-info page, or one of its grant-table pages.
It doesn't make sense to save/restore such pages -- they get reconstructed
appropriately on the receiving end, by the toolstack and/or by the domain
itself when it resumes execution.

 -- Keir

Re: xm save fails to save all pages

[Juergen Gross]

On 10/25/2011 03:32 PM, Keir Fraser wrote:
> On 25/10/2011 14:15, "Juergen Gross"<juergen.gross@ts.fujitsu.com>  wrote:
>
>> in preparation to support live migration for BS2000 I'm testing my domU (HVM
>> with PV-drivers) with xm save/restore. I'm running xen 4.0.2 (from SLES11
>> SP1).
>>
>> During xm save I see the following line in xend.log:
>>
>> [2011-10-25 13:25:25 31519] INFO (XendCheckpoint:484) Saving memory pages:
>> iter 1   0%type fail: page 510 mfn 000011fe
>>
>> I added some diagnostic code to the hypervisor (in arch/x86/domctl.c) and
>> found
>> that the hypervisor believes gmfn 11fe of the domU is part of the xen heap.
>>
>> The problem is always reported for gmfn 11fe, regardless of the memory size of
>> the domU: I tried 1, 2 and 8 GB. The memory page isn't used for anything
>> special in the domU, there is no problem accessing it or mapping it to dom0
>> before doing the xm save (or after xm save -c).
>>
>> When I try to restore the saved domain I can't map gmfn 11fe of the domU any
>> longer in dom0 (this was the first hint there is a problem at all).
>>
>> How can a domU memory page be part of the xen heap?
> It could be the domain's shared-info page, or one of its grant-table pages.
> It doesn't make sense to save/restore such pages -- they get reconstructed
> appropriately on the receiving end, by the toolstack and/or by the domain
> itself when it resumes execution.

Thanks! It IS a grant-table page.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html