From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xen.org
Subject: Re: live migration from legacy to staging fails
Date: Thu, 7 Apr 2016 20:21:09 +0100 [thread overview]
Message-ID: <5706B325.70106@citrix.com> (raw)
In-Reply-To: <20160407154018.GA4983@aepfle.de>
On 07/04/16 16:40, Olaf Hering wrote:
> convert-legacy-stream.py fails to receive a HVM domU coming from xen-4.5.
> It runs into legacy.CHUNK_enable_verify_mode "Unable to convert a debug
> stream", but only if the '--debug' knob was passed to 'xl migrate'.
> The comment there is clearly wrong.
>
> How is this supposed to be handled? I think --debug is supposed to
> enable just all the DPRINTKs, nothing else.
Sorry - I have been having email problems today. I see have already
found and addressed the issue.
To answer this question, --debug does more than just increase the
verbosity. Once the live phase is complete, it sends the verify_mode
marker, then resends the entire memory contents. (Once the legacy
sending side was complete, it reliably fell over a SIGSEGV for me, and
ended up terminating the migration due to an early eof on the fd.)
The receiving side, on receipt of verify_mode, switches from memcpy() to
memcmp() to verify that the memory it received during the live phase
matches up.
The problematic issue is that any domain with PV rings will expect to
see memory corruption according to verify mode, and this is expected
behaviour due to {net,blk}backends continuing to process requests after
the domain has paused.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
prev parent reply other threads:[~2016-04-07 19:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-07 15:40 live migration from legacy to staging fails Olaf Hering
2016-04-07 19:21 ` Andrew Cooper [this message]
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=5706B325.70106@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=olaf@aepfle.de \
--cc=xen-devel@lists.xen.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).