Hello guy, I am writing to you because I would like to get to know you about a small "project" that I developed about Ovirt that for me seems very interesting and may interested develope teams. After studying Ovirt and seeing that the ideal solution would be to have three nodes, for "economic" needs, I wanted to try buying two SuperMicro nodes, with two M2 disks on which I installed CentOS, two SSD disks as cache for writing to speed up I / O operations, 4 rotating 15,000 RPM disks that I formatted in ZFS, putting 3 as storage for the VMs and one in reserve. At this point, I installed Ovirt as a VM on storage and it ran "normally", thus always creating my VMs on the storage with the normal Ovirt procedure. The thing that I think is interesting, is that for every VM I assign a storage quota, so the VM1 will have for example 100Gb of disk assigned, called Disk1. Obviously, this space is subsequently editable through the ZFS commands. Always with the ZFS functionalities, I have the possibility to take a snapshot of disk1 and "send" it to node 2 which is configured exactly as node 1. This operation, thanks to ZFS, is very fast and need chip bandwith... In this way, node 1 is the production node, node 2 acts from a silent "repository" of snapshots that arriving, every few minutes (even absurdly every minute) from node1. In case of a fault in the VM of node1, or of the entire node1, I have the possibility to restoring the VM to the node 2, with a simple ZFS command, the snapshot to tot minutes ago, "attach" that datastore to the node and restart the VM, having lost as data only the delta from the last snapshot at the time of the fault. The procedure I tested and tested several times, coming to inject a cryptolocker on VM1, turning it off, restoring the last snap on node2 and restarting it at the last snap, all within a few minutes. In my opinion, developing a web interface now (something I am not able to do) that would allow the installation of deciding the ZFS configuration of the storage disks and then, again via the web, the possibility of defining the cron of the snapshot and possible restoration, the product would be really interesting and attractive, because meanwhile I don't have to have three nodes and more because in case of fault, in a few minutes you can get back on your feet with a data loss that for the vast majority of companies is plausible and approachable. If you are interesting about this solution, i will be happy to "talk" to you about it. Thanks a lot. Fabio Zaltron -- Zaltron Fabio