Logo

Contents:

  • StorPool User Guide - version 21
    • 1. StorPool Overview
    • 2. Architecture
    • 3. Feature Highlights
      • 3.1. Scale-out, not Scale-Up
      • 3.2. High Performance
      • 3.3. High Availability and Reliability
      • 3.4. Commodity Hardware
      • 3.5. Shared Block Device
      • 3.6. Co-existence with hypervisor software
      • 3.7. Compatibility
      • 3.8. CLI interface and API
      • 3.9. Reliable Support
    • 4. Hardware Requirements
      • 4.1. Minimum StorPool cluster
      • 4.2. Recommended StorPool cluster
      • 4.3. How StorPool relies on hardware
        • 4.3.1. CPU
        • 4.3.2. RAM
        • 4.3.3. Storage (HDDs / SSDs)
        • 4.3.4. Network
      • 4.4. Software Compatibility
        • 4.4.1. Operating Systems
        • 4.4.2. File Systems
        • 4.4.3. Hypervisors & Cloud Management/Orchestration
    • 5. Installation and Upgrade
    • 6. Node configuration options
      • 6.1. Minimal Node Configuration
      • 6.2. Full Configuration Options List
        • 6.2.1. Cluster name
        • 6.2.2. Cluster ID
        • 6.2.3. Non-voting beacon node
        • 6.2.4. Communication interface for StorPool cluster
        • 6.2.5. Address for the API management (storpool_mgmt)
        • 6.2.6. Port for the API management (storpool_mgmt)
        • 6.2.7. Ignore RX port option
        • 6.2.8. Preferred port
        • 6.2.9. Address for the bridge service (storpool_bridge)
        • 6.2.10. Interface for the bridge address (storpool_bridge)
        • 6.2.11. Parallel requests per disk when recovering from remote (storpool_bridge)
        • 6.2.12. Working directory
        • 6.2.13. Report directory
        • 6.2.14. Restart automatically in case of crash
        • 6.2.15. Expected nodes
        • 6.2.16. Local user for debug data collection
        • 6.2.17. Remote addresses for sending debug data
        • 6.2.18. Remote ports for sending debug data
        • 6.2.19. Group owner for the StorPool devices
        • 6.2.20. Permissions for the StorPool devices
        • 6.2.21. Logging of non-read-only open/close for StorPool devices
        • 6.2.22. Exclude disks globally or per server instance
        • 6.2.23. storpool_logd service related configuration
        • 6.2.24. Cgroup setup
        • 6.2.25. Network and Storage controllers interrupts affinity
        • 6.2.26. Cache size
        • 6.2.27. API authentication token
        • 6.2.28. NVMe SSD drives
        • 6.2.29. Per host configuration
    • 7. Storage devices
      • 7.1. Journals
      • 7.2. Using disk_init_helper
        • 7.2.1. Example node
        • 7.2.2. Discovering drives
          • 7.2.2.1. Basic usage
          • 7.2.2.2. Viewing configuration
          • 7.2.2.3. Recognizing SSDs
          • 7.2.2.4. Specifying a journal
        • 7.2.3. Initializing drives
      • 7.3. Manual partitioning
        • 7.3.1. Creating partitions
        • 7.3.2. Initializing a drive
        • 7.3.3. Drive initialization options
    • 8. Network interfaces
      • 8.1. Preparing Interfaces
      • 8.2. net_helper
        • 8.2.1. exclusive-ifaces
        • 8.2.2. active-backup-bond and bridge-active-backup-bond
        • 8.2.3. mlag-bond and bridge-mlag-bond
      • 8.3. Examples
      • 8.4. Manual config notes
    • 9. Background services
      • 9.1. storpool_beacon
      • 9.2. storpool_server
      • 9.3. storpool_block
      • 9.4. storpool_mgmt
      • 9.5. storpool_bridge
      • 9.6. storpool_controller
      • 9.7. storpool_nvmed
      • 9.8. storpool_stat
      • 9.9. storpool_qos
    • 10. Managing services with storpool_ctl
      • 10.1. Supported actions
      • 10.2. Getting status
      • 10.3. Starting services
      • 10.4. Enabling services
      • 10.5. Disabling services
      • 10.6. Stopping services
    • 11. CLI tutorial
      • 11.1. Examples
      • 11.2. More information
    • 12. CLI reference
      • 12.1. Location
      • 12.2. Cluster
      • 12.3. Remote Bridge
      • 12.4. Network
      • 12.5. Server
      • 12.6. Fault sets
      • 12.7. Services
      • 12.8. Disk
        • 12.8.1. Disk list main info
        • 12.8.2. Disk list additional info
        • 12.8.3. Disk list server internal info
        • 12.8.4. Disk list performance info
        • 12.8.5. Ejecting disks and internal server tests
      • 12.9. Placement Groups
      • 12.10. Volumes
      • 12.11. Snapshots
        • 12.11.1. Remote snapshots
      • 12.12. Attachments
      • 12.13. Client
      • 12.14. Templates
      • 12.15. iSCSI
        • 12.15.1. Create a Portal Group
        • 12.15.2. Register an Initiator
        • 12.15.3. Export a Volume
        • 12.15.4. Get iSCSI Configuration
        • 12.15.5. iscsi_tool
        • 12.15.6. iscsi_targets
      • 12.16. Kubernetes
      • 12.17. Relocator
      • 12.18. Balancer
      • 12.19. Tasks
      • 12.20. Maintenance Mode
      • 12.21. Management menu
      • 12.22. Management Configuration
      • 12.23. Mode
    • 13. Multi-server
      • 13.1. Configuration
      • 13.2. Helper
    • 14. Redundancy
      • 14.1. Replication
        • 14.1.1. Triple replication
        • 14.1.2. Dual replication
      • 14.2. Erasure Coding
        • 14.2.1. Features
        • 14.2.2. Redundancy schemes
    • 15. Volume management
      • 15.1. Creating a volume
      • 15.2. Deleting a volume
      • 15.3. Renaming a volume
      • 15.4. Resizing a volume
      • 15.5. Snapshots
      • 15.6. Creating a snapshot of a volume
      • 15.7. Converting a volume to a snapshot (freeze)
      • 15.8. Creating a volume based on an existing snapshot (a.k.a. clone)
      • 15.9. Deleting a snapshot
      • 15.10. Rebase to null (a.k.a. promote)
      • 15.11. Rebase
      • 15.12. Example use of snapshots
    • 16. StorPool iSCSI support
      • 16.1. A Quick Overview of iSCSI
      • 16.2. An iSCSI Setup in a StorPool Cluster
      • 16.3. Routed iSCSI setup
        • 16.3.1. Overview
        • 16.3.2. Configuration
      • 16.4. Caveats with a Complex iSCSI Architecture
    • 17. Multi-site and multi-cluster
      • 17.1. Multicluster
      • 17.2. Multi site
      • 17.3. Setup
      • 17.4. Connecting two clusters
        • 17.4.1. Cluster A
        • 17.4.2. Cluster B
      • 17.5. Bridge redundancy
        • 17.5.1. Separate IP addresses
        • 17.5.2. Single IP failed over between the nodes
      • 17.6. Bridge throughput performance
        • 17.6.1. Network
        • 17.6.2. CPU
        • 17.6.3. Disks throughput
      • 17.7. Exports
      • 17.8. Remote clones
      • 17.9. Creating a remote backup on a volume
      • 17.10. Creating an atomic remote backup for multiple volumes
      • 17.11. Restoring a volume from remote snapshot
      • 17.12. Remote deferred deletion
      • 17.13. Volume and snapshot move
        • 17.13.1. Volume move
        • 17.13.2. Snapshot move
    • 18. Rebalancing StorPool
      • 18.1. Overview
      • 18.2. Restoring volume redundancy on a failed drive
      • 18.3. Restoring volume redundancy for two failed drives (single-copy situation)
      • 18.4. Adding new drives and rebalancing data on them
      • 18.5. Restoring volume redundancy with rebalancing data on other placementGroup
      • 18.6. Decommissioning a live node
      • 18.7. Decommissioning a dead node
      • 18.8. Resolving imbalances in the drive usage
      • 18.9. Resolving imbalances in the drive usage with three-node clusters
      • 18.10. Reverting balancer to a previous state
      • 18.11. Reading the output of storpool balancer disks
        • 18.11.1. balancer tool output
      • 18.12. Errors from the balancer tool
      • 18.13. Miscellaneous
    • 19. Troubleshooting Guide
      • 19.1. Normal state of the system
        • 19.1.1. All nodes in the storage cluster are up and running
        • 19.1.2. All configured StorPool services are up and running
        • 19.1.3. Working cgroup memory and cpuset isolation is properly configured
        • 19.1.4. All network interfaces are properly configured
        • 19.1.5. All drives are up and running
        • 19.1.6. There are no hanging active requests
      • 19.2. Degraded state
        • 19.2.1. Degraded state due to service issues
        • 19.2.2. Degraded state due to host OS misconfiguration
        • 19.2.3. Degraded state due to network interface issues
        • 19.2.4. Drive/Controller issues
      • 19.3. Critical state
        • 19.3.1. API service failure
        • 19.3.2. Server service failure
        • 19.3.3. Client service failure
        • 19.3.4. Network interface or Switch failure
        • 19.3.5. Hard Drive/SSD failures
        • 19.3.6. Hanging requests in the cluster
  • API reference
  • StorPool Integrations
    • CloudStack
    • Kubernetes
      • 1. Introduction
      • 2. Comparison
      • 3. StorPool CSI
        • 3.1. Requirements
        • 3.2. Kubelet configuration
        • 3.3. Installation
      • 4. StorPool iSCSI CSI
        • 4.1. Requirements
        • 4.2. Installation
      • 5. Usage example
    • OnApp
      • OnApp integration
        • 1. Short Description
      • OnApp acceptance tests
        • 1. Installation
        • 2. Acceptance tests
          • 2.1. 1. Test that proper CPU and RAM are reported to OnApp for each hypervisor
          • 2.2. 2. Test creating a VPS
          • 2.3. 3. Test live migration between two nodes with StorPool
          • 2.4. 4. Test resizing a volume for a VPS
          • 2.5. 5. Test adding a volume as a drive for a VPS
          • 2.6. 6. Test shrinking a volume used as a drive for a VPS
          • 2.7. 7. Test backing up a VPS (only in cluster with available backup server configured with StorPool OnApp integration)
          • 2.8. 8. Test restoring a VPS from backup (only in cluster with available backup server configured with StorPool OnApp integration)
          • 2.9. 9. Test removing a volume configured for the VPS
          • 2.10. 10. Test undeploy/deletion of the VPS
      • OnApp LVM to LVMSP disk migration
        • 1. Limitations
        • 2. Preparation
        • 3. Data synchronization
        • 4. Finalizing
        • 5. RAID1 resync tuning
      • OnApp XEN to KVM disk migration
        • 1. Introduction
        • 2. Preparation steps
        • 3. Migration Case-1: Same disk structure (common for Windows and FreeBSD)
        • 4. Migration Case-2: XEN VM with raw disk, KVM with partition table (Linux)
          • 4.1. (1) Preparing the KVM disks
          • 4.2. (2) Migrating the data from the raw XEN disk to KVM disk with a partition
          • 4.3. (3) Finalizing the disk migration
        • 5. Optimization and tuning
          • 5.1. Raid1 resync tuning
        • 6. Addendum
      • OnApp KVM to KVM with virtio migration procedure
        • 1. Preparation
          • 1.1. Prepare OnApp’s DB
          • 1.2. Alter the VM’s content
          • 1.3. Update the VM’s metadata in the OnApp’s DB
          • 1.4. Finalize
      • Known Issues
        • 1. Unable to Delete VM - logical volume(s) not found
    • OpenNebula
      • OpenNebula Integration
      • Support Life Cycles for OpenNebula Environments
        • Fully-Managed OpenNebula Cloud (FMOC)
        • StorPool add-on for OpenNebula (add-on)
    • OpenStack
  • StorPool operations procedures
    • Adding a drive to a running cluster
      • 1. Drives stress tests
        • 1.1. How disk_tester works
        • 1.2. How to read the results
      • 2. Partition and init drive
        • 2.1. HDD on 3108 MegaRaid controller
          • 2.1.1. Locating the disk
          • 2.1.2. Prepare HDD
          • 2.1.3. Create Partitions
          • 2.1.4. Initialize the HDD
        • 2.2. SATA SSD drive
        • 2.3. NVMe drive
          • 2.3.1. Partitioning the NVMe
          • 2.3.2. Adjusting configuration
          • 2.3.3. Initializing the NVMe
          • 2.3.4. Adjusting hugepages
      • 3. Adjusting cgroups
      • 4. Restarting the required services (only for NVMe drives)
      • 5. Manually adding a drive initialized with –no-notify in the cluster
      • 6. Check disk is added to the cluster
      • 7. Adding drive to a placement group and balancing data
    • Add and Remove Node
      • 1. Add a Node
      • 2. Remove a Node from Cluster
    • Ejected disk
      • 1. Check if the drive is actually available.
      • 2. Check if this is a repeated event
      • 3. Check if the drive is causing delays for the cluster operations
      • 4. Return drive to the cluster
      • 5. Removal & re-balance out
        • 5.1. Collect information on the drive
          • 5.1.1. Location information
          • 5.1.2. Error information
        • 5.2. Forget and start balancing
          • 5.2.1. Remove drive from placement groups and from list in the cluster
          • 5.2.2. Make sure the drive is flagged as ejected:
          • 5.2.3. Clean up RAID VDs, if applicable
          • 5.2.4. Start locate function, if available
          • 5.2.5. Balance out the drive (restore redundancy)
        • 5.3. Notify customer on the event
        • 5.4. Monitor progress
        • 5.5. Notify customer that the rebalance is complete and the new drive is expected.
        • 5.6. After the drive is replaced, disable locator lights.
    • Stale backup volumes and snapshots cleanup procedure
      • 1. Introduction
      • 2. Volumes attached to nodes
      • 3. Volumes exported through iSCSI (Hypervisor nodes)
      • 4. Volumes held by the device mappper (Backup nodes)
    • Testing a StorPool drive
      • 1. Put node in maintenance
      • 2. Perform test
        • 2.1. Check disk’s server instance
        • 2.2. No single drives on server instances
        • 2.3. Single drive on server instance
      • 3. Validate result
        • 3.1. Disk comes back
        • 3.2. Disk doesn’t come back
  • Misc
    • Control Groups
      • 1. Kernel Control Groups and StorPool
        • 1.1. Overview
        • 1.2. Cgroups
        • 1.3. Cgexec
        • 1.4. Slices
        • 1.5. StorPool and Cgroups
          • 1.5.1. Memory configuration
          • 1.5.2. Cpuset configuration
        • 1.6. Cgconfig
      • 2. Using the cgtool to create Cgroups configurations for freshly installed machines
        • 2.1. Hypervisors
        • 2.2. Dedicated storage and Hyperconverged machines
          • 2.2.1. Dedicated storage machines
          • 2.2.2. Hyperconverged machines
      • 3. Using the cgtool to configure multiple similar machines
        • 3.1. Dumping a configuration
      • 4. Verifying machine cgroups state and configurations
        • 4.1. storpool_cg print
        • 4.2. storpool_cg check
        • 4.3. storpool_process
      • 5. Using the cgtool to update already configured machines
        • 5.1. Migrating to new-style configs
    • Xeon Scalable BIOS & OS Tuning
      • 1. Intro
      • 2. TLDR
      • 3. BIOS
      • 4. BIOS Walkthrough
      • 5. OS
      • 6. Rationale
    • Common monitoring via the StorPool API
      • 1. Introduction
      • 2. Internal elements
        • 2.1. Tasks
        • 2.2. Attachments
      • 3. Visible elements
        • 3.1. Networks
        • 3.2. Services
          • 3.2.1. Server
          • 3.2.2. Client
          • 3.2.3. Management
          • 3.2.4. iSCSI
          • 3.2.5. Bridge
          • 3.2.6. Disks
          • 3.2.7. Templates
          • 3.2.8. Volumes
        • 3.3. General cluster status
          • 3.3.1. Disks
          • 3.3.2. Networks
          • 3.3.3. Services
          • 3.3.4. Cluster services
    • Connecting a Windows Server 2016 host to StorPool iSCSI
      • 1. Short Overview of iSCSI
      • 2. How does iSCSI function in StorPool
      • 3. Configuring the StorPool iSCSI target
      • 4. Configuring a Windows Server 2016 host
        • 4.1. Reliability settings
        • 4.2. Basic network settings
        • 4.3. Basic connection to targets
        • 4.4. Configuring Multipath I/O (MPIO)
          • 4.4.1. Prerequisites for Multipath I/O (MPIO)
          • 4.4.2. Installation and connection to targets
    • Configuration of Linux Initiator for StorPool iSCSI
      • 1. Multipath
        • 1.1. Configure multipath
      • 2. iSCSI Initiator
        • 2.1. Set block device timeout
        • 2.2. Discover and connect to target
        • 2.3. Check multipath
        • 2.4. Verify timeouts
      • 3. Failover and recovery
    • Connecting a VMware ESXi host to StorPool iSCSI
      • 1. Short Overview of iSCSI
      • 2. How does iSCSI function in StorPool
      • 3. Configuring the StorPool iSCSI target
        • 3.1. Configuring a VMware ESXi host
        • 3.2. Optimizing Multipath Performance
        • 3.3. Configuring vSwitch
    • VolumeCare
      • 1. Overview
      • 2. General configuration
        • 2.1. [format] Section
        • 2.2. [volumecare] Section
      • 3. Retention policies
        • 3.1. Local
        • 3.2. basic (stopgap)
        • 3.3. exp
        • 3.4. keep-daily
        • 3.5. nosnap
          • 3.5.1. Remote
        • 3.6. basic-mirror (stopgap-mirror)
        • 3.7. basic-remote
        • 3.8. keep-daily-remote (stopgap-remote)
        • 3.9. keep-daily-split
        • 3.10. mhdm (minutes-hours-days-months)
        • 3.11. remote-backup
      • 4. Policy resolution
      • 5. storpool_vcctl
        • 5.1. config
        • 5.2. show
        • 5.3. list
        • 5.4. status
        • 5.5. revert
      • 6. Changing a policy
        • 6.1. Single-cluster
        • 6.2. Multiple clusters
      • 7. Example configurations
        • 7.1. Single-cluster
        • 7.2. Primary cluster
        • 7.3. Backup cluster
        • 7.4. Two clusters sending backups to each other
      • 8. VolumeCare Changelog
    • Revert OpenNebula volume from a snapshot
      • Common restore scenarios
      • Revert procedure steps
        • 1. Get the names of existing (i.e., not previously deleted) volumes related to a specific VM:
        • 2. Find all remote exported snapshots for a specific volume in the primary cluster:
        • 3. Transfer a remote snapshot locally:
        • 4. Monitor transfer progress:
        • 5. Undeploy the VM:
        • 6. Preserve the old volume:
        • 7. Delete the old volume:
        • 8. Create a new volume based on the snapshot:
        • 9. Create a snapshot copy in the backup cluster for preservation purposes:
    • BIOS configuration via OS tools
      • 1. Intro
      • 2. SuperMicro
        • 2.1. SR-IOV
        • 2.2. NUMA nodes on AMD EPYC2
      • 3. DELL
        • 3.1. SR-IOV
      • 4. HP
    • StorPool’s monitoring system alerts & description
      • 1. Introduction
      • 2. Cluster status alerts
        • 2.1. agscore-entries
        • 2.2. agscore-space
        • 2.3. attachments-count
        • 2.4. balancer
        • 2.5. bridge
        • 2.6. bridgestatus
        • 2.7. client
        • 2.8. clusteruptime
        • 2.9. controller
        • 2.10. dematerialization
        • 2.11. disbalance
        • 2.12. disk
        • 2.13. diskentries
        • 2.14. disk-missing-pg
        • 2.15. disk-journals
        • 2.16. disk-pending-errors
        • 2.17. disk-recoveries
        • 2.18. disk-softeject
        • 2.19. disk-test
        • 2.20. disk-to-test
        • 2.21. diskobjects
        • 2.22. disks
        • 2.23. disk-softeject
        • 2.24. diskspace
        • 2.25. features
        • 2.26. iscsi
        • 2.27. iscsi-backup
        • 2.28. iscsi-ctrlrs
        • 2.29. latthreshold-cli
        • 2.30. latthreshold-disk
        • 2.31. locations
        • 2.32. maintenances
        • 2.33. mgmt
        • 2.34. mgmtConfig
        • 2.35. monitoringdata
        • 2.36. needbalance
        • 2.37. network
        • 2.38. onapp-bkp-vol
        • 2.39. placementgroup-drives
        • 2.40. quorum
        • 2.41. reformat
        • 2.42. relocator
        • 2.43. server
        • 2.44. snapfromremote
        • 2.45. snaplen
        • 2.46. snaprepl
        • 2.47. snaptargets
        • 2.48. snaptmpl
        • 2.49. tasks
        • 2.50. template
        • 2.51. totalvolumes
        • 2.52. volumecare-local
        • 2.53. volumecare-policies
        • 2.54. volumecare-remote
        • 2.55. volumecare-svc
        • 2.56. volumerepl
        • 2.57. volumes
        • 2.58. volumesizes
        • 2.59. volumetargets
        • 2.60. volumetmpl
      • 3. Per-host alerts
        • 3.1. apichecks
        • 3.2. configfile
        • 3.3. configuration
        • 3.4. hw-ecc
        • 3.5. initiators-iscsi
        • 3.6. kernels
        • 3.7. lldp
        • 3.8. rootcgprocess
        • 3.9. portals-iscsi
        • 3.10. status
      • 4. Metrics-based alerts
        • 4.1. cgroups
        • 4.2. cpustat
        • 4.3. dataholes
        • 4.4. diskerrors
        • 4.5. io-latencies
        • 4.6. iolatmon
        • 4.7. service-latency
        • 4.8. service-load
        • 4.9. stats
        • 4.10. status
      • 5. Others
        • 5.1. billingdata
    • Data collected by the StorPool monitoring system
      • Overview
      • What data is collected
      • How the data is collected
      • How the data is sent
      • How the data is processed
    • Metrics collected and available from StorPool
      • 1. Overview
      • 2. Internals
        • 2.1. storpool_stat operations
        • 2.2. Data interpolation between s1 and m1 retention policies
        • 2.3. Disk usage and IO of InfluxDB databases
      • 3. Data structure
      • 4. Measurements reference
        • 4.1. bridgestatus
        • 4.2. cpustat
        • 4.3. disk
        • 4.4. diskiostat
        • 4.5. diskstat
        • 4.6. iostat
        • 4.7. iscsisession
        • 4.8. memstat
        • 4.9. netstat
        • 4.10. servicestat
        • 4.11. task
        • 4.12. template
    • StorPool analytics
      • 1. Overview
      • 2. Basics
      • 3. Example scenarios for use
        • 3.1. Single drive creating delays
        • 3.2. Balancing CPU usage on hypervisors
        • 3.3. Checking for CPU starvation for StorPool services
      • 4. Dashboards reference
        • 4.1. Home
        • 4.2. CPU
          • 4.2.1. CPU stat
          • 4.2.2. Per-CPU stat
          • 4.2.3. Per-service CPU stat
          • 4.2.4. Total CPU non-SP stat
          • 4.2.5. Total CPU stat
        • 4.3. Servers
          • 4.3.1. All server stat
          • 4.3.2. General server stat
          • 4.3.3. Per-disk backend stat
          • 4.3.4. Per-host backend stat
        • 4.4. Clients
          • 4.4.1. All client stat
          • 4.4.2. General client stat
          • 4.4.3. Per-host client stat
        • 4.5. Memory
          • 4.5.1. Cgroup memory
          • 4.5.2. Cgroup memory per node
        • 4.6. Volume
          • 4.6.1. Per-volume stat
          • 4.6.2. Top volumes
        • 4.7. Network
          • 4.7.1. Network service stat
        • 4.8. System disk
          • 4.8.1. SP disk stat
          • 4.8.2. System disk stat
        • 4.9. iSCSI
          • 4.9.1. iSCSI stats per initiator
          • 4.9.2. iSCSI stats per node/network
          • 4.9.3. iSCSI stats per target
          • 4.9.4. iSCSI totals per initiator
          • 4.9.5. iSCSI totals per initiator
        • 4.10. Template
          • 4.10.1. Template usage
          • 4.10.2. Template usage - internal
        • 4.11. Disk
          • 4.11.1. Disk usage
          • 4.11.2. Disk usage - internal
          • 4.11.3. Single disk usage - internal
        • 4.12. Custom
    • Enable TRIM/Discard Operations For KVM Based Clouds
      • Verify The Storage Solution
      • Virtualization Stack
      • Virtual Machine Type
      • Virtual Drives Discard
      • Guest Configuration
      • Hints
  • Changelogs
    • StorPool 21.0 Change Log
      • 21.0 revision 21.0.94.f7de41582
      • 21.0 revision 21.0.75.1e0880427
      • 20.0 revision 20.0.1095.734a81b7e
      • 20.0 revision 20.0.1032.aeda18feb
    • StorPool 20.0 Change Log
      • 20.0 revision 20.0.1095.734a81b7e
      • 20.0 revision 20.0.1032.aeda18feb
      • 20.0 revision 20.0.1005.c221f1691
      • 20.0 revision 20.0.987.e0aa2a0f7
      • 20.0 revision 20.0.953.b098a1c1a
      • 20.0 revision 20.0.920.e06a6829e
      • 20.0 revision 20.0.843.07f4dfc11
      • 20.0 revision 20.0.787.54d165f71
      • 20.0 revision 20.0.768.9d77ff11e
      • 20.0 revision 20.0.520.e3fc57b76
      • 20.0 revision 20.0.508.e2623b204
      • 20.0 revision 20.0.487.818a7cea4
      • 20.0 revision 20.0.473.ad8854a34
      • 20.0 revision 20.0.466.2a2e26fd9
      • 20.0 revision 20.0.441.61c5774c8
      • 20.0 revision 20.0.419.261c0e3b2
      • 20.0 revision 20.0.386.8ea42a7d8
      • 20.0 revision 20.0.372.4cd1679db
      • 20.0 revision 20.0.353.e5f7ee9c0
      • 20.0 revision 20.0.334.70c4fbda5
      • 20.0 revision 20.0.325.7d16d036f
      • 20.0 revision 20.0.276.b05695816
      • 20.0 revision 20.0.205.c5cbaeb49
      • 20.0 revision 20.0.202.79fc357c5
      • 20.0 revision 20.0.172.8ebac5311
      • 20.0 revision 20.0.93.78df908ec
      • 20.0 revision 20.0.38.c5178becb
      • 20.0 revision 20.0.19.1a208ffab
    • StorPool 19.4 Change Log
      • 19.4 revision 19.01.3152.2b7de29c0
      • 19.4 revision 19.01.3106.45589969c
      • 19.4 revision 19.01.3061.a03558598
      • 19.4 revision 19.01.3006.6d2a7fccf
      • 19.4 revision 19.01.2995.15aa353e8
      • 19.4 revision 19.01.2975.d4308b0d0
      • 19.4 revision 19.01.2930.57ca5627f
      • 19.4 revision 19.01.2894.c16b8c152
      • 19.4 revision 19.01.2888.26d18ba04
      • 19.4 revision 19.01.2878.075480123
      • 19.4 revision 19.01.2877.2ee379917
      • 19.4 revision 19.01.2795.61bf1bd1d
      • 19.4 revision 19.01.2794.6d8d69281
      • 19.4 revision 19.01.2778.3c99182fa
      • 19.4 revision 19.01.2741.1490a1793
      • 19.4 revision 19.01.2701.c2377e67a
      • 19.4 revision 19.01.2686.1f4cf6e1d
      • 19.4 revision 19.01.2646.0ec2ea57b
      • 19.4 revision 19.01.2627.d3811f42a
      • 19.4 revision 19.01.2624.ae6abe68f
      • 19.4 revision 19.01.2609.d51d58af3
    • StorPool 19.3 Change Log
      • 19.3 revision 19.01.2592.cf99471bd
      • 19.3 revision 19.01.2571.5eb9133c9
      • 19.3 revision 19.01.2562.7b73fb02d
      • 19.3 revision 19.01.2545.66f61a9cd
      • 19.3 revision 19.01.2539.30ba167e1
      • 19.3 revision 19.01.2465.6f77d00cd
      • 19.3 revision 19.01.2456.977787e12
      • 19.3 revision 19.01.2439.425b19e8d
      • 19.3 revision 19.01.2426.40f100363
      • 19.3 revision 19.01.2401.48d842f1d
      • 19.3 revision 19.01.2333.b24f05090
      • 19.3 revision 19.01.2321.a82720c45
      • 19.3 revision 19.01.2319.27c976e3e
      • 19.3 revision 19.01.2318.10e55fce0
      • 19.3 revision 19.01.2268.656ce3b10
      • 19.3 revision 19.01.2216.14df508f2
      • 19.3 revision 19.01.2199.8700d0744
    • StorPool 19.2 Change Log
      • 19.2 revision 19.01.2173.0ca29830b
      • 19.2 revision 19.01.2156.b87fc49d8
      • 19.2 revision 19.01.2137.71224a0ce
      • 19.2 revision 19.01.2120.40c434b67
      • 19.2 revision 19.01.2099.32074a501
      • 19.2 revision 19.01.2084.34da44f18
      • 19.2 revision 19.01.2068.b4804fe04
      • 19.2 revision 19.01.2016.c4bc17cda
      • 19.2 revision 19.01.2012.bc34dd830
      • 19.2 revision 19.01.1991.f5ec6de23
      • 19.2 revision 19.01.1957.1a9a9bb68
      • 19.2 revision 19.01.1949.1aea86986
      • 19.2 revision 19.01.1946.0b0b05206
      • 19.2 revision 19.01.1942.0464eda88
      • 19.2 revision 19.01.1907.2389092f3
      • 19.2 revision 19.01.1905.5a6c7e113
      • 19.2 revision 19.01.1879.4679753db
      • 19.2 revision 19.01.1816.16fa37c0d
      • 19.2 revision 19.01.1813.f4697d8c2
      • 19.2 revision 19.01.1795.5b374e835
      • 19.2 revision 19.01.1732.02297f62b
      • 19.2 revision 19.01.1720.8c71b2ec3
      • 19.2 revision 19.01.1689.6a0aa758b
      • 19.2 revision 19.01.1656.1d6d61d3f
    • StorPool 19.1 Change Log
      • 19.1 revision 19.01.1628.1b627d0
      • 19.1 revision 19.01.1548.00e5a5633
      • 19.1 revision 19.01.1511.0b533fb
      • 19.1 revision 19.01.1468.90a9873
      • 19.1 revision 19.01.1413.b807f92
      • 19.1 revision 19.01.1376.ce07826
      • 19.1 revision 19.01.1357.39c014c
      • 19.1 revision 19.01.1346.dd68fa2c6
      • 19.1 revision 19.01.1293.cfcb869
      • 19.1 revision 19.01.1217.1635af7
      • 19.1 revision 19.01.1108.02703b8c5
      • 19.1 revision 19.01.1025.0baac06a6
      • 19.1 revision 19.01.878.7b1f83e3d
      • 19.1 revision 19.01.759.024d1bd
      • 19.1 revision 19.01.742.47c6e9c
      • 19.1 revision 19.01.719.c40dd8c
      • 19.1 revision 19.01.544.39e62dbad
      • 19.1 revision 19.01.496.6d2c5bf83
      • 19.1 revision 19.01.385.fc63315ef
      • 19.1 revision 19.01.375.684a0da12
      • 19.1 revision 19.01.355.896c5ebaf
      • 19.1 revision 19.01.318.daa3c5938
      • 19.1 revision 19.01.301.f1b25e7
      • 19.1 revision 19.01.271.de5921845
      • 19.1 revision 19.01.212.66fed3091
      • 19.1 revision 19.01.199.b98e9d4
      • 19.1 revision 19.01.182.666093099
      • 18.02.1030.2e4eab8
      • 18.02.953.79d8ee7
      • 18.02.944.478cc9f
      • 18.02.886.f6b2fcf20
      • 18.02.847.b09fd4bec
      • 18.02.763.0aa70d7
      • 18.02.458.ac2f823
      • 18.02.370.2b8c3c3
      • 18.02.334.c204ed2
      • 18.02.206.06d240e
      • 18.02.178.9d29cd7
      • 18.02.164.7277e8c
  • Release Notes
    • StorPool Release Notes
      • Erasure Coding
      • storpool_qos
      • Highly available volumecare
        • Short description
        • Why it is needed
        • How it works
      • StorPool Log Daemon (storpool_logd)
        • Short description
        • Why it is needed
        • How it works
        • Typical use cases
      • HA Virtual Machine service (storpool_havm)
      • Network interface helper (net_helper)
      • In-server disk and journal performance tracking
        • Short description
        • Why it is needed
        • How it works
        • Typical use cases
      • Per GiB limits
      • Local and remote recovery overrides
      • Disk discovery and initialize helper
      • Persistent memory support
      • Meta V2 release
      • The storpool_ctl helper tool
      • Initiator addresses cache for storpool_stat
      • Remote bridge status
      • vfio-pci driver handling for NVMe devices
      • Auto-interface configuration
      • Volume overrides
      • In-server disk tester
      • Reuse server implicit on disk down
      • Maintenance mode
      • Active requests
      • Non-blocking NIC initialization
      • Creation/access of volumes based on global IDs
      • MultiCluster mode
  • StorPool FAQ
    • Common
      • 1. What is the upgrade policy and compatibility between versions?
      • 2. How to calculate the estimate usable disk space for a hybrid cluster?
      • 3. What is the current capacity, provisioned and available space in the cluster?
      • 4. What is the current thin provisioning gain of the cluster?
      • 5. How does StorPool handle writes?
      • 6. Why are there partitions on all SATA drives used by StorPool?
      • 7. Why the StorPool processes seem to be at 100% CPU usage all the time?
      • 8. What addresses uses StorPool for monitoring
      • 9. What is required when I add/change memory modules on a hypervisor?
    • Exceptions
      • 1. StorPool not working on vlan interface on I350 NIC
    • Onapp integration related
    • How much is the used and free space?
      • 1. How much is the current usage?
        • 1.1. Short answer
        • 1.2. Long answer
      • 2. How do we calculate the usage charge?
      • 3. How much space you can provision and how much data you can store on your cluster?
      • 4. Why there is space used in a new/empty cluster?
  • Known Issues
    • A software bug in OpenNebula 5.12 can cause data loss
Python
  • StorPool operations procedures

StorPool operations procedures

Contents:

  • Adding a drive to a running cluster
  • Add and Remove Node
  • Ejected disk
  • Stale backup volumes and snapshots cleanup procedure
  • Testing a StorPool drive

© Copyright 2012-, Visit our main site StorPool Storage <info@storpool.com>