How to manually send AutoSupport messages to NetApp

Description

One of NetApp’s AutoSupport best practices is to enable the storage system to automatically generate and transmit AutoSupport messages to NetApp using the integrated functionality in Data ONTAP. By enabling AutoSupport automatically, NetApp can provide proactive support through My AutoSupport, and reactive support through the NetApp Support Center. The My AutoSupport tool allows users to administer and support their NetApp storage systems with tools such as an AutoSupport data viewer, device visualizer, storage efficiency and health check reports, and Data ONTAP upgrade plan generator.

For a small number of users, it might not be possible for AutoSupport messages to be sent automatically due to network connectivity limitations. However, the AutoSupport data might be required for Technical Support to efficiently troubleshoot a system failure. In these cases, the AutoSupport data will have to be collected manually. In Data ONTAP 7.x and earlier, a majority of the AutoSupport data was formatted as plain text. However, in Data ONTAP 8.0 and later, AutoSupport data is increasingly being generated in the XML format, which requires an XML viewer to read the data. The switch to XML was done to minimize the size of AutoSupport messages. Additionally, in Data ONTAP 8.0.1 and later, the attachments are encoded in a MIME format when stored in the storage system’s /etc/log/autosupport directory.

Some support engineers might find it advantageous for the user to manually send AutoSupport data in a way that would allow the NetApp systems such as My AutoSupport or the NetApp SmartSolve Tools Portal to display this data. This article contains the steps to provide AutoSupport as a file upload or in a manner that enables the data to be visible in My AutoSupport.

For more information on enabling AutoSupport, see the AutoSupport section on the NetApp Support site.

How to Network Boot (Netboot) a LOADER / CFE based filer in Data ONTAP 7G

KB ID: 1012003 Version: 13.0 Published date: 03/02/2015 Views: 14837

Description

Currently, netbooting a kernel image over the network by the TFTP and HTTP protocol is supported by platforms using LOADER (FAS2000 series, FAS3040/FAS3070, FAS3200, FAS6000 and FAS8000 series) or Common Firmware Environment (FAS200 series and FAS3020/FAS3050). To configure an existing controller to provide the TFTP and HTTP services for netbooting, the steps are described below:

Procedure

For setting up TFTP services for netbooting:

Log in to a controller that is up and running Data ONTAP.

On the controller, type the following:filer> options tftpd.enable on

Create the /etc/tftpboot directory if one does not exist. This is the default root directory where the netboot kernel, for example netapp-mips, should be placed. Check with ‘options tftpd.rootdir‘ whether the tftp root dir reflects the directory above.

Place the netboot kernel image into this directory (/etc/tftpboot or whatever the tftp root dir is set to)Note: Obtain the file from the Data ONTAP software download (http://mysupport.netapp.com/NOW/cgi-bin/software) page (obtain the one for the right platform)

Setting up HTTP services for netbooting:

Log in to a controller that is running Data ONTAP.

Place the netboot kernel, for example netapp-mips, into the /etc/http directory. By default, this directory serves HTTP requests to service management (ZAPI) requests to the controller.

For TFTP netbooting using the default rootdir:LOADER> netboot tftp://Filer/netapp-mips

CFE supports booting from a CompactFlash device or from the network using TFTP or HTTP protocols. For a brand new CompactFlash Card, there is no Data ONTAP image, therefore, it must boot from network (netboot). The netboot network configuration does not persist while rebooting.

Important Note:It might take some time before the network connection is established. To check the status, use the ifconfig command to check the link status. Try a ping to the http server first, since loading the kernel image takes a long time to abort.

Provide all the network parameters, that is gateway and DNS, even if they are not needed, it helps to establish the connection faster.

Note: Use the netboot file when downloading and installing Data ONTAP.

Disclaimer

NetApp provides no representations or warranties regarding the accuracy, reliability, or serviceability of any information or recommendations provided in this publication, or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS, and the use of this information or the implementation of any recommendations or techniques herein is a customer’s responsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.

How to move an aggregate between software disk-owned HA pairs.

Description

This article explains, how move an aggregate from one controller in a HA pair to its partner in a software disk owned system. This procedure only applies to 7-mode systems.

Procedure

For reference: FILER1 owns the disk initially. FILER2 is where the disks/volume are being moved to.

WARNING:
Before starting this procedure, confirm that there are no aggregates or FlexVols on FILER2 that have the same name as the original aggregate/FlexVols or traditional volume being moved. Failure to do so will result in the relocated volume(s) with conflicting names being appended with a (1) instead of the original name.

Note:
This procedure is only supported under the following conditions:

Disks do not get moved, ownership remains of either node in HA pair.

If disks are moved outside the HA pair, shelf MUST NOT be moved.

It could be misunderstood to move disk/shelf to another filer using similar procedure. If the shelf needs to be moved outside of the HA pair, downtime is required.

WARNING:
The node on which the disk assign is done must be the node that is giving away the aggregate.

FILER1> disk assign 0a.16 0a.17 0a.18 0a.19 -o FILER2 -f

(-f must be used since the disks are already owned)

Verify that no further disks belonging to the original aggregate are left on the original node.

FILER1>aggr status -r <original-volname>

Online the relocated aggregate from FILER2:

FILER2> aggr online <test>

Note:
It will be necessary to reconfigure any Common Internet File System Protocol (CIFS) shares,Network File System (NFS) exports or configure the appropriate igroups on the partner for the relocated volume(s) before clients can access this data.

NetApp provides no representations or warranties regarding the accuracy, reliability, or serviceability of any information or recommendations provided in this publication, or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS, and the use of this information or the implementation of any recommendations or techniques herein is a customer’s responsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.