gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] Qemu glusterfs, exposing complete bricks instead of


From: Sander Eikelenboom
Subject: Re: [Gluster-devel] Qemu glusterfs, exposing complete bricks instead of individual images as shared storage to VM's ?
Date: Sat, 30 Nov 2013 00:56:26 +0100

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 <address@hidden> wrote:
>   

>  Saturday, November 30, 2013, 12:32:50 AM, you wrote:
>  
>  
>  
>  
>  
>  
 >> On Fri, Nov 29, 2013 at 5:06 PM, Sander Eikelenboom <address@hidden> 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
 >> address@hidden
 >>  https://lists.nongnu.org/mailman/listinfo/gluster-devel
 >>
>  
>  
>  





reply via email to

[Prev in Thread] Current Thread [Next in Thread]