Hi,
We considered a similar problem in our company.
Shared storage is needed between VMs running on different networks.
NFS/CephFS is ok as long as the VM can see the source.
The best solution would be to use https://virtio-fs.gitlab.io/
Any FS would be used on the host side (e.g. NFS or CephFS) and exported
to
the VM natively (the network problem disappears).
But you should start by introducing an appropriate mechanism on the CS
side
(similar in operation to Manila Share from Openstack).
So, the initiative itself is very good.
Overall, CloudStack has been heading in the right direction lately :-)
Best regards,
Piotr
-----Original Message-----
From: Nux <n...@li.nux.ro>
Sent: Wednesday, June 19, 2024 12:59 AM
To: d...@cloudstack.apache.org; Users <users@cloudstack.apache.org>
Subject: Re: [Proposal] Storage Filesystem as a First Class Feature
Hi, I'd like to draw the attention to some of the more operational
aspects
of this feature, mainly the storage appliance internals and UI.
So long story short, I've discussed with Abhisar and others and we'll
be
deploying a VM based on the Cloudstack Debian systemvm template which
will
export NFS v3/4 for user VMs to consume.
Below are some of the more finer details, please have a read if you are
interested in this feature and feel free to comment and make
suggestions.
1 - The appliance will only have a single export, that export will be a
single disk (data volume). Keep it simple.
2 - GPT partition table and a single partition, filesystem probably XFS
and/or customisable - something stock Debian supports, simple and
boring
stuff.
3 - NFS export should be simple, we can standardise on a path name eg
/nfs
or /fileshare and it will be identical on all appliances.
4 - Starting specs: 2 cores, 4 GB RAM - should be OK for a small NFS
server,
the appliance can be upgraded to bigger offerings.
5 - Disk offering should be flagged accordingly, the disk offering will
have
a flag/checkbox for "storage appliance" use.
6 - This appliance will not be a system VM, it will be a "blackbox",
but the
approach will be similar here to CKS.
7 - Security model: by default we export to * (all hosts) into a single
network - for isolated networks - in SG zones we need to play with
security
groups & a global setting for dumb shared networks (without SG) because
of
security implications - requires further discussion.
8 - We export with default, best practices NFS options - anything
against
no_root_squash?
9 - Explore exporting the file share via multiple protocols - sftp,
tftp,
smb, nfs, http(s)? - The issue here is authentication becomes a
problem,
also user permissions will get messy and possibly conflict with
no_root_squash, in fact might require an all_squash and everything
mapped to
a single user that will be then also used for all those other services.
Also
logging will become necessary. Thoughts?
10 - UI details, but this will probably show up in the Storage section
somehow.
11 - Display free/used space, create alerts for full disk etc for this
appliance.
12 - Formatting and setting up to be done by an internal agent,
specifics
are sent via the kernel cmd line of the VM, similar to how we configure
system VMs.
What do you folks think of these points and have I missed anything
crucial?
On 2024-06-04 05:04, Abhisar Sinha wrote:
Hi,
I would like to propose supporting storage filesystem as a first-class
feature in Cloudstack.
The File Share can be associated with one or more guest networks or
vpc
tiers and can be used by any VM on the network in a shared manner. It
is designed to be resizable and highly available. This feature can
later be used as integration endpoints with the CSI driver, go-sdk,
Terraform, Ansible and others.
The draft functional spec is here :
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Filesystem+as
+a+First+Class+Feature
Looking forward to your comments and suggestions.
Thanks,
Abhisar
