[Qemu-devel] about post copy recovery

[Qemu-devel] about post copy recovery

[Li, Liang Z]

Hi David,

I remembered some guys wanted to solve the issue of post copy recovery when network broken down, do you know latest status?

Thanks!
Liang

Re: [Qemu-devel] about post copy recovery

[Dr. David Alan Gilbert]

* Li, Liang Z (liang.z.li@intel.com) wrote:
> 
> Hi David,
> 
> I remembered some guys wanted to solve the issue of post copy recovery when network broken down, do you know latest status?

Hi Liang,
  Yes, Haris looked at it as part of GSoC, the latest
version is what was posted:

https://lists.nongnu.org/archive/html/qemu-devel/2016-08/msg03468.html

I've not done any work on it since then;  there are a couple of
hard problems to be solved.  The simpler is making sure that
we always correctly detect a migration error due to networking
(rather than some other non-recoverable error); there's lots of
migration code that doesn't check for a file error straight away
and only hits the error code later on when it's too late to recover.

The harder problem is that we often end up with the case where
the main thread is blocked trying to access postcopied-RAM,
e.g. an emulated network driver tries to write an incoming
packet to guest RAM but finds the guest RAM hasn't arrived
yet.
With the main thread blocked it's very difficult to recover -
we can't issue any commands to trigger the recovery and even
if we could we'll have to be very careful about what things
those commands need the main thread to do.

Dave

> 
> Thanks!
> Liang
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] about post copy recovery

[Li, Liang Z]

> * Li, Liang Z (liang.z.li@intel.com) wrote:
> >
> > Hi David,
> >
> > I remembered some guys wanted to solve the issue of post copy recovery
> when network broken down, do you know latest status?
> 
> Hi Liang,
>   Yes, Haris looked at it as part of GSoC, the latest version is what was posted:
> 
> https://lists.nongnu.org/archive/html/qemu-devel/2016-08/msg03468.html
> 
> I've not done any work on it since then;  there are a couple of hard problems
> to be solved.  The simpler is making sure that we always correctly detect a
> migration error due to networking (rather than some other non-recoverable
> error); there's lots of migration code that doesn't check for a file error
> straight away and only hits the error code later on when it's too late to
> recover.
> 
> The harder problem is that we often end up with the case where the main
> thread is blocked trying to access postcopied-RAM, e.g. an emulated
> network driver tries to write an incoming packet to guest RAM but finds the
> guest RAM hasn't arrived yet.
> With the main thread blocked it's very difficult to recover - we can't issue any
> commands to trigger the recovery and even if we could we'll have to be very
> careful about what things those commands need the main thread to do.
> 
> Dave

Thanks for your information!
I will take a look first, maybe get back to you later.

Liang