Re: any advantage to using pool type glusterfs if no GFAPI

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

 



On Fri, Oct 06, 2023 at 13:23:18 -0700, W Kern wrote:
> I have used fuse mounted gluster with 'dir' for years. Works great, aside
> from  having to use the --unsafe flag on migrations.
> 
> I am building up a new system  and wondering if using the glusterfs type
> would be a better/safer choice.
> 
> I'm not concerned about gfapi (host is U22LTS so I'm not even sure if it has
> it).
> 
> I'm not concerned about the automount feature as that happens on start up
> anyway.
> 
> I'm more interested if there is any technical or performance reasons to
> prefer 'glusterfs' pool type over 'dir'
> 
> of course not having the --unsafe flag would be nice, but thats all scripted
> in anyway.

Let's break down multiple things:

Firstly regarding use of '--unsafe' for migration on fuse-mounted
glusterfs. This should work without the need to use --unafe at least
since:

commit 478da65fb46c866973886848ae17f1e16199a77d
Author: Michal Prívozník <mprivozn@xxxxxxxxxx>
Date:   Thu Sep 27 16:19:31 2018 +0200

    virFileIsSharedFSType: Check for fuse.glusterfs too

$ git desc 478da65fb46c866973886848ae17f1e16199a77d
v4.8.0-21-g478da65fb4

Thus released in libvirt-4.9


Secondly let's discuss the actual real way how qemu interacts with the
blocks. With fuse in use the gluster volume is mounted on the host and
qemu accesses it directly as any other file. Thus for qemu this is
transparent.

With libgfapi, each qemu instance runs their own gluster client
internally. Advantage is that you don't have it mounted in your host
and maybe save few cycles on fuse not being needed. Disadvantage is that
you have multiple copies of the gluster client in memory.



Now the third issue and that is storage pool type in libvirt.

So in the first place having a storage pool in libvirt is not really
needed. This depends on how you configure the disks in the VM:

If you do it via:

 <disk type'file' device='disk'>
   [...]
   <source file='/path/to/some/glusterfs/mount/os.img'/>
 </disk>

Then you are not even using a storage pool in the first place. That
happens only if you have a <disk type='volume'...>.

In such case I'd suggest you don't even set up one.

This brings us to pool type gluster. This pool type uses libgfapi to
natively access the gluster volume without mounting it in the host. Thus
if you need it to automount the images, it will not do that.
Additionally support for <disk type='volume'> was never finished for
that one either.

Conclusion: You don't want to use storage pool of type 'gluster', and
very likely you don't need any storage pool.




[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux