On Sat, Nov 21, 2015, at 13:59, Dan Kenigsberg wrote: > On Fri, Nov 20, 2015 at 01:54:35PM +0100, Giuseppe Ragusa wrote: > > Hi all, > > I go on with my wishlist, derived from both solitary mumblings and > > community talks at the the first Italian oVirt Meetup. > > > > I offer to help in coding (work/family schedules permitting) but keep in > > mind that I'm a sysadmin with mainly C and bash-scripting skills (but > > hoping to improve my less-than-newbie Python too...) > > > > I've sent separate wishlist messages for oVirt Node and Engine. > > > > VDSM: > > > > *) allow VDSM to configure/manage Samba, CTDB and Ganesha (specifically, > > I'm thinking of the GlusterFS integration); there are related wishlist > > items on configuring/managing Samba/CTDB/Ganesha on the Engine and on oVirt > > Node > > I'd apreciate a more detailed feature definition. Vdsm (and ovirt) try > to configure only thing that are needed for their own usage. What do you > want to control? When? You're welcome to draf a feature page prior to > coding the fix ;-)
I was thinking of adding CIFS/NFSv4 functionality to an hyperconverged cluster (GlusterFS/oVirt) which would have separate volumes for virtual machines storage (one volume for the Engine and one for other vms, with no CIFS/NFSv4 capabilities offered) and for data shares (directly accessible by clients on LAN and obviously from local vms too). Think of it as a 3-node HA NetApp+VMware killer ;-) The UI idea (but that would be the Engine part, I understand) was along the lines of single-check enabling CIFS and/or NFSv4 sharing for a GlusterFS data volume, then optionally adding any further specific options (hosts allowed, users/groups for read/write access, network recycle_bin etc.); global Samba (domain/workgroup membership etc.) and CTDB (IPs/interfaces) configuration parameters would be needed too. I have no experience on a GaneshaNFS clustered/HA configuration with GlusterFS, but (from superficial skimming through docs) it seems that it was not possible at all before 2.2 and now it needs a full Pacemaker/Corosync setup too (contrary to the IBM-GPFS-backed case), so that could be a problem. This VDSM wishlist item was driven by the idea that all actions (and so future GlusterFS/Samba/CTDB too) performed by the Engine through the hosts/nodes were somehow "mediated" by VDSM and its API, but if this is not the case, then I retire my suggestion here and I will try to pursue it only on the Engine/Node side ;) Many thanks for your attention. Regards, Giuseppe > > *) add Open vSwitch direct support (not Neutron-mediated); there are > > related wishlist items on configuring/managing Open vSwitch on oVirt Node > > and on the Engine > > That's on our immediate roadmap. Soon, vdsm-hook-ovs would be ready for > testing. > > > > > *) add DRBD9 as a supported Storage Domain type; there are related wishlist > > items on configuring/managing DRBD9 on the Engine and on oVirt Node > > > > *) allow VDSM to configure/manage containers (maybe extend it by use of the > > LXC libvirt driver, similarly to the experimental work that has been put up > > to allow Xen vm management); there are related wishlist items on > > configuring/managing containers on the Engine and on oVirt Node > > > > *) add a VDSM_remote mode (for lack of a better name, but mainly inspired > > by pacemaker_remote) to be used inside a guest by the above mentioned > > container support (giving to the Engine the required visibility on the > > managed containers, but excluding the "virtual node" from power management > > and other unsuitable actions) > > > > Regards, > > Giuseppe > > > > _______________________________________________ > > Users mailing list > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/users > _______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
