Re: [Xen-devel] [PATCH v10 5/5] libxl: network buffering cmdline switch

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Hongyang Yang writes ("Re: [PATCH v10 5/5] libxl: network buffering cmdline 
switch"):
> On 06/06/2014 01:30 AM, Ian Jackson wrote:
> > Wouldn't it be better if these were options on the devices, in the
> > domain configuration ?
> 
> Do you mean we make "-n -N" options into domain configuration?

Well, the equivalent information, yes.  Not exactly as those options.

> I think these options are only related to remus and may not be used that
> often because we provided a default network script which would be suitable
> for most cases. these options are sort of second choices for users, may not
> worth to be set in the domain configuration.

There is no problem with having extra options in the domain
configuration which most users do not set.  Users who don't want to
use remus can just ignore them.

The real question here is this: in a single system, is the network
buffering configuration more likely to, for a single domain (a) vary
between different devices or (b) vary between subsequent invocations
of remus ?

If we put the netbuffer config in the arguments to the remus
invocation, (a) becomes impossible.  If we put it in the domain device
configuration, (b) becomes difficult (although perhaps not quite
impossible).

> > Feel free to tell me I'm wrong and it is better this way, if that's
> > true - just explain it.
> >
> >> +     * TODO: Split-Brain check.
> >
> > What are your plans for the split brain check ?
> 
> It's hard to do the split brain check under current implementation because
> there's only one remus connection between the two domain. We may need to add
> a heardbeat module to do this.

Yes.  I guess my question is: do you plan to add hooks/calls/something
to libxl to allow the construction of a coherent system ?  That is, do
you intend that the libxl remus API will acquire the necessary
interfaces to connect to an external heartbeat module ?

Thanks,
Ian.

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