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.
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.
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?
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.
> 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.
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).
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...
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.
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.