vania-janet/multiturn-rag-retrieval-data huggingface dataset:
CloudDriver is deleted when the all current processes are completed.

CloudDriver is deployed only on the private network that connects to the IBM management plane over a private message queue. They are IBM developed components, are not user accessible, and have the following attributes and functions:



* Deployment and configuration of the vCenter Server instance within the user account.
* Add and remove hosts from the vCenter Server clusters.
* Add and remove clusters from vCenter Server instances.
* Add and remove add on services or function to vCenter Server instances.





 Automation flow 

The following flow describes the order of events when you use the IBM Cloud for VMware Solutions console to order a VMware instance:



1. Ordering VLANs and subnets for networking from IBM Cloud.
2. Ordering IBM Cloud bare metal servers with vSphere Hypervisor installed.
3. Ordering of Microsoft® Windows® VSI to serve as the Active Directory™ domain controller.
4. Deployment of the Cloud Driver VSI.
5. Validation of the networking and deployed hardware.
6. If applicable, the initial configuration of the single node vSAN.
7. Deployment and configuration of vCenter (with embedded PSC) and NSX.
8. Clustering of remaining ESXi nodes, expansion of vSAN if applicable, and configuration of NSX components (VTEP).
9. Validating the installation and configuration of the environment.
10. Deployment of optional services, such as backup server and storage.
11. Removal of the Cloud Driver VSI.









 IDs and passwords 

IBM Cloud for VMware Solutions automation retains a set of user IDs and passwords encrypted within the IBM Cloud management plane. Automation user IDs are separate from the user IDs displayed in the IBM Cloud for VMware Solutions console and which are reserved for your use.

Change these passwords and use your own password information management (PIM) system to store and manage these passwords. You cannot change or disable the passwords that are used by automation without disrupting the automation.
AC-6 (9) - Auditing Use of Privileged Functions 



  Control requirements 

AC-6 (9) - 0
:   The information system audits the execution of privileged functions.





  Implementation guidance 

See the resources that follow to learn more about how to implement this control.



*  [Running operator actions through a bastion host](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-connectivity-bastion)







  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 that Activity Tracker Event Routing is configured to collect global events generated by IBM Cloud services







  NIST supplemental guidance 

Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse, and in doing so, help mitigate the risk from insider threats and the advanced persistent threat (APT).
Selecting a subnet for multiple device orders can cause that subnet to no longer have available IP addresses. If you request a specific subnet that no longer has IP addresses available, IBM must contact you, which drastically increases provisioning time, and reduces ordering convenience. Use this advanced feature only when a specific procedure is needed.





 Primary IP addresses 

Primary IP addresses are the names that are given to IP addresses that are assigned to your private and public network interfaces by default. An IPv4 address is included with the price of your server for each network. These addresses provide server-unique connectivity on their respective network, and are nontransferable. It's important to understand what primary IP addresses, and thus what [primary subnets](https://cloud.ibm.com/docs/subnets?topic=subnets-about-subnets-and-ipsprimary-subnets) do and don't allow. It is highly recommended to use [secondary IP addresses](https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-optionsnetwork-ip-address-secondary) when you announce external services so your IP addresses are not tightly coupled to any particular server.

IPv6 - Within the Add-ons section of the network options is the IPv6 address option. If you want a public primary IPv6 address, select this option. Your server must have a primary IPv6 address to interact with any other products that use IPv6 connectivity.





 Secondary IP addresses 

You can request more IP addresses for your server (which is recommended when you announce services externally) when you order a server. The Public secondary IP addresses option is in the Add-ons section of the network options. Select the number of IP addresses you want, then a [secondary static subnet](https://cloud.ibm.com/docs/subnets?topic=subnets-about-subnets-and-ipsstatic-subnets) of the appropriate size is automatically provisioned and routed to your server's public primary IP address.
CM-7 (1) - Periodic Review 



  Control requirements 

The organization:

CM-7 (1) (a)
:   Reviews the information system [IBM Assignment: at least monthly] to identify unnecessary and/or nonsecure functions, ports, protocols, and services; and

CM-7 (1) (b)
:   Disables [Assignment: organization-defined functions, ports, protocols, and services within the information system deemed to be unnecessary and/or nonsecure].





  NIST supplemental guidance 

The organization can either make a determination of the relative security of the function, port, protocol, and/or service or base the security decision on the assessment of other entities. Bluetooth, FTP, and peer-to-peer networking are examples of less than secure protocols.
Compute and OS design considerations 

The SAP systems in a landscape have specific requirements for servers, operating systems, network setup, and supported storage.

In some regards, SAP workloads that use a Cloud Service Provider (such as IBM Cloud® for SAP) Infrastructure-as-a-Service is similar to existing practices (over many decades) for running SAP workloads by using an external data center or data center provider. An SAP landscape has specific requirements for connectivity, between hosts within Cloud IaaS and to external systems, IBM Cloud® for SAP provides a rich set of functions beyond hosting of SAP systems to improve your SAP landscape.

To assist your project's planning phase, the following sections provide IBM Cloud® for SAP portfolio design considerations for Compute and OS.



 Compute Performance considerations 

The IBM Cloud® for SAP portfolio is ideal for practically all SAP use case scenarios. You can use your servers for mission-critical workloads, as your test environment, or your business continuity disaster recovery (BCDR) site.



 SAP NetWeaver work processes scheduling and scaling 

CPU thread consumption affects the following processes.



* Dialog Work Process
* Update Work Process
* Background Work Process
* Enqueue Work Process
* Spool Work Process







 Compute Profiles of SAP-certified Bare Metal on Classic and on VPC Infrastructure 

You are offered an array of RAM and CPU combinations as the SAP-certified servers, which have a pre-configured amount of RAM and number of CPUs.

These combinations are "Appliance" delivery model of hardware certification. Therefore, the combination that you select cannot be changed during the ordering process or through a support ticket after servers are deployed.

Some IBM Cloud® for SAP Bare Metal profiles do allow alterations, and therefore - as far as HANA deployments are concerned - would use the "TDI" delivery model for which you would need to run validation checks to gain SAP Support.





 Compute Profiles of SAP-certified Virtual Servers on VPC Infrastructure 

IBM Cloud® for SAP provides SAP-certified infrastructure by using the latest Virtual Servers. These virtual servers are available with instantaneous provisioning, and are offered in different profiles that define CPU and RAM combinations.





 Compute Profiles of SAP-certified IBM Power Virtual Servers 

This offering is complementary from IBM Power Systems, with low latency access to IBM Cloud services
The Transit Gateway service is used to interconnect VPC environments and classic infrastructure across the three accounts.
2. Each account has a DNS Services instance to manage private domain names. The instances are connected to share DNS zones.





 DNS Services 

You can use DNS Services to resolve private addresses (domain names) from resources deployed in IBM Cloud. The domain names cannot be resolved from the public internet. A DNS zone is a collection of domain names and consists of DNS resource records. [DNS zones and their records can be used by other accounts](https://cloud.ibm.com/docs/dns-svcs?topic=dns-svcs-cross-account-about), thus establishing linked zones.





 Transit Gateway 

The Transit Gateway service allows to establish connectivity between IBM Cloud environments, including classic infrastructure and Virtual Private Clouds (VPC). You can even [connect environments hosted in different accounts](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-adding-cross-account-connections&interface=ui). Data flowing through Transit Gateway stays within the IBM Cloud private network and is not exposed to the public internet.







 Implementing resource sharing 

As stated in the introduction, it is common practice to access services outside the one (cloud) account. Depending on the level of integration, there are different ways to authorize service access and implement authentication. Those available options are discussed below.



 Authentication with passwords or API keys 

Many resources allow to generate multiple sets of credentials. Usually, they either consist of a combination of user identity (ID) and password or just a single API key. Often, it is possible to specify the set of privileges for the credentials, e.g., to allow read-only access or scope what can be accessed, modified, or even created and deleted. The credentials are then imported or configured for a dependent service or application to access that resource. Even though access is possible, set up requires some (manual) work and overall they are only loosely coupled or integrated.
Additional configuration file Required. You need to configure all of the parameters that include user roles in this file to ensure the successful deployment of the PKCS #11 library. For more information, see the [configuration file template](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-set-up-pkcs-apistep3-setup-configuration-file). Not required. The parameters that are needed to connect the Hyper Protect Crypto Services cloud HSM can be set up along with the application code. 
 Keystore Provided by Hyper Protect Crypto Services. The keys that are generated with the PKCS #11 API are protected by the master key and are stored in cloud databases. Not provided by Hyper Protect Crypto Services. You need to store keys that are generated by the GREP11 API on the local workstation or other devices. 
 Supported cryptographic operations The PKCS #11 API supports most of the standard PKCS #11 functions:<br><br><br><br> * General purpose.<br> * Slot and token management.<br> * Session management<br> * Object management.<br> * Generate keys.<br> * Wrap and unwrap keys.<br> * Derive keys.<br> * Encrypt and decrypt data.<br> * Sign and verify message.<br> * Create message digests.<br> * Retrieve mechanism information.<br> * Retrieve and set key attributes.<br><br><br> The GREP11 API does not support general purpose functions and session management functions. It supports most of the EP11 cryptographic functions:<br><br><br><br> * Generate keys.<br> * Wrap, unwrap, and rewrap keys.<br> * Derive keys.<br> * Encrypt and decrypt data.<br> * Sign and verify message.<br> * Create message digests.<br> * Retrieve mechanism information.<br> * Retrieve and set key attributes.<br><br><br>
Power Virtual Server for SAP HANA - variation 'SAP ready PowerVS' 

The SAP ready PowerVS variation of the Power Virtual Server for SAP HANA creates a basic and expandable SAP system landscape. The variation builds on the foundation of the VPC landing zone and Power Virtual Server with VPC landing zone. PowerVS instances for SAP HANA, SAP NetWeaver, and optionally for shared SAP files are deployed and preconfigured for SAP installation.

Services such as DNS, NTP and NFS running in VPC and provided by Power Virtual Server with VPC landing zone are leveraged.

Redundant IBM Cloud® connections provide the network bridge between the IBM Power infrastructure and the IBM Cloud® VPC and public internet.

The resulting SAP landscape leverages the services such as Activity Tracker, Cloud Object Storage, Key Management from the VPC landing zone and the network connectivity configuration provided by Power Virtual Server with VPC landing zone.



 Architecture diagram 

Zoom

![Architecture diagram for 'SAP on Power Virtual Server for SAP HANA' - variation 'SAP ready PowerVS'.](https://cloud.ibm.com/docs-content/v1/content/9610604e9f8dcd5f7b6b138dd22ba445300be7f5/deployable-reference-architectures/terraform-ibm-powervs-sap/sap-ready-to-go/deploy-arch-ibm-pvs-sap-ready-to-go.svg)

Figure 1. PowerVS instances prepared to run SAP in PowerVS workspace





 Design requirements 

Zoom

![Design requirements for 'Power Virtual Server for SAP HANA' - variation 'SAP ready PowerVS'.](https://cloud.ibm.com/docs-content/v1/content/9610604e9f8dcd5f7b6b138dd22ba445300be7f5/deployable-reference-architectures/terraform-ibm-powervs-sap/sap-ready-to-go/heat-map-deploy-arch-ibm-pvs-sap-ready-to-go.svg)

Figure 2. Scope of the solution requirements
Modifying or uninstalling HCX 

Existing installations can be upgraded, or some or all of a Hybrid Cloud Services deployment can be removed.



 Unstretching a Layer 2 network 

Unstretching a Layer 2 network is necessary before you remove the associated Layer 2 concentrator service virtual appliance, or before you uninstall Hybrid Cloud Services.



1. Check the stretched networks.
2. From the Hybrid Cloud Services plug-in page, view the Hybrid Services tab and check the Network Extension Service section. If active or scheduled jobs are in progress, wait until they are complete or stop them before you continue.
3. To remove the network, click the Delete (red X) icon on the right.
4. Click OK to confirm.







 Uninstalling HCX virtual appliances 

A service appliance might be uninstalled in preparation for uninstalling Hybrid Cloud Services or due to a change in the installation architecture. Use the Hybrid Cloud Services to administer appliances, as outlined in the following procedure.



 Prerequisites for uninstalling HCX virtual appliances 



* Cancel or reset the execution time for any migrations that might occur during the uninstallation task.
* Check the vSphere Web Client task console for any running migrations, and wait until they are complete.
* Ensure that no active Hybrid Cloud Services tasks exist.



Never delete virtual appliances from the vSphere inventory. Always use the management portal to interact with service virtual appliances.





 Procedure to uninstall HCX virtual appliances 



1. In the vSphere Web Client interface, select the Hybrid Cloud Services plug-in from the left pane.
2. In the center pane, click the Hybrid Services tab.
3. Locate the Hybrid Cloud Gateway appliance and click the entry to display the details.
4. On the lower right, click the Delete icon to remove the appliance.
5. If a stretched network does not share an IP address with the Hybrid Cloud Gateway, you must remove it separately. Expand the Network Extensions Service details, and click the Delete icon to remove the Layer 2 Concentrator.
See [Restricted DNS zone names](https://cloud.ibm.com/docs/dns-svcs?topic=dns-svcs-managing-dns-zonesrestricted-dns-zone-names) for the complete list.





 Can I create two DNS zones with the same name? 

Creating two DNS Zones with the same name is allowed. Use label and description as described in the following steps to differentiate between the two.



1. Create an instance of DNS Services.
2. Create a DNS zone for each environment (for example, production, staging, development, testing). When creating the zone, be sure to include a description indicating what environment the zone is for. The zone name is the same for each zone (for example, testing.com). A single DNS Services instance can only contain 10 zones.
3. Add a zone to the instance of DNS Services.
4. In each respective zone, add specific VPCs as permitted networks. For example, for a development VPC, create a permitted network with the development VPC ID in the DNS zone for the development environment. While duplicate zone names are allowed in an account, duplicate zones cannot be associated with a single permitted network.
5. The result is that traffic from the development VPC only sees records from the development DNS zone and similarly for all the other environments. This way, you can use the same zone name in all environments, with the results tailored to each respective environment.







 Can I add the same permitted network (for example, a VPC) to two DNS zones of the same name? 

No, adding the same permitted network (for example, a VPC) to two DNS zones of the same name is not allowed.





 What are the authoritative servers for the DNS Services zones? Can I resolve the private DNS zones iteratively? 

Unlike public DNS zones, DNS Services does not expose authoritative servers for private DNS zones. Clients must send their recursive DNS queries to the DNS resolvers provided by the service. DNS Services does not allow iterative resolution of private DNS zones.
Fortinet FortiGate virtual machine (VM) design 

The FortiGate® VM solution complements the IBM Cloud® for VMware Solutions offerings by providing next–generation firewall (NGFW) capabilities for networks within your VMware® estate. These services are provided by one or more pairs of FortiGate virtual appliances that are deployed to your VMware environment.

FortiGate VM does not replace NSX–T™ but rather complements and enhances the existing VMware NSX® architecture when installed into your VMware vCenter Server® instance on IBM Cloud®. FortiGate VM is deployed as a pair of virtual appliances with one network interface (port1) configured for management access and nine available network interfaces in the client’s data plane. With appropriate configuration of networks and routes, you can use FortiGate VM to provide network security between all tiers of your network topology.



 Topologies 

You can deploy FortiGate VM according to several different strategies as Figure 1 illustrates.

Zoom

![FortiGate VM deployment topologies](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/fortigate-vm.svg)

Figure 1. FortiGate VM deployment topologies

In this figure, FCR is the IBM Cloud front–end (public) customer router, and BCR is the IBM Cloud back–end (private) customer router. For more information about the IBM Cloud network design, see [Physical network design](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-design_physicalinfrastructure).



 IBM Cloud edge services 

You can deploy a VMware ESXi™ gateway cluster as part of your vCenter Server instance. This cluster is configured to peer with the IBM Cloud customer routers to provide firewall and gateway services for IBM Cloud public and private VLANs of your choice.
Networking considerations for vCenter Server instances 

Review the following information for details about networking considerations and requirements for your VMware vCenter Server® instances. Ensure that you meet the requirements so that your instance functions properly.



 Networking components for vCenter Server instances 

To review the networking components that are included in your vCenter Server instance, see [Technical specifications for vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_vcenterserveroverviewvc_vcenterserveroverview-specs).





 Firewall considerations 

If you're using firewalls, you must configure rules for all communications from the IBM® CloudDriver virtual server instance (VSI) and the SDDC Manager virtual machines (VMs). These rules must allow all protocols to communicate on the IP addresses 10.0.0.0/8 and 161.26.0.0/16. Examples of such firewalls are NSX Distributed Firewalls (DFW) or vSRX gateway cluster firewalls.

Some components might attempt to connect to the public network, although they are deployed to your private network. In some cases, such as Zerto Virtual Replication or FortiGate-VM, this connection is required for licensing or to report usage. These components are configured to connect either by using the instance NAT or a proxy you provide. You might need to allow these connections in your firewall. In other cases, these connection attempts are only for diagnostic and usage data, and the connections fail since no public connectivity is available or configured.





 Using NSX with your virtual machines 

During vCenter Server instance deployment, VMware NSX® is ordered, installed, licensed, and configured in your instance. Also, NSX Manager, VMware NSX Controllers™, and NSX Transport Zone are set up, and each VMware ESXi™ server is configured with the NSX components.

An VMware NSX Edge™ Services Gateway is also deployed to be used by your workload VM or VMs.
The components on cloud are passive in the sense that they do not perform active production workload, but they are receiving updates from the on premises components that are performing all of the productive workload.

On the HA+DR side, you see a typical 3-site deploy, where two sites are performing productive workload (active-active couples), while the third site has passive components that just receive the updates from the two productive sites.

In both cases, you see an “on-demand” environment that is dynamically created and used solely to run DR test.

You should limit the continuous availability class to only those workloads really needing this service level.

To achieve a continuous availability level is expensive and might be limited by constraints such as the distance and network bandwidth between primary and secondary sites.





 Advanced recovery class 

For [advanced recovery class](https://cloud.ibm.com/docs/overview?topic=overview-understanding-drplan-objectives), a continuous data replication solution maintains a live copy of source disks over a different cloud site or zone. This can be achieved mainly in three ways:

Native Cloud function
: Cloud offers disk replication functions to native duplicates data among cloud zones or sites.

DRaaS products
: In cloud marketplace, there are products and tools available that can be acquired and implemented on cloud resources (compute, storage, network) to provide a user-controllable disk replication in support of a DR as a service solution. Most of these products replicate data with a software solution that is an agent installed in the source VM or Hypervisor that intercepts the updates and sends them to a correspondent receiving software-based replicator at the DR location.

Software Defined Storage (SDS)
: Instead of using native storage functions of the cloud, SDS products from the marketplace use cloud resources (compute, storage, network) to provide a user-controllable disk subsystem, including data replication functions.

OS disks might not be duplicated with an SDS solution as you might have limitations in having a VM to boot from an SDS replicated disk.