Overview of ELM Licensing May 2010 Version 1.5

1. Overview of ELM LicensingMay 2010Version 1.5 VMAX Danube and Alicanto Entitlements System

2. Before We Start There are both Business issues and Technical issues involved in ELM for Danube We are going to end up talking about both in this meeting Let’s separate out changes for Technical Specs from additional Business needs There are PMT and cPPT meetings in place to address Business issues See Smadar Lipetz for information and representation

3. Quick Summary Danube approach Uses Back Office to generate Entitlements We are not going to discuss the Back Office in this session Assume for now that it will generate License Files that contain Feature Entitlements Feature Entitlements gate what operations allowed/not allowed Manual overrides are provided via SymmWin Capacity usage is defined and measured but not gated We provide non judgmental Reporting to customer and SYR The approach supports both VMAX and Alicanto This is not being undertaken for DMX, nor taken back to VMAX pre-5875

4. Overview of How It Works Single complete License File generated as part DX/CX ordering process One License File defines Entitlements for a specific Symmetrix Additional Entitlement purchases result in net new complete License File License File gets to particular Symmetrix instances Retrieved via SMC – this is not fully automated! Retrieved from Licensing website by the Customer, as done for SPA Retrieved from Licensing website by CE or PSE Overridden manually by CE or PSE License File is processed Processing available on SE hosts and SP Results in Feature Registration updates to Feature and Capacity Entitlements Regular License Files contain the SymmID and will not work when its not the correct Symmetrix Entitlements status via reporting available on Service Processor, on Solutions Enabler hosts, on MF Enabler hosts, on TPF hosts Reporting is not done on System i hosts

5. Enterprise Licenses Will Exist • Enterprise License Files include the keyword SymmID = “any” • These can be used anywhere – note anywhere • These files include the Master Customer Number • They also include the Customer Name in License File • Helps EMC spot problems • Helps customer know it’s their file

6. Deciding what the Entitlements mean • Features with on/off for Danube • TF/Clone • TF/Snap • SRDF/S, SRDF/A • STAR • FAST for Thin • FAST for Thick • Optimizer • DCP • SPC • SymmWin will allow manual override (on/off) of specific Features • Do No Harm • Features can be “Entitled” via the License File • Features can be “Manually Set” by PSE Lab or CE • Features can be marked “In Use” upon upgrade of pre-Danube VMAX in the field • Features can be marked “In Use”, because older Host software is blindly using • If Feature is any of these, then it’s “ON” • Solutions Enabler, MF Enabler, TPF operations are allowed against that Feature

7. SE, MFE, TPF Gates and Checks • When Solutions Enabler (including in System i), MF Enabler, TPF talk to Danube VMAX and Alicanto, Symmetrix Feature Enablement determines Feature access • In general, checks are done on creation of constructs • For example RDF groups, RDF devices, dynamic RDF pairs, DSE pools, Snap sessions, clone sessions • Requirements document specifies when each kind of Entitlement gets checked • Host software checks for “ON”, does not care how it got “ON” • Reporting cares how it got marked “ON”

8. Capacities Definitions • License Files also contain capacity definitions • No on/off concept – this is a reporting function • No Feature usage ever prevented because of Capacity definitions • SE generates report what is actually in use and what was specified in the License File

9. Capacity Meaning • Exact Definition of what Capacity means is under business discussion • Trying to head towards notion of “How much Data under Management” • There will be Capacity Definitions in the License File – in TB • Many should be the same, but will be defined independently – for a reason • Capacity of the VMAX array – total Capacity of the array • Capacity for SRDF –what is for configuration in SRDF (S and A) • Capacity for STAR –what is for configuration in STAR topologies • Capacity for TF/Clone –what is for configuration in Clones • Capacity for TF/Snap –what is for configuration in Snaps • Capacity for Optimizer –should match the definition of total Capacity for the array • Capacity for FAST Thick –what is for configuration in FAST Thick policies • Capacity for FAST Thin –what is for configuration in FAST Thin policies • Capacity for DCP –should match the definition of total Capacity for the array • Capacity for SPC –should match the definition of total Capacity for the array • If they don’t match the total Capacity of the array • It means the Features were not properly charged for

10. Summary of How We Propose to Measure • Capacity of the VMAX array • We’ll measure the sum of the amount of raw data each disk can hold • Does not take RAID protection into consideration • Does not take use or mapping into account • Capacity for SRDF • We’ll measure how much customer data (logical size) is being protected by SRDF/S and SRDF/A • On R1’s, R2’s, R21’s, R11’s, R22’s • Regardless of RAID protection type • Capacity for STAR • We’ll measure how much customer data (logical size) is being protected by STAR • Capacity for TF/Clone • We’ll measure the size of the customer data (logical size) being protected and logical size of all copies • Regardless of RAID protection type • Capacity for TF/Snap • We’ll measure the size of the customer data (logical size) being protected and the logical size of all snap pools • Regardless of RAID protection type • Capacity for Optimizer, DCP, SPC • It’s the same as the Capacity of the array • Capacity for FAST Thick • We’ll measure the amount of customer data (logical size) managed by all FAST Thick policies • Capacity for FAST Thin • We’ll measure the amount of customer data (logical size) managed by all FAST Thin policies • This could be larger than the entire array

11. Providing Reporting to Customers • Usage Inventory performed automatically on SP, results in XML report about usage • Report run once per day automatically • Can be run on demand via SE (also on SP) • Reports can be run using customer tools (such as SMC and SE CLI) • Reports will include Entitlements and Measures of Capacity Usage • Content of report collected by SYR for data mining back at EMC • Original License File Reported back to SYR • We are not going to discuss what then happens in SYR in this meeting

12. Questions That Arise • Will Host Keys still exist? • We will continue to ship host keys with DMX • In Danube, specific host keys have been replaced by Entitlements • Most host keys will be ignored by the new versions of SE, MFE, TPF • Details are listed in the SRS and the SE specification • Some Specialty host keys will remain – like key for mapping unprotected devices

13. SE Keys Continued • SE will remove checks for the following keys – regardless of whether the key is present • Base, Config Manager, Device Masking, Delta Mark, SymAPI Server, SMC, TxIM, Mapping, SPA, EDP, WORM, VDEVs, SRDF/AR, Virtual Provisioning, Perma-Cache, Secure Erase, IPSEC, SRDF Cascaded • These removals do not imply that all is free, for example SMC must be purchased, SRDF Cascaded is inherent with SRDF purchase, SPA has it’s own Entitlements • SE will continue to check the following host keys • DCS, ORS-DM and ORS-LM, SRDF_SE_MSCS, RESPAK, SLC_Enabler, Mapping unprotected Devices • MFE will continue to check the following host keys • Starfire, Consistent Split, z/OS Migrator, FMM, Congroup Autoswap Extension, Host Based Flashcopy • MFE will check the following keys when operating against pre-5875 • TF Mirror, QOS and QOS Cache Partitioning, SAR, Snap Target, Snap Virtual, STAR, TF/Clone, SRDF/S, SRDF/A

14. More Questions That Arise • My Application bypasses keys, will it still work? • There are applications that either ship host software keys or call “bypass” routines to make functionality happen • There is no such thing as bypassing Entitlements at the host software level in the new versions host enabler software (SE, MFE, TPF) and Enginuity 5875 Danube • For example, customers will not get TF/Clone functionality they have not paid for it • Buying a product that exploits TF/Clone does not get you TF/Clone • Hence all software in the stack must anticipate that it cannot perform the functions it wants to, for lack of proper array licensing

15. More Questions that Arise • How will Enginuity, SE, MFE, TPF, Applications, and Partners get License Files? • For Beta – this should be done using real back-office Entitlements • For EMC Internal • Tool will exist to create License Files • Cannot create ELA licenses • History kept of who created what License File • These will be labeled in the License File as internally generated • These will ultimately be used at Partner sites

16. More Questions That Arise • Can a License File be altered? • No, there is a tamper proofing applied to each Entitlement in the file • All Entitlements must match – you cannot piece together a License File • How are add on purchases handled? • A new License File must be issued • Each License File fully describes the Symmetrix • Do Entitlements ever expire? • ELM mechanisms support time based Entitlements (e.g. good for 1 year or 2 years) • There is no concept of expiration for ELM with Symmetrix • It would never make sense to have a Symmetrix stop working

17. More Questions That Arise • Do Entitlements Failover? • No – this is not necessary • Failover configurations cannot be configured without proper Entitlements being in place • Can we have a disaster because GDDR or SRDF/CE won’t be able to failover because the right Entitlements are not present? • No, the configurations required cannot be created in the first place without Entitlements • Therefore no Failover scenario can malfunction because of Entitlements • But what if it all gets setup and then someone takes away the Entitlement? • The capability to operate as normal still exists – because of the “In Use” designation inside the Symmetrix

18. More Questions That Arise • What if the customer wants to create a new configuration after the Entitlement is removed? • It still works – so long as the “In Use” flag is on • How does that “In Use” get turned off? • Right now it doesn’t – it’s way too dangerous, we need to think it all the way through

19. More Questions That Arise • What about older versions of hosts software working against 5875? • All hosts have to continue to work, even if they have not been upgraded • Customers can upgrade their Enginuity level and not upgrade all their host software instances • Hence, all functionality defined by the existing versions of SE, MFE, TPF works if there is an SE key on the host – even if there is no Entitlement on the VMAX • Internally in Enginuity, we set the “In Use” flag • Yes, it’s a way around Entitlements • Upgrade your VMAX to 5875 • Do not upgrade your host software • Configure and Use everything you can (to mark things “In Use”) • Upgrade your host software • Feature use without Entitlement will be reported to EMC via SYR

20. A look at Symmetrix ELM Field use cases 1 VMAX/Alicanto (Danube) VMAX (Danube) 5874 5875 VMAX/Alicanto (Danube) 2 3 • Features will not run on an array if entitlement can't be verified***** • Manual overrides available Install a new VMAX or Alicanto with Danube • During upgrade, Features automatically enabled • Features continue to run regardless of entitlement discovery • Entitlement file ultimately needed for complete compliance information Upgrade an existing VMAX DMX License Move from DMX to VMAX Danube • Entitlement file needed (Support from back office/business processes needed) • Manual overrides likely used

21. Symmetrix ELM Host use case examples • Everything that has SE key continues to work • Upon SE upgrade, Features “In Use” continue • SE pre 7.0 does not operate VMAX • Features will require specific Entitlements OR override • SE checks with the array to see what is allowed • SE keys remain in place for old arrays SE 7.0 thru 7.1.2 SE 7.2 4 VMAX (Danube) Alicanto 3 VMAX (Danube) • Alicanto will require a specific minimum revision Pre-SE 7.2.1 6 System i, Mainframe,TPF follow the same rules

22. Your Questions • What else before we discuss specs?