----- Original Message -----
----- Original Message -----
> From: "M. Mohan Kumar" <mohan(a)in.ibm.com>
> To: vdsm-devel(a)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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel