[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
>>
>
>
>
Re: [Gluster-devel] Qemu glusterfs, exposing complete bricks instead of individual images as shared storage to VM's ?, Niels de Vos, 2013/11/30