QuantaStor Troubleshooting Guide - Revision history

Qadmin: /* Firewall configuration */

2020-07-29T17:10:59Z

Firewall configuration

← Older revision		Revision as of 17:10, 29 July 2020
Line 462:		Line 462:
	= Firewall configuration =		= Firewall configuration =

	For two QuantaStor systems to communicate in a grid you'll need to open up tcp ports 5151 an 5152. Without those open nodes cannot communicate with each other to exchange metadata. For replication of volumes and network shares between nodes you'll also need to open up port 22 but you've probably already opened that in order to get ssh access to the systems.		For two QuantaStor systems to communicate in a grid you'll need to open up tcp ports 5151 and 5152. Without those open nodes cannot communicate with each other to exchange metadata. For replication of volumes and network shares between nodes you'll also need to open up port 22 but you've probably already opened that in order to get ssh access to the systems.

	= Audit Logging =		= Audit Logging =

Qadmin: /* QuantaStor System ID changed */

2019-05-03T18:40:12Z

QuantaStor System ID changed

← Older revision		Revision as of 18:40, 3 May 2019
Line 415:		Line 415:
	= QuantaStor System ID changed =		= QuantaStor System ID changed =

	When a Storage System ID is changed on a QuantaStor due to a re-install of the OS or the use of the 'qs-util resetids' command, it will present out the Storage Volumes on it's Storage Pool with that new Storage System ID. This will cause some clients to believe it is a new Storage ~~appliance~~. When this happens, hypervisors like VMware will mark their Datastores with an all paths down state which will require some manual steps inside of VMware to re-import the datastore and any VM's stored on that datastore. Procedures vary across hypervisors, please consult the documentation for your specific hypervisor platform.		When a Storage System ID is changed on a QuantaStor due to a re-install of the OS or the use of the 'qs-util resetids' command, it will present out the Storage Volumes on it's Storage Pool with that new Storage System ID. This will cause some clients to believe it is a new Storage System. When this happens, hypervisors like VMware will mark their Datastores with an all paths down state which will require some manual steps inside of VMware to re-import the datastore and any VM's stored on that datastore. Procedures vary across hypervisors, please consult the documentation for your specific hypervisor platform.

	NOTE: If the re-installation was due to a bare metal upgrade from ISO media, you can use the 'Recovery Manager' in the web management interface to recover the old configuration database which is automatically backed up on all storage pools every hour. After recovering a prior database you will need to reboot the ~~appliance~~.		NOTE: If the re-installation was due to a bare metal upgrade from ISO media, you can use the 'Recovery Manager' in the web management interface to recover the old configuration database which is automatically backed up on all storage pools every hour. After recovering a prior database you will need to reboot the system.

	== Steps for re-importing your VMware DataStore ==		== Steps for re-importing your VMware DataStore ==

	The following sections will guide you through the process of re-importing a VMware datastore that has a different Storage Volume ID on it. This procedure is necessary if you're importing a remote-replica of a Storage Volume or you have reset the system IDs on ~~an appliance~~ such that VMware now no longer recognizes the storage volumes as the originals.		The following sections will guide you through the process of re-importing a VMware datastore that has a different Storage Volume ID on it. This procedure is necessary if you're importing a remote-replica of a Storage Volume or you have reset the system IDs on a system such that VMware now no longer recognizes the storage volumes as the originals.

	=== Import the VMware DataStore with a new Signature ===		=== Import the VMware DataStore with a new Signature ===

Qadmin: /* QuantaStor audit log */

2016-02-12T19:47:16Z

QuantaStor audit log

← Older revision		Revision as of 19:47, 12 February 2016
Line 464:		Line 464:
	For two QuantaStor systems to communicate in a grid you'll need to open up tcp ports 5151 an 5152. Without those open nodes cannot communicate with each other to exchange metadata. For replication of volumes and network shares between nodes you'll also need to open up port 22 but you've probably already opened that in order to get ssh access to the systems.		For two QuantaStor systems to communicate in a grid you'll need to open up tcp ports 5151 an 5152. Without those open nodes cannot communicate with each other to exchange metadata. For replication of volumes and network shares between nodes you'll also need to open up port 22 but you've probably already opened that in order to get ssh access to the systems.

	= ~~QuantaStor audit log~~ =		= Audit Logging =

	The QuantaStor management services audit logs are located at /var/log/qs_audit.log.		The QuantaStor management services audit logs are located at /var/log/qs_audit.log.

Qadmin: /* Librato Metrics Configuration Troubleshooting */

2016-02-12T19:40:07Z

Librato Metrics Configuration Troubleshooting

← Older revision		Revision as of 19:40, 12 February 2016
Line 147:		Line 147:

	WARNING: Make sure you do not run this script on the boot device or the wrong storage pool!		WARNING: Make sure you do not run this script on the boot device or the wrong storage pool!

	~~== Librato Metrics Configuration Troubleshooting ==~~

	If you've setup Librato metrics and are not seeing information show up in your Librato account the first thing to do is to verify your network settings. To do so you'll need to login to your QuantaStor appliance at the console or via SSH as qadmin. After you login run this command to see if you can ping the Google web site, currently the Metrics web site doesn't respond to ping:

	~~<code>~~
	~~ping www.google.com~~
	~~</code>~~

	~~If the ping is unsuccessful then the appliance has a bad gateway or DNS configuration. The next step would be to ping Google's DNS server like so:~~

	~~<code>~~
	~~ping 8.8.8.8~~
	~~</code>~~

	~~If the ping is successful then the appliance's gateway settings are good but the DNS settings are bad.~~
	~~If the ping is unsuccessful then the appliance's gateway settings are bad and the DNS may also be bad.~~
	~~For more information on setting the DNS settings for your system please see the Storage System Modify [http://wiki.osnexus.com/mediawiki/index.php/Storage_System_Modify_Dialog documentation here].~~

	~~Gateway settings are configured per network adapter and we recommend that you only configure the gateway on a single network interface.~~

	~~If both of those are working fine then please contact OSNEXUS (support@osnexus.com) or Librato support.~~

	== XenServer Troubleshooting ==		== XenServer Troubleshooting ==

Qadmin: /* Common Issues */

2016-02-12T19:38:57Z

Common Issues

@@ Line 126: / Line 126: @@
 We have seen some problems with these NICs with QuantaStor v2.x which uses the older 2.6 kernel.  If you're using a Solarflare NIC be sure to start with QuantaStor v3.x.
-== Common Issues ==
+== Common Pool Creation Issues ==
 === Created hardware unit but disks are not visible ===

Qadmin: /* QuantaGrid / Grid Formation Troubleshooting */

2016-02-12T19:37:48Z

QuantaGrid / Grid Formation Troubleshooting

← Older revision		Revision as of 19:37, 12 February 2016
Line 432:		Line 432:
	</pre>		</pre>

	= ~~QuantaGrid /~~ Grid Formation Troubleshooting =		= Grid Formation Troubleshooting =

	== Remote storage system and local system have the same storage systems IDs ==		== Remote storage system and local system have the same storage systems IDs ==

Qadmin: /* BTRFS Troubleshooting */

2016-02-12T19:37:32Z

BTRFS Troubleshooting

@@ Line 431: / Line 431: @@
 COMPLETED: Scan found '32' errors, repaired '0' blocks in 21504MB
 </pre>
 = QuantaGrid / Grid Formation Troubleshooting =

Qadmin: /* QuantaStor System ID changed */

2015-03-25T03:09:19Z

QuantaStor System ID changed

← Older revision		Revision as of 03:09, 25 March 2015
Line 491:		Line 491:
	= QuantaStor System ID changed =		= QuantaStor System ID changed =

	When a Storage System ID is changed on a QuantaStor due to a re-install of the OS or the use of the 'qs-util resetids' command, it will present out the Storage Volumes on it's Storage Pool with that new Storage System ID. This will cause some clients to believe it is a new Storage appliance. When this happens, hypervisors like VMware will mark their Datastores with an all paths down state which will require some manual steps inside of VMware to re-import the datastore and any VM's stored on that datastore. Procedures vary across hypervisors, please consult the documentation for your specific hypervisor platform ~~for storage import procedures~~.		When a Storage System ID is changed on a QuantaStor due to a re-install of the OS or the use of the 'qs-util resetids' command, it will present out the Storage Volumes on it's Storage Pool with that new Storage System ID. This will cause some clients to believe it is a new Storage appliance. When this happens, hypervisors like VMware will mark their Datastores with an all paths down state which will require some manual steps inside of VMware to re-import the datastore and any VM's stored on that datastore. Procedures vary across hypervisors, please consult the documentation for your specific hypervisor platform.

	NOTE: If the re-installation was due to a bare metal upgrade from ISO media, you can use the 'Recovery Manager' in the web management interface to recover the old configuration database which is automatically backed up on all storage pools every hour. After recovering a prior database you will need to reboot the appliance.		NOTE: If the re-installation was due to a bare metal upgrade from ISO media, you can use the 'Recovery Manager' in the web management interface to recover the old configuration database which is automatically backed up on all storage pools every hour. After recovering a prior database you will need to reboot the appliance.

Qadmin: /* QuantaStor System ID changed */

2015-03-25T03:08:51Z

QuantaStor System ID changed

← Older revision		Revision as of 03:08, 25 March 2015
Line 491:		Line 491:
	= QuantaStor System ID changed =		= QuantaStor System ID changed =

	When a Storage System ID is changed on a QuantaStor due to a re-install of the OS or the use of the 'qs-util resetids' command, it will present out the Storage Volumes on it's Storage Pool with that new Storage System ID. This will cause some clients to believe it is a new Storage appliance. ~~This can cause some clients~~, ~~such as~~ VMware~~, to~~ mark ~~the Datastore~~ with an all paths down state~~, requiring~~ manual steps inside of VMware to re-import the datastore and any VM's stored on that datastore. ~~We have documented~~ the ~~steps below~~ for ~~re-importing a datastore in VMware 5.5~~.		When a Storage System ID is changed on a QuantaStor due to a re-install of the OS or the use of the 'qs-util resetids' command, it will present out the Storage Volumes on it's Storage Pool with that new Storage System ID. This will cause some clients to believe it is a new Storage appliance. When this happens, hypervisors like VMware will mark their Datastores with an all paths down state which will require some manual steps inside of VMware to re-import the datastore and any VM's stored on that datastore. Procedures vary across hypervisors, please consult the documentation for your specific hypervisor platform for storage import procedures.
	NOTE: If the re-installation was due to a bare metal upgrade from ISO media, you can use the 'Recovery Manager' in the web management interface to recover the old configuration database which is automatically backed up on all storage pools every hour. After recovering a prior database you will need to reboot the appliance.		NOTE: If the re-installation was due to a bare metal upgrade from ISO media, you can use the 'Recovery Manager' in the web management interface to recover the old configuration database which is automatically backed up on all storage pools every hour. After recovering a prior database you will need to reboot the appliance.

Qadmin: /* QuantaStor System ID changed */

2015-03-25T03:06:08Z

QuantaStor System ID changed

← Older revision		Revision as of 03:06, 25 March 2015
Line 494:		Line 494:
	NOTE: If the re-installation was due to a bare metal upgrade from ISO media, you can use the 'Recovery Manager' in the web management interface to recover the old configuration database which is automatically backed up on all storage pools every hour. After recovering a prior database you will need to reboot the appliance.		NOTE: If the re-installation was due to a bare metal upgrade from ISO media, you can use the 'Recovery Manager' in the web management interface to recover the old configuration database which is automatically backed up on all storage pools every hour. After recovering a prior database you will need to reboot the appliance.

	== ~~Import the~~ VMware DataStore ~~with a new Signature~~ ==		== Steps for re-importing your VMware DataStore ==

	Use the Add Storage Wizard in the Storage section of VMware vSphere to add the LUN and DataStore back into VMware ~~with~~ with a new Signature. The key steps in the Add Storage Wizard is detailed in the below screenshots.		The following sections will guide you through the process of re-importing a VMware datastore that has a different Storage Volume ID on it. This procedure is necessary if you're importing a remote-replica of a Storage Volume or you have reset the system IDs on an appliance such that VMware now no longer recognizes the storage volumes as the originals.

			=== Import the VMware DataStore with a new Signature ===

			Use the Add Storage Wizard in the Storage section of VMware vSphere to add the LUN and DataStore back into VMware with a new Signature. The key steps in the Add Storage Wizard is detailed in the below screenshots.

	[[File:Vmware_Import_Datastore.png\|750px]]		[[File:Vmware_Import_Datastore.png\|750px]]
Line 506:		Line 510:
	[[File:Vmware_Import_Datastore_Finish.png\|750px]]		[[File:Vmware_Import_Datastore_Finish.png\|750px]]

	== Remove inaccessible VM's and rename the Datastore back to it's original name ==		=== Remove inaccessible VM's and rename the Datastore back to it's original name ===

	To be able to rename the Datastore back to it's original name, you will need to remove any inaccessible VM's from inventory that referenced the original datastore name. e.g. in the screenshot below, there are VM's listed as inaccessible that referenced the original datastore.		To be able to rename the Datastore back to it's original name, you will need to remove any inaccessible VM's from inventory that referenced the original datastore name. e.g. in the screenshot below, there are VM's listed as inaccessible that referenced the original datastore.
Line 521:		Line 525:
	[[File:Vmware_Import_Rename_datastore-2.png\|700px]]		[[File:Vmware_Import_Rename_datastore-2.png\|700px]]

	== Browse Datastore and re-import VM's ==		=== Browse Datastore and re-import VM's ===

	Now that the Datastore is available, you can browse the Datastore and add all of the VM's back to the VMware inventory with the 'Add to Inventory' option. You will need to ensure that when powering the VM's up, that you tell VMware that they were 'Moved'. This is detailed in further detail in the screenshots below.		Now that the Datastore is available, you can browse the Datastore and add all of the VM's back to the VMware inventory with the 'Add to Inventory' option. You will need to ensure that when powering the VM's up, that you tell VMware that they were 'Moved'. This is detailed in further detail in the screenshots below.