Matt Dillon - vkernels

Hi Allan, Kris!  Love your shows as always!

    On 164 you had some questions about DragonFly's vkernels.  vkernels
    are DragonFly's original attempt at implementing virtualization,
    without actually needing to implement virtualization.  DragonFly itself
    does not have a full-fledged hardware virtualization abstraction like one
    sees on Linux or FreeBSD.  Eventually we might port one, but it isn't
    a strong point for us.  I'd rather focus on system performance.  I would
    like DFly to run well under a virtualized environment as a guest.
    Some of our devs are interested in porting a hosting capability from
    one of the other BSDs once they have something that works well.

    The DragonFly vkernel is essentially just the DragonFly kernel compiled
    as a user-mode application.  Meaning the vkernel 'drivers' can just use
    normal system calls to implement disk and network I/O.  The real DFly
    kernel provides a virtualized page table abstraction (VMX not required),
    and execution context management, and that's pretty much all the vkernel
    needs.  The vkernel implementation is pretty good, though the pmap
    implementation in platform/vkernel64 currently uses a global lock and
    is significantly behind the real kernel in terms of SMP performance.

    The intent of the vkernel is to make it easier to test DragonFly kernel
    features in a user mode context for debugging purposes, and to provide
    a layer of security for people who don't trust normal user-based
    compartmentalization.  And, of course, it is much easier to manage
    resource caps with a vkernel.  But as with any virtualized system,
    the trade-off against perfomrance is fairly severe.

    --

    In anycase, the COW feature simply mmap()'s the disk image MAP_PRIVATE+RW
    instead of using pread()/pwrite().  It's great for managing many vkernels
    with a single base system image.  Since multiple disk images can be
    specified (and one can of course use NFS as well), this does not prevent
    having a second, normal write-back image, for data.  Having easy base
    system replication coupled with a writable mount is an incredibly useful
    feature to have, much easier to work with than a read-only NFS mount.

    It isn't unionfs... I'm not saving the changes anywhere.  It would be
    fairly easy to do so, but I think it would be even easier to not bother
    and simply instrument the system running under the vkernel to spool off
    anything it wants to retain across reboots to a non-COW partition, NFS
    mount, or other outside-of-COW storage.

						-Matt