[vdsm] Storage Device Management in VDSM and oVirt

[Ayal Baron]

----- Original Message -----
> 
> >> This seems interesting.
> >>
> >> I am interested in pursuing this further and helping contribute to
> >> the
> >> vdsm lsm integration. lsm is still in the early stages, but i feel
> >> its
> >> the right time to start influencing it so that vdsm integration
> >> can
> >> be
> >> smooth. My interest mainly lies in how external storage array can
> >> be
> >> integrated into oVirt/VDSM and help oVirt exploit the array
> >> offload
> >> features as part of the virtualization stack.
> >>
> >> I didn't find any oVirt wiki page on this topic, tho' there is a
> >> old
> >> mailing list thread on vdsm lsm integration, which when read
> >> brings
> >> up
> >> more issues to discuss :)
> >> How does storage repo engine and possible vdsm services framework
> >> ( i
> >> learnt about these in my brief chat with Saggie some time back)
> >> play
> >> a
> >> role here ?
> > Maybe Saggi could elaborate here.
> >
> >> Can "Provisioning Storage" itself be like a high level service,
> >> with
> >> gluster and lsm  exposing storage services, which vdsm can
> >> enumerate
> >> and
> >> send to oVirt GUI, is that the idea ?
> > I'm not sure "Provisioning Storage" is a clear enough definition,
> > as it could cover a lot of possibly unrelated things, but I'd need
> > to understand more what you mean to really be able to comment
> > properly.
> >
> 
> Well, I was envisioning oVirt as being able to provision and consume
> storage, both, going ahead.
> Provisioning thru' vdsm-libstoragemgmt (lsm) integration. oVirt user
> should be able to carve out LUNs,
> be able to associate the LUNs visibility to host(s) of a oVirt
> cluster,
> all via libstoragemgmt interfaces.
> 
> With gluster being integrated into vdsm, oVirt user can provision and
> manage gluster volumes soon,
> which also falls under "provisioning storage", hence I was wondering
> if
> there would be a new tab
> in oVirt for "provisioning storage", where gluster ( in near future)
> and
> external array/LUNs  ( via
> vdsm -lsm integration) can be provisioned.


Ok, now I that I understand a little more, then in general I agree.
First upstream oVirt already has the ability to provision gLuster (albeit still in a limited way) and definitely we will need more provisioning capabilities including for example setting up LIO on a host and exposing LUNs that would be available to other hosts/VMs (for one, live storage migration without shared disks would need this).
Specifically wrt "Provisioning Storage" tab, that's more of a design question as there are going to be many services we will need to provision not all specifically around storage and I'm not sure that we'd want a new tab for every type.


> 
> 
> >> Is there any wiki page on this topic which lists the todos on this
> >> front, which I can start looking at ?
> > Unfortunately there is not as we haven't sat down to plan it in
> > depth, but you're more than welcome to start it.
> >
> > Generally, the idea is as follows:
> > Currently vdsm has storage virtualization capabilites, i.e. we've
> > implemented a form of thin-provisioning, we provide snapshots
> > using qcow etc, without relying on the hardware.  Using lsm we
> > could have feature negotiation and whenever we can offload, do it.
> > e.g. we could know if a storage array supports thin cloning, if it
> > supports thick cloning, if a LUN supports thin provisioning etc.
> > In the last example (thin provisioning) when we create a VG on top
> > of a thin-p LUN we should create all disk image (LVs)
> > 'preallocated' and avoid vdsm's thin provisioning implementation
> > (as it is not needed).
> >
> 
> I was thinking libstoragemgmt 'query capability' or similar interface
> should help vdsm know the array capabilities.

that is correct.

> I agree that if the backing LUN already is thinp'ed, then vdsm should
> not add its own over it. So such usecases & needs
> from vdsm perspective need to be thought about and eventually it
> should
> influence the libstoragemgmt interfaces

I don't see how it would influence the lsm interfaces.

> 
> > However, we'd need a mechanism at domain level to 'disable' some of
> > the capabilities, so for example if we know that on a specific
> > array snapshots are limited or provide poor performance (worse
> > than qcow) or whatever, we'd be able to fall back to vdsm's
> > software implementation.
> >
> 
> I was thinking that its for the user to decide, not sure if we can
> auto-detect and automate this. But i feel this falls under the
> 'advanced
> usecase' category :)
> We can always think about this later, rite ?

Correct, the mechanism is in order to allow the user to decide.

> 
>