vania-janet/multiturn-rag-retrieval-data huggingface dataset:
The expanded functionality of the Network Gateway device provides firewall features for your network in place of a standard firewall.
* Does public traffic pass through my load balancer or Hardware Firewall first?

Coming from the public internet in, the load balancing products are first, the Hardware Firewall products are next, and the NetScaler products are last (along with the customers servers).
* Does a server's uplink port speed need to match the Hardware Firewall?

The Hardware Firewall does need to match the public uplink speed of the server. However, because it only protects the public side of the network, the public uplink speed is what must match the firewall selection. Customers can create a case to request a downgrade of only the public interfaces if desired.
* Does IBM Cloud charge for firewall bandwidth?

The Hardware Firewall and FortiGate Security Appliance (FSA) 1G are not metered for bandwidth. FSA 10G is charged for firewall bandwidth after 20 TB are used. Additionally, these products can reduce total bandwidth utilization by limiting the traffic that servers must respond to.
* How do I upgrade the uplink of my Hardware Firewall?

The Hardware Firewall is locked to the public uplink port speed of a server. You can upgrade in place by cancelling the firewall, upgrading the port speed for the server, and ordering a new firewall. Alternatively, you can deploy a new server with the desired uplinks and associated firewall.
* Is High Availability possible with the Hardware Firewall?

No. The Hardware Firewall platform is enterprise-grade and highly durable, but true High Availability (redundant devices) is not an option for the Hardware Firewall. For HA, a Hardware Firewall (High Availability) or FortiGate Security Appliance (High Availability) is required. The Network Gateway product also has an HA option with firewall capabilities.
* I am running a hypervisor on an IBM Cloud server. Will the Hardware Firewall protect the Virtual Machines running on my hypervisor?

No. Portable IPs are used for the VMs in a hypervisor environment and portable IPs are not protected by the hardware firewall. A FortiGate Security Appliance is recommended.
CP-7 (1) - Separation from Primary Site 



  Control requirements 

CP-7 (1) - 0
:   The organization identifies an alternate processing site that is separated from the primary processing site to reduce susceptibility to the same threats.





  IBM Cloud for Financial Services profile 

The rules related to this control that follow are part of the IBM Cloud for Financial Services v1.2.0 profile in [IBM Cloud® Security and Compliance Center](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-getting-started).



*  Check whether Hyper Protect Crypto Services instance has at least # crypto units
*  Check whether each Application Load Balancer for VPC is configured to use at least # zones
*  Check whether an OpenShift cluster has worker nodes across multiple zones
*  Check that any Cloud Object Storage buckets used by Activity Tracker Event Routing are configured as cross-region
*  Check that Hyper Protect Crypto Services has failover units in at least 2 different regions that are Financial Services Validated
*  Check whether there are at least # instances of Direct Link in an account
*  Check whether each Virtual Private Cloud is configured to use at least # zones







  NIST supplemental guidance 

Threats that affect alternate processing sites are typically defined in organizational assessments of risk and include, for example, natural disasters, structural failures, hostile cyber attacks, and errors of omission/commission. Organizations determine what is considered a sufficient degree of separation between primary and alternate processing sites based on the types of threats that are of concern. For one particular type of threat (i.e., hostile cyber attack), the degree of separation between sites is less relevant.
Restricting the IP address range prevents IP addresses from being automatically assigned to another virtual server instance during a provisioning request.
4. Click Create subnet.







 Reserving virtual IP addresses 

A high availability cluster typically needs virtual IP addresses that must move with the application in a failover scenario.

Currently, Power Systems Virtual Server does not support reserving a floating IP address. Follow this procedure to avoid that virtual IP addresses are erroneously used during other virtual server deployments in the same workspace:



* Go to the specific [Subnets](https://cloud.ibm.com/power/subnets) of your Power Systems Virtual Server workspace, and define a subset of the full CIDR as allowed IP range.
* Select one unused IP address within the CIDR range of the subnet, but outside of the IP range that you previously restricted.
* You need to manage the usage of these addresses on your own. Usage of IBM Cloud® DNS Services might help for administration.







 Exploring more network architecture options 

You use an IBM Cloud® connection to connect your Power Systems Virtual Server instances to other IBM Cloud® resources within your account. IBM Cloud® connections are not required to configure a Red Hat High Availability cluster on Power Systems Virtual Server, but might be required for integration scenarios when you use IBM Cloud® classic network and Virtual Private Cloud (VPC) infrastructures. For more information, see [Managing IBM Cloud® connections](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-cloud-connections).

Use IBM Transit Gateway to interconnect your Power Systems Virtual Server to IBM Cloud® classic and Virtual Private Cloud (VPC) infrastructures outside of your account or region. For more information about integrating on-premises network and Power Systems Virtual Server, see [Network architecture diagrams](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-network-architecture-diagrams).





 Creating an SSH key 

Use the following steps to create one or more root login SSH keys.

First, you need to create a keypair and load the public key to the SSH keys store in Power Systems Virtual Server.
This knowledge includes, but is not limited to, use of the vSphere web client, vSphere client, and assignment of hardware resources such as networking and storage.













 Deploying AltaVault OVA 

Deploy the AltaVault OVA to the vSphere environment by using the utility server after all of the prerequisites are met. Instructions for OVA deployment can be found in the [NetApp AltaVault Installation and Service Guide ![External link icon](https://cloud.ibm.com/docs-content/v1/content/icons/launch-glyph.svg)](https://library.netapp.com/ecm/ecm_download_file/ECMLP2317733). The trial version of AltaVault comes configured with four virtual CPUs, 6 GB of memory, and a 150 GB primary disk. Use the Installation and Service Guide to do the following steps:



1. Increase the amount of memory to 24 GB.
2. Add a secondary disk storage device that is less than or equal to 8 TB to store deduplicated backup data.
3. Assign different portable private networks to the AltaVault appliance after the memory and disk configurations are changed.



The NICs are assigned the following interface functions:



* Primary: Used for the AltaVault appliance management and data replication to the cloud. It is assigned the Primary Network port group in the example environment.
* e0a: An optional interface that is used to replicate data from the AltaVault appliance to the cloud.
* e0b: An interface that is used to export the mount point for the SMB/CIFS or NFS share. It is assigned the Share Network port group in the example environment.
* e0c: An optional interface that is used to export the mount point for the SMB/CIFS or NFS share.



In the example configuration in this procedure, the AltaVault appliance uses the Primary interface as the replicate-to-cloud interface and the e0b interface to export a CIFS/SMB mount point. Note: You cannot use both A CIFS/SMB share and an NFS share to access the same data.
You can collect data plane logs that are generated by the ESXi hosts and its components.

To see the list of components per ESXi host, list the .conf files in the /etc/vmsyslog.conf.d directory.

The following table lists common logs that are generated by ESXi hosts:



Table 3. ESXi host logs

 Component Description 

 vpxa Logs that are generated by the agent that communicates with vCenter Server from the ESXi hosts. 
 hostd Logs that are generated by the agent that manages the ESXi host and its virtual machines. Reports actions such as VM power on, power off. 
 vmkernel Logs that report activity that is related to virtual machines and ESXi. 
 vmkwarning Duplicate wmkernel logs with severity warning or higher. 
 vmksummary Logs that provide information on availability and uptime statistics. 







 VMware NSX logs 

You can collect management plane logs that are generated by the NSX nodes and its components to gain insight into network traffic and who is logging to a resource.

The following table lists common logs that are generated by NSX nodes services:



Table 4. NSX logs

 Component Description 

 nsx-controller Logs that are generated by the NSX controller cluster. 
 nsx-opsagent Logs that are generated by the OpsAgent service. 
 nsx-proxy Logs that are generated by the NSX Edge servers. 
 nsx-sfhc Logs that are generated by the NSX-T Data Center Kernel Modules on ESXi Hypervisors. 
 nsx-sha Logs that are generated by the System Health Agent (SHA). 







 Guest Introspection logs 

When you enable the identity at source firewall functionality of the identity firewall in your VMware deployment, you must enable the Guest Introspection service. This service reports information about the login of users, the directory groups the users are a member of, and sends the IPs of the users to the Service Virtual Machine (SVM). The SVM updates the NSX Manager that uses this information to apply the firewall policies.

The following table lists common logs that are generated by the Guest Introspection service:



Table 5. Guest introspection service logs
Table 1. Built-in reduce functions

 Function Description 

 _count Produces the row count for a specific key. The values can be any valid JSON. 
 _stats Produces a JSON structure that contains the sum, the count, the min, the max, and the sum-squared values. All values must be numeric. 
 _sum Produces the sum of all values for a key. The values must be numeric. 
 _approx_count_distinct Approximates the number of distinct keys in a view index by using a variant of the [HyperLogLog](https://en.wikipedia.org/wiki/HyperLogLog) algorithm. 









 Custom reduce functions 

Most customers find that built-in reducers are sufficient to perform aggregations on the view key-value pairs emitted from their Map functions. However, for unusual use-cases, a JavaScript reduce function can be supplied instead of the name of one of the built-in reducers.

Reduce functions are passed three arguments in the following order:



* keys
* values
* rereduce



If a view has a custom JavaScript reduce function, it is used to produce aggregate results for that view. A reduce function is passed a set of intermediate values and combines them to a single value. A reduce function must accept, as input, results emitted by its corresponding map function, as well as results returned by the reduce function itself. The latter case is referred to as a "rereduce".

A description of the reduce functions is shown in the following example.

See the following example of a custom reduce function:

function (keys, values, rereduce) {
return sum(values);
}

Reduce functions must handle two cases:



1. When rereduce is false:



* keys is an array whose elements are arrays of the form [key, id], where key is a key that is emitted by the map function, and id identifies the document from which the key was generated values is an array of the values that are emitted for the respective elements in keys, for example: reduce([ key1,id1], key2,id2], key3,id3] ], [value1,value2,value3], false).
Managing Entrust DataControl 

New installations of Entrust DataControl® are no longer supported for new or existing deployments of vCenter Server® instances. You can still use or delete existing Entrust DataControl installations on your existing instances.

To manage the Entrust DataControl service, access the Entrust DataControl WebGUI from the IBM Cloud® for VMware Solutions console, or access the Entrust DataControl console from the vSphere® Web Client.



 Accessing the Entrust DataControl WebGUI from the VMware Solutions console 

To log in to the WebGUI of the primary or secondary Entrust DataControl appliance, use the WebGUI credentials that are found on the Entrust DataControl service details page.





 Accessing the Entrust DataControl console from the vSphere Web Client 

To access the Entrust DataControl console from the vSphere Web Client, use the following procedure:



1. In the vSphere Web Client, find the virtual machines that are named KC1 and KC2.
2. Right-click KC1 or KC2, and then click Open Console.
3. Log in to the console by using the console credentials that you can find on the Entrust DataControl service details page.



For more information, see [Ordering services for vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_addingservices).





 Enabling internet access for the Entrust DataControl virtual machines 

For Entrust DataControl v4.3.2 and later, IBM Cloud for VMware Solutions provides automatic renewal support for Entrust licenses with the Call Home feature enabled. For VMware vCenter Server® instances that are not private-only, Entrust DataControl is deployed with firewall and SNAT (Source Network Address Translation) rules that are defined on the management services ESG mgmt-nsx-edge.

These rules enable internet access for the Entrust virtual machines (VMs).
Solving problems 

If you run into problems while you're using Hyper Protect Virtual Servers, you can recover from these problems in many cases by following a few steps.



 Installion of the IBM Cloud CLI fails 

I can't install the IBM Cloud CLI on the virtual server.

 What’s happening 

You see an error message indicating that you do not have the permission to install the CLI.

 Why it’s happening 

This error occurs because the /tmp file system does not have execute permission.

 How to fix it 

Run the mount -i -o remount,exec /tmp/ command to remount the /tmp file system with execute permission.





 You can't see the details of your virtual server instance on its dashboard - or the dashboard seems to display incorrectly 

Though a new virtual server was successfully created, the details of the system are displayed incorrectly or aren't displayed at all.

 What’s happening 

The dashboard of your new virtual server does not show configuration details of your system, or these details aren't presented in the correct manner.

 Why it’s happening 

This issue can have multiple causes. The most probable causes are either a caching issue, or you might be using an unsupported browser.

 How to fix it 

Verify that you're using a supported browser. Delete your browser cache, log out of the IBM Cloud, and log in again.





 Status 'Inactive' is displayed in the Resource list when you create multiple virtual servers 

If you create more than five virtual server instances almost simultaneously in one data center that has no existing instances, one or more virtual servers displays with the status 'Inactive' (provisioning failed) within the Resource list. When you click the 'Inactive' server in Name field, an error message is displayed to indicate that provisioning has failed.

 What’s happening 

You try to create more than five virtual servers within a short period in one data center without any existing virtual server instances.

 Why it’s happening 

The number of virtual servers per data center is limited to five. Creating more than five virtual servers almost all at the same time in one data center leads to the status 'Inactive' (provisioning failed) for the sixth and all subsequent instances.

 How to fix it
Not all PKCS #11 functions are implemented by IBM Cloud® Hyper Protect Crypto Services. For the implemented PKCS #11 functions, see

[Supported PKCS #11 functions](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-pkcs11-api-refpkcs11_function_list).

To review the PKCS #11 standard documentation, see:



* [Cryptographic Token Interface Usage Guide Version 2.40](http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/pkcs11-ug-v2.40.html)
* [Cryptographic Token Interface Base Specification Version 2.40 Plus Errata 01](http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/pkcs11-base-v2.40.html)
* [Cryptographic Token Interface Current Mechanisms Specification Version 2.40 Plus Errata 01](http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.html)





 PKCS 11 implementation components 

To connect and use the PKCS #11 API, you need to understand the PKCS #11 API that is implemented by Hyper Protect Crypto Services and the relationship with the GREP11 API. For more information, see

[Comparing the PKCS #11 API with the GREP11 API](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-uko-introduce-cloud-hsmuko-compare-grep11-pkcs11). With the support of the PKCS 11 API, you don't need to change your existing applications that use the PKCS 11 standard. Hyper Protect Crypto Services also provides the isolated keystores to store cryptographic keys generated by the PKCS 11 functions. These keys are protected by the master key and the applications never see the key files locally.
The "S" in S/4HANA stands for "simple", while the "4" refers to the generation sequence. Compared to the SAP core product SAP ECC, which is still used in most companies, SAP S/4HANA offers many innovative functions that revolutionize the system landscape from the ground up. As SAP plans to discontinue the mainstream maintenance of its existing ERP solutions by 2027, many SAP ECC users are already considering a migration to SAP HA SZ S/4HANA





 What is created 

The scripts work in two phases. The first phase automates creating the resources for the VPC provisioning process in an existing VPC created when you deployed the bastion VSI. The second phase creates the SAP architecture in a distributed environment. This phase creates the:



* SAP HA SZ S/4HANA App cluster server on a distinct VSI as a single zone VPC
* SAP HANA cluster DB on a dedicated server type VSI as a Single Zone VPC



For more information about this architecture, see [SAP NetWeaver 7.x with SAP HANA IBM Cloud VPC](https://cloud.ibm.com/docs/sap?topic=sap-sap-refarch-nw-hana&interface=ui).

During the first phase, the VPC is provisioned with these components:



* 1 VPC where the virtual server instances are provisioned
* 1 security group. The rules for this security group allow:



* Inbound DNS (port 53) and
* Inbound SSH (TCP port 22) connections to your virtual server instance
* All outbound traffic from the virtual server instance



* 1 subnet to enable networking in your VPC
* 2 X virtual server instances with SAP certified storage and network configurations
* 2 floating IP’s address that you use to access your VPC virtual server instance over the public network



During the second phase, the Ansible Playbook is called and the SAP High availability architecture is installed for both dedicated VSIs SAP App VSI machine and dedicated SAP HANA VSI box. The SAP architecture that is deployed is the SAP S/4HANA release on pacemaker cluster HA dedicated SAP HANA 2.0 VSI’s release as a distributed deployment model.
I created secrets that reference the default Ingress certificate, but I have not created and registered a Secrets Manager instance. How do I manage my secrets?
: If you don't register a Secrets Manager instance, Red Hat OpenShift on IBM Cloud only automatically updates the default Ingress secret. You are responsible for managing any other secrets by using kubectl commands or another rotation method. If you have any secrets that reference the default Ingress certificate, you should remove them by using ibmcloud ks ingress secret rm.

What is the difference between the ibmcloud oc ingress instance CLI commands and the ibmcloud oc ingress secret CLI commands?
: There are two sets of CLI commands that work directly with Secrets Manager instances in Red Hat OpenShift on IBM Cloud: the ibmcloud oc ingress secret commands and the ibmcloud oc ingress instance commands. The ibmcloud oc ingress instance commands are used to manage your Secrets Manager instances. The ibmcloud oc ingress secret commands are used to manage your Ingress secrets that are stored in a Secrets Manager instance or secrets that are written directly to the cluster.





 Setting up your Secrets Manager instance 

Follow the steps to set up Secrets Manager in your cluster.



 Enable service-to-service communication 

Integrating Secrets Manager with your Red Hat OpenShift on IBM Cloud cluster requires service-to-service communication authorization. Follow the steps to set up the authorization. For additional info, see [Integrations for Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-integrationscreate-authorization).



1. In the IBM Cloud console, click Manage > Access (IAM).
2. Click Authorizations.
3. Click Create.
4. In the Source service list, select Kubernetes Service.
5. Select the option to scope the access to All resources.
6. In the Target service list, select Secrets Manager.
7. Select the option to scope the access to All resources.
8. In the Service access section, check the Manager option.
9. Click Authorize.
Deploying the Power Virtual Server for SAP HANA - 'SAP ready PowerVS' Variation 

To deploy the Power Virtual Server for SAP HANA through the IBM Cloud console:



1. Go to the IBM Cloud catalog and search for 'Power Virtual Server for SAP HANA'. Click the tile.
2. Select the latest version.
3. Select the SAP ready PowerVS variation.
4. Click Review deployment options.



* Select Add to project to add this deployment to an IBM Cloud project and combine it with other deployments. IBM Cloud projects include several more pipeline steps before deployment, including deployment validation, cost calculation, compliance verification, and approval process.
* Select Create from the CLI to get the CLI command. With that command you can trigger the deployment from the CLI.
* Select Work with code to embed the code into other terraform deployments.
* Select Deploy with IBM Cloud Schematics to trigger deployment process directly.





Edit the configuration by entering the Required input variables. Optional input variables are for advanced configuration and for deeper customization of the provisioned elements. You should know exactly what is the change goal and result by modifying the optional input variables.



* Input parameters are described in [readme file](https://github.com/terraform-ibm-modules/terraform-ibm-powervs-sap/blob/main/examples/ibm-catalog/deployable-architectures/sap-ready-to-go/README.md).
* Secure input parameters might be entered directly or might be referenced from an existing IBM Cloud Secrets Manager. For more information, see [Storing arbitrary secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-arbitrary-secrets).



The deployment typically can take up to 60 minutes but might take longer depending on the performance of IBM Cloud components.



 Validating the deployment 

After you provision an instance, verify the success of the deployment by:



* Checking the log files in IBM Cloud Schematics. There shouldn't be any errors.
* Trying out the access to the bastion host by using a SSH key. Access should be possible.