11:50 a.m.
> 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.
> 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.
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
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 ?