Re: virtualized nfsd (Re: virtual kernels, syscall routing, etc.)

[matthew sporleder <msporleder%gmail.com@localhost>]

On Fri, Oct 16, 2009 at 4:00 PM, Antti Kantee <pooka%cs.hut.fi@localhost> wrote:
> On Fri Oct 16 2009 at 05:08:54 -0400, der Mouse wrote:
>> >> Good news everyone!
>>
>> >> I've made the kernel nfs service (nfsd) run in userspace.
>>
>> > Ok, I've worked on this a little more.  [...]
>>
>> Okay, this is relatively impressive, extracting what is normally a
>> piece of the kernel into a userland process - two pieces, in fact, the
>> NFS server and the underlying networking stack.
>
> Actually three, since the NFS server requires something to serve files
> off of, i.e. a file system driver.
>
>> But...why?  I had an NFS daemon that ran in userland as an ordinary
>> userland process, no "unholy cocktails" or "virtual kernels" or even
>> hacked-up librpcsvc needed, decades ago.  I can't have been the only
>> one.  Is this just an exercise in recreating a kernel code environment
>> in userspace, or is there something else I'm missing?
>
> You are asking two separate questions.
>
>  1) why do we want to virtualize nfsd+networking with a process?
>
> It's convenient, lightweight, and pluggable.  For instance, on a network
> you can move your nfs services freely between any physical host (as long
> as you can move the backend file system image efficiently).  With the file
> system driver in the bundle, that host doesn't necessarily even have to be
> NetBSD, but you can still serve files from an image containing our ffs.
> And if you want many, say >1000, isolated virtual services, you don't
> waste a gigaton of memory like you do in full-OS style virtualization
> such as Xen or Usermode $OS.
>
> Someone mentioned they had a real life use case for this.  Maybe they
> would care to comment more?
>

This reminds me of the NetApp GFiler I had a few years ago (back when
netapp was running on netbsd?) that would fail over
-very-transparently in the event of a problem.

It basically worked by each Filer (server) running its own image with
nfsd, smbd, etc, but could also host its pair's image concurrently if
needed.  How many other programs can you add to this vm?  :)