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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-09-24 at 11:00 -0700, Shriram Rajagopalan wrote:
> 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.

Would "allow_unsafe" or "force_unsafe" be a more accurate name?

Ian.


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