12:09 a.m.
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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
3287
days inactive
3287
days old
0 comments
1 participants
participants (1)
-
Giuseppe Ragusa