Re: [Xen-users] Live migration problem

[Steven Hand <Steven.Hand@xxxxxxxxxxxx>]

>One thing I don't understand is when I look at xc_linux_save.c's =
>suspend_and_state function - it appears it does:
>
>  xcio_suspend_domain(ioctxt);
>
>retry:
>=20
>  ... stuff tries to see if xcio_suspend_domain worked - is that =
>correct?
>
>Should the xcio_suspend_domain() call be after the retry: label?  Or =
>does that xcio_suspend_domain call guarantee the message is delivered =
>and the code under retry: is just waiting for the state to now change?

The latter - although there was a bug earlier whereby even though the
message (a 'xfr_vm_suspend' message to xend) was correctly delivered,
it could get ignored by xend. This is fixed in 2.0-testing; the patch
is small though and so you could just try it on a 2.0 tree if you don't 
want to upgrade your kernels. 

>Second, I see it tries 100 times with a 10,000microsecond sleep =
>inbetween.  So it only waits for 1 second for the domain to suspend.  I =
>realize 1 second is a really long time in terms of computing.  But I'm =
>wondering what all conditions must be true for it to be able to suspend =
>a domain.  Could there legitimately be times when it would take longer =
>than a second for suspension?

So the idea here is that the domain itself may want to do various things
before it's ready to suspend - think of an ACPI 'suspend' hook which 
allows device drivers etc to get themselves prepared to power down rather
than just yanking the plug. Of course since the guest may not cooperate
etc you need to timeout on this phase. This is what's going on here. 

cheers,

S.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users