----- Original Message ----- > ----- Original Message ----- > > From: "M. Mohan Kumar" <mo...@in.ibm.com> > > To: vdsm-devel@lists.fedorahosted.org > > Sent: Wednesday, July 25, 2012 1:26:15 PM > > Subject: [vdsm] [RFC] GlusterFS domain specific changes > > > > > > We are developing a GlusterFS server translator to export block > > devices > > as regular files to the client. Using block devices to serve VM > > images > > gives performance improvements, since it avoids some file system > > bottlenecks in the host kernel. Goal is to use one block device(ie > > file > > at the client side) per VM image and feed this file to QEMU to get > > the > > performance improvements. QEMU will talk to glusterfs server > > directly > > using libgfapi. > > > > Currently we support only exporting Volume groups and Logical > > Volumes. Logical volumes are exported as regular files to the > > client.
Are you actually using LVM behind the scenes? If so, why bother with exposing the LVs as files and not raw block devices? > > > > In GlusterFS terminology a volume capable of exporting block > > devices is > > created by specifying the 'Volume Group' (ie VG in Logical Volume > > management). Block Device translator(BD xlator) exports this volume > > group as a directory and LVs under it as regular files. In the > > gluster > > mount point creating a file results in creating a logical volume, > > removing a file results in removing logical volume etc. > > > > When a GlusterFS volume enabled with BD xlator is used, directory > > creation in that gluster mount path is not supported because > > directory > > maps to Volume groups in BD xlator. But it could be an issue in > > VDSM > > environment when a new VDSM volume is created for GlusterFS domain, > > VDSM > > mounts the storage domain and creates directories under that and > > create > > files for vm image and other uses (like meta data). > > > > Is it possible to modify this behavior in VDSM to use flat > > structure > > instead of creating directories and VM images and other files > > underneath > > it? ie for GlusterFS domain with BD xlator VDSM will not create any > > directory and only creates all required files under the mount point > > directory itself. > > From your description I think that the GlusterFS for block devices is > actually more similar to what happens with the regular block domains. > You should probably need to mount the share somewhere in the system > and > then use symlinks to point to the volumes. > > Create a regular block domain and look inside > /rhev/data-center/mnt/blockSD, > you'll probably get the idea of what I mean. > > That said we'd need to come up with a way of extending the LVs on the > gluster server when required (for thin provisioning). Why? if it's exposed as a file that probably means it supports sparseness. i.e. if this becomes a new type of block domain it should only support 'preallocated' images. > > -- > Federico > _______________________________________________ > vdsm-devel mailing list > vdsm-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
