Score:0

Share files via a shared disc across multiple VM's running Ubuntu 18?

mp flag
B P

I am trying to share a single disk across multiple VM's (Ubuntu 18). The VM's are hosted in Azure and the disk is an Azure Managed Disk. I've attached the disk to both VM's and have mounted them. I can see the partition on each, as well as the test file I've created, test.txt. However, updates to the contents of the txt file while SSH'ed into VM1 are not reflected in VM22. Instead, the VM2 shows the prior value until I unmount and remount the drive.

I'm new to Ubuntu/Linux, and am trying to figure out where to look. My initial thoughts...

  • Perhaps the filesystem I'm using (gpt) cannot support multiple, concurrent access in this manner and I must use something else? If so, what is more suitable?
  • The VM seems to take a copy of the file when it's mounted and writes are not shared.
  • Perhaps this is the problem and this can be turned off?
  • Perhaps this is a problem with Azure, although I no longer believe it to be.
  • Perhaps there is a permissions issue because the user accounts differ between machines. I know Linux includes permissions on a file + directory basis as a first-class concern.

Any other thoughts?

Score:0
ng flag

Shared managed disks need to be used in conjunction with a cluster manager or similar to handle the concurrancy, the Azure feature is really just about being able to technically attach it to more than one VM. See the docs here:

Shared managed disks don't natively offer a fully managed file system that can be accessed using SMB/NFS. You need to use a cluster manager, like Windows Server Failover Cluster (WSFC), or Pacemaker, that handles cluster node communication and write locking.

As Tero mentioned, what you have done is a recipie for data loss.

Score:0
us flag

GPT is a partitioning mechanism, not a filesystem.

Most filesystems are designed so that they assume exclusive access to the underlying block device. For example caching relies on the fact that all operations are seen by cache layer.

Your setup violates that assumption and that's why you see behavior like that. You have been lucky to have seen only such small problems. Data loss is guaranteed in any larger operations, as the filesystem metadata is updated by either party at their own time.

Now, the correct solution depends on your exact requirements.

Do you really need shared access on block device level?

If yes, then you need to use a clustered file system.

Or do you only need both servers able to access same set of files?

In that case, you should set up NFS server on one server, and NFS client on second one.

B P avatar
mp flag
B P
Writes will come from a different server in the future and these two will simply need read access. I guess I’m wondering what the point of a shared managed disk is then.
vidarlo avatar
ar flag
Why wouldn't something like NFS work in that scenario?
us flag
There are use cases where sharing block device is required, like failover servers. The preference should still be a networked file system or even application level data distribution. When the distribution mechanism is made on higher levels, it is easier to guarantee its correctness.
B P avatar
mp flag
B P
@TeroKilkanen @vidarlo i'm looking to monitor a directory for changes from multiple VM's. anytime a file changes, each VM would run a script. i've been doing a poc with `iwatch` but my testing with NFS shows the watch is not picking up when changes occur. i can think of some other ways of doing this, but this seemed more intuitive.
us flag
I would use `lsyncd` for this purpose. I would set it up to monitor file, and then it could execute the script remotely whenever there is a file change. This requires some programming in Lua though. You could use any other watch mechanism that can execute a command. Then you just use `ssh user@vm /path/to/script` to run the script.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.