LDoms virtual disks and ZFS backends

Scope: Oracle Solaris 11.4 and, for LDoms, compatible SPARC hardware with Oracle VM Server for SPARC. Examples are educational: verify release, privileges, target names and backups before running changes.

How it works

The path of an I/O

A guest virtual disk client (vdc) sends requests over logical domain channels to a virtual disk server (vds), which accesses its backend. A guest sees a disk even when the storage resides elsewhere.

Backend choices

Backends can be ZFS volumes, files, physical disks or slices; each has different manageability and performance tradeoffs. A zvol is convenient for provisioning and snapshots, but plan pool capacity and snapshot retention.

Stable identity

Virtual disk IDs can affect the disk names Solaris sees. Explicit IDs can help keep boot and data disk identities predictable.

Multi-path caution

Do not mount the same writable filesystem concurrently from independent guests unless a supported cluster filesystem and fencing design explicitly permits it.

Worked examples

Each example explains the question it answers, a reproducible starting point, what to look for, and operational precautions.

1. List backend mappings

Identify the complete disk chain.

ldm list-services
ldm list-bindings app01
zfs list -t volume -o name,volsize,used,refer

Interpretation: Map guest vdisk → exported volume@vds → /dev/zvol/dsk path.

Operational note: Run commands in a test environment first; confirm device names, privileges and release-specific options.

2. Add a data disk

Provision an illustrative separate data disk.

zfs create -V 100G rpool/ldoms/app01-data
ldm add-vdsdev /dev/zvol/dsk/rpool/ldoms/app01-data app01-data@primary-vds0
ldm add-vdisk data0 app01-data@primary-vds0 app01

Interpretation: Inside the guest, discover the disk using `format` and confirm its device identity before creating a filesystem.

Operational note: Never run filesystem creation commands against a disk you have not positively identified.

3. Observe backing pool pressure

Investigate whether slow guest I/O is storage-bound.

zpool status -v
zpool iostat -v 2
zfs get volsize,volblocksize,used rpool/ldoms/app01-data

Interpretation: Correlate host-level pool latency/throughput with guest `iostat -xn 2`.

Operational note: Run commands in a test environment first; confirm device names, privileges and release-specific options.

4. Snapshot the backend safely

Understand crash-consistent vs application-consistent copies.

zfs snapshot rpool/ldoms/app01-data@before-change
zfs list -t snapshot

Interpretation: A host-side snapshot alone does not quiesce guest databases or guarantee application consistency.

Operational note: Use guest/application quiescing or database-native backup procedures for consistent recovery.

Before you finish

Verify backend service domain health before changing guest disks.
Monitor snapshot growth and ZFS pool capacity.

Primary documentation

Read the relevant Oracle documentation for exact version-specific flags, supported platforms and limitations: Oracle primary reference ↗.

This field manual is independent, not affiliated with or endorsed by Oracle. Command examples should be adapted to your environment.

Logical Domains: architecture and design →Build a guest LDom from scratch →LDoms virtual networking, VLANs and resiliency →LDom migration: prerequisites and runbook →