Storage Volumes - Revision history

Qadmin: Link multi-admin approval to Security Configuration#Multi-admin Approvals

2026-09-28T16:40:39Z

Link multi-admin approval to Security Configuration#Multi-admin Approvals

← Older revision		Revision as of 16:40, 28 September 2026
Line 411:		Line 411:
	* '''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.		* '''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.		* '''Deleting a snapshot''' updates the parent volume's snapshot list and count.
	* Where multi-admin approval ~~is configured~~, a delete is held as a pending request until the required number of ~~approvals is met~~.		* Where [[Security Configuration#Multi-admin Approvals\|multi-admin approval]] covers Storage Volume deletes, a delete is held as a pending request until the required number of administrators approve it.

	== Sessions ==		== Sessions ==

Qadmin: Link the new Clustered SCSI-3 Persistent Reservations page

2026-09-28T16:32:19Z

Link the new Clustered SCSI-3 Persistent Reservations page

← Older revision		Revision as of 16:32, 28 September 2026
Line 241:		Line 241:

	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.		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.		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.

Qadmin: Rewrite from the product against 6.9.0: full Create/Modify/Assign/QoS/Snapshot/Clone/Delete dialog coverage, 11 new screenshots, corrected block-size default (64K not Auto) and snapshot naming (GMT timestamp not _snap000), documented the additive CHAP model, over-provisioning thresholds, XenServer resize guard and lazy cloning; carried forward the non-clustered-filesystem assignment caution (QSTOR-12352)

2026-09-03T04:36:46Z

Rewrite from the product against 6.9.0: full Create/Modify/Assign/QoS/Snapshot/Clone/Delete dialog coverage, 11 new screenshots, corrected block-size default (64K not Auto) and snapshot naming (GMT timestamp not _snap000), documented the additive CHAP model, over-provisioning thresholds, XenServer resize guard and lazy cloning; carried forward the non-clustered-filesystem assignment caution (QSTOR-12352)

Show changes

Qadmin at 13:56, 18 August 2026

2026-08-18T13:56:44Z

← Older revision		Revision as of 13:56, 18 August 2026
Line 85:		Line 85:
	=== Managing Host Initiators ===		=== Managing Host Initiators ===

	Hosts represent the client computers that one may assign Storage Volumes to. In FC/SCSI terminology the host systems are ''initiate'' the communication with your storage volumes (target devices) and so they are called '''initiators'''. Each Host entry may have one or more initiators associated with it. These can be one or more NVMeoF, iSCSI and/or FC initiators per Host.		Hosts represent the client computers that one may assign Storage Volumes to. In FC/SCSI terminology the host systems are ''initiate'' the communication with your storage volumes (target devices) and so they are called '''initiators'''. Each Host entry may have one or more initiators associated with it. These can be one or more [[NVMe-oF Target Configuration\|NVMeoF]], iSCSI and/or FC initiators per Host.

			=== NVMe-oF Access ===

			Storage Volumes can also be presented over NVMe over Fabrics (NVMe-oF) as an alternative to iSCSI or Fibre Channel. NVMe-oF is enabled per network port and supports both TCP and RDMA (RoCE v2) transports. Each volume gets its own NVMe subsystem (NQN) the same way it gets an IQN for iSCSI, and host access uses the same initiator-based model described above.

			See [[NVMe-oF Target Configuration]] for how to enable it on a target port and connect a host.

	=== Managing Host Initiator Groups ===		=== Managing Host Initiator Groups ===

Qadmin: /* Managing iSCSI Sessions */

2024-03-20T06:19:12Z

Managing iSCSI Sessions

← Older revision		Revision as of 06:19, 20 March 2024
Line 124:		Line 124:
	Note that for FC data migration one may use either a Qlogic or a Emulex FC HBA in initiator mode but QuantaStor only supports Qlogic QLE24xx/25xx/26xx series cards in FC Target mode. One may also use OEM versions of the Qlogic QLE series cards. It is best to use Qlogic cards as they may be used in both initiator and target mode. FC mode is switched in the ''Fibre Channel'' section by right-clicking on a given port and then selecting ''FC Port Enable (Target Mode)..'' or ''FC Port Disable (Initiator Mode)..''.		Note that for FC data migration one may use either a Qlogic or a Emulex FC HBA in initiator mode but QuantaStor only supports Qlogic QLE24xx/25xx/26xx series cards in FC Target mode. One may also use OEM versions of the Qlogic QLE series cards. It is best to use Qlogic cards as they may be used in both initiator and target mode. FC mode is switched in the ''Fibre Channel'' section by right-clicking on a given port and then selecting ''FC Port Enable (Target Mode)..'' or ''FC Port Disable (Initiator Mode)..''.

	=== Managing iSCSI Sessions ===		=== Managing FC/iSCSI Sessions ===
	[[File:Drop Session - Web.jpg\|512px\|thumb\|Drop an iSCSI session.]]		[[File:Drop Session - Web.jpg\|512px\|thumb\|Drop an iSCSI session.]]

	A list of active iSCSI sessions for a given volume can be found by selecting the ''Storage Volume'' in the tree section and then select the 'Sessions' tab. The ''Sessions'' tab shows both active FC and iSCSI session information. To drop an iSCSI session simply right-click on a session in the table and choose ''Drop Session...'' from the pop-up menu.		A list of active FC and iSCSI sessions for a given volume can be found by selecting the ''Storage Volume'' in the tree section and then select the 'Sessions' tab. The ''Sessions'' tab shows both active FC and iSCSI session information. To drop an iSCSI session simply right-click on a session in the table and choose ''Drop Session...'' from the pop-up menu.


	''Note: Some initiators will automatically re-establish a new iSCSI session if one is dropped by the storage system. To prevent this, unassign the ''Storage Volume'' from assigned ''Host'' or ''Host Group'' so that the host may not automatically re-login.''		''Note: Some initiators will automatically re-establish a new iSCSI session if one is dropped by the storage system. To prevent this, unassign the ''Storage Volume'' from assigned ''Host'' or ''Host Group'' so that the host may not automatically re-login.''

Qadmin: /* Managing Host Initiator Groups */

2024-03-20T06:18:51Z

Managing Host Initiator Groups

← Older revision		Revision as of 06:18, 20 March 2024
Line 89:		Line 89:
	=== Managing Host Initiator Groups ===		=== Managing Host Initiator Groups ===

	~~Sometimes you'll have~~ multiple ~~hosts that need to be assigned the same storage volume~~(s) ~~such as with a VMware or a XenServer resource pool. In such cases~~ we recommend making a Host Group ~~object which indicates all of the hosts in your cluster/resource pool~~. ~~With a host group you can assign the volume~~ to the ~~group once~~ and ~~save a lot of time. Also, when you add another host~~ to the ~~host group, it automatically gets access~~ to all the ~~volumes~~ assigned to the ~~group so it makes it very easy to add nodes to your cluster~~ and ~~manage storage from a group perspective rather than individual hosts which can be cumbersome especially for larger clusters~~.		When multiple Host entries comprise a cluster (eg VMware, HyperV) we recommend making a Host Group to combine them. This way Storage Volumes may be assigned to the Host Group and that will provide access to the Storage Volume to all Hosts in the Host Group. When additional Hosts are added to a Host Group they'll automatically be assigned access to all Storage Volumes in the Host Group. This greatly simplifies Storage Volume assignment and management.

	=== Disk Migration / LUN Copy to Storage Volume ===		=== Disk Migration / LUN Copy to Storage Volume ===

Qadmin: /* Managing Host Initiators */

2024-03-20T06:15:58Z

Managing Host Initiators

← Older revision		Revision as of 06:15, 20 March 2024
Line 85:		Line 85:
	=== Managing Host Initiators ===		=== Managing Host Initiators ===

	Hosts represent the client computers that ~~you~~ assign ~~storage volumes~~ to. In SCSI terminology the host ~~computers~~ ''initiate'' the communication with your storage volumes (target devices) and so they are called initiators. Each ~~host~~ entry ~~can~~ have one or more initiators associated with it ~~and the reason for this is because an iSCSI initiator (Host)~~ can be ~~identified by IP address~~ or ~~IQN or both at the same time. We recommend using the IQN (~~iSCSI ~~Qualified Name) at all times as you can have login problems when you try to identify a host by IP address especially when that host has multiple NICs~~ and ~~they're not all specified.~~		Hosts represent the client computers that one may assign Storage Volumes to. In FC/SCSI terminology the host systems are ''initiate'' the communication with your storage volumes (target devices) and so they are called '''initiators'''. Each Host entry may have one or more initiators associated with it. These can be one or more NVMeoF, iSCSI and/or FC initiators per Host.

	~~For details of installation please refer to QuantaStor Users Guide under iSCSI Initiator Configuration~~.

	=== Managing Host Initiator Groups ===		=== Managing Host Initiator Groups ===

Qadmin: /* Creating Storage Volume Snapshots (Snap-Clones) */

2024-03-20T06:14:01Z

Creating Storage Volume Snapshots (Snap-Clones)

← Older revision		Revision as of 06:14, 20 March 2024
Line 64:		Line 64:
	QuantaStor supports creation of snapshots and even snapshots of snapshots. Snapshots are R/W by default and read-only snapshots are also supported. QuantaStor uses what we call a ''lazy cloning'' technique where the underlying clone to make a snapshot writable is not done until the snapshot has been assigned to a host. Most snapshots are created by a schedule and then deleted without ever being accessed, so the ''lazy cloning'' technique boosts the performance and scalability of the ''Snapshot Schedules'' and ''Remote Replication'' system.		QuantaStor supports creation of snapshots and even snapshots of snapshots. Snapshots are R/W by default and read-only snapshots are also supported. QuantaStor uses what we call a ''lazy cloning'' technique where the underlying clone to make a snapshot writable is not done until the snapshot has been assigned to a host. Most snapshots are created by a schedule and then deleted without ever being accessed, so the ''lazy cloning'' technique boosts the performance and scalability of the ''Snapshot Schedules'' and ''Remote Replication'' system.

	* snapshots are 'thin', that is they are a copy of the meta-data associated with the original volume and not a full copy of all the data blocks.		All Storage Volume snapshots are 'thin provisioned', that is they are a copy of the meta-data associated with the original volume and not a full copy of all the data blocks. To create a snapshot or a batch of snapshots you'll want to select the Storage Volume that you which to snap, right-click on it and choose 'Snapshot Storage Volume...' from the menu. If you do not supply a name then QuantaStor will automatically choose a name for you by appending the suffix "_snap" to the end of the original's volume name. So if you have a storage volume named 'vol1' and you create a snapshot of it, you'll have a snapshot named 'vol1_snap000'. If you create many snapshots then the system will increment the number at the end so that each snapshot has a unique name.

	~~All of these advanced snapshot~~ capabilities ~~make QuantaStor ideally suited for virtual desktop solutions, off-host backup,~~ and ~~'''N'''ear '''C'''ontinuous '''D'''ata '''P'''rotection (NCDP)~~. ~~If you~~'~~re looking~~ to ~~get NCDP functionality, just create a 'snapshot schedule' and~~ snapshots ~~can be created~~ for ~~your storage volumes as frequently as every hour.~~		We recommend setting up a Snapshot Schedule so as to have rollback capabilities and some protection against ransomware. Snapshot Schedules have 'Long Term Retention Rules' to preserve snapshots for multiple months and/or quarters providing rollback and data recovery that is ideally prior to an attack in such a scenario.

	~~To create a snapshot~~ or ~~a batch of snapshots you'll want to select the storage volume~~ that ~~you which~~ to ~~snap, right-click on it and choose 'Snapshot Storage Volume...' from the menu.~~

	If you do not supply a name then QuantaStor will automatically choose a name for you by appending the suffix "_snap" to the end of the original's volume name. So if you have a storage volume named 'vol1' and you create a snapshot of it, you'll have a snapshot named 'vol1_snap000'. If you create many snapshots then the system will increment the number at the end so that each snapshot has a ~~unique name~~.

	=== Creating Storage Volume Clones ===		=== Creating Storage Volume Clones ===

Qadmin: /* Creating Volume Snapshots */

2024-03-20T06:09:52Z

Creating Volume Snapshots

← Older revision		Revision as of 06:09, 20 March 2024
Line 60:		Line 60:
	QuantaStor supports increasing the size of storage volumes but due to the high probability of data-loss that would come from truncation of the end of a disk QuantaStor does not support shrink. To resize a volume simply right-click on it then choose ''Resize Volume...'' from the pop-up menu. After the resize is complete a signal is sent to the connected iSCSI and FC initiator sessions to let the client hosts know that the block device has been resized. Some operating systems will detect the new size automatically, others will require a device rescan to detect the new expanded size. In most cases additional steps are required in the host OS to expand partitions or other volume settings adjusted to make use of the additional space.		QuantaStor supports increasing the size of storage volumes but due to the high probability of data-loss that would come from truncation of the end of a disk QuantaStor does not support shrink. To resize a volume simply right-click on it then choose ''Resize Volume...'' from the pop-up menu. After the resize is complete a signal is sent to the connected iSCSI and FC initiator sessions to let the client hosts know that the block device has been resized. Some operating systems will detect the new size automatically, others will require a device rescan to detect the new expanded size. In most cases additional steps are required in the host OS to expand partitions or other volume settings adjusted to make use of the additional space.

	=== Creating Volume Snapshots ===		=== Creating Storage Volume Snapshots (Snap-Clones) ===

	QuantaStor supports creation of snapshots and even snapshots of snapshots. Snapshots are R/W by default and read-only snapshots are also supported. QuantaStor uses what we call a ''lazy cloning'' technique where the underlying clone to make a snapshot writable is not done until the snapshot has been assigned to a host. Most snapshots are created by a schedule and then deleted without ever being accessed, so the ''lazy cloning'' technique boosts the performance and scalability of the ''Snapshot Schedules'' and ''Remote Replication'' system.		QuantaStor supports creation of snapshots and even snapshots of snapshots. Snapshots are R/W by default and read-only snapshots are also supported. QuantaStor uses what we call a ''lazy cloning'' technique where the underlying clone to make a snapshot writable is not done until the snapshot has been assigned to a host. Most snapshots are created by a schedule and then deleted without ever being accessed, so the ''lazy cloning'' technique boosts the performance and scalability of the ''Snapshot Schedules'' and ''Remote Replication'' system.

Qadmin: /* Creating Clones */

2024-03-20T06:09:33Z

Creating Clones

← Older revision		Revision as of 06:09, 20 March 2024
Line 72:		Line 72:
	If you do not supply a name then QuantaStor will automatically choose a name for you by appending the suffix "_snap" to the end of the original's volume name. So if you have a storage volume named 'vol1' and you create a snapshot of it, you'll have a snapshot named 'vol1_snap000'. If you create many snapshots then the system will increment the number at the end so that each snapshot has a unique name.		If you do not supply a name then QuantaStor will automatically choose a name for you by appending the suffix "_snap" to the end of the original's volume name. So if you have a storage volume named 'vol1' and you create a snapshot of it, you'll have a snapshot named 'vol1_snap000'. If you create many snapshots then the system will increment the number at the end so that each snapshot has a unique name.

	=== Creating Clones ===		=== Creating Storage Volume Clones ===

	Clones represent complete copies of the data blocks in the original storage volume, and a clone can be created in any storage pool in your storage system whereas a snapshot can only be created within the same storage pool as the original. You can create a clone at any time and while the source volume is in use because QuantaStor creates a temporary snapshot in the background to facilitate the clone process. The temporary snapshot is automatically deleted once the clone operation completes. Note also that you cannot use a cloned storage volume until the data copy completes. You can monitor the progress of the cloning by looking at the Task bar at the bottom of the QuantaStor Manager screen. (Note: In contrast to clones (complete copies), snapshots are created near instantly and do not involve data movement so you can use them immediately. Named snapshots are read/write by default.)		Clones represent complete copies of the data blocks in the original storage volume, and a clone can be created in any storage pool in your storage system whereas a snapshot can only be created within the same storage pool as the original. You can create a clone at any time and while the source volume is in use because QuantaStor creates a temporary snapshot in the background to facilitate the clone process. The temporary snapshot is automatically deleted once the clone operation completes. Note also that you cannot use a cloned storage volume until the data copy completes. You can monitor the progress of the cloning by looking at the Task bar at the bottom of the QuantaStor Manager screen. (Note: In contrast to clones (complete copies), snapshots are created near instantly and do not involve data movement so you can use them immediately. Named snapshots are read/write by default.)