HP-UX Secure Resource Partitions (SRP) A.02.01 Administrator's Guide

83
15.2 Using the srp -import Command
The srp -import command imports the SRP contained in the specified exchange file. The
exchange file contains the previously exported SRP’s configuration, and possibly specified directories.
The srp -import command validates the ability for the target system to accept the exchange file
and configures the new SRP. You can only import an SRP that does not exist on the target system.
NOTE:
• An imported SRP will not be automatically started at system boot time. Refer to 6.1.5.1 Input
Data for information about how to enable the autostart feature.
• Cloning an SRP on the same system is not supported. If you attempt to import an SRP onto a
system that already has an SRP with the same name, the srp -import command returns an
error.
You can save the exchange file for archival purposes, or you can import it to another system.
The srp -import command has the following syntax:
srp –import [-b[atch]] [-preview] [–xfile <exchange_file>]
[variable=<value>...]
The options are as follows:
batch
Run srp-import in batch mode. The command will not prompt for
arguments or template variable values.
preview
Validates if the target system will accept an exchange file for import.
exchange_file
Specifies the existing exchange file name. The srp –export command
creates the exchange file.
The default is
srp.exchange
.
variable=value
The most commonly used variables for the import
operation are as follows:
• iface
The network interface name on which to assign the imported
SRP’s IP address.
You can use the following notation to assign a value to a variable:
name=value
,
name='value'
, or
name="value"
15.3 Best practices for Exporting and Importing an SRP
To simplify the export and import of an SRP across systems, HP recommends to you keep the
properties of the SRP to be atomic and that you do not share files and data with other SRP
compartments unnecessarily. The following are best practices for using the srp –export and srp
-import commands:
• Maintain consistent OS versions and patch levels across systems
While SRP itself has minimal requirements for OS levels and patches to be synchronized
across systems, applications utilized within the SRP compartments may have more specific
requirements. By maintaining consistency across systems, you will not have to manually
track application dependencies when determining a target system for the SRP to import.
• Consider using shared storage or file systems when creating an SRP that will be cloned
By using shared storage for the SRP home directory and any file systems mounted within