mount a shared disk between two Linux Guest (OEL6.4)

[Paul_A]

Dear experts,

I'm running Virtualbox 4.3.30.
I have two Linux hosts (Oracle Linux 6.4): roma and rome. What I try to accomplish, is a disk that is read/writeable by both guest-hosts.

On one host I add a new disk, fixed size, 12Gb. I make it shareable and startup that host.
I create a filesystem on the new disk, and it becomes /dev/sdb1

I connect that same disk to the second host too, and start up that host as well.
On both hosts I create a mountpoint /SWLib and mount the disk there:
fstab:

Code: Select all

/dev/sdb1        /SWLib      ext4  defaults  1 2

When I touch a file on the one, I don't see it on the other hosts until I umount/mount.
And vice-versa. Obviously, I mounted it wrong, I have been trying to mount it also with:

Code: Select all

mount -t vboxsf /dev/sdb1 /SWLib

But that gives a protocol error:

Code: Select all

[root@rome ~]# mount -t vboxsf /dev/sdb1 /SWLib
/sbin/mount.vboxsf: mounting failed with the error: Protocol error

I have not found a solution yet. Any ideas highly appreciated.

[mpack]

It isn't possible to actually have a drive which is writable by multiple PCs. Physical drives can only be installed in one PC at a time, and as to VMs: the drives are host files, and it simply isn't possible for the file to be opened for writing twice or more times.

You can however simulate such a feature, in fact that feature is built into VirtualBox and is called "Shared Folders". See the user manual for details.

[socratis]

There is this special-cases, experts-only mode of a VDI, called "Shareable hard disk". From the user manual:

3. Shareable hard disks are a variant of write-through hard disks. In principle they behave exactly the same, i.e. their state is not saved when a snapshot is taken, and not restored when a snapshot is restored. The difference only shows if you attach such disks to several VMs. Shareable disks may be attached to several VMs which may run concurrently. This makes them suitable for use by cluster filesystems between VMs and similar applications which are explicitly prepared to access a disk concurrently. Only fixed size images can be used in this way, and dynamically allocated images are rejected.
Warning: This is an expert feature, and misuse can lead to data loss – regular filesystems are not prepared to handle simultaneous changes by several parties.

Disclaimer: never tried it or heard of anyone that did.

[loukingjr]

I certainly never tried it and most likely never will. The phrase "explicitly prepared" seems to be the key factor.

I agree with Don that using shared folders would be much easier.

[mpack]

Shareable disks are essentially read only: the same mechanism is used by linked clones and immutable drives. I doubt this is what the OP wants.

[loukingjr]

It's odd that they are listed under "Special image write modes" then.

[mpack]

Why is that strange? Immutable drives are listed there too.

[loukingjr]

Only in the sense it doesn't actually say they are read only. I use shared folders anyway.

[socratis]

Shareable disks are essentially read only: the same mechanism is used by linked clones and immutable drives. I doubt this is what the OP wants.

That's not my understanding from the manual. They are a variant of write-through hard disks. The latter are definitely not read-only. Unfortunately I don't have a cluster-aware OS to try it out.

[mpack]

Possibly you are correct. I'm simply guessing that the only way to make a virtual image shareable and writeable is to use a differencing scheme, which will of course mean that each VMs writes are hidden from the others - and of course the base disk would be locked down. I can't see how else it would work: at some point there has to be one controller which handles writes to the drive, and that controller must belong to one VM.

However, like you, this is not a feature I've ever been tempted to use.

@Paul_A: this disagreement between experts doesn't change the fact that this is not a substitute for shared folders, in fact the feature shouldn't be used at all by non-experts.