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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.