rump_sp —
rump remote system call support
The rump_sp facility allows clients to attach to a rump
  kernel server over a socket and perform system calls. While making a local
  rump system call is faster than calling the host kernel, a remote system call
  over a socket is slower. This facility is therefore meant mostly for
  operations which are not performance critical, such as configuration of a rump
  kernel server.
The NetBSD base system comes with multiple preinstalled
  clients which can be used to configure a rump kernel and request diagnostic
  information. These clients run as hybrids partially in the host system and
  partially against the rump kernel. For example, network-related clients will
  typically avoid making any file system related system calls against the rump
  kernel, since it is not guaranteed that a rump network server has file system
  support. Another example is DNS: since a rump server very rarely has a DNS
  service configured, host networking is used to do DNS lookups.
Some examples of clients include
    rump.ifconfig which configures interfaces,
    rump.sysctl which is used to access the
    sysctl(7) namespace and
    rump.traceroute which is used to display a network
    trace starting from the rump kernel.
Also, almost any unmodified dynamically linked application (for
    example telnet(1) or
    ls(1)) can be used as a rump
    kernel client with the help of system call hijacking. See
    rumphijack(3) for more
    information.
A remote rump server is specified using an URL. Currently two types of URLs are
  supported: TCP and local domain sockets. The TCP URL is of the format
  tcp://ip.address:port/ and the local domain URL is unix://path. The latter can
  accept relative or absolute paths. Note that absolute paths require three
  leading slashes.
To preserve the standard usage of the rump clients' counterparts
    the environment variable RUMP_SERVER is used to
    specify the server URL. To keep track of which rump kernel the current shell
    is using, modifying the shell prompt is recommended -- this is analogous to
    the visual clue you have when you login from one machine to another.
The current scheme gives all connecting clients root credentials. It is
  recommended to take precautions which prevent unauthorized access. For a unix
  domain socket it is enough to prevent access to the socket using file system
  permissions. For TCP/IP sockets the only available means is to prevent network
  access to the socket with the use of firewalls. More fine-grained access
  control based on cryptographic credentials may be implemented at a future
  date.
Get a list of file systems supported by a rump kernel server (in case that
  particular server does not support file systems, an error will be returned):
$ env RUMP_SERVER=unix://sock rump.sysctl vfs.generic.fstypes
 
rump_sp first appeared in NetBSD
  6.0.