Re: [Xen-devel] [PATCH v2 0/3] Add support for NetBSD gntdev

[Ian Campbell <Ian.Campbell%citrix.com@localhost>]

On Fri, 2012-11-30 at 09:57 +0000, Roger Pau Monné wrote:
> On 30/11/12 10:41, Manuel Bouyer wrote:
> > On Fri, Nov 30, 2012 at 10:21:02AM +0100, Roger Pau Monné wrote:
> >>> And I don't like the idea of software doing things in my back.
> >>> And, beside this, I don't think local vs remote is the right criteria.
> >>> There are remote filesystems which may play nice with vnd. There
> >>> are local filesystems that may not play nice with vnd.
> >>
> >> I would agree with you if this was a DomU crash, but in this case the
> >> crash happens in the Dom0, and every DomU that the system might be
> >> running crashes completely. This is not acceptable in any way from my
> >> point of view.
> >>
> >> I think we should not expect the user to be aware of this kind of
> >> problems. If we cannot guarantee that the vnd driver is functional for
> >> all filesystems, we should not use it. From my point of view reliability
> >> should always come before performance.
> > 
> > In my POV, the admin show know what he's doing. This includes be aware of 
> > the
> > limitations of the software he uses. A 50% performances loss just "in case"
> > is not accetpable. Or at last last there should be a way for the admin
> > to revert to an acceptable configuration, performance wise, without
> > hacking and rebuilding from sources.
> 
> There are also other tools that build on top of libxl, like libvirt, are
> we going to modify those high level tools to add a new option to the
> config file if the disk of a DomU is in NFS and the Dom0 is NetBSD? I
> don't think we should take that road, I think libxl should take care of
> all those quicks, and provide an uniform layer that can be trusted
> independently of the environment, so the same configuration file can be
> used in all supported Dom0 OSes.
> 
> Not fixing this in libxl just moves the problem a layer upper, where
> there's a lot more of options, and of course a lot more of work to track
> and fix them all.

libxl only selects the backend itself if the caller doesn't provide one.
If the caller sets the backend field !=  UNKNOWN then libxl will (try)
and use it. This field is exposed by xl via the backendtype= key in the
disk configuration
http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt

AIUI libvirt reuses xl's syntax and so would inherit this for free. In
any case any upper layer building on libxl is likely to want to provide
the option to manually select a specific backend. I think this satisfies
Manuel's "there should be a way for the admin..." requirement.

I agree that it doesn't seem right to expect upper layers to
automatically set this manual override, IYSWIM, though.

Ian.