[vdsm] Storage Device Management in VDSM and oVirt

[Ayal Baron]

----- Original Message -----
> On 04/22/2012 12:28 PM, Ayal Baron wrote:
> >
> >>> This way we'd have a 2 stage process:
> >>> 1. setupStorage (generic)
> >> I was looking up on the VDSM archives and there are talks of using
> >> libstoragemgmt (lsm)
> > Funny, we started using that acronym for Live Storage Migration :)
> >
> >> under VDSM. I was wondering if the setupStorage would be something
> >> where
> >> lsm would
> >> be used to do the work, it seems fit for purpose here.
> >>
> >>
> > I don't think this is the libstoragemgmt mandate.
> >
> > libstoragemgmt is:
> > "A library that will provide a vendor agnostic open source storage
> > application programming interface (API) for storage arrays."
> >
> > i.e. it is there to abstract storage array specifics from the user.
> > It will be used by things like LVM etc, not the other way around.
> >
> > setupStorage would use libstoragemgmt wherever appropriate of
> > course.
> >
> > But as the libstoragemgmt maintainer, Tony (cc'd) can correct me if
> > I'm wrong here.
> >
> >
> 
> I was looking at setupStorage as Provisioning + Setting up.
> I know one of the basic goals of lsm is provision the storage to the
> host
> and preparing the storage for consumption is higher layers work.
> 
> With that, i think then its becomes a 3 stage process, from
> oVirt/VDSM
> pov...
> 1) Provision Storage (using lsm if applicable, based on whether
> external
> storage is connected)
> 2) Setup Storage (prepare the provisioned LUNs for usage)
> 3) createSD/createGlusterVolume/...  (plugin specific)
> 
> Since we are talking about Storage management using VDSM, i was
> interested in understanding the plans, strategy of how VDSM + lsm
> will integrate ?


There are various ways of approaching this.
1. Given proper storage you could just provision new LUNs whenever you need a new virtual disk and utilize storage side thin provisioning and snapshots for most of your needs.
When you have such storage you don't really need steps 2 and 3 above.  Your storage is your virtual images repository.
Although quite simple and powerful, very few arrays are capable of growing to a very large number of objects (luns + snapshots + whatever) today, so I don't see this being the most common use case any time soon.

2. Provision LUNs (either statically or dynamically using lsm) once, preferably thinly provisioned. Then setupStorage (storage domain over VG / gLuster / other) and use lsm for creating snapshots/clones on the fly
In my opinion this will be more prevalent to begin with.

With lsm we will (hopefully) have a way of enumerating storage side capabilities so then when we create a repository (gluster / sd / ...) we'd be able to determine on the fly what capabilities it has and determine if to use these or to use virtualized capabilities (e.g. in the virt case when you need to create a snapshot use qcowX).

In oVirt, once you've defined a storage domain and it exposes a set of capabilities, user should be able to override (e.g. even though storage supports snapshots, I want to use qcow as this storage can only create 255 snapshots per volume and I need more than that).

I'm assuming that we will not have any way of knowing the limits per machine.

Does that make sense?

> 
> thanx,
> deepak
> 
> 
> 
>