VPLEX Change Control Process (CCA)

Version 1.2

May 7, 2015

Author: Scott Hill

Major Contributors: John Colburn, Martin Bowesman, David Bacon, Brian McGovern and Mike
Neiser

Email Feedback to: VPLEXCCA

VPLEX Change Control Process (CCA) EMC Confidential

Revision History

Version Authors Description Date

1.1.16 Scott Hill Added Revision History table 10/14/2014

1.1.17 Scott Hill Added two additional cli command 10/28/2014

1] to list any monitors setup or used on a
VPLEX
2] to check the if snmp is configured on
the VPLEX
1.1.18 David Bacon Corrected issues with embedded 11/03/2014
cca_commands.txt file.
Change text to reflect importance of using
the embedded file as the sole source for
running commands.
Added “appendix A” listing out the
contents of the cca_commands.txt file for
those that want to have those commands
listed inside of the word document.
Updated TOC to have a pointer to the
cca_comands.txt file
1.1.18b David Bacon Corrected issue in cca_commands.txt file 11/10/14
that caused ndu pre-check--verbose to be
malformed. Also provided detail about
importance of having lun0 in each storage
view.

1.1.18c David Bacon Adding in cca_commands.txt check for 11/14/2014

engine type.
1.1.18d Mike Neiser Added in LUN 0 and NPIV info 12/22/2014

1.1.18e David Bacon Fixed cca_commands.txt corruption 02/24/2015

1.2 Mike Neiser CCA5 submission examples; Large CD file 05/07/2015

handling; Engine add guidelines; LUN 0
clarifications and table update;
Simultaneous log collection warning on
Metro/Geo configs; Dark site CCAs; Pre-
check issues & Support; Emergency CCA
process

EMC Confidential Page 1 of 20 Version 1.2

Table of Contents
Requirements for a VPLEX Change Control Process for a CCA ........................................................ 3
Purpose of the CCA...................................................................................................................... 3
!!Policy for CCA submission!! ...................................................................................................... 3
CCA Expiry Period ........................................................................................................................ 3
Configuration changes/upgrades that require a CCA today ....................................................... 3
GeoSynchrony Code upgrade Planning ........................................................................................... 5
Requirements for CCA submission: ............................................................................................. 5
VPLEX CCA Process Step-by-step ..................................................................................................... 7
CCA COMMANDS ........................................................................................................................... 10
File Handling Instructions .............................................................................................................. 11
Note about Putty Logging:......................................................................................................... 11
Note about the “collect-diagnostic --noextended” output tar file ........................................... 11
File Splitting Large Diagnostics Files .......................................................................................... 11
Note about Customer SAN Switch Data Required (Switch_data.txt) ........................................ 12
Note about data collection file naming scheme (C1_XXXX.log and C2_YYYY.log) .................... 13
CCA Requirements for other VPLEX change activity types............................................................ 14
Convert Cluster Topology (Local to Metro or Local to Geo) ................................................. 14
Upgrade Cluster Hardware (VS1 to VS2) ............................................................................... 14
Upgrade Engine Count........................................................................................................... 14
Relocation of a VPLEX, part or whole .................................................................................... 14
Installation of a VPLEX ........................................................................................................... 14
Dark Site support ....................................................................................................................... 15
Use of the Remote Change Management (RCM) team for code upgrades .................................. 15
RCM Notes: ................................................................................................................................ 15
Reasons a CCA can be rejected ..................................................................................................... 16
Requirements for an Emergency CCA ........................................................................................... 17
What does not constitute an emergency CCA .......................................................................... 17
Appendix A: ................................................................................................................................... 18

EMC Confidential Page 2 of 20 Version 1.2

Requirements for a VPLEX Change Control Process for a CCA

Purpose of the CCA

EMC requires a CCA for any upgrade action that changes the current configuration of a VPLEX.

There are documents located on the VPLEX Procedure Generator and support.emc.com that the
submitter and the customer should be referring to when configuring a Host and Storage device
to be used with VPLEX to ensure they get the best performance from these devices and to avoid
issues that are pointed out in these documents.

!!Policy for CCA submission!!

CCAs are required to be submitted at a minimum ten (10) business days in advance of
the scheduled date of the action(s) the CCA is being submitted for . This lead time is
required because if issues are noted in the CCA review the field will need time to discuss these
with the customer and for the issues to be corrected, new data collected and the CCA
resubmitted for a new review prior to the scheduled date. CCAs will be rejected if submitted
with nine (9) business or less days between the date of submission and the scheduled date for
the upgrade action.

CCA Expiry Period

If a CCA has been approved yet is not carried out within 30-days of approval the CCA becomes
null and void and a re-submittal, with the required data listed in this document, is required.
There will be no exceptions to this policy. The person(s) who will be performing the upgrade
action(s) are responsible for checking the approval date of the CCA. If it is over 30-days
(starting at day 31), the CCA process must be restarted and the CCA re-submitted.

Requirements for an Emergency CCA – Refer to Page 17

Configuration changes/upgrades that require a CCA today
Today a CCA is required for any upgrade to a VPLEX. There are four types of “upgrades” for the
VPLEX product today,

1) Upgrade of the GeoSynchrony code

2) Conversion from a VPLEX-Local to a Metro or Local to a Geo.
3) Upgrade of the VPLEX hardware from VS1 hardware to VS2 hardware
4) Upgrade of the current VPLEX engine configuration
a) single configuration (two directors/one engine)
to a Dual configuration (four directors/two engines)
b) single configuration (two directors/one engine) to a
Quad Configuration (eight directors/four engines)
c) Dual configuration (four directors/two engines) to a
Quad configuration (eight directors/four engines)

EMC Confidential Page 3 of 20 Version 1.2

If you go to the VPLEX Procedure Generator (PG) and you click on VPLEX Installation and
Upgrade you will see Installation and the four upgrade options listed as follows,

When selecting any of the upgrade or convert options listed above, you will receive the
following message reminding you that you must submit a CCA for this activity.

You will not get this message when you click on “Install VPLEX”. While not mandatory, it is
recommended to submit a CCA for any new installation to be made aware of any known issues,
ETAs, and workarounds for the latest code level. No VPLEX logs are necessary for a VPLEX
installation CCA. See notes below for details on CCA file requirements.

Other actions that require a CCA be submitted are the following:

1) Relocation of an entire VPLEX setup or just one cluster in a Metro or Geo

configuration.

The replacement of a component (FRU) does not require a CCA action as this is not an upgrade or
change to the VPLEX configuration.

EMC Confidential Page 4 of 20 Version 1.2

GeoSynchrony Code upgrade Planning
Please consult the VPLEX Change Control Wiki to see what the current TARGET code is. This is
the recommended code level for customers to upgrade to, unless there are specific
features/fixes that the customer requires in a different GA release of GeoSynchrony.

Review the GeoSynchrony release notes with the customer to ensure all requirements have
been met before submitting the CCA to ensure a smooth process.

Requirements for CCA submission:

1. Always refer to the VPLEX Change Control Wiki for the latest details about VPLEX CCA
Processes.
2. Activities related to a VPLEX Metro or Geo configurations must be submitted as a
SINGLE CCA with a separate task for each cluster. The SR referenced in each task must
reference an OPEN SR associated with the serial number of the affected cluster.

Your Tasks tab should look like this for a Metro/Geo:

Do not enter tasks for management server upgrades on each cluster. CCA reviewers
only need to review the main cluster software upgrade tasks.

3. Multiple VPLEX Locals must be submitted as separate CCAs. Each CCA should have a
SINGLE task referencing the affected cluster. The SR referenced in that task must
reference an OPEN SR associated with the serial number of the affected cluster.

4. All SRs associated with the CCA MUST have an open TASK in the SR and this Task MUST
remain opened until the CCA, conditionally approved, task(s) have been completed. This
will ensure that the SR is not auto closed by the rule that checks SRs for Open Tasks and
if none are found the SR is auto closed.

5. We ask that your CCA Project Diagram include:

o Reference to all back-end storage types connected to the VPLEX (these are
listed when you run the pre-upgrade commands contained in this doc)
o Reference to the switch types that the VPLEX is connected to on the customer’s
SAN
o Representative host types that are connected to the customer’s VPLEX
o Diagram should look like this:

EMC Confidential Page 5 of 20 Version 1.2

 6. Each task in the CCA Project must have a log file attached containing the PuTTY session
log captured when running the commands listed below on each cluster. Do NOT run the
commands script on both clusters of a Metro/Geo configuration at the same time due to
the heavy burden imposed by running the ‘collect-diagnostics’ command.

7. Each CCA project must have a Switch_data.txt file attached which indicates the type of
Fibre Channel switches that each cluster is attached to and the version of code running
on that switch. See below for further explanation.

Your file attachments should look like this in CCA5 (with your appropriate C1_####.log
and C2_####.log files, along with the Switch_data.txt file):

8. The referenced upgrade SR(s) in the CCA must have the .tar file attached from running
“collect-diagnostics --noextended” on each cluster. This data is important to
have available in the event of problems during or after the NDU. The collect-diagnostic
logs MUST be recent logs, a day or two at most before the CCA is submitted. Please see
note below for more details about the file handling.

EMC Confidential Page 6 of 20 Version 1.2

VPLEX CCA Process Step-by-step
1. Use the latest Procedure Generator from Solve Desktop to generate the applicable
procedure for your activity. Please read through to the procedure so that you
understand the requirements for the activity.
2. To enter the VPLEX CLI, log into the management server as the ‘service’ user, using
the password found in the Upgrade procedure (See the section titled “Run the
firmware upgrade pre-checks and health-check” for the details). This will place you at
the system level (Linux) prompt of the management server. Enter ‘vplexcli’ at the
prompt and use the same ‘service’ account credentials to enter the VPLEX CLI to run
the commands in the file attached to this document.

3. Once you log into the VPLEX CLI, run the command ‘ndu pre-check’
Note: If the setup is a Metro or Geo you need to run the ‘ndu pre-check’ on both
clusters.
o If there are any errors or warnings reported. Please discuss these with the
customer first and explain that all errors will need to be corrected before the
activity can proceed. These issues will most certainly be highlighted in the CCA
review.
o Common errors consist of:
1. Time drift between directors and Management servers. Follow
https://support.emc.com/kb/14180 to correct this.
2. Front-end and back-end connectivity issues:
a. Storage view HA issues (one port in each upgrader set, which is the
first upgraders, which are the ‘A’ directors and the second
upgraders which are the ‘B’ directors). Ndu pre-check will complain
but it’s normal on some configs to have storage views with only one
port on an ‘A’ and one on a ‘B’ director. Review the output to see if
the storage view names are repeated in the output. As long as each
view has a port on an ‘A’ and a ‘B’ director, it’s not an issue.
b. Over-pathing BE volumes. Inform the customer that they need to
reduce paths via the procedure found in SolVe.
3. Meta-volumes on single array or not backed up.
a. Single array errors are a common error when a single BE array is
available on a cluster. Meta-volume backup issues need to be
corrected via the troubleshooting info in the applicable upgrade
procedure.
4. The auto-resume attribute of the distributed device(s) is set to false. See
https://support.emc.com/kb/92664 for details.

4. After the initial errors are corrected (meta-volumes on the same BE array errors are
acceptable) and warnings are addressed, run the commands specified below. See
below for file handling instructions.

EMC Confidential Page 7 of 20 Version 1.2

 o A common CCA rejection finding is based on the LUN 0 issue during output of
‘export storage-view find --free-lun -c cluster-[1,2]’ in the
commands specified in this document.

 As part of the command output, due to KB 190162, we need to confirm

that each storage view has a LUN 0 in it, prior to the NDU (unless the
system is on a version of code where the matrix (below) entry for
‘Missing LUN0?’ is shown to be N/A). CCA reviewers analyze the output
of the above command for storage views that have a starting LUN
number of 0. Then they review the output of the ‘ndu pre-check’
and see if the storage views missing a LUN 0, have no exported volumes.
For example:

VPlexcli:/> export storage-view find --free-lun -c cluster-1

View doc_example : next free LUN number is 0.

In the output of the ‘ndu pre-check’ we see:

==================================================================
[Fri May 1 20:37:24 2015] Verify no unhealthy storage views
==================================================================

View health summary(cluster-1):

view name health-state exported volumes ports initiators
registered
------------------ ------------ ---------------- ----- ----------
------------------ ------------ ---------------- ----- ----------
doc_example healthy 0 4 2

With a value of ‘0’ in the ‘exported volumes’ column, it means that this
storage view, ‘doc_example’ is empty. Therefore, in this example, no
action needs to be taken. However, if there are non-empty storage
views without a LUN 0, that issue must be corrected, by the customer,
prior to the upgrade.

Please consult the matrix in Table 1 to see the rules on how a CCA
Approver MUST proceed if there are VPLEX storage views missing a
LUN 0.

EMC Confidential Page 8 of 20 Version 1.2

 Table 1

From Version To Version NPIV in use? Missing LUN0? Action Required

5.3P1/P2/P3 5.4.1 N/A Yes No action necessary
5.3 GA 5.4.1 N/A Yes Must add LUN 0
5.2.x 5.4.1 N/A Yes Must add LUN 0
5.1P3/P4 5.4.1 N/A Yes No action necessary
5.3 GA 5.3.x N/A Yes Must add LUN 0
5.3P1 5.3.x N/A Yes No action necessary
5.2.x 5.2.y Yes N/A Disable I/O Forwarding
5.2.x 5.2.y No Yes Must add LUN 0
5.2.x 5.3.x N/A Yes Must add LUN 0
5.0.x/5.1.x 5.3.x N/A N/A No action necessary

Note: For all above upgrade paths if NPIV is not in use and LUN 0 is present in all storage
views, no action is necessary. Note the LUN0 issue is fixed in upgrades from 5.3P1 to later
codes.

 Another major upgrade aspect, as shown above, is that we cannot

determine from our log collection whether ‘NPIV’ (KB 190301, N-Port
Virtualization on AIX hosts) is being utilized by hosts connected to the
VPLEX. You must ask the customer for this info, then specify it in your CCA
submission to permit the reviewer to properly address whether I/O
Forwarding should be disabled during the VPLEX NDU.

5. Check the output captured to determine if this a VPLEX Local or Metro/Geo

o “configuration get-product-type” should indicate this
o “cluster summary” will show all clusters that are part of this configuration

6. As noted above, if this is a VPLEX Metro or Geo, please ensure that you create a single
CCA with a task for each cluster. See below for file handling instructions for the CCA.

7. As noted above, the scheduled date for the upgrade should be no less than 10 days
after the date that you submit your project. We ask that the data collected for the CCA
be recent, as we want to ensure that there is minimal time between the review and the
upgrade. See Emergency CCA Notes.

8. Once you submit the CCA, please verify that the CCA has been properly submitted and
was not auto rejected for any reason.

9. When your CCA has been approved you will receive a notification from CCA5 indicating
the approval with conditions. You will also receive an email from the VPLEX CCA

EMC Confidential Page 9 of 20 Version 1.2

 approver providing more thorough details regarding your planned activity. If there are
any actions specified in the approval, please ensure that you take the appropriate
action prior to the upgrade window. Many issues are discussed in the upgrade
procedure itself, so please consult that document first. Most issues in the CCA
feedback email will be configuration issues; if you are unsure how to resolve issues
with the customer, raise an FSS request for assistance. Only if the feedback is
informing you of a real error or bug should you engage Tech Support to resolve the
situation. For cases where customer approval is required to use various skip options
during the NDU, please ensure that this approval is communicated with the individual
performing the upgrade (ie: RCM) The CCA submitter is responsible for ALL
communication with the individual performing the upgrade.

10. As indicated in the upgrade procedures, please ensure that prior to the upgrade the
system status has not changed since the CCA was submitted. Always upgrade
according to the latest Procedure Generator output.

11. When closing the CCA, please ensure that call home is functioning appropriately and
that the IB is updated with the new configuration state.

CCA COMMANDS
Required Command outputs to capture from each VPLEX cluster are included in the embedded
“cca_commands.txt” file below.

cca_commands.txt

Use the embedded file to COPY and PASTE the commands into your putty sessions for each
cluster being upgraded. Please note that if the customer has change the cluster names from the
default of “cluster-1” and “cluster-2” you will need to modify those commands accordingly.
There are comments included in the embedded file that highlight the commands where this may
be an issue. Note “Appendix A” has the full listing of commands and comment also.

Once all commands have been run and ‘collect-diagnostics --noextended’ has been
run, please attach the captured output to CCA as per the naming conventions below. The .tar
file generated from running collect-diagnostics MUST be attached to the SR associated with the
cluster in the CCA. The CD collection is too large to upload to the CCA project/task.

EMC Confidential Page 10 of 20 Version 1.2

File Handling Instructions
Note about Putty Logging:
 All commands and their output are to be captured in a PuTTY Logging session, set for ‘Printable
output’.

If you are using a different SSH application to capture the output, save this output and attach it to the
CCA for review. Saving only “Printable output” creates a much cleaner log file for review.

Note about the “collect-diagnostic --noextended” output tar file

 The collect-diagnostics logs will be located on the management server under the folder:
/diag/collect-diagnostics-out. You will need to use windows secure copy
(WinSCP), Secure Copy (SCP), or a similar application to copy the collect-diagnostic
base log off the management server.

 What the base collect-diagnostic logs collected will look like in this folder:

Base diagnostic file appearance:

<TLA>-diagnostics-YYYY-DD-MM-HH.MM.SS.tar.gz
Example:
FNM00112100321-diagnostics-2011-05-04-12.34.34.tar.gz

The TLA = Top Level Assembly, is the serial number assigned to a complete VPLEX rack
setup.
It can be found on the sticker on the back of the rack or by typing one of the two
following commands,
VPlexcli:/> ls –t /engines/*::top-level-assembly
or
ll /engines/engine-<cluster-id>-<engine-id>
VPlexcli:/> ll /engines/engine-1-1

Look for top-level-assembly near the end of the output.

File Splitting Large Diagnostics Files

 Due to the size of the .tar file generated from running “collect-diagnostics --
noextended” , it will need to be uploaded to the associated SR(s) listed in the CCA. Do not
attempt to attach this file to the CCA.
o If the file size exceeds 2GB, it will be not be possible to attach this file to the SR. In this
case, please ensure that you secure these .tar files somewhere other than on the
Management Server (an ftp site, but see the next bullet for a more permanent solution

EMC Confidential Page 11 of 20 Version 1.2

 to the large file issue). Make note of this situation as a NOTE in the CCA and as an
update within each of the SRs. This file may need to be accessed in the event of a
problem during or after the NDU. Also in certain circumstances this file will be required
during the CCA review process.
o Please consider utilizing the standalone, open-source ‘File Splitter’ program (for
Windows) - File Splitter to split large collect-diagnostics files into segments smaller than
2Gb. Once that’s done, please attach the segments to the upgrade SR(s) for
safekeeping. Here’s a sample of the simple FileSplitter interface:

Once the ‘Start’ button is clicked, this would then split the 4.1Gb input file into 1.5Gb
segments that can be attached to the upgrade SR.

Note about Customer SAN Switch Data Required (Switch_data.txt)

Along with the commands outputs collected from the VPLEX, you will also need to collect the
customer’s SAN switch type connected to the VPLEX and version of code running on those
switches . Please provide this detail in a text file named ‘Switch_data.txt’ attached to the
project within your CCA.

 One file per project is enough. Not submitting a Switch_data.txt file will generate an
auto rejection of the CCA.
 Note that the filename is CASE SENSITIVE: Switch_data.txt
 Please do not attach the output of supportshow, supportsave or show tech-support.
We only require switch type and OS version:

For example: Title this file as “Switch_data.txt”

Cisco/9513/NX-OS 5.2(8a)

Brocade/DCX/FOS 6.4.3b

EMC Confidential Page 12 of 20 Version 1.2

Note about data collection file naming scheme (C1_XXXX.log and
C2_YYYY.log)

All data captured logs, using PuTTY logging, are to use the following naming scheme as we are
working to automate the initial submission process via the CCA5 website.
NOTE: Remember collect only PRINTABLE output in putty, this makes the data easier to read
and therefore speed up the review of your CCA.

All PuTTY logging files will be named as followed:

<Cluster-id>_<last four of the TLA>.log

Example: C1_0062.log

So for cluster-1 the file will renamed, C1_0494.log

for cluster-2 the file will be named, C2_0495.log

After naming the logging files appropriately, please attach them to their respective task in the
CCA. If the logs are not properly named or missing, the CCA will be auto rejected by the
automated CCA5 process.

EMC Confidential Page 13 of 20 Version 1.2

CCA Requirements for other VPLEX change activity types.
For all activities listed in the “Configuration changes/upgrades that require a CCA today” section
above, we ask for the same data collection process to be followed. For all of these activities, it is
recommended to always upgrade the system to the current target code.

Convert Cluster Topology (Local to Metro or Local to Geo)

When a VPLEX is to be converted from a VPLEX-Local to a VPLEX-Metro or VPLEX-Geo
you will follow the same CCA process as for a GeoSynchrony Upgrade. If the system is
not already running at target level, please ensure that you add tasks to the CCA to have
the system upgraded. Then have separate tasks for the conversion from Local to
Metro/Geo.

Upgrade Cluster Hardware (VS1 to VS2)

When a VPLEX VS1 system is to be upgraded to a VS2 system, you will follow the CCA
process as for a GeoSynchrony Upgrade.

Upgrade Engine Count

When the number of engines is to be increased in a VPLEX system, you will follow the
same CCA process as for a GeoSynchrony upgrade. In addition to any required code
upgrade to the system (system must be at a minimum of 5.2SP1P2 code due to the
introduction of the new Emerson UPS units which are equivalent FRUs to the existing
APC units), please ensure that you add task(s) to increase the number of engines.
Please specify the “from” and “to” count in the CCA.

Relocation of a VPLEX, part or whole

When an entire VPLEX, or just one cluster, is to be relocated within the same data
center, using the same array(s) and host(s). You will still need to follow the same CCA
process as for an upgrade.

If the entire VPLEX or just one cluster is to be relocated to a different data center and a
new array(s) and host(s) will be used follow the same steps as the upgrade steps. There
will be a lot of data provided for this last action so you will need to allow a minimum of
three weeks for this particular CCA to ensure all the areas that will need to be addressed
in the planning are reviewed, discussed with the customer and fully understood. Any
missteps or missing info will be grounds for rejection of this CCA.

Installation of a VPLEX
When a new VPLEX is to be installed there will be no required logs for review. There will
be conditional text included in the approval email. Please be sure to review this data.
As detailed in the VPLEX Configuration Guide (on support.emc.com) it is recommended
that all new installs be upgraded to the latest GA version of the GeoSynchrony code,
prior to configuring the cluster(s). This is done by performing the steps found in the
‘Upgrading an Unconfigured System’ section in the VPLEX Configuration Guide. Also,
installs are not done by RCM but by Implementation personnel only. Important:
Because of auto reject rules in CCA you must create and upload dummy files to the
CCA project using the naming convention above.

EMC Confidential Page 14 of 20 Version 1.2

Dark Site support
Dark sites can present a challenge, some sites allow for sanitized data to be removed
from site. However some sites, such as military sites, do not allow anything off site. If
we can get the CLI command output minus some data like IP addresses, the CCA should
proceed as normal, and not being able to upload a ‘collect-diagnostics’ file CD is
acceptable, but please note that in the CCA to eliminate confusion on the part of the
reviewer.

If it is a totally dark site then a manual CCA can be done by a locally trained FSS via FSS
request. They must follow the latest Reviewer’s Guide and submit a complete CCA with
dummy files uploaded in order to maintain trackability of the event. The assigned FSS
can then approve with the appropriate notes.

Use of the Remote Change Management (RCM) team for code

upgrades
Only upgrades to the GeoSynchrony code are RCM-eligible. EMC recommends that the field
engage the Remote Change Management (RCM) team to perform code upgrades. The RCM
team operates 24 x 7 performing proactive remote activities across a number of EMC products.
Please note if ANY issues have been reported in the ‘ndu pre-check’ these MUST be corrected by
the field and customer before RCM can perform the upgrade. RCM does not correct VPLEX
issues. If the customer has provided authorization to use a –skip option (ie: for Storage View or
Auto-Resume settings) please ensure that this authorization is communicated to the RCM group
so that they take the appropriate action during the upgrade without having to further confirm
with the customer.

It is recommended that if the customer or field would like to make use of the RCM team for an
upgrade that the RCM Team be contacted first, before submitting the CCA, to setup their
availability for doing the upgrade. Then once you have a date the RCM Team will be available
make this the scheduled date in the CCA then submit the CCA along with all the rest of the
requirements for submission.

RCM Group Landing Page: RCM; Email: RCM@emc.com; or Phone: +353 (0)21 494 5555 (ext.
25400 from Hopkinton).

RCM Notes:
When requesting the RCM team via their web app there is a section titled ‘Product specific
Information’ where the last field requests you to provide a ‘CCA Approved Documentation’. For
this field take a copy of the approval e-mail that is sent after a VPLEX CCA is approved, or save a
copy and attach this as the approval documentation. If you are using Microsoft’s IE8 or 9 you
will get an error message when trying to attach the file. Please use Chrome and/or Firefox with
the RCM portal so that you are able to attach the file and not get the error.

EMC Confidential Page 15 of 20 Version 1.2

Reasons a CCA can be rejected
The following reasons are why a CCA can be rejected.

 Missing required data (see above)

 No SR listed in the CCA task tab
 SR listed in the Task tab is closed or for wrong product type
 Upgrade had already been carried out before CCA was approved
 CCA is submitted < 10 days prior to the activity.

EMC Confidential Page 16 of 20 Version 1.2

Requirements for an Emergency CCA
If you submit an “Emergency CCA” the following requirements must be met:

 Engineering has been working on an escalation and has determined that the present
code level the customer is running on their VPLEX has a code bug and the fix is in the
level of code engineering states they should upgrade to in order to correct the issue on
the VPLEX. Most times engineering will recommend upgrading to the latest level of
code. If the latest level of code does not have the fix then engineering may have to write
a HOT FIX for this customer’s issue.

Note:
A code with a HOT FIX is specific to the customer it was written for and CANNOT be used on
any other customer’s VPLEX, not even the same customer if they have a second VPLEX setup
without express permission from engineering.

 It has been determined from investigation by VPLEX Support that the customer has
encountered a known issue at the level of code they are running and the fix is in the
next or latest level of code.

What does not constitute an emergency CCA

When a customer informs you they want to upgrade their VPLEX code to the latest code level
and want to do it inside of the 10-day lead time.

You are to inform the customer this is not permitted due to the critical nature of VPLEX in their
virtualized storage environment. The CCA process has to be followed and there is a minimum
10-day lead time required. The 10-day requirement is to allow time for corrections should any
issues be discovered during the CCA review. See “Policy for CCA submission” back at the top of
the document.

In addition, please consult the Emergency CCA process document on the VPLEX Change Control
Wiki for more details surrounding the submission and handling of, Emergency VPLEX CCAs.

EMC Confidential Page 17 of 20 Version 1.2

Appendix A:
cca_commands.txt contents. Please open the “cca_commands.txt” file above to avoid potential
issues caused by “Word” formatting. Note that these commands must be run in the VPLEX CLI.

date -u
version -a
ls -t /management-server::cluster-ip-seed
configuration get-product-type
ls -t /engines/*::top-level-assembly
##check engine family VS1 is WildCat, VS2 is Argonaut. Be aware of upgrade paths
ls -t /engines/**::engine-family
ll /engines/*/directors
director uptime
director appstatus
cluster summary
cluster status
ll /clusters/**/storage-arrays
virtual-volume summary
storage-volume summary
extent summary
local-device summary
connectivity show
connectivity validate-be
ll /engines/**/ports
ll /engines/**/sfps
ll /clusters/*/exports/initiator-ports
ll /engines/**/stand-by-power-supplies/**/

##METRO or GEO
ds summary
consistency-group summary
ll /clusters/**/consistency-groups/
vpn status
connectivity validate-wan-com

ll /
ll /cluster-witness
ll /cluster-witness/components

##Recoverpoint##
ll /recoverpoint
ll /recoverpoint/rpa-clusters

EMC Confidential Page 18 of 20 Version 1.2

 ll /recoverpoint/rpa-clusters/*
ll /recoverpoint/rpa-clusters/*/volumes
rp summary
rp validate-configuration
##

health-check

##LUN0 check
## If clusters have non-default names, substitute them in place of
## cluster-1 and cluster-2 in the following commands
## There must NOT be any non-empty storage views where the NEXT free lun is 0, this
must be fixed prior to NDU

ll /clusters
export storage-view find --free-lun -c cluster-1
export storage-view find --free-lun -c cluster-2

version -a --verbose
ll /monitoring/directors/*/monitors
snmp-agent status
ndu pre-check --verbose
collect-diagnostics --noextended
##Attach the resultant .tar.gz file to the SR for this Cluster.

EMC Confidential Page 19 of 20 Version 1.2

 THIS PAGE LEFT BLANK INTENTIONALLY

EMC Confidential Page 20 of 20 Version 1.2