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 ?

_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to