As a developer, I’ve been using various AI tools in my work to gather knowledge, troubleshoot issues, and polish code. My usual suspects have been ChatGPT and DeepSeek, which have served me well for general queries and code suggestions. However, when I recently worked on a project that was almost entirely written with the help of ChatGPT and GitHub Copilot, I hit a wall – exceeding my quota limits. This led me to search for a viable alternative that could meet my specific requirements.

KVM supports “Shared Mountpoint” storage. A shared mountpoint is a file system path local to each server in a given cluster. The path must be the same across all Hosts in the cluster, for example /mnt/primary1. This shared mountpoint is assumed to be a clustered filesystem such as OCFS2. In this case the CloudStack does not attempt to mount or unmount the storage as is done with NFS. The CloudStack requires that the administrator insure that the storage is available.

In this part, we will introduce how to use OCFS2 in Apache CloudStack.

When mounting an iSCSI target on two or more servers simultaneously using conventional filesystems (ext4, XFS, etc.), data corruption is inevitable. Each server maintains independent caches and metadata in memory, creating a critical coordination gap: neither server is aware of the other’s modifications. This lack of synchronization leads to: Metadata corruption, Lost or duplicated files, Filesystem structural damage, Potential complete data loss.

To safely share storage across multiple servers, you must implement a cluster-aware filesystem specifically designed for concurrent access. Currently, the two most prominent options are: OCFS2 (Oracle Cluster File System) - Oracle’s robust, feature-rich solution; GFS2 (Global File System) - Red Hat’s scalable cluster filesystem.

In this part, we’ll focus on implementing OCFS2 across Oracle Linux servers, providing step-by-step configuration for reliable shared storage access.

While working with a VMware ESXi 8.0 Update 3 testing environment, I encountered an issue where the vCenter Server Appliance (VCSA) repeatedly crashed without an obvious root cause. Attempts to power off the appliance failed with disk-related errors, and although the VM could be forcefully restarted, the problem reappeared after a short period of time.

At first glance, the ESXi host appeared to be running out of disk space, despite being provisioned with a 150 GB disk. This raised an important question: where had the space gone? As it turned out, the root cause was not excessive data growth, but rather unallocated disk space that had never been added to the VMFS datastore.

In this post, I walk through the investigation process, explain how to identify unallocated space on an ESXi host, and demonstrate how to safely extend a VMFS datastore to recover the missing capacity and prevent future outages.

Most CloudStack users settle for local storage or NFS in production. Local storage locks VMs to specific hosts, while NFS often becomes a performance bottleneck. There’s a better way: SAN storage.

In Part 1, we’ll build an iSCSI SAN that combines the best of both worlds—shared access without the single-point bottlenecks, giving you true cloud flexibility without compromise.