What are the performance implications of running VMs on a ZFS host?

I'm considering migrating from ext3 to ZFS for data storage on my Debian Linux host, using ZFS on Linux. One killer feature of ZFS that I really want is its data integrity guarantees. The ability to trivially grow storage as my storage needs increase is also something I'd look forward to.

However, I also run a few VMs on the same host. (Though normally, in my case only one VM is running on the host at any one time.)

Considering ZFS's data checksumming and copy-on-write behavior, together with the fact that the VM disk images are comparatively huge files (my main VM's disk image file currently sits at 31 GB), what are the performance implications inside the VM guest of such a migration? What steps can I take to reduce the possible negative performance impact?

I can live with less data integrity guarantees on the VM disk images if necessary (I don't do anything really critical inside any of the VMs) and can easily separate them from the rest of the filesystem, but it would be nice if I don't have to (even selectively) turn off pretty much the feature that most makes me want to migrate to a different file system.

The hardware is pretty beefy for a workstation-class system, but won't hold much of a candle to a high-end server (32 GB RAM with rarely >10 GB in use, 6-core 3.3 GHz CPU, currently 2.6 TB usable disk space according to df and a total of about 1.1 TB free; migrating to ZFS will likely add some more free space) and I'm not planning on running data deduplication (as turning on dedup just wouldn't add much in my situation). The plan is to start with a JBOD configuration (obviously with good backups) but I may move to a two-way mirror setup eventually if conditions warrant.


Since ZFS works at a block level the size of the files makes no difference. ZFS requires more memory and CPU but is not inherently significantly slower as a filesystem. Though you need to be aware that RAIDZ is not equivalent in speed to RAID5. RAID10 is fine where speed is a priority.


ZFS on decent (i.e buff) hardware will likely be faster than other file systems, you likely want to create a ZIL on a fast (i.e. SSD) location. This is essentially a location to cache writes (well, more like a journal in ext3/4). This lets the box ack writes as being written to disk before the actual spindles have the data.

You can also create a L2 ARC on SSD for read cache. This is fantastic in a VM environment where you can bring physical disks to their knees by booting several VMs at the same time.

Drives go into VDEVs, VDEVs go into zpools (please use entire disks at a time). If this is a smaller system you may want to have a single zpool and (if you are not too concerned about data loss) a single VDEV. VDEVs are where you select the RAID level (although you can also MIRROR VDEVs if you've got enough disks). The slowest disk in a VDEV determines how fast the entire VDEV is.

ZFS is all about data integrity - the reason a lot of the traditional tools for file system maintenance don't exist (like fsck) is the problem they solve can't exist on a ZFS file system.

IMO the biggest drawback of ZFS is that if your file systems approach full (say 75%+) it gets VERY slow. Just don't go there.