Virtualization
A hypervisor reaches MooseFS the way any other application does: a host mounts the file system. A virtual machine's disk is a file on that mount. Every host that mounts the same instance reaches the same tree, so an image written from one host is reachable from all of those hosts.
Only the last step differs between hypervisors. That step tells the product that the mounted directory is storage that the product may use. The step also names which of the product's own storage types the directory falls under. Proxmox and XCP-ng cover that step for each product.
The mount is one of two ways in
mfsmount gives the host a POSIX file system. Disk images, templates, and ISO files are stored on it as ordinary files. Both pages below take this route. Only this route gives every host of a hypervisor cluster the same directory.
MooseFS Block Device (mfsbdev) is the second way in. MooseFS Block Device presents one file stored in MooseFS to one Linux host as a local block device. A guest's disk therefore appears as a device instead of as a file in a directory. A read/write mapping takes a lock on that file. The Master Server holds the lock for the whole instance. A second read/write mapping of the same image, on this or any other host, is therefore refused. The image keeps a single writer unless the mapping is made with map -i. That option still tries to take the lock, but the mapping is made even when the lock cannot be taken. Mappings are held in the daemon and end with the daemon. A daemon started from a mappings file recreates the mappings that the file names. The procedures are in Block device operations. Clients covers the differences between the forms of the client.
An image file behaves like any other file
The image is split into chunks. The Storage Class of the image decides how many copies of each chunk exist and which Chunkservers hold them. Classes are set per directory and per file. Running images, their backups, and the ISO files next to the images can therefore each be kept under a separate class. The tools for this are in data placement tasks. Virtualization workload describes which class suits which part of a virtualization workload, and how many Chunkservers such a setup needs.
A thinly provisioned image costs the chunks it has touched, not the bytes written into them. Chunks that the file never touched are not stored and not counted, so the length of the image and its cost to the cluster differ. The free space that the mount reports is raw space, counted before redundancy. The figure that a hypervisor shows for such a storage entry is therefore not the volume of images that fits in the entry. Both readings are explained in raw space and user space.
The Master Server holds POSIX record locks and BSD locks for the whole instance. A lock that one host takes on an image is therefore visible to every other host. A hypervisor that protects its images with file locks keeps that protection on every host that mounts the instance. A mount started with mfsnoposixlocks or mfsnobsdlocks keeps that family of locks local, so those locks are no longer visible to other hosts. The two options are listed among the mount options. File locking covers the mechanism.
When a component stops answering, the client repeats the operation instead of failing it. The budget is mfsioretries attempts, 30 by default. That comes to roughly two minutes. After that the application receives an I/O error. A guest therefore stalls on its disk for that time, instead of getting a write error. Client and mount problems covers what the retry budget is made of.
Each MooseFS component gets its own platform decision
The page on bare metal, virtual machines, and containers covers, per role, where the Master Server, the Chunkservers, and the clients run. That page also describes what each role loses when it runs as a guest of the hypervisor that it serves.