From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH 4 of 5] tools: set migration constraints from cmdline
Date: Tue, 12 Mar 2013 18:06:58 +0100 [thread overview]
Message-ID: <20130312170658.GB27485@aepfle.de> (raw)
In-Reply-To: <1363106927.32410.54.camel@zakaz.uk.xensource.com>
On Tue, Mar 12, Ian Campbell wrote:
> > -M <number> Number of iterations before final suspend (default: 30)
>
> Do the defaults here reflect the current behaviour or are they in
> themselves a change?
The numbers do not change. Currently 0 is passed into xc_domain_save,
which means that function will pick default values.
> > -A Abort migration instead of doing final suspend.
> ... if <what>
If the number of iterations or the total amount of memory transfered is
exceeded.
You are right, that knob needs a better description.
> > -int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
> > +int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
> > + const libxl_domain_suspend_properties *props,
> > const libxl_asyncop_how *ao_how)
> > {
> > AO_CREATE(ctx, domid, ao_how);
> > @@ -777,8 +778,13 @@ int libxl_domain_suspend(libxl_ctx *ctx,
> > dss->domid = domid;
> > dss->fd = fd;
> > dss->type = type;
> > - dss->live = flags & LIBXL_SUSPEND_LIVE;
> > - dss->debug = flags & LIBXL_SUSPEND_DEBUG;
> > + if (props) {
> > + dss->live = props->flags & LIBXL_SUSPEND_LIVE;
> > + dss->debug = props->flags & LIBXL_SUSPEND_DEBUG;
> > + dss->max_iters = props->max_iters;
> > + dss->max_factor = props->max_factor;
> > + dss->xlflags = props->flags;
> > + }
>
> Do these things all get sane defaults if !props? Or is !props
> disallowed? (in which case error return required)
If no props given the migration will not be a live migration. Everything
else will get sane defaults. And the hvm flag is written somewhere down
the callchain.
> >
> > libxl__domain_suspend(egc, dss);
> > return AO_INPROGRESS;
> > @@ -3769,13 +3778,17 @@ int main_migrate(int argc, char **argv)
> > char *rune = NULL;
> > char *host;
> > int opt, daemonize = 1, monitor = 1, debug = 0;
> > + int max_iters = 0, max_factor = 0, abort_if_busy = 0;
> > static struct option opts[] = {
> > {"debug", 0, 0, 0x100},
> > + {"max_iters", 1, 0, 'M'},
> > + {"max_factor", 1, 0, 'm'},
>
> Wouldn't I or i and F or f be more descriptive than M and m (without
> looking, tell me which is which? ;-) )
>
> I wouldn't especially object if these were long only options, I expect
> using them will be something only a tiny minority of users even think
> of, unless some higher level entity does it for them (in which case the
> length of the option is irrelevant).
I can tweak this part and make it long-only options.
> > + "-A, --abort_if_busy Abort migration instead of doing final suspend."
>
> As with other similar locations the text of -A needs to say under what
> conditions it aborts, I think.
I agree, will resend this patch with updated descriptions.
Olaf
next prev parent reply other threads:[~2013-03-12 17:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-06 16:48 [PATCH 0 of 5] set migrate constraints from cmdline, better xend.log logging Olaf Hering
2013-03-06 16:48 ` [PATCH 1 of 5] tools/xc: print messages from xc_save with xc_report Olaf Hering
2013-03-06 16:48 ` [PATCH 2 of 5] tools/xc: document printf calls in xc_restore Olaf Hering
2013-03-12 16:36 ` Ian Campbell
2013-03-12 16:47 ` Olaf Hering
2013-03-12 16:50 ` Ian Campbell
2013-03-12 16:58 ` Olaf Hering
2013-03-06 16:48 ` [PATCH 3 of 5] tools/xc: rework xc_save.c:switch_qemu_logdirty Olaf Hering
2013-03-06 18:13 ` Olaf Hering
2013-03-06 16:48 ` [PATCH 4 of 5] tools: set migration constraints from cmdline Olaf Hering
2013-03-12 16:48 ` Ian Campbell
2013-03-12 17:06 ` Olaf Hering [this message]
2013-03-06 16:48 ` [PATCH 5 of 5] tools: add xm migrate --log_progress option Olaf Hering
2013-03-12 16:36 ` [PATCH 0 of 5] set migrate constraints from cmdline, better xend.log logging Ian Campbell
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=20130312170658.GB27485@aepfle.de \
--to=olaf@aepfle.de \
--cc=Ian.Campbell@citrix.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.