[Gluster-devel] Qemu glusterfs, exposing complete bricks instead of individual images as shared storage to VM's ?

[Sander Eikelenboom]

Saturday, November 30, 2013, 12:48:44 AM, you wrote:

> Should be possible to specify another block device to QEMU and format that and use a filesystem, however the problem here is that if multiple devices use the same block device, then your filesystem will explode (get corrupted) if you don't plan accordingly. For example, if you did this with ext4, goodbye data, if you did this with GFS2, and had cman properly running, it should probably work, although I haven't tested this specific use case.

> Make sense?

Erhmm well that's why glusterfs is momentarily in between :-)

I have a LVM volume "shared_data" on the host .. which I export as a brick with glusterfs.
Multiple VM's mount this brick over the tcp/ip transport, and all seems to go well with locking.

I have looked at GFS2 and Ceph as well, though glusterfs served me well.
It's just to see if it would be possible to eliminate the use of the tcp/ip transport for
the VM's that use Qemu to reduce that overhead.



> Cheers




> On Fri, Nov 29, 2013 at 6:46 PM, Sander Eikelenboom <linux at eikelenboom.it> wrote:
>   

>  Saturday, November 30, 2013, 12:32:50 AM, you wrote:
>  
>  
>  
>  
>  
>  
 >> On Fri, Nov 29, 2013 at 5:06 PM, Sander Eikelenboom <linux at eikelenboom.it> wrote:
 >>
 >> Hi,
 >>
 >>  I'm using glusterfs for quite some time on my server for shared-storage to VM's.
 >>  At the moment this had to go over tcp/ip bridge between host and guests, so
 >>  i was interested in the option to use glusterfs directly with qemu. But it seems it
 >>  only supports to expose individual images files that reside on a glusterfs brick.
 >>
 >>  Would it be possible to extend this and make a complete brick available as disk to qemu as shared storage ?
 >>  (so multiple vm's and the host can share this same storage space)
>  
>  
>  
>  
 >> Sounds like you want to use Gluster as a backing store for the VM images through qemu, but in addition, you probably want to mount a common glusterfs volume inside the vms as well. That's how you do it!
 >>
>  
>  But that common glusterfs would be using tcp/ip then and not libgfapi or not ?
>  
>  Could be i'm misreading the docs but specifying the image file seems mandatory:
>  
>  Gluster drive specification in QEMU
>  ­drive file=gluster://server[:port]/volname/image[?transport=...]
>  
>  And since using libgfapi should benefit performance by removing the necessity to converting everything to networking packets and vice versa.
>  
>  So it would be nice if i could do:
>  
>  VM1 qemu:
>  ­drive file=gluster://server[:port]/volname
>  
>  VM qemu:
>  ­drive file=gluster://server[:port]/volname
>  
>  And that volume would be mountable in the VM (as a block device), don't know if that would be easily possible
>  though since it probably is not a real normal block device.
>  

>  
>  
 >> Cheers,
 >> James
>  
 >>  
>  
 >>
 >>  --
 >>  Sander
 >>
 >>
 >>  _______________________________________________
 >>  Gluster-devel mailing list
 >>  Gluster-devel at nongnu.org
 >>  https://lists.nongnu.org/mailman/listinfo/gluster-devel
 >>
>  
>  
>