Re: [Xen-devel] [PATCH v19 08/12] xl/remus: cmdline switch to explicitly enable unsafe configurations

[Shriram Rajagopalan <rshriram@xxxxxxxxx>]

On Sep 24, 2014 11:40 AM, "Ian Jackson" <Ian.Jackson@xxxxxxxxxxxxx> wrote:
>
> Yang Hongyang writes ("[PATCH v19 08/12] xl/remus: cmdline switch to explicitly enable unsafe configurations"):
> > By default, network buffering and disk replication are enabled;
> > checkpoints are replicated to another standby VM.
> >
> > This patch allows the user to disable any of these features by
> > explicitly specifying a 'run in unsafe mode' switch when invoking
> > the 'xl remus' command. While running Remus in an unsafe mode
> > makes little sense under normal circumstances, it is useful to be
> > able to disable one or more features mentioned above for
> > testing/debugging/profiling purposes.
> >
> > Unless this option is enabled, it will not be possible to
> > replicate memory checkpoints to /dev/null (blackhole replication),
> > disable network buffering or disk replication.
> >
> > As a starter, the use of blackhole replication now requires that
> > the unsafe mode be enabled. Subsequent patches will add support
> > for disabling network buffering and disk replication in a similar
> > manner.
>
> This is fine in general, but I have a comment which Ian Campbell may
> disagree about:
>
> >Â libxl_domain_remus_info = Struct("domain_remus_info",[
> >   ("interval",  Âinteger),
> > +  ("unsafe",   Âlibxl_defbool),
> >   ("blackhole",  libxl_defbool),
> >   ("compression", libxl_defbool),
>
> Ian, would this `unsafe' option better exist only at the xl level ?
>

This needs to be at libxl level because other users of the libxl_Remus_domain_start API could potentially invoke it with net/buffer disabled, with the assumption that such a config would still provide the desired HA semantics. The libxl level unsafe option forces the caller to explicitly acknowledge that he/she is aware of the consequences. Whether the caller is xl or libvirt or someone else, it doesn't matter.
FYI, there is literally no prep work in xl (in safe config). Given that the whole Remus api is now asynchronous, other users of libxl can invoke Remus on a domain with equal ease as xl.

> Ian.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel