Comment by mrb | Hacker News Reader

Comment by mrb | Hacker News Reader

Wow this is huge. Having an OS be able to run both ZFS and KVM enables fantastic things. For example you can store each virtual machine disk template on a dedicated ZFS filesystem, and use "zfs clone" to rapidly deploy VMs (instead of using the KVM-level support for base disk images "qemu-img create -b ..."), as well as "zfs snapshot", "zfs revert", etc. The main advantage being that these clones and snapshots are possible while using the simple and fast "raw" KVM disk image format instead of the notoriously slower "qcow2" format that was, until today, the best format supporting base images and snapshots.

I, for one, have been wanting to use ZFS specifically like that for a while. This does not compare at all to running ZFS on, say, an NFS server or iSCSI SAN serving data to a server running KVM (ZFS data integrity is only verified remotely on the storage server, it is slower, etc).

Who ported KVM to Illumos? I know some old version of QEMU was running on Solaris at some point in the past, but I had no idea they had a full blown KVM port.

KVM was ported to illumos by Max Bruning, Robert Mustacchi and me. Details are here: http://t.co/knW1UIJ

Can you provide more details of Crossbow? Who maintains it/status? I hadn't heard anything about it since OpenSolaris went dead.

Could you be more specific? It's there, it works, it's in shipping illumos-based products (from Joyent and others) and it's supported by those who ship it or stand it up. In that regard, it's like any other aspect of the system...

Thank you. I guess I just have to go dig through the Illumos/OpenIndiana documents.

Uhm, isn't that a violation of the GPL given that you're mixing the complete work with non-compatible (by design) CDDL code? Did you ask for KVM to be relicensed for the port or something?

There is not a licensing issue here: both KVM and our KVM port remain licensed under the GPL.

Isn't your port of KVM integrated into the Solaris kernel? How are you ensuring they are two independent and separate works under copyright law?

No; the KVM kernel module is in its own repo: https://github.com/joyent/illumos-kvm

But distributing binaries built with some GPL'd code is a violation of the GPL if you don't publish all the code that went into the binary.

My (somewhat casual) understanding is that the Solaris kernel has always, by necessity, supported modules under a different license much more deeply than Linux. Commercially significant software like the Veritas filesystem and device drivers have always worked this way. So, e.g., the Solaris kernel has a real, no-foolin' ABI.

That doesnt mean that linking in a GPL module doesnt make the rest of the kernel GPL. A real ABI might not mean it is not linked. Allowing commercial modules and linking with GPL ones are not the same.

I dont know though, the definition of linking is pretty opaque to me.

It doesn't matter - Joyent doesn't own the copyright for Solaris so nothing that they do can change the licencing conditions for Solaris itself.

You can write GPL'ed device drivers for Windows - doesn't make Windows GPL.

> You can write GPL'ed device drivers for Windows - doesn't make Windows GPL.

The public interface exposed to Windows drivers is _much_ more shallow than the public interface exposed to Linux and Solaris/Illumos modules. Not coincidentially, the Windows driver exports overlap a lot with the interface that Linux allows for usage in proprietary drivers.

Instead, KVM uses a lot of hooks into the kernel innards (into the scheduler, into the MMU, etc.) that are marked as EXPORT_SYMBOL_GPL in the Linux kernel, and the Illumos port does use some of the same hooks.

I am not a lawyer, so I don't have any clear answer. I also work for Red Hat, so even if I had one I would not want to say it (should not say it). But the licensing question is _not_ an idle question.

Also, the licensing question does not detract anything from the awesome work of these guys.

Actually, our port does not use these hooks -- there were zero mods to the illumos kernel to support KVM per se.

You do not get to choose whether it matters that the hooks (such as context ops) were preexisting. Perhaps it does, perhaps it doesn't. But it's the same trying to define what is a derived work, and neither you nor the KVM copyright holders can do that.

In the meanwhile, just thank whoever said that GPL-incompatibility was an explicit design goal for the CDDL.

The definition of a derived work is actually much more crisp than you are making it out to be -- and it is simple fact (and not opinion) that illumos is not a derived work of our KVM module. Indeed, this issue is so clear-cut and your objections so unfounded that this is beginning to sound like you are deliberately trying to place doubt over the legality of our work. So as long as we're playing Pretend Lawyer, consider your employer and look this one up: tortious interference.

> this is beginning to sound like you are deliberately trying to place doubt over the legality of our work

Oh come on. Again: if anyone has placed doubt on it, it's whoever chose CDDL because it was GPL-incompatible. All I'm saying is the question is not idle. If it was so clear-cut, it would not have popped out in 3 out of 3 places where I read about KVM/Illumos (your blog, LWN, HN).

Kind of an off topic rant, but can we at least avoid url shorteners that point to other url shorteners? Here is the original link http://www.slideshare.net/bcantrill/experiences-porting-kvm-...

Honestly, no one should be using URL shorteners on HN. Use a footnote[1] if necessary.

[1] http://www.google.com/search?q=hi,+this+is+a+footnote

I like the footnote form. I use that in e-mails as well.

SlideShare is also a world of hate. Try http://www.linux-kvm.org/wiki/images/7/71/2011-forum-porting...

I really like the use of DTrace in #if 0'd out code for identifying the highest priorities on porting. Having faced a similar task that seemed impenetrable at the start I would have really liked to have this technique available.

Nice work and congrats on the port.

While ZFS adds some advantages, if you were going for snap shots and quick deploy with KVM your best bet was to use LVM as a raw device. A quick lvm snapshot + virt-clone + virsh start will let me have a cloned vm up within seconds.

Thats not saying ZFS doesn't add a lot (checksum backed store, heap of other features). But I would actually expect LVM to be faster, precisely because it is "crappier" (no checksumming, very basic address remapping, etc).

The real question will be support, if they can convince people that this will have enough life to build a user base large enough to support it moving forward. Especially if oracle stops publishing code under open source licenses.

The problem with LVM snapshots is that you have to manually reserve a portion of the logical volume to store them. And if you calculate your needs incorrectly, LVM runs out of space to preserve them, and they become corrupted (they are reported as "INVALID" in lvdisplay IIRC).

That's why I prefer KVM's built-in base image support (qemu-img create -b ...) to quickly provision VMs, instead of LVM. That's how I architected KVM hosts for my employer, running 100+ lightweight VMs each, with 1000+ disk images available on disk.

http://smartos.org/2011/08/15/kvm-on-illumos/

Reply on news.ycombinator.com