xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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

  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).