----- 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. > > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
