*music* Don't tell anyone I'm free...
*music* Don't tell anyone I'm free...
Commentary: Hello, and welcome to BSDTalk number 98. It's Wednesday,
February 7, 2007. I just have an interview with Matthew Dillon
today, so we'll go right to it.
Host: Today on BSDTalk, we're speaking to Matthew Dillon. Welcome
to the show.
Matt: Thank you.
Host: So, recently there has been a release, so maybe you can start
by giving us a basic overview of what's new in DragonFlyBSD.
Matt: The biggest user-visible item in this release is the virtual
kernel support, which is basically similar to UML (User Mode Linux),
but DragonFly on DragonFly, basically running a DragonFly kernel
as a single process on a DragonFly system. My primary reason for
doing this first is that it became very obvious that the engineering
cycle time just to test and make changes was going way too slowly
for kernel work, and for the features that we really want to get
in the system, the ultimate goals of DragonFly ---the clustering,
the new filesystem--- we really needed that ability with the virtual
kernel to have an instant run, instant test cycle.
Host: So for people who aren't familiar with the different levels
of virtualization, where do these virtual kernels fit in between
BSD jails versus Xen or QEMU?
Matt: You have a jail-like environment, you have a Xen-like
environment, and you have a QEMU or VMWare-like environment, and
they're different levels of virtualization.
The jail doesn't try to virtualize anything really, it just restricts
what the programs have access to, running on the same system
basically. It's not really virtualizing a kernel, it's just making
it look that way, kind of faking it. It still has many uses, because
it's very high performance, because it's not virtualizing anything.
In a Xen-like environment you're running a kernel that's aware of
the Xen environment, so it's not 100% hardware virtualization. It's
aware that it's in a Xen environment and it makes allowances for
that by doing special calls when it needs to do something with the
VM system, for example, or with drivers.
A VMWare or QEMU virtualization is a full hardware virtualization
where you run the same kernel and system that you would run on bare
harware but you would run it on QEMU or VMWare, and it would just
run---or at least, that's the idea.
Where we come in is closer to Xen than anything else. The DragonFly
virtual kernel is very aware that it is running as a virtual kernel.
It only runs a real DragonFly kernel, so it's not like Xen where
we're trying to allow or support multiple guest operating systems.
What we're really doing is supporting DragonFly kernel running under
DragonFly kernel, and we're doing that by giving the real kernel
(and the virtual kernel) additional system calls that allow the
manipulation of VM spaces, the interception of system calls, and
that sort of thing. So the DragonFly virtual kernel isn't actually
doing anything special other than using these new system calls to
manage its own memory space and to manage the virtualized user
processes that are running under it. The advantage of this is that
the real kernel has very low resource overhead. The real kernel
is only managing page tables for the virtualized processes being
run by the virtual kernel, and on nearly all BSD systems (certianly
FreeBSD and DragonFly), page tables are all throw-away, which means
that the real kernel can throw them away at any time and take extra
faults to regenerate them later on. So the resource overhead is
very low except for the memory issue, which is the amount of memory
that you tell the virtual kernel it has.
Host: What about filesystem space?
Matt: Well, the virtual kernel is basically a kernel, so right now
you give it a root image, basically a virtualized hard drive, that's
basically just a 50GB file you give to the virtual kernel and that's
what it uses as a block device for its filesystem. We've given it
a network interface using the tap device, so the virtual kernel can
communicate with the outside world via the network interface, which
means that of course it can use NFS and any other networking protocol
to also access filesystems. Eventually we're going to have as part
of the clustering work a protocol called SYSLINK, which will be
used to link the clustered hosts together, and that will also have
the capability of doing a filesystem transport, a device transport,
and transport for other resources such as CPU contexts and VM
contexts and that sort of thing.
Host: Any why develop your own virtual kernel technology instead
of using existing ones, perhaps like Xen or QEMU?
Matt: Well, the problem with QEMU and VMWare is that they aren't
really good for testing kernels. They're good for running systems.
In many cases they can be higher performing than a virtual kernel,
although theoretically as things mature I think the virtual kernel
technology --that is, the Xen-like technology-- will be able to
exceed that, because
