[ovirt-users] oVirt 4.0 wishlist: VDSM

[Giuseppe Ragusa]

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
> > Users at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
>