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: dev@cloudstack.apache.org; Users <us...@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
