Maintenance, Troubleshooting & Support

Initiator NQN Identifier

KumoScale software supports ACLs. When the initiator discovers or logs into a target, the initiator must provide its host NQN identifier. The default NQN is read from the /etc/nvme/hostnqn file located on the initiator server, unless otherwise specified.

Users can either use the script provided by KIOXIA or manually perform the following steps, as shown.

To create the default host NQN identifier, use the command sequence below:

  • Create a new folder titled /etc/nvme/ on the initiator server.
  • Use the nvme command to create and populate file hostnqn with the host NQN:
nvme gen-hostnqn>>/etc/nvme/hostnqn
  • The created host NQN can be viewed and used by the command:
cat /etc/nvme/hostnqn

Use this NQN identifier to set the initiator of a target within KumoScale software.

 An initiator name (NQN) cannot be modified once it is set .

KumoScale Field Types

The following table describes input field types for KumoScale parameters.

Field Type

Specification

Name

Up to 16 characters: Alphanumeric, ‘_’ and ‘-‘ and must begin with a letter

Portal port

1024-65535

Rebooting a Storage Node

Storage nodes may be rebooted via the REST API reboot command. See the REST API guide for details on how to successfully reboot nodes.

Restore Factory Default Settings when using Appliance Mode

 All KumoScale software configurations are lost and data becomes unavailable after this process .

 Administrators must re-install licenses if they simultaneously reset to factory defaults for all KumoScale storage nodes .

When using Appliance mode, all user configurations and logs may be reset to factory settings using the CLI command reset-factory. The data on the SSDs will become inaccessible due to the loss of the volume mapping and initiator configuration.

It is recommended that KumoScale software be removed from the KumoScale Provisioner service prior to the restore operation. If it is not, administrators will have to remove the KumoScale software storage node (after it was restored and configured) and add it again.

Generating Log Files

Administrators may generate and collect KumoScale log files remotely via the REST API.

Currently Running Tasks

Administrators may read the status and properties of user-triggered tasks in KumoScale software using the show-tasks command. Ongoing tasks are aborted using the stop-task or remove-task functions.

Locating an SSD

You can locate an SSD by setting a blinking LED on an SSD slot with locate-ssd.

Troubleshooting

Storage Node is Created but not Available

If a storage node is created but is not available, it usually means that the user has provided a KumoScale software secret but does not have a valid license. You will not be able to resolve the problem by applying changes or deleting the node. You will need to contact KumoScale Technical Support to assist you in resolving this issue.

Adding a Second Master in Appliance Mode

When using KumoScale in appliance mode, if you add a second storage node as a master to the cluster and execute the kubectl describe command, you may get the message “Cannot add a master while there are not enough masters pending”. Since the number of master node needs be an odd number, the master will stay in pending state, until a third storage node is added.

KumoScale Provisioner Service Log Collection

To collect logs on provisioning into the file provisioner.log issue the following commands:

To return the name of the KumoScale Provisioner service, use either:

get services -A | grep provisioner

or

kubectl get provisionerservices.provisioner.kumoscale.kioxia.com

Then to collect provisioning data from <ks_prov_pod_name>, the service returned above, enter:

kubectl logs -n kumo-services <ks_prov_pod_name> ks-provisioner > provisioner.log

For example, to collect KumoScale Provisioner service logs for the ks-provisioner-deployment-84bcbbbf77-gshdh pod, use:

kubectl logs -n kumo-services ks-provisioner-deployment-84bcbbbf77-gshdh ks-provisioner > provisioner.log

Paging in Commands with Large Output

KumoScale software supports up to 16K volumes and 1K targets per system. This may result in a very large number of items in the KumoScale commands output, which may cause very slow analysis.

KumoScale software provides several options to overcome this problem via the REST API:

  • Filtering – Several Get commands enable filtering the result by using input parameters, thus returning only the required information.
  • Paging – Users may enter the maximum number of items for the response, together with the ID of the last item received, thus reading the response in measured quantities.

 

Next: KumoScale v. 3.20 documentation