All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andres Lagar Cavilla <andreslc@cs.toronto.edu>
To: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>
Cc: Teemu Koponen <tkoponen@iki.fi>, xen-devel@lists.xensource.com
Subject: Re: Live Migration Error
Date: Mon, 16 May 2005 13:55:37 -0500	[thread overview]
Message-ID: <4288ECA9.4000503@cs.toronto.edu> (raw)
In-Reply-To: <A95E2296287EAD4EB592B5DEEFCE0E9D1E3FFF@liverpoolst.ad.cl.cam.ac.uk>

Hi Ian,
I got a fresh code image this morning. Live migration works fine, even 
after un-tweaking the timer back to its default value. I have tested, 
not necessarily thoroughly, but I haven't run into trouble yet. I guess 
this closes this chapter.
For whatever it may be worth, I have some comments regarding the 
"previous" (Friday May 13) xfrd version:
- Even though timeout increase would allow live migration to complete 
succesfully this was not always the case; there was actually a 50% 
chance of success.
- On all successful migrations, the number of skipped pages after the 
last iteration and before domain suspend was always zero:

Saving memory pages: iter 3   0%
 3: sent 0, skipped 0,
 3: sent 0, skipped 0, [DEBUG] Conn_sxpr>
(AndresNfsDomain 8)[DEBUG] Conn_sxpr< err=0
[1116255361.997192] SUSPEND flags 00020004 shinfo 00000beb eip c01068fe 
esi 0002de60

- On all failed migrations, there was a nonzero number of said skipped 
pages (sometimes 12, sometimes 4)

Hope this somehow helps.
Keep up the excellent work
Andres

Ian Pratt wrote:
> 
>
>  
>>Teemu saves the day!!!
>>I actually set the timeout to 100 for no particular reason 
>>(originally it was 10, 20 didn't work either) Thanks Ian for 
>>your suggestion as well
>>    
>
>I'd be really surprised if increasing the timeout actually made a difference. Are you sure you're not just using the shadow mode fix that was checked in a couple of hours ago?
>
>Best,
>Ian
>
>  
>>Cheers!!
>>Andres
>>At 02:45 PM 5/13/2005, Teemu Koponen wrote:
>>    
>>>On May 13, 2005, at 20:07, Andres Lagar Cavilla wrote:
>>>
>>>Andres,
>>>
>>>      
>>>>I try to do a live migration in the same physical host, i.e. xm 
>>>>migrate --live 'whatever' localhost It fails with 'Error: errors: 
>>>>suspend, failed, Callbak timed out'.
>>>>It seems like transfer of memory pages works until the 
>>>>        
>>point when the 
>>    
>>>>domain needs to be suspended to do the final transfer. 
>>>>        
>>Funny thing is 
>>    
>>>>it used to work before, gloriously, and I haven't made any 
>>>>software/hardware changes. At some point a xm save command 
>>>>        
>>failed with 
>>    
>>>>timeout, and from there on live migration fails with this message. 
>>>>Non-live migration works perfectly, also between different physical 
>>>>hosts. save/restore also works flawlessly.
>>>>        
>>>I had similar timeout errors previously, when I was using a 
>>>      
>>bit slower 
>>    
>>>servers. I overcame the problem by slightly increasing the timeout 
>>>value in controller.py. It seemed to provide a remedy.
>>>
>>>Teemu
>>>
>>>--
>>>      
>>
>>_______________________________________________
>>Xen-devel mailing list
>>Xen-devel@lists.xensource.com
>>http://lists.xensource.com/xen-devel
>>
>>    

  parent reply	other threads:[~2005-05-16 18:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-13 21:14 Live Migration Error Ian Pratt
     [not found] ` <A95E2296287EAD4EB592B5DEEFCE0E9D1E3FFF@liverpoolst.ad.cl.c am.ac.uk>
2005-05-13 21:22   ` Andrés Lagar Cavilla
2005-05-16 18:55 ` Andres Lagar Cavilla [this message]
2005-05-16 20:09   ` Jim Henderson
  -- strict thread matches above, loose matches on Subject: below --
2005-05-16 20:14 Ian Pratt
2005-05-13 17:07 Andres Lagar Cavilla
2005-05-13 18:45 ` Teemu Koponen
2005-05-13 20:50   ` Andrés Lagar Cavilla
2005-05-13 21:12   ` Andrés Lagar Cavilla
2005-05-13 16:36 Ian Pratt
     [not found] ` <A95E2296287EAD4EB592B5DEEFCE0E9D1E3FE9@liverpoolst.ad.cl.c am.ac.uk>
2005-05-13 20:47   ` Andrés Lagar Cavilla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4288ECA9.4000503@cs.toronto.edu \
    --to=andreslc@cs.toronto.edu \
    --cc=m+Ian.Pratt@cl.cam.ac.uk \
    --cc=tkoponen@iki.fi \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.