Justus Winter: A story about virtualization
I'm sure you all will be a bit disappointed (I know I am) that there
are no ascii screenshots in this weeks report. But let me make it up
to you by telling you a story.
I was at the FOSDEM in the year 2012 and I went to a nice workshop on
sunday afternoon in the Virtualization Devroom. Renzo Davoli was the
host of this workshop
and he started with a little introductory talk to get everyone to
agree on a common terminology first. He began by asking the question,
what virtualization meant in the most general way. He defined the
ability to virtualize a resource as the ability to freely and
transparently control how someone (say a process) is interacting with
said resource. So for example if you LD_PRELOAD a library to
impersonate fopen(3) and friends, you have virtualized the
filesystem (for some small values of virtualized). He then went on to
discuss various methods of virtualization that are commonly available
on Linux, not only full system virtualization solutions, but also all
kinds of methods allowing a more fine-grained control over what
resources are virtualized. Of course every method had its strengths
and its weaknesses.
Having seen Samuels talk
about all the awesome things Hurd can do for virtualization I
approached him with a question in the free discussion part of his
workshop. I asked whether he would agree that once a resource is moved
from the kernel to the userspace, the problem of virtualizing that
resource is almost trivially solved, and he agreed. So I said that
this was awesome, because then the trivial and elegant solution for
all his virtualization (and tracing) needs are micro kernel operating
systems, and he also agreed to that but (as far as I can recall) he
mentioned that there is none that would meet his needs (I believe he
is a computer science professor and heavily relies on virtualization
techniques for his lab and for teaching purposes).
And even though a microkernel operating systems has a cost (message
passing instead of function calls for example) it also has its merits
such as scaling better from a development point of view. Also, many
cool features can emerge just from the design. For example think about
the container support in Linux and how painfully long it took to make
all the resources namespace aware (with one of the most critical, the
user namespace being the most difficult one). On Hurd you get the same
functionality for free. If you are curious, read Samuels awesome
slides.
So what have I done this week?
- procfs should ignore --no dev,exec,suid : http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00076.html
- libnetfs does not respond properly to file_get_translator requests on nodes with a passive translator record: http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00148.html
- As the mtab translator is a translator of its own, there needs to be a way to bind it to /proc/mounts. I figured the easiest way would be to just serve a node with an appropriate passive translator record: http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00149.html
- There was no clean way to start the console-client. I added daemonizing support to the console-client and created an appropriate initscript: http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00165.html
- I also worked a lot on my mtab translator prototype: http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00183.html