On Wed, Oct 24, 2012 at 11:19:13AM +0200, Runar Ingebrigtsen wrote: > >GlusterFS replication works at a different layer: each glusterfs brick sits > >on top of a local filesystem, and the operations are at the level of files > >(roughly "open file named X", "seek", "read file", "write file") rather than > >block-level operations. > > Hm, does this mean the whole file will be replicated each time it > changes? Nope. Gluster works at the POSIX filesystem layer, so commands like "seek(x); write(data)" would replicate as the same commands to both bricks. There used to be an issue with healing, i.e. fixing up replicas after they have been offline for a while. Prior to gluster 3.3 this involved locking the whole file, which if it was a VM image would make it unavailable until healing was complete. Gluster 3.3.x does healing across ranges instead. However gluster 3.3.x is still not ideal as a VM backing store, because of the performance issues of going via the kernel and back out through the FUSE layer. There are bleeding-edge patches to KVM which allow it to use libglusterfs to talk directly to the storage bricks, staying in userland: http://lists.gnu.org/archive/html/qemu-devel/2012-06/msg01745.html Or you could try using NFS to gluster's NFS server. Or you can boot from a gluster image, but mount a gluster volume within the VM for application data. Regards, Brian.