From: Ian Campbell <ian.campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
Wen Congyang <wency@cn.fujitsu.com>,
xen devel <xen-devel@lists.xen.org>
Subject: Re: question about migration
Date: Mon, 4 Jan 2016 15:48:26 +0000 [thread overview]
Message-ID: <1451922506.13361.171.camel@citrix.com> (raw)
In-Reply-To: <22154.36943.266930.151060@mariner.uk.xensource.com>
On Mon, 2016-01-04 at 15:31 +0000, Ian Jackson wrote:
> [...]
> The daemonic xl exits in this situation because it expects the
> migration machinery to tidy up the domain.
>
> * It is not possible to resume the domain in the source after it has
> suspended.
Isn't supposed to be, isn't that why SCHEDOP_suspend returns a flag to
indicate if it was cancelled or not, so the guest can be resumed on the
source if "something" went wrong? (And isn't such a resume the same as what
happens after a checkpoint?)
Unless you are referring not to the general case but to some more specific
scenario/window where this is no longer possible?
> The domain is, in the hypervisor, in the lifecycle state
> SHUTDOWN. For this reason in general, it is a bad idea to suspend
> the guest until the migration is known to be likely to succeed.
>
> After a late migration failure the domain should probably be treated
> as crashed. This is slightly awkward to implement because the
> daemonic xl would have to hang around to see what happened next and
> perhaps be told what to do. Or maybe the migrating xl would have to
> know what the on_crash configuration was.
>
> In the meantime the failure is rather less graceful: debris is
> simply left for the user. This is not ideal but tolerable I think.
>
> Ian.
>
>
> From 00c4fc6495078026d68f3fdd88bfd29a8ad483d7 Mon Sep 17 00:00:00 2001
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Date: Mon, 4 Jan 2016 15:13:14 +0000
> Subject: [PATCH] libxl: Fix doc comment ref to DOMAIN_DEATH
>
> The doc comment for libxl_evdisable_domain_death mistakenly referred
> to DOMAIN_DESTROY but the event type name is actually DOMAIN_DEATH.
>
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> tools/libxl/libxl_event.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> index fad4c14..1ea789e 100644
> --- a/tools/libxl/libxl_event.h
> +++ b/tools/libxl/libxl_event.h
> @@ -179,9 +179,9 @@ typedef struct libxl__evgen_domain_death
> libxl_evgen_domain_death;
> int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
> libxl_ev_user, libxl_evgen_domain_death
> **evgen_out);
> void libxl_evdisable_domain_death(libxl_ctx *ctx,
> libxl_evgen_domain_death*);
> - /* Arranges for the generation of DOMAIN_SHUTDOWN and DOMAIN_DESTROY
> + /* Arranges for the generation of DOMAIN_SHUTDOWN and DOMAIN_DEATH
> * events. A domain which is destroyed before it shuts down
> - * may generate only a DESTROY event.
> + * may generate only a DEATH event.
> */
>
> typedef struct libxl__evgen_disk_eject libxl_evgen_disk_eject;
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-01-04 15:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-24 2:29 question about migration Wen Congyang
2015-12-24 12:36 ` Andrew Cooper
2015-12-25 0:55 ` Wen Congyang
2015-12-29 10:57 ` Andrew Cooper
2015-12-25 1:45 ` Wen Congyang
2015-12-25 3:06 ` Wen Congyang
2015-12-29 12:46 ` Andrew Cooper
2016-01-04 15:31 ` Ian Jackson
2016-01-04 15:44 ` Ian Campbell
2016-01-04 15:48 ` Ian Campbell [this message]
2016-01-04 16:38 ` Andrew Cooper
2016-01-04 17:46 ` Ian Jackson
2016-01-04 18:05 ` Andrew Cooper
2016-01-05 15:40 ` Ian Jackson
2016-01-05 17:39 ` Andrew Cooper
2016-01-05 18:17 ` Ian Jackson
2016-01-06 10:21 ` Ian Campbell
2015-12-29 11:24 ` Andrew Cooper
2016-01-04 10:28 ` Paul Durrant
2016-01-04 10:36 ` Andrew Cooper
2016-01-04 11:08 ` Paul Durrant
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=1451922506.13361.171.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=wei.liu2@citrix.com \
--cc=wency@cn.fujitsu.com \
--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).