From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Ian Campbell <ian.campbell@citrix.com>
Subject: Re: Possible error restoring machine
Date: Wed, 23 May 2012 09:30:41 -0400 [thread overview]
Message-ID: <CAP8mzPMxuAw5TgbMfa9crxSr_T-c3Wq+1aK8UUGpZXYKnWZdHg@mail.gmail.com> (raw)
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC2CDEB431483@LONPMAILBOX01.citrite.net>
[-- Attachment #1.1: Type: text/plain, Size: 1942 bytes --]
On Wed, May 23, 2012 at 5:39 AM, Frediano Ziglio <frediano.ziglio@citrix.com>
wrote:
> I noted a possible problem restoring a machine.
>
> In xc_domain_restore (xc_domain_restore.c) if it's not the last
> checkpoint we set O_NONBLOCK flag (search for fcntl) that we can call
> pagebuf_get or just load other pages (see following "goto loadpages;"
> line).
> Now we could ending up calling xc_tmem_restore/xc_tmem_restore_extra
> (xc_tmem.c) which call read_extract (xc_private.c) on the same non
> blocking socket/file but read_extract does not handle EAGAIN/EWOULDBLOCK
> (both can be returned on non blocking socket depending on file type and
> Unix/Linux version) leading to a failure.
> Does this make sense or is it impossible ??
>
It certainly is possible. But again, I have never seen anyone use tmem with
Remus. I dont even know if it would work properly, even if we fix the
read_exact code
to handle non-blocking fds.
For the normal live-migration scenario, the O_NONBLOCK change does not
happen.
So, RDEXACT == rdexact == read_exact, output wise.
> Also note that rdexact (xc_domain_restore.c) handle data timeout but we
> can still block in read_exact called by
> xc_tmem_restore/xc_tmem_restore_extra.
>
Yep. Only in Remus case. As stated above, havent come across anyone
using Remus + tmem and/or dont know if it would work properly. I dont
know the semantics of tmem enough to comment on remus+tmem, whether
it makes sense or not, etc..
> Last note on rdexact, isn't 1 second (HEARTBEAT_MS) too small if there
> are network problems?
>
This wont be a problem for live migration. Because that timeout code
is within the if (ctx->completed) { } block. It only becomes active when
Remus is enabled i.e. ctx->last_checkpoint = 0. Otherwise, the read call is
still blocking.
> Frediano
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 2581 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2012-05-23 13:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-23 9:39 Possible error restoring machine Frediano Ziglio
2012-05-23 10:25 ` Ian Campbell
2012-05-23 11:37 ` Frediano Ziglio
2012-05-23 13:30 ` Shriram Rajagopalan [this message]
2012-05-23 14:15 ` Dan Magenheimer
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=CAP8mzPMxuAw5TgbMfa9crxSr_T-c3Wq+1aK8UUGpZXYKnWZdHg@mail.gmail.com \
--to=rshriram@cs.ubc.ca \
--cc=frediano.ziglio@citrix.com \
--cc=ian.campbell@citrix.com \
--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 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).