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