Storage Volumes

A Storage Volume is a block device that QuantaStor presents to a client host over iSCSI, Fibre Channel or NVMe over Fabrics -- the object the storage industry usually calls a LUN. This page covers how volumes are provisioned from a Storage Pool, every field in the Create and Modify dialogs, thin and thick provisioning, host assignment and CHAP, QoS throttles, snapshots, clones, volume groups, and what happens when a volume is deleted.

Section	Purpose
What a Storage Volume is	How a volume relates to its Storage Pool, and the identifiers it gets
Where the controls are	Which operations are on the toolbar and which are right-click only
Creating a Storage Volume	The Create dialog, tab by tab
Thin and thick provisioning	What % Reserved does and when a create is refused
Modifying a Storage Volume	What can be changed after provisioning and what cannot
Growing a Storage Volume	Resize, and the checks that block it
Access protocols	iSCSI, Fibre Channel, NVMe-oF and Infiniband, and where each is configured
Assigning volumes to hosts	The two assignment dialogs, and the multi-host corruption caution
CHAP authentication	The three CHAP sources and how they combine
Access mode and read-only volumes	Read/Write, Read Only and None
Quality of Service (QoS) controls	Per-volume bandwidth throttles and QoS policies
Snapshots	Space-efficient point-in-time copies, and lazy cloning
Clones	Full block copies, and why there is no volume promote
Rollback and restore	The three ways back to a previous point in time
Snapshot holds	Protecting a snapshot from deletion
Storage Volume Groups	Snapshotting and cloning a set of volumes together
Deleting Storage Volumes	Delete behavior, and what it does to snapshots and assignments
Sessions	Viewing and dropping active iSCSI and FC sessions
Migrating LUNs from another SAN	Copying an external LUN into a Storage Volume

What a Storage Volume is

Storage Volumes are provisioned from a Storage Pool, so create the pool first -- see Storage Pools. On a scale-up (ZFS) pool each volume is a zvol inside the pool's ZFS dataset; on a scale-out pool it is a Ceph RBD image. The pool supplies the capacity, the RAID layout, the read and write cache devices and the fault tolerance; the volume adds a size, a block size, an access mode and a set of host assignments.

Every volume gets its own iSCSI target IQN of the form iqn.2009-10.com.osnexus:<pool-prefix>-<volume-prefix>:<volume-name> plus an EUI and a SCSI device descriptor, all visible in the volume's Properties. Because each volume is its own iSCSI target, iSCSI initiators always reach it at LUN 0; the LUN number matters only for Fibre Channel.

Volumes are thin provisioned by default -- a new volume consumes no pool space until data is written to it. See Thin and thick provisioning.

A volume name may be 1 to 40 characters and may contain alphanumerics plus -, _ and ..

Where the controls are

Right-clicking a Storage Volume. Set QoS Controls, Instant Rollback from Snapshot and Create Remote Replica Volume are only reachable here, not from the toolbar.

Select the Storage Volumes section of the tree and the ribbon shows two button groups:

• Storage Volume -- Create, Snapshot, Resize, Assign, Multi-Delete, Clone, Restore, Modify
• Storage Volume Group -- Create, Snapshot, Modify, Delete, Clone, Add/Remove Volumes

Several operations have no toolbar button at all and are reached by right-clicking the volume: Set QoS Controls, Instant Rollback from Snapshot, Create Pass-thru Storage Volume(s), Create Remote Replica Volume and Properties. Right-clicking a snapshot rather than a volume adds two more items that do not appear on a source volume: Rollback Volume Clone and Add Storage Volume Hold.

With a volume selected, the center pane carries a Volume Dashboard (Performance, Capacity, Trends and Replication views over a selectable time range) above four tabs: Storage Volumes, Snapshots, Sessions and Storage Volume Groups.

Creating a Storage Volume

Navigation: Storage Management → Storage Volumes → Storage Volume (toolbar group) → Create

The dialog has three tabs. The Storage Pool selection on the first tab drives what is enabled on the third, so choose the pool before working through Advanced Settings.

General Settings

The General Settings tab of Create Storage Volume. The pool's type and RAID layout are echoed back so you can confirm you are provisioning from the intended pool.

• Name -- pre-filled with the next free volume-<n> name. 40 characters maximum.
• Description -- free text, optional.
• I/O Profile -- an IO tuning profile applied to the volume. Three ship with the product; the profile sets the volume's block size and the iSCSI target parameters (queued commands, first and max burst length, max receive and transmit data segment length). List them with qs volume-profile-list.
• Size -- a number plus a unit. MiB, GiB and TiB are base-2 (multiples of 1024). The slider spans the pool's current free space, but the field itself is not capped: a thin volume may legitimately be larger than the free space the pool has today. The dialog pre-selects 40 GiB when the pool has that much free, 10 GiB when it has at least that, and 1 GiB otherwise.
• Storage Pool -- the pool to provision from. CephFS and Ceph object pools, and the internal pools whose names start with . or [, are filtered out of the list.
• Namespace -- greyed out unless the selected pool is a Ceph RBD pool that has namespaces defined. Scale-out block only.
• Storage Pool Information -- read-only: percent utilized, pool type (Scale-up (ZFS) or Scale-out) and RAID type.

Profile	Block size	Optimized for
Default	64K	General purpose and backup workloads
Databases	8K	Database workloads and small-block I/O
Desktop and Server Virtualization	64K	Virtual machine workloads

Security Settings

Security Settings. The two default CHAP sources are enabled on a new volume; the username and password fields stay greyed out until you opt in to volume-specific CHAP.

• Access Mode -- Read/Write (default) or Read Only. See Access mode and read-only volumes.
• CHAP Authentication & Policy Settings -- three independent checkboxes plus a username and password pair. The first two are checked on a new volume; the CHAP Username and CHAP Password fields are disabled until Use Volume specific CHAP user/pass specified below is checked. See CHAP authentication.

Advanced Settings

Advanced Settings for a volume in a scale-up (ZFS) pool. Stripe Size and Stripe Count are scale-out only and stay greyed out; Enable Direct RBD Mapping/Access is hidden entirely.

The tab's own header states the rule that matters most: volume block size is immutable after the volume is created; everything else on this tab can be adjusted afterwards.

Block Device Settings

• Block Size -- 4K through 4M. Defaults to 64K on a ZFS pool and 4M on a Ceph RBD pool. Selecting an I/O Profile overrides the selection with the profile's block size. ZFS accepts 1K to 1M and Ceph object sizes must be 4K to 32M, so the dialog validates your choice against the selected pool and refuses a value outside that pool's range. Larger blocks favor sequential I/O; smaller blocks favor small random I/O.
• Stripe Size and Stripe Count -- Ceph RBD only, and only at create time; greyed out for a ZFS pool. They break each RBD object of Block Size into Stripe Count chunks of Stripe Size. Both must be powers of two, both must be set together, their product may not exceed the block size, and the stripe count may not exceed 64. Leave both on auto unless you have a specific reason.
• % Reserved -- 0 to 100, with a slider. See Thin and thick provisioning.
• Compression -- inherited from the pool and adjustable per volume. ZFS pools only. on, off, lz4, lzjb, zle, gzip and gzip-1 to gzip-9, zstd and zstd-1 to zstd-19, zstd-fast and zstd-fast-1 to zstd-fast-10.
• Sync Policy -- ZFS pools only. standard honours the application's O_SYNC flag; always makes every write synchronous to the ZIL, which is where a write log (SLOG) device pays off; disabled makes every write asynchronous. Choosing disabled raises a confirmation prompt, because it can cost you acknowledged writes on a power loss and is not supported for production use.
• Cache Policy Primary -- how the ARC (RAM read cache) is used: all, metadata or none. ZFS pools only.
• Cache Policy Secondary -- the same choice for L2ARC (SSD read cache). ZFS pools only.

Fibre Channel LUN Assignment

• FC LUN Assignment -- Dynamic (default) lets the system allocate a LUN number when the volume is first assigned to a host; Static pins it. The FC LUN field is inert until you select Static.
• FC LUN -- 0 to 16383, where 0 means unassigned. Only meaningful for Fibre Channel; iSCSI targets each have a unique IQN and always present at LUN 0. A LUN number already in use is rejected.

Remaining options

• Use QoS Policy -- enabled only for ZFS pools. Check it to enable the policy picker beside it. See Quality of Service (QoS) controls.
• Use Quota -- greyed out until at least one provisioning quota exists. Associating a volume with a quota makes the volume deduct from that quota rather than counting only against the pool.
• Use Case -- Default for a volume you intend to present to a host, or Ceph OSD to reserve the zvol as a Ceph OSD backing device. A Ceph OSD volume can never be presented over iSCSI, FC or NVMe-oF, and the assignment dialogs refuse it. The control is fixed once the volume exists, and a pool that itself carries a use case forces that use case on to every volume in it. A zvol carved from an OSD-dedicated pool also defaults to 100% reserved, because if the underlying zpool runs out of space every OSD on it starts failing writes at once.
• Enable Direct RBD Mapping/Access -- shown only when the selected pool is a Ceph RBD pool. It lets remote hosts map the RBD directly with the RBD client software, and permanently disables iSCSI, FC and NVMe-oF access to that volume. It cannot be changed later.
• Batch Create -- 1 to 1000. See below.

Batch Create

Set Batch Create above 1 to provision several identically configured volumes in one operation. The batch is named from the Name field with a numbered suffix -- vol.000, vol.001, vol.002 and so on -- and a suffix already in use is skipped.

Creating a volume from a Storage Tier

Navigation: Storage Management → Storage Pools → Storage Tier (select + right-click) → Create Storage Volume from Storage Tier

Create Storage Volume from Storage Tier has the same three tabs, with the Storage Pool picker replaced by a Storage Tier picker: the system then chooses the best pool inside that tier for the new volume. Use it when you want capacity from a class of storage rather than one named pool. See Provisioning Tiers.

Pass-thru Storage Volumes

Navigation: Storage Management → Physical Disks → Physical Disk (toolbar group) → Create Pass-thru

Create Pass-thru Storage Volume(s) maps physical media one-to-one to Storage Volumes with no Storage Pool in between, in either Raw Device Pass-thru or GPT Partitioned Pass-thru mode. Select one or more disks in the dialog's disk chooser. Pass-thru volumes are still presented to hosts like any other volume, but because there is no pool underneath them they cannot be resized, snapshotted or restored from a snapshot -- those operations return an error naming the volume as mapping directly to raw media. Use qs volume-create-passthru for the CLI equivalent.

Thin and thick provisioning

% Reserved is the single control for this. At 0% -- the default -- the volume is fully thin provisioned: it is created as a sparse zvol and consumes pool space only as data is written. At 100% the volume's full size is reserved out of the pool immediately (a ZFS refreservation), which guarantees the volume can always be written to its full size at the cost of that capacity being unavailable to anything else. Anything in between reserves that fraction.

The reservation is only a reservation, so it can be raised or lowered at any time from Modify Storage Volume -- there is no data movement and no measurable performance difference between a thin and a thick volume. Thin provisioning is the default and the usual choice.

Two consequences worth knowing:

• Only the reserved portion is checked against the pool's free space at create time. A 0% reserved volume larger than the pool's remaining free space is accepted. This is what over-provisioning means, and it is your responsibility to watch the pool.
• The create is still refused when the pool is already low. Below the pool free space alert threshold (10% by default) a create that pushes allocation past the free space needs the force flag; below the critical alert threshold (5% by default) it is refused outright, and below 3% the error says the pool is critically low. Both thresholds come from the Alert Manager configuration, so a site that has changed them will see different numbers.

Reserved space is shown in the Modify dialog as a byte figure rather than a percentage, deliberately: modifying with a percentage would round and could silently change the reservation you already had.

Modifying a Storage Volume

Navigation: Storage Management → Storage Volumes → Storage Volume (toolbar group) → Modify

Advanced Settings in Modify Storage Volume. Block Size, Stripe Size and Stripe Count are greyed out because they are fixed at create time; Reserved is expressed in bytes rather than as a percentage.

Modify carries the same three tabs as Create, with a Storage Volume picker at the top of General Settings so you can switch volumes without closing the dialog. What differs from Create:

• General Settings offers only Name, Description and I/O Profile. Size is not here -- growing a volume is a separate operation, see Growing a Storage Volume -- and neither is the Storage Pool, because a volume cannot be moved between pools. To place a copy in a different pool, clone it.
• Advanced Settings greys out Block Size, Stripe Size and Stripe Count, which are fixed for the life of the volume. Reserved replaces % Reserved and takes a byte value. Use Quota, Use Case, Batch Create and Enable Direct RBD Mapping/Access are absent, all being create-time only.
• Active Replica Checkpoint appears at the bottom of Advanced Settings, and is enabled only for a replication checkpoint volume or one already marked as such. A volume marked as an active replica checkpoint cannot be overwritten by a replication schedule, which is what protects a DR-site replica that has been brought into use from being clobbered by the source. Checkpoints are marked automatically as soon as access is granted to them or a host logs in to them. See Remote-replication (DR).
• Security Settings is identical to Create: access mode and the CHAP settings, both changeable at any time.

Contrary to what older documentation stated, there is no Is Snapshot control in this dialog, and QuantaStor has no btrfs pool type -- qs pool-create --pool-type accepts only zfs (the default) and swap. Is Snapshot? exists on this wiki's older pages because it is a column heading in the volume grid, not a setting.

Growing a Storage Volume

Navigation: Storage Management → Storage Volumes → Storage Volume (toolbar group) → Resize

Storage Volumes can only be grown, never shrunk. Truncating the end of a block device destroys data, so the operation refuses any size smaller than or equal to the current one.

Enter the new size and press OK. After the volume grows, QuantaStor issues a SCSI LUN resize event to the target driver so connected iSCSI and FC initiators are told the device changed size. Some operating systems pick the new size up on their own; others need a device rescan. Either way, expanding the partition and the filesystem on top of the volume is a separate job on the host.

Resize is blocked, and the Force checkbox is what overrides each of these:

• The volume has active iSCSI or FC sessions.
• The volume is assigned to a host whose type is XenServer. Resizing a volume that backs an active XenServer iSCSI Storage Repository can corrupt the SR, so this one is called out separately in the error.
• The pool does not have enough free space for the growth.

Pass-thru volumes map directly to raw media and cannot be resized at all. A lazily cloned snapshot is materialized first and then resized.

Access protocols

A volume is reachable over three protocol families, and the volume itself carries almost none of the configuration -- it lives on the Host object and on the target ports.

Protocol	Volume-side setting	Configured at
iSCSI	None. Every volume gets an IQN automatically and presents at LUN 0. CHAP is per volume.	The initiator IQN on the Host; iSCSI enablement per network port on the Storage System's Network Ports tab
Fibre Channel	FC LUN Assignment and FC LUN on the Advanced Settings tab	The initiator WWPN on the Host; target-mode ports on the Storage System's FC Ports tab -- see Fibre Channel Target Port Management
NVMe over Fabrics	None	The host NQN on the Host; per-port enablement -- see NVMe-oF Target Configuration
Infiniband	None	The Infiniband Ports tab on the Storage System lists the discovered IB target ports and their GIDs

Host initiator entries accept an iSCSI IQN, an FC WWPN or an NVMe NQN, so one Host object can represent a machine that reaches the same volume by more than one protocol. Assigning NVMe-oF access is rejected on RHEL-based QuantaStor builds, where NVMe-oF target support is not yet available.

Older documentation described Infiniband/SRP as a way to access Storage Volumes. The current product exposes no SRP target configuration -- the Infiniband Ports tab is a read-only inventory of IB ports -- so plan on iSCSI, Fibre Channel or NVMe-oF (which can itself run over RDMA/RoCE) for block access.

Assigning volumes to hosts

Assignment is what grants access. QuantaStor has no open-access mode. Each volume is its own iSCSI target with an initiator access group, and only the initiators belonging to assigned Hosts and Host Groups are placed in that group, so an unassigned volume is reachable by nobody.

There are two dialogs, differing only in which side you start from.

Assign/Unassign Storage Volume (one volume, many hosts)

Navigation: Storage Management → Storage Volumes → Storage Volume (toolbar group) → Assign

Assign/Unassign Storage Volume. The Hosts and Host Groups tabs show the current assignment as ticked rows; the tick state you leave becomes the complete assignment list.

Pick the volume at the top, then tick hosts on the Hosts tab and host groups on the Host Groups tab. The dialog opens with the volume's existing assignments already ticked, and the state you leave is the complete assignment list -- clearing a tick unassigns that host. Volumes that cannot be presented to a host at all (Ceph OSD backing zvols, direct-RBD volumes, and Ceph RBD snapshots) do not appear in the volume picker.

Release/free unused storage volume LUN number(s) returns the volume's FC LUN number to the free pool if the operation leaves it assigned to nothing. Leave it clear -- the default -- to keep the LUN number static, so a later re-assignment reuses the same number. This only matters for Fibre Channel.

Assign/Unassign Storage Volumes (one host, many volumes)

Navigation: Storage Management → Hosts & Portal Groups → Host (toolbar group) → Assign

Assign/Unassign Storage Volumes, reached from a Host. The same dialog opens from the Host Group group and works on a host group instead.

Starting from a Host (or, from the Host Group toolbar group, a Host Group) gives you the mirror image: one host on the left, a searchable dual list of volumes to move across. This is the dialog to use when bringing a new server online against a set of LUNs. Both dialogs carry the same LUN release checkbox and both apply set semantics.

Do not assign a non-clustered filesystem to two hosts

CAUTION: a Storage Volume formatted with an ordinary, non-clustered filesystem must never be assigned to more than one host at a time. Two Windows hosts writing to the same NTFS volume over iSCSI will corrupt it, and quickly. NTFS, ext3, ext4, XFS, UFS and most other single-host filesystems have no distributed locking, so each host caches metadata it believes it owns exclusively and the two sets of writes destroy each other.

Shared access is safe only where the software on top of the volume is designed for it: VMware VMFS, Hyper-V with CSV, and cluster filesystems such as OCFS2 and GFS2 all have distributed locking services for exactly this purpose. Assign a volume to a Host Group when you mean "all the nodes of this cluster", and to a single Host otherwise.

A Windows Server Failover Cluster -- Hyper-V with CSV, or a SQL Server Failover Cluster Instance -- also needs its SCSI-3 persistent reservations to survive an HA failover. Enable that on the pool's HA group; see Clustered SCSI-3 Persistent Reservations.

QuantaStor's own use of OpenZFS for scale-up pools is not a counter-example. A pool is only ever imported on one system at a time, and the high-availability system coordinates that -- among other techniques with device-level persistent reservations (SCSI-3 PR) on enterprise dual-ported SAS and dual-ported NVMe media.

Host Groups

When several Host entries make up a cluster, put them in a Host Group and assign volumes to the group. Hosts added to the group later automatically pick up access to every volume assigned to it, which is what makes group assignment worth the extra object.

CHAP authentication

CHAP is iSCSI's challenge-response authentication, configured per volume on the Security Settings tab. The three checkboxes are additive, not a precedence order -- every source you enable contributes a credential to the volume's target, and an initiator may authenticate with any of them:

• Use User's default CHAP user/pass if available -- takes the default CHAP username and password from the user accounts (and user groups) that own the volume. Set those once in the User Modify dialog and every volume you own inherits them, which is the point of the option.
• Use Resource Group default CHAP user/pass -- takes the default CHAP credential from the tenant resource group the volume belongs to.
• Use Volume specific CHAP user/pass specified below -- enables the CHAP Username and CHAP Password fields for a credential unique to this one volume.

Two failure modes are worth knowing because both surface as alerts rather than dialog errors:

• Enabling volume-specific CHAP and leaving either field empty raises Storage Volume X has an invalid CHAP username/password combination.
• If two enabled sources supply the same CHAP username with different passwords, QuantaStor raises an alert telling you to give each source a unique username. Only one of the two passwords ends up on the target, so this looks like an intermittent authentication failure from the initiator side.

Rules the fields enforce: the password is 12 to 16 characters, the username is 1 to 255 characters, and neither may contain spaces or the < and > characters.

QuantaStor uses uni-directional CHAP by default -- the target authenticates the initiator, not the reverse -- so do not set mutual-authentication properties such as node.session.auth.username_in on the initiator. Bi-directional CHAP is enabled by setting enable_bidi_chap=true in the [target_manager] section of /etc/quantastor.conf.

Access mode and read-only volumes

Access Mode is on the Security Settings tab and can be changed at any time.

• Read/Write -- the default, including for snapshots.
• Read Only -- QuantaStor sets the read-only attribute on the SCSI device and its LUN mapping, so the restriction is enforced by the target driver rather than being advisory. Use it for a golden image you clone new volumes from, so nothing can modify the template.

The Snapshot and Clone dialogs offer a third choice, None, which creates the volume with no host access at all. It is a useful default for a snapshot you are keeping purely as a recovery point.

Quality of Service (QoS) controls

Navigation: Storage Management → Storage Volumes → Storage Volume (select + right-click) → Set QoS Controls

Set Storage Volume QoS Controls. Zero means unlimited; ticking Use QoS Policy hands control to the policy and disables the sliders.

In a shared or multi-tenant environment one volume can consume an unfair share of a system's bandwidth. QoS controls cap it. Read Bandwidth and Write Bandwidth are set in MB/s, from 0 to 2000, with 0 meaning no limit.

Tick Use QoS Policy and pick a policy instead, and the two sliders grey out and show the policy's values. The two are mutually exclusive by design: applying a policy to a volume clears any per-volume limits, and setting a per-volume limit clears the policy association.

QoS applies to Storage Volumes only -- not to Network Shares -- and the Use QoS Policy checkbox on the Create and Modify dialogs is enabled only for volumes in a scale-up (ZFS) pool.

QoS policies

A policy lets you change the limits for a whole group of volumes across the grid in one operation; changes take effect on every associated volume immediately. Policies are also a practical way to widen limits during a quiet window and tighten them again afterwards. Create one with qs qos-policy-create:

qs qos-policy-create --name=high-performance --bw-read=300MB --bw-write=300MB
qs volume-set-qos --volume=vol1 --qos-policy=high-performance

The CLI also accepts --iops-read and --iops-write on qs volume-set-qos to cap 4K IOPS; the web interface offers bandwidth limits only.

To see the QoS settings in the volume grid, click the arrow on any column header, hover Columns, and tick QoS Policy, QoS Max Read/s and QoS Max Write/s.

Snapshots

Navigation: Storage Management → Storage Volumes → Storage Volume (toolbar group) → Snapshot

Snapshot Storage Volume. The default name is a GMT timestamp appended to the source volume's name.

A snapshot is a space-efficient point-in-time copy: it records the metadata of the source volume rather than copying its blocks, so it is created near-instantly and initially consumes almost nothing. Snapshots of snapshots are supported. Snapshots can only be created inside the same Storage Pool as the source.

Dialog fields:

• Storage Volume -- the source. The pool it lives in is shown beneath.
• Naming Options -- Create snapshot using default GMT timestamp name (the default) names the snapshot <volume>_GMT<YYYYMMDD>_<HHMMSS>. Choose Create snapshot with custom name to type your own.
• Description -- optional.
• Use Quota -- charge the snapshot against a provisioning quota.
• Access Mode -- Read/Write (default), Read Only or None.
• Snapshot Count -- 1 to 1000, to take a batch at once.

Only volumes in a scale-up (ZFS) or scale-out (Ceph RBD) pool can be snapshotted. Attempting it on a pass-thru volume reports that the volume is not in an Advanced (zfs) pool and suggests using clone instead.

Lazy cloning

Making a snapshot writable means creating a ZFS clone of it, and most snapshots are created by a schedule and deleted without ever being read. QuantaStor therefore uses lazy cloning: the snapshot is taken immediately, but the clone that makes it a usable block device is deferred. The web interface always uses lazy cloning.

The visible effect is that a freshly created snapshot sits in the Offline state with no device path and no iSCSI target of its own. It is materialized -- the clone is created, the target registered, the state moves to Normal -- the first time it is needed: when it is assigned to a host, modified, resized, or used as the source of a restore. Nothing is lost by the delay, and the saving in CPU and memory is what makes large snapshot schedules and remote replication scale.

The CLI leaves the choice to you: qs volume-snapshot materializes the clone immediately unless you pass --lazy-clone=true.

Set up a Snapshot Schedule rather than taking snapshots by hand. Schedules have long-term retention rules that can keep snapshots for months or quarters, which is what gives you a recovery point from before a ransomware event rather than after it.

Clones

Navigation: Storage Management → Storage Volumes → Storage Volume (toolbar group) → Clone

Clone Storage Volume. The destination pool can be any pool on the system, which is the main reason to clone rather than snapshot.

A clone is a complete copy of the source volume's blocks, and unlike a snapshot it can be created in any Storage Pool, not just the source's. That is usually the reason to choose one.

Cloning does not require taking the source offline: QuantaStor takes a temporary snapshot of the source behind the scenes so the copy is point-in-time consistent while the source keeps serving I/O, then streams the blocks into the destination pool. The destination pool needs room for the full size of the source. Progress shows in the task bar at the bottom of the web interface, and the clone is not usable until the copy finishes -- in contrast to a snapshot, which is usable immediately.

Fields are Storage Volume (source), Clone Name (optional -- the source name is used as a prefix if you leave it blank), Description, Storage Pool (destination), Use Quota, Access Mode (Read/Write, Read Only or None) and Force, which is required when the source volume is in use.

There is no promote operation for Storage Volumes. A snapshot never has to be promoted to become an independent volume -- it is already a first-class volume you can assign, resize and snapshot in turn. If what you want is a copy with no dependency on the original at all, clone it; the clone shares no blocks with the source. (Network Shares do have a promote operation, qs share-promote; there is deliberately no volume equivalent.)

Rollback and restore

Three separate operations take a volume back to an earlier point in time, and they are not interchangeable.

Operation	What it does	Speed	Constraint
Instant Rollback from Snapshot (right-click)	Rolls the source volume back to the snapshot in place	Near instant, no data movement	Only the most recently created snapshot. Scale-up (ZFS) pools only
Restore Storage Volume (toolbar)	Full copy of the snapshot's contents back over the source	Slow, proportional to size	Works from any snapshot in the volume's snapshot chain, and preserves snapshot history
Rollback Volume Clone (right-click a snapshot)	Discards everything written to the snapshot and resets it to its point in time	Near instant	The object must be a cloned snapshot

For rollback, ZFS can only unwind to the newest snapshot, so to roll back to an earlier one every snapshot taken after it must be deleted first. With snapshots Vt1, Vt2 and Vt3 of volume V1, only Vt3 is a valid rollback point; using Vt1 means deleting Vt2 and Vt3 first. Restore has no such restriction, which is the trade for its being a full copy.

All three refuse to run while the volume has active iSCSI or FC sessions unless Force is checked. That check exists to stop a restore landing under a mounted filesystem, which corrupts it -- so use Force only when the volume is genuinely no longer in use on the host, not as a way past an inconvenience. The chosen snapshot must also be a descendant of the volume you are restoring, and cannot be restored over itself.

Rollback and restore both replace the data in the original with the data in the snapshot. Everything written to the original since that snapshot was taken is lost. Take a snapshot of the current state first if there is any doubt -- it costs almost nothing.

Snapshot holds

Navigation: Storage Management → Storage Volumes → snapshot (select + right-click) → Add Storage Volume Hold

A hold on a snapshot prevents it from being deleted until the hold is released. Give it a Hold Tag Name to identify it; for a snapshot created by a schedule, the schedule's id is the default tag. Remove Storage Volume Hold releases it and makes the snapshot deletable again. The CLI equivalents are qs volume-hold-add and qs volume-hold-remove.

Storage Volume Groups

A Storage Volume Group is a named set of Storage Volumes that lets you snapshot or clone all of them in one operation -- the point being an application spread across several LUNs, where a snapshot of one alone is not useful. Volumes may belong to more than one group.

Navigation: Storage Management → Storage Volumes → Storage Volume Group (toolbar group) → Create

The toolbar group offers Create, Snapshot, Modify, Delete, Clone and Add/Remove Volumes. Create takes a name, a description and a searchable member list; leaving the name blank generates one prefixed volgroup.

Points to know:

• Keep the members on one Storage System. Group members on different systems are allowed, but cloning a group requires them to be on the same system.
• Group snapshot takes a snapshot of every member, with one shared name prefix, an access mode and a snapshot count, exactly as the single-volume dialog does. The task reports how many members failed if any do.
• Group clone clones every member. Where a group mixes ZFS and Ceph RBD members, each member is cloned into its own pool rather than all into one destination.
• Delete removes the group. Delete Associated Volumes additionally deletes the member volumes -- leave it clear and the volumes survive the group. If a member also belongs to another volume group, deleting the volumes needs Force Deletion.
• Add/Remove Volumes edits membership with checkboxes; the state you leave is the new member list.

Deleting Storage Volumes

Navigation: Storage Management → Storage Volumes → Storage Volume (toolbar group) → Multi-Delete

Delete Storage Volumes. The Auto Select buttons are the fastest way to clear out accumulated snapshots; note that Delete Child Snapshots Only leaves the selected volumes themselves alone.

WARNING: deleting a Storage Volume destroys all of its data.

The toolbar Multi-Delete button opens Delete Storage Volumes, a dual-list dialog built for clearing out volumes and snapshots in bulk; right-clicking a single volume and choosing Delete Storage Volume opens the same dialog with that volume pre-selected. Filter by Storage System and Storage Pool, or type a partial name and press Search. Hide Snapshots is ticked by default so the available list shows only source volumes. The selected side shows a running count and the space the deletion will reclaim.

Auto Select Options fill the selection for you: Select All Snapshots picks every snapshot in the selected pool, and Select All Orphaned Snapshots picks only those no longer associated with a replication schedule -- the ones whose schedule id shows in the grid as a red UUID.

The two checkboxes at the bottom are easy to misread:

• Force overrides the safety checks listed below.
• Delete Child Snapshots Only deletes the snapshots of the selected volumes and leaves the selected volumes themselves in place. It is not a modifier that lets you delete a volume together with its snapshots. The CLI exposes both behaviors separately, as --delete-child-snaps-only and --delete-child-snaps-and-parent on qs volume-delete, and --dry-run-only=true lists exactly what a delete would remove without removing anything.

What a delete does and what stops it:

• Host assignments are removed automatically. The volume's access control entries are deleted as part of the operation, so there is no need to unassign first.
• The FC LUN number and target id are returned to the free pool, and any QoS controls on the volume are disabled.
• A volume that has snapshots is refused, naming the number of snapshots. Delete the snapshots first, or select the parent and its snapshots together in the dialog.
• A volume with active iSCSI sessions is refused unless Force is set; the error names the initiator IP and IQN.
• A volume used by, or previously created by, a snapshot or replication schedule is refused unless Force is set. The message tells you which kind of schedule, and warns that forcing it rules the volume out of future schedules.
• Deleting a snapshot updates the parent volume's snapshot list and count.
• Where multi-admin approval covers Storage Volume deletes, a delete is held as a pending request until the required number of administrators approve it.

Sessions

Select a Storage Volume and open the Sessions tab to see the active iSCSI and FC sessions for it. Right-click a session and choose Drop Session to disconnect it; the CLI equivalent is qs volume-session-close.

Note: many initiators re-establish a dropped session automatically. To keep a host out, unassign the Storage Volume from the Host or Host Group instead of dropping the session.

Migrating LUNs from another SAN

Navigation: Storage Management → Physical Disks → Physical Disk (toolbar group) → Copy

Moving LUNs off a legacy SAN normally means mapping both arrays to a host and pushing the data through it, which doubles the network hops. QuantaStor can instead connect to the old array directly and copy each LUN into a new Storage Volume. Select the discovered device under Physical Disks and use Copy: the dialog shows the source device on the left and the destination pool and new volume name on the right, allocates a volume of exactly the source's size, and copies every block. The CLI equivalent is qs disk-copy, which can also target a Network Share file and write raw, qcow, vhd or vmdk images.

Over Fibre Channel, put an FC HBA in the QuantaStor system in initiator mode, zone it to the legacy array, and present the LUNs to that initiator's WWPN. Then Scan for Disks and the LUNs appear under Physical Disks. Either Qlogic or Emulex HBAs work as initiators, but only Qlogic QLE24xx/25xx/26xx series cards (and OEM equivalents) are supported in FC target mode, so a Qlogic card is the better choice if the same port may later serve storage. Target mode is toggled per port -- see Fibre Channel Target Port Management.

Over iSCSI the QuantaStor system has to log in to the legacy array first. Create an iSCSI Software Adapter under Hardware Enclosures & Controllers, or do it from the console:

sudo qs-util iscsiinstall          # install the open-iscsi initiator software
sudo qs-util iscsiiqn              # print this system's IQN, to assign LUNs to
sudo qs-util iscsilogin 10.0.0.10  # discover and log in to all targets at that address

Assign the legacy LUNs to the IQN that qs-util iscsiiqn reports -- a snapshot LUN if the old array can make one, so the data is not changing under the copy -- then Scan for Disks and copy each device as above. qs-util with no arguments lists the other iSCSI helpers, including iscsidiscover and iscsirelogin.

CLI quick reference

Every operation on this page has a CLI equivalent. Full argument lists are in the QuantaStor CLI Command Reference.

qs volume-create --name=vol1 --size=100G --pool=pool0 --percent-reserved=0
qs volume-modify --volume=vol1 --access-mode=readonly
qs volume-resize --volume=vol1 --new-size=200G
qs volume-assign --volume=vol1 --host-list=host1,host2
qs volume-unassign-all --volume=vol1
qs volume-snapshot --volume=vol1 --count=1 --lazy-clone=true
qs volume-clone --volume=vol1 --pool=pool1 --name=vol1-copy
qs volume-rollback --volume=vol1 --snapshot=vol1_GMT20260101_120000
qs volume-restore --volume=vol1 --snapshot=vol1_GMT20260101_120000
qs volume-set-qos --volume=vol1 --bw-read=300MB --bw-write=300MB
qs volume-health-check --volume=vol1
qs volume-delete --volume-list=vol1 --dry-run-only=true
qs volume-delete --volume-list=vol1

qs volume-search takes a key:value filter with the modifiers = (equal), ~ (not), >, < and * (like), which is the practical way to work with thousands of volumes and snapshots from a script.

Related pages

• Storage Pools -- the pools volumes are provisioned from
• Physical Disks/Devices -- the media under a pool, pass-thru volumes and disk copy
• Provisioning Tiers -- provisioning a volume from a tier rather than a named pool
• Fibre Channel Target Port Management -- FC target and initiator port configuration
• NVMe-oF Target Configuration -- presenting volumes over NVMe over Fabrics
• Snapshot Schedules -- automating snapshots with retention rules
• Remote-replication (DR) -- replicating volumes to another site
• Performance Tuning -- system and pool level tuning behind volume performance

---

Verified against QuantaStor 6.9.0.