Florent BEAUCHAMP e2ca66130c feat(live-mount): optional local VDI cache, making the mount read/write (#10434) ...

* refactor(mixins,proxy,xo-server): pass the XAPI names as one xapiLabels object

The SR name was a lone `nameLabel` threaded through xo-server, xo-proxy and
the mixin; the VDI names are about to join it. No change in behavior: the
proxy API still takes `nameLabel`.

Also export OC_MOUNT from _utils.mjs, the cache module will need it.

* feat(iscsi): FileBlockDevice can serve a block device node

With `size`, the path must be a block device (e.g. a VDI hot-plugged onto the
appliance, /dev/xvdX): its inode reports a size of 0, so the capacity comes
from the caller, and a short read is an I/O error instead of a sparse tail.

Also add unit tests for FileBlockDevice, which had none, and integration
tests against a loop device.

* feat(iscsi): advertise read-only LUNs as write protected

A read-only BlockDevice now sets the Write Protect bit of MODE SENSE, so the
guest mounts the disk read-only instead of failing on its first write. This is
the case of a live mounted disk, served by a read-only DiskBlockDevice.

* feat(live-mount): name the SR and VDI after the backed up VM and restore point

The SR is now `[XO live mount] <VM> (<backup date>)` and the VDI keeps the
name of the backed up disk, so a live mounted disk reads like the disk the
user knows. The VDI is also tagged with `xo:live-mount`, like the SR.

The proxy API takes them as `xapiLabels`; `nameLabel` is still accepted from
older XOs.

* feat(live-mount): optional local VDI cache, making the mount read/write

Without a cache, a live mounted disk is read-only and every read goes to the
backup repository. With `cacheSrId` (xo-server) / `cacheSr` (proxy API), the
disk is materialized block by block into a VDI of that SR, hot-plugged onto
the appliance serving the mount (XOA or the proxy):

- a block is read from the backup repository at most once;
- the LUN is read/write, writes land in the cache VDI and the backup is never
  modified;
- the VDI is created with the mount and destroyed with it: what was written
  is lost on unmount.

The appliance must be a VM of the target pool, and the SR plugged on the host
running it. On a local SR, the appliance must not be migrated while the mount
lasts, since the cache VDI cannot follow it: this is documented, not enforced.

The cache VDI is tagged `[NOBAK] [NOSNAP]` to stay out of the appliance's own
backups, and the SR of a cached mount is named `[XO live restore] …`. The
cache device is opened with retries, since its node may lag behind the
hot-plug.

2026-10-28 09:00:03 +01:00

..

api.md

feat(live-mount): optional local VDI cache, making the mount read/write (#10434)

2026-10-28 09:00:03 +01:00