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

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Tue Oct 20 2009 at 09:02:05 -0400, matthew sporleder wrote:
> > 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?  :)

Well, theoretically unlimited, since you can make system calls into a
rump kernel over socket RPC.  In practise you really want them in the
same address space or at least the socket syscall path would have to be
optimized quite quite a lot.

Yea, you could add samba if you really wanted to and yea, I do have a
copy of apache somewhere using the rump virtual TCP/IP stack.

That said, rump-style ultralight virtualization is best when you want only
one or two kernel components virtualized for your application.  If you
want the kitchen sink, pantry and part of the liquor cabinet, you might
want to look at full OS virtualization instead -- if you want 1% of the
OS services virtualized, you're most likely going to complain about 99%
overhead, but if you want 50% virtualized, well, who cares about 2x.

But, it seems to me that the bulk of the problem in having a hot spare
for a filer is getting the master and spare(s) to agree on the state of
the system and virtualization will not magically solve that (nor will
cloud computing, sorry ;).  Migration is easy.  Failover isn't.

... hmm, i wonder if I still have my failover patches for
/usr/games/tetris somewhere ...