Jeff, Thanks for the details. If I might trouble you for a few more... Jeff Darcy wrote: > On 12/30/12 1:33 PM, Miles Fidelman wrote: >> What's the alternative, though? Ok, for application files (say a word >> processing document) that works, but what about spools, databases, and >> such? Seems like blocks are the common denominator. > It's all blocks underneath; it's a matter of how you get to those blocks. If > you use a simulated block device which is actually a GlusterFS file, then > you'll be going through both FUSE and the loopback driver. That actually works > OK for many things, but latency will be a bit high e.g. for databases. One > option is to use the qemu interface, which avoids both sources of overhead. In > fact, the overhead from virtualizing your database server is likely to be lower > than FUSE+loopback because our esteemed kernel colleagues seem a lot more > interested in making virtual I/O work better than in doing the same for FUSE. > It's still a tiny hit compared to running a DB on bare metal, but the value of > being able to survive a failure should more than outweigh that. > I'm running Xen virtualization, and I understand how all the pieces fit together for running paravitualized hosts over a local disk, software raid, LVM, and DRBD - but none of those involve qemu. I wonder if you could say a little bit about how all the pieces wire together, if I wanted to mount a Gluster filesystem from a paravirtualized VM, through the qemu interface? Thanks again, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra
