You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You can use the {operator-name} to check a cluster that you deployed on {vmw-full} for common installation and misconfiguration issues that relate to storage.
The {operator-name} checks clusters that are deployed on vSphere for common installation and misconfiguration issues that are related to storage.
9
+
The {operator-name} checks a cluster that you deployed on {vmw-full} for common installation and configuration issues that relate to storage.
12
10
13
-
The Operator runs in the `openshift-cluster-storage-operator` namespace and is started by the Cluster Storage Operator when the Cluster Storage Operator detects that the cluster is deployed on vSphere. The {operator-name} communicates with the vSphere vCenter Server to determine the virtual machines in the cluster, the default datastore, and other information about the vSphere vCenter Server configuration. The Operator uses the credentials from the Cloud Credential Operator to connect to vSphere.
11
+
After the Cluster Storage Operator starts and determines that a cluster runs on {vmw-full}, the Cluster Storage Operator launches the {operator-name}. When the {operator-name} starts, the Operator immediately runs the checks. The {operator-name} communicates with the {vmw-short} vCenter Server to find the virtual machines in the cluster, the default datastore, and other information about the {vmw-short} vCenter Server configuration. The Operator uses the credentials from the Cloud Credential Operator to connect to {vmw-short}.
14
12
15
13
The Operator runs the checks according to the following schedule:
16
14
@@ -20,7 +18,5 @@ The Operator runs the checks according to the following schedule:
20
18
21
19
* When all checks pass, the schedule returns to an hour interval.
22
20
23
-
The Operator increases the frequency of the checks after a failure so that the Operator can report success quickly after the failure condition is remedied. You can run the Operator manually for immediate troubleshooting information.
21
+
After a failure, the Operator increases its check frequency to quickly report success when the failure condition gets resolved. You can run the Operator manually for immediate troubleshooting information.
@@ -16,33 +15,33 @@ The following tables identify the configuration checks that the {operator-name}
16
15
|Description
17
16
18
17
|`CheckDefaultDatastore`
19
-
|Verifies that the default datastore name in the vSphere configuration is short enough for use with dynamic provisioning.
18
+
|Verifies that the default datastore name in the {vmw-full} configuration is short enough for use with dynamic provisioning.
20
19
21
20
If this check fails, you can expect the following:
22
21
23
22
* `systemd` logs errors to the journal such as `Failed to set up mount unit: Invalid argument`.
24
23
25
-
* `systemd` does not unmount volumes if the virtual machine is shut down or rebooted without draining all the pods from the node.
24
+
* `systemd` does not unmount volumes if the virtual machine shuts down or reboots without draining all the pods from the node.
26
25
27
-
If this check fails, reconfigure vSphere with a shorter name for the default datastore.
26
+
If this check fails, reconfigure {vmw-short} with a shorter name for the default datastore.
28
27
29
28
|`CheckFolderPermissions`
30
-
|Verifies the permission to list volumes in the default datastore. This permission is required to create volumes. The Operator verifies the permission by listing the `/` and `/kubevols` directories. The root directory must exist. It is acceptable if the `/kubevols` directory does not exist when the check runs. The `/kubevols` directory is created when the datastore is used with dynamic provisioning if the directory does not already exist.
29
+
|Verifies the permission to list volumes in the default datastore. You must enable the permission to create volumes. The Operator verifies the permission by listing the `/` and `/kubevols` directories. When the Operator performs the check, the root directory must exist. The `/kubevols` directory might not exist at the time of the check. The creation of the `/kubevols` directory occurs when the datastore supports dynamic provisioning.
31
30
32
-
If this check fails, review the required permissions for the vCenter account that was specified during the {product-title} installation.
31
+
If this check fails, review the required permissions for the vCenter account that you specified during the {product-title} installation.
33
32
34
33
|`CheckStorageClasses`
35
34
|Verifies the following:
36
35
37
-
* The fully qualified path to each persistent volume that is provisioned by this storage class is less than 255 characters.
36
+
* The fully qualified path to each persistent volume that the storage class provisions does not go lower than 255 characters.
38
37
39
-
* If a storage class uses a storage policy, the storage class must use one policy only and that policy must be defined.
38
+
* The storage class can use only one storage policy and the policy must be defined.
40
39
41
40
|`CheckTaskPermissions`
42
41
|Verifies the permission to list recent tasks and datastores.
43
42
44
43
|`ClusterInfo`
45
-
|Collects the cluster version and UUID from vSphere vCenter.
44
+
|Collects the cluster version and UUID from {vmw-short} vCenter.
46
45
|===
47
46
48
47
.Node configuration checks
@@ -52,19 +51,19 @@ If this check fails, review the required permissions for the vCenter account tha
52
51
|Description
53
52
54
53
|`CheckNodeDiskUUID`
55
-
|Verifies that all the vSphere virtual machines are configured with `disk.enableUUID=TRUE`.
54
+
|Verifies that all the {vmw-short} virtual machines include the `disk.enableUUID=TRUE` configuration.
56
55
57
-
If this check fails, see the link:https://access.redhat.com/solutions/4606201[How to check 'disk.EnableUUID' parameter from VM in vSphere] Red Hat Knowledgebase solution.
56
+
If this check fails, see the link:https://access.redhat.com/solutions/4606201[How to check `disk.EnableUUID` parameter from VM in vSphere] Red Hat Knowledgebase solution.
58
57
59
58
|`CheckNodeProviderID`
60
-
|Verifies that all nodes are configured with the `ProviderID` from vSphere vCenter. This check fails when the output from the following command does not include a provider ID for each node.
59
+
|Verifies that all nodes have the `ProviderID`configuration from {vmw-short} vCenter. This check fails when the output from the following command does not include a provider ID for each node.
61
60
62
61
[source,terminal]
63
62
----
64
63
$ oc get nodes -o custom-columns=NAME:.metadata.name,PROVIDER_ID:.spec.providerID,UUID:.status.nodeInfo.systemUUID
65
64
----
66
65
67
-
If this check fails, refer to the vSphere product documentation for information about setting the provider ID for each node in the cluster.
66
+
If this check fails, reference the {vmw-short} product documentation on how to set the provider ID for each node in the cluster.
68
67
69
68
|`CollectNodeESXiVersion`
70
69
|Reports the version of the ESXi hosts that run nodes.
@@ -73,5 +72,3 @@ If this check fails, refer to the vSphere product documentation for information
73
72
|Reports the virtual machine hardware version for a node.
@@ -21,20 +20,18 @@ The {operator-name} exposes the following metrics for use by the {product-title}
21
20
|Number of failed cluster-level checks that the {operator-name} performed. For example, a value of `1` indicates that one cluster-level check failed.
22
21
23
22
|`vsphere_esxi_version_total`
24
-
|Number of ESXi hosts with a specific version. Be aware that if a host runs more than one node, the host is counted only once.
23
+
|Counts the number of ESXi hosts with a specific version. Note that if a host runs more than one node, the {operator-name} counts the host only once.
25
24
26
25
|`vsphere_node_check_total`
27
26
|Cumulative number of node-level checks that the {operator-name} performed. This count includes both successes and failures.
28
27
29
28
|`vsphere_node_check_errors`
30
-
|Number of failed node-level checks that the {operator-name} performed. For example, a value of `1` indicates that one node-level check failed.
29
+
|Counts the number of failed node-level checks that the {operator-name} performed. For example, a value of `1` indicates that one node-level check failed.
31
30
32
31
|`vsphere_node_hw_version_total`
33
-
|Number of vSphere nodes with a specific hardware version.
32
+
|Number of {vmw-short} nodes with a specific hardware version.
34
33
35
34
|`vsphere_vcenter_info`
36
-
|Information about the vSphere vCenter Server.
35
+
|Information about the {vmw-short} vCenter Server.
You can override the schedule for running the {operator-name} checks and run the checks immediately.
12
10
13
-
The {operator-name} automatically runs the checks every hour. However, when the Operator starts, it runs the checks immediately. The Operator is started by the Cluster Storage Operator when the Cluster Storage Operator starts and determines that the cluster is running on vSphere. To run the checks immediately, you can scale the {operator-name} to `0` and back to `1` so that it restarts the {operator-name}.
11
+
The {operator-name} automatically runs the checks every hour. After the Operator starts, the Operator runs the checks immediately. After the Cluster Storage Operator starts and determines that a cluster runs on {vmw-full}, the Cluster Storage Operator starts the {operator-name}. To run the checks immediately, you can scale the {operator-name} to `0` and back to `1` so that the Cluster Storage Operator restarts the {operator-name}.
The names for persistent volumes that use vSphere storage are related to the datastore name and cluster ID.
12
-
13
-
When a persistent volume is created, `systemd` creates a mount unit for the persistent volume. The `systemd` process has a 255 character limit for the length of the fully qualified path to the VDMK file that is used for the persistent volume.
9
+
The datastore name and cluster ID relate to the names for persistent volumes that use {vmw-full} storage. After the creation of a persistent volume, `systemd` creates a mount unit for the persistent volume.
14
10
15
-
The fully qualified path is based on the naming conventions for `systemd` and vSphere. The naming conventions use the following pattern:
11
+
The `systemd` process has a 255 character limit for the length of the fully qualified path to the virtual machine disk (VMDK) file. This path follows the naming conventions for `systemd` and {vmw-short}. The naming conventions use the following example pattern:
16
12
17
13
[source,text]
18
14
----
@@ -21,11 +17,8 @@ The fully qualified path is based on the naming conventions for `systemd` and vS
21
17
22
18
* The naming conventions require 205 characters of the 255 character limit.
23
19
24
-
* The datastore name and the cluster ID are determined from the deployment.
25
-
26
-
* The datastore name and cluster ID are substituted into the preceding pattern. Then the path is processed with the `systemd-escape` command to escape special characters. For example, a hyphen character uses four characters after it is escaped. The escaped value is `\x2d`.
20
+
* The depolyment determines the datastore name and the cluster ID.
27
21
28
-
* After processing with `systemd-escape` to ensure that `systemd` can access the fully qualified path to the VDMK file, the length of the path must be less than 255 characters.
22
+
* The datastore name and cluster ID substitute into the example pattern. The fully qualified path gets processed with the `systemd-escape` command to escape special characters. For example, after the escape operation, a hyphen character uses four characters, such as `\x2d`.
29
23
30
-
// Clear temporary attributes
31
-
:!operator-name:
24
+
* After the `systemd-escape` CLI processes the VMDK file path, the length of the path must not be lower than 255 characters. This criteria ensures that the `systemd` process can access the fully qualified VMDK file path.
After the {operator-name} runs and performs the configuration checks, it creates events that can be viewed from the command line or from the {product-title} web console.
9
+
After the {operator-name} runs and performs the configuration checks, the Operator creates events that you can view from the command-line interface (CLI) or from the {product-title} web console.
10
+
11
+
.Prerequisites
12
+
13
+
* The {operator-name} ran checks on your cluster.
12
14
13
15
.Procedure
14
16
15
-
* To view the events by using the command line, run the following command:
17
+
* To view the events by using the CLI, run the following command:
* To view the events by using the {product-title} web console, navigate to *Home*->*Events* and select `openshift-cluster-storage-operator` from the *Project* menu.
After the {operator-name} runs and performs the configuration checks, it creates log records that can be viewed from the command line or from the {product-title} web console.
9
+
After the {operator-name} runs and performs the configuration checks, the Operator creates log records that you can view from the command-line interface (CLI) or from the {product-title} web console. Log lines that indicate `passed` means that you do not need to perform any actions.
10
+
11
+
The ideal output for a log line indicates `passed` or `0 problems`. If a log line indicates `failure` or 1 or more problems, see the information in the "Configuration checks run by the {operator-name}" document.
12
+
13
+
.Prerequisites
14
+
15
+
* The {operator-name} ran checks on your cluster.
12
16
13
17
.Procedure
14
18
15
-
* To view the logs by using the command line, run the following command:
19
+
* To view the logs by using the CLI, run the following command. A log line that shows `passed` in the output means that you must analyze the log output and resolve the issue.
16
20
+
17
21
[source,terminal]
18
22
----
@@ -32,14 +36,12 @@ I0108 08:32:28.480685 1 operator.go:271] CheckNodeProviderID:<host_name> p
32
36
----
33
37
34
38
* To view the Operator logs with the {product-title} web console, perform the following steps:
35
-
39
+
+
36
40
.. Navigate to *Workloads*->*Pods*.
37
-
41
+
+
38
42
.. Select `openshift-cluster-storage-operator` from the *Projects* menu.
39
-
43
+
+
40
44
.. Click the link for the `vsphere-problem-detector-operator` pod.
41
-
45
+
+
42
46
.. Click the *Logs* tab on the *Pod details* page to view the logs.
0 commit comments