We have multiple z/OS guests successfully using the same Crypto Domain, 
but they use separate cards (on a z9 EC). 
Maybe an example will help... here's what we have in the directory and on 
the HMC...

>From our "USER DIRECT" (really -- no directory management product on that 
system!)...
USER DIRECT
...
USER ZOSGUEST1 ...  <--- (obviously a pseudonym to protect the innocent)
...
*       DOMAIN = regs, APDED=cards; VM can't share DOM in same APDED   <-- 
Comments for my weary mind
 CRYPTO DOMAIN 1 APDEDICATED 2 3 CSU * 
...
USER ZOSGUEST2 ...
*       DOMAIN = regs, APDED=cards; VM can't share DOM in same APDED 
 CRYPTO DOMAIN 2 APDEDICATED 2 3 CSU * 
...
USER ZOSGUEST3 ...
*       DOMAIN = regs, APDED=cards; VM can't share DOM in same APDED 
 CRYPTO DOMAIN 3 APDEDICATED 2 3 CSU * 
...
Notice that the "DOMAIN n" changes for each guest, while the "APDEDICATED" 
args remain the same.

>From the HMC for the LPAR running the z/VM (5.2) system which hosts these 
(and other) z/OS guests (where "x" replaces the checkmark in the box 
before the numbers on that Crypto screen)....
Control Domain Index   Usage Domain Index
  0                      0 
x 1                    x 1
x 2                    x 2 
x 3                    x 3 
x 4                    x 4
x 5                    x 5
x 6                    x 6
x 7                    x 7
x 8                    x 8 
  9                      9
  ...                    ...

Cryptographic Candidate List    Cryptographic Online list
  0                                0
  1                                1
x 2                              x 2
x 3                              x 3
  4                                4
  ...                              ...
 
IBM Crypto hardware seems partly governed by "security by ignorance".  I 
spent a good deal of time with nice IBM folks in product support and pubs 
getting the PRSM manual updated with clearer explanations, definitions, 
and examples.  I asked that the HMC contain better doc (which I have not 
checked since the HMC was upgraded from OS/2 to Linux).

Hope a real-life example helps.  This is tough stuff to get working.

Mike Walter 
Hewitt Associates 
Any opinions expressed herein are mine alone and do not necessarily 
represent the opinions or policies of Hewitt Associates.




"Kurt Acker" <[EMAIL PROTECTED]> 

Sent by: "The IBM z/VM Operating System" <[email protected]>
03/01/2007 04:08 PM
Please respond to
"The IBM z/VM Operating System" <[email protected]>



To
[email protected]
cc

Subject
Re: Multiple Guests using the Same Crypto Domain







>From the planning and admin: 

Should I be able to run two guests using crypto with the same domain? 
Only one virtual machine may use a domain at a time. If more than one 
virtual machine has a CRYPTO statement for a given domain, only the first 
virtual machine that logs on receives use of the domain. 

Also, as a processor migration is mentioned, here is some info that is 
within our hardware buckets: 

 1. 06/01/18 RUNNING Z/OS GUESTS ON Z/VM USING PCI CRYPTO CARDS ON Z890,   
   
             Z990, AND LATER PROCESSORS.       
             Changes in crypto set-up are necessary when migrating from   
             the Cryptographic Coprocessor Facility (CCF) on the zSeries   
   
             z800 and z900 servers to the PCI cryptographic cards on the   
   
             z890 (2086device), z990 (2084device), and later processors.   
   
             With the z990 and z890, the Cryptographic Coprocessor       
             Facility has been removed and replaced with the Central       

             Processor Assist for Cryptographic Functions (CPACF) and  
             the PCI cryptographic accelerators and coprocessors. This    
             requires changes to the z/VM CRYPTO directory control       
             statement.  
             For CCF, it was necessary to include the CRYPTO Directory    
             Control Statement with the following operands:  DOMAIN,       

             CSU, KEYENTRY, SPECIAL, and MODIFY.  For PCI crypto, the  
             CSU, KEYENTRY, SPECIAL, and MODIFY operands are no longer    
             needed and are ignored if specified. The operands used for   
             PCI crypto are DOMAIN, APDEDICATED, and APVIRT. The APVIRT   
             operand is intended to authorize hardware for SSL       
             acceleration for Linux and VSE guests and is not used for    
             z/OS guests. If the APVIRT operand is specified for z/OS  
             guests, the Integrated Cryptographic Services Facility  
             (ICSF) component of z/OS will not function properly.  
             An example of the CRYPTO directory control statement  
             authorizing a z/OS guest to access the PCI crypto cards is:   
   
             CRYPTO DOMAIN 1 APDEDICATED 2 3 This statement authorizes    
             the z/OS guest to have dedicated access to crypto queue 1    
             on both AP 2 and AP 3.  
             The APs specified on the above statement must be selected    
             from the set of APs selected on the PCI Cryptographic       
             Online List on the Crypto Image Profile Page for the VM       

             logical partition.  The DOMAINs specified must be selected   
             from the set of domains specified on the Usage Domain Index   
   
             selections on the Crypto Image Profile Page for the logical   
   
             partition. For CCF, an additional required step was to  
             define a virtual crypto facility by using either the CRYPTO   
   
             operand on the CPU directory statement or the DEFINE CRYPTO   
   
             command.  Neither of these are required for PCI crypto.  It   
   
             is recommended that these no longer be used in orde to  
             avoid the following message at logon:  HCP663E The crypto    
             cannot be defined because no real crypto facility is  
             installed.  
             An additional hardware requirement for z/OS guests is that   
             the CP Crypto Assist functions (CPACF) must be enabled on    
             the processor.  Once CPACF is enabled on the hardware, no    
             z/VM set-up is required to authorize guests to access these   
   
             functions and they will be available to all guests.       
 
Hopefully this helps answer things, 

Kurt Acker  



"Don W." <[EMAIL PROTECTED]> 
Sent by: The IBM z/VM Operating System <[email protected]> 
03/01/2007 11:24 AM 

Please respond to
The IBM z/VM Operating System <[email protected]>


To
[email protected] 
cc

Subject
Re: Multiple Guests using the Same Crypto Domain








On Wed, 28 Feb 2007 20:06:52 -0500, Lloyd Fuller <[EMAIL PROTECTED]> 
wrote:

>On Wed, 28 Feb 2007 15:06:48 -0600, Don W. wrote:
>
>>I am trying to define two z/OS guests that are using CRYPTO. The 
mainframe
>>supposedly has two CRYPTO Coprocessors. The guests need to have the same
>>DOMAIN. I thought I should be able to dedicate a CRYPTO Coprocessor to 
each
>>guest and use the same domain. When I bring up the first guest, it seems 
to
>>reserve both CRYPTO processors. The first guest gets msg HCPAPJ1708I No
>>Processor is available to service virtual crypto unit (0/1). The second
>>guest gets a msg that the DOMAIN is in use and CRYPTO is not available.
>>Should I be able to run two guests using crypto with the same domain?
>
>To answer this we will need to know what type of processor.  The 
different
processors handle things different.  In
>addition, if this is a z800/z900 or older, you can only bind them to CPU0
and CPU1.
>
>Lloyd
>=========================================================================
We are currently using a z900 but will soon have a z9.


 
The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient 
is strictly prohibited.


Reply via email to