vania-janet/multiturn-rag-retrieval-data huggingface dataset:
If you are considering the Migration Coordinator, see [Migrating distributed firewall configuration](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/migration/GUID-CFFE8C28-2D32-4AC5-98C2-9F1AEE525190.html).
2. To migrate the VMs hosted on the NSX-V logical switch that is stretched to the NSX-T environment, log in to the vCenter appliance on the vCenter Server with NSX-T environment and initiate the import VMs workflow. This process asks for credentials on the vCenter appliance on the vCenter Server with NSX-T environment and vMotion one or more VMs. For more information, see [Introducing the Advanced Cross vCenter Server vMotion capability](https://core.vmware.com/resource/introducing-advanced-cross-vcenter-server-vmotion-capabilitysection1).
3. When all the VMs are migrated, the L2 bridge can be disconnected.







 Considerations for using NSX-T L2 bridge in migration 

A recommended practice is to use one NSX-T edge node to extend one NSX-V logical switch. This Edge node must be a virtual appliance because the NSX-T edge must be deployed on a IBM Cloud Bare Metal Server that is prepared for NSX-V. Each NSX-T edge node has two N-VDS switches: the first one is connected to the physical network to provide a TEP uplink and the second one is connected to the NSX-V logical switch. The NSX-V logical switches do not support VLAN tagging, so only one logical switch can be connected to the edge node's interface. For this reason, one edge cluster (two edge nodes) is required for each NSX-V logical switch that requires L2 extension.

The default MAC address of the NSX-T virtual-distributed router needs to be changed so that it does not conflict with the one used by the NSX-V Distributed Logical Router (DLR).
Configuration is done through editing .yml files. The Ansible playbooks also automate some of the tasks performed by the Fabric APIs, such as creating a channel, joining a peer to a channel, and installing and instantiating smart contracts. Even more, there are playbooks available for tearing down the configuration so you can reset your network as needed. This option is a great option for setting up networks for POCs, demos, development, and test networks.

The Ansible playbooks provide an easy-to-use, automated process to replicate your blockchain networks on-demand. All components that are deployed with the playbooks are also visible in the console where you can interact with them as normal and govern your network.









 Considerations and Limitations 

Console wallet identities - When you use the Ansible playbooks to deploy blockchain nodes, the identities that are required to operate the nodes in the network are generated for you. Don't worry, you have the opportunity to configure the node enroll ID and secrets. But the identities aren't added to the console wallet in the browser. That is a simple manual import step that you need to perform after the playbooks finish and is described in the [tutorial](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ansible-buildansible-build-next-steps) on using the playbooks to build your network.





 Getting started 

There are multiple ways to install the Ansible collection. One option is to install all of the prerequisite software locally, which can be cumbersome for first-time Ansible users. Another simpler option is to run the playbooks from a Docker image. Because using a Docker image completely bypasses the need for the prerequisite setup (the prereqs are part of the Docker image), this approach is by far the simplest option and is the process that we use throughout these tutorials. This option does require that you install Docker before proceeding. To determine whether Docker is installed, run the command docker --version. If it is installed, you'll see something similar to:


Docker version 18.09.2, build 6247962
Strategy Description Benefits 

 Cold (Active/Standby) With a Cold DR strategy, your solution is running in one environment and duplicate resources are available on standby. When an event occurs, you react and build up the standby site. A cold strategy is a reactive approach, where the upfront cost is minimal, other than storage costs for snapshots and backups. The cold approach typically entails higher RPO/RTO times and is simple to implement. 
 Warm (Active/Active) With a warm DR strategy, you have a pre-built environment that is already built up at a different site. The VPC, with the appropriate subnets, VSIs, load balancers, securities policies are already up and running. At a minimum, data or DBs are regularly being backed up and ready to be exported over to the backup DR site. When an event happens, you switch over to the backup DR. The warm approach has a shorter RPO/RTO and a higher-cost point with all the pre-provisioned services up and active. 







 IBM Cloud VPC DR Considerations 

Things you should consider when you are implementing your zonal DR:



 Situation Option Description 

 Restore and create resources with images Take regular Snapshots Use point-of-time snapshots to back up data on the boot and data volumes. The first snapshot is complete, and subsequent snapshots are incremental. The volume snapshots are stored in the regional IBM Cloud Object Storage buckets and are available only in the region where they were created. You can create new instances from a snapshot of a boot volume. You can attach data volumes to either a new or existing instance. For more information, see the Snapshot Overview. 
 Create a Custom Image If you are not taking snapshots of the boot volumes, create a custom image to reduce the provisioning time for instances. New virtual instances are built from a golden virtual instance, with preinstalled applications and configurations. 
 Streamline your recovery Use hostnames for Subnets Subnets are zone-specific. Subnets do not extend across the three zones. This limitation can pose a challenge especially for zonal DR. New IP addresses are assigned to the new instances, which can break any existing configurations such as security rules, application configuration files.
Following registration, your users authenticate by using either the OAuth2 authorization code or resource owner password[authorization grant](https://datatracker.ietf.org/doc/html/rfc6749section-1.3) flows to authenticate users.





 Dynamic client registration 



1. A user triggers a request by the client application to the App ID SDK.
2. If your app is not registered as a mobile client yet, the SDK initiates a dynamic registration flow.
3. On a successful registration, App ID returns your installation-specific client ID.







 Authorization flow 

Zoom

![App ID mobile request flow](https://cloud.ibm.com/docs-content/v1/content/27ecaa7a29890634603881a8e64789974a29916b/appid/images/mobile-flow.svg)

Figure 1. App ID mobile request flow



1. The App ID SDK starts the authorization process by using the App ID /authorization endpoint.
2. The login widget is displayed to the user.
3. The user authenticates by using one of the configured identity providers.
4. App ID returns an authorization grant.
5. The authorization grant is exchanged for access, identity, and refresh tokens from the App ID /token endpoint.









 Configuring your mobile app with the App ID SDKs 

Get started with the App ID SDKs.



 Before you begin 

You need the following information:



* An App ID instance
* Your instance's tenant ID. This can be found in the Service Credentials tab of your service dashboard.
* Your instance's deployment IBM Cloud region. You can find your region by looking at the console.



Table 1. IBM Cloud regions and corresponding SDK values

 IBM Cloud Region SDK value 

 US South AppID.REGION_US_SOUTH 
 Sydney AppID.REGION_SYDNEY 
 United Kingdom AppID.REGION_UK 
 Germany AppID.REGION_GERMANY 











 Authenticating with the Android SDK
IBM Cloud CLI requires Java SDK 1.7.0. The prefix for running commands by using the IBM Cloud CLI is ibmcloud. In the terminal, you're notified when updates to the ibmcloud CLI and plug-ins are available. Be sure to keep your CLI up-to-date so that you can use all the available commands and flags.
2. Install the IBM Cloud Hyper Protect DBaaS CLI plug-in. See [Installing the Hyper Protect DBaaS for MongoDB CLI plug-in](https://cloud.ibm.com/docs/hyper-protect-dbaas-for-mongodb?topic=hyper-protect-dbaas-for-mongodb-install-dbaas-cli-plugindbaas_cli_instr) or [Installing the Hyper Protect DBaaS for PostgreSQL CLI plug-in](https://cloud.ibm.com/docs/hyper-protect-dbaas-for-postgresql?topic=hyper-protect-dbaas-for-postgresql-install-dbaas-cli-plugindbaas_cli_instr) for detailed instructions. If you want to view the current version of your Hyper Protect DBaaS CLI plug-in, run ibmcloud plugin show dbaas.







 CLI plug-in usage command 



 ibmcloud dbaas help 

This command displays a list of DBaaS commands.

ibmcloud help dbaas

In the returned list, for some of the commands, you can see two command names, for example, cluster, cluster-show and databases, databases-list. The ones with -show and -list are old command names, which are deprecated but can still work. We recommend using the new commands without -list and -show, as documented in the following sections.







 Cluster commands 



 ibmcloud dbaas cluster 

This command shows the detailed information about a database cluster, including information about each node.

ibmcloud dbaas cluster RESOURCE_NAME [--output json]



 Command option 

RESOURCE_NAME
Providing Application users with the ability to create their own dashboard assets 

If you want to allow the users of your applications to be able to explore the data from their applications by creating and editing their own dashboards, then do the next steps:



1.  dashboardAPI.MODES.EDIT
2.  When the user performs a save dashboard action in your application, then your app should use the dashboardAPI.getSpec() method to get a specification of the dashboard in its current edited state. Your application should store this specification to allow it to be reopened later by the users. To open a saved dashboard, use the dashboard.openDashboard() method.
3.  You can code your application to register for an event to tell it when the dashboard changed and would need saving by using the dashboardAPI.on(dashboardAPI.EVENTS.DIRTY, window.onDirty) event. This allows your application to show an indicator that the dashboard has changes since the last save, and to ask if the dashboard must be saved, when the user closes it. The dirty state can be reset by using the dashboardAPI.clearDirty() method.



Note: Persistence of dashboards in the IBM® Cognos Dashboard Embedded service itself does not exist. It is the responsibility of your application to persist dashboard specifications, by using the pattern described in this section, as required. This allows the dashboard persisted assets to be stored and managed with the rest of your application’s assets, for more consistency overall in the application.

Example flow of how to create and save a new dashboard:

![createsavenewdashboardflow](https://cloud.ibm.com/docs-content/v1/content/2781097afe16f2d329d7a606ddd260fb1a3e355c/services/cognos-dashboard-embedded//images/createsavenewdashboardflow.svg)
* entityAttributes: A JSON object consisting of the attribute name and their values that define the specified entity. This is an optional parameter if the feature flag is not configured with any targeting definition. If the targeting is configured, then entityAttributes should be provided for the rule evaluation. An attribute is a parameter that is used to define a segment. The SDK uses the attribute values to determine whether the specified entity satisfies the targeting rules, and returns the appropriate feature flag value.







 Get single property 

Property property = appConfigClient.getProperty("check-in-charges");

if (property != null) {
System.out.println("Property Name : " + property.getPropertyName());
System.out.println("Property Id : " + property.getPropertyId());
System.out.println("Property Type : " + property.getPropertyDataType());
}





 Get all properties 

HashMap<String, Property> property = appConfigClient.getProperties();





 Property evaluation 

You can use the property.getCurrentValue(entityId, entityAttributes) method to evaluate the value of the property. This method returns the default property value or its overridden value based on the evaluation.

String entityId = "john_doe";
JSONObject entityAttributes = new JSONObject();
entityAttributes.put("city", "Bangalore");
entityAttributes.put("country", "India");

String value = (String) property.getCurrentValue(entityId, entityAttributes);



* entityId: Id of the entity. This is a string identifier related to the entity against which the property is evaluated. For example, an entity might be an instance of an app that runs on a mobile device, a microservice that runs on the cloud, or a component of infrastructure that runs that microservice.
Changing the membership count of a static instance group 

If you are using the static method for your instance group, the instance group works to always maintain the number of instances you have set. If any instances fail, the instance group automatically replaces those failed instances in the instance group. By maintaining the instances in the group, the availibility of the applications running in those instances is also enhanced.

You can manually scale the instances in the group at any time by editing the membership count.



* On the Instance group details page, edit the membership count and specify the number of instances you desire to have in your instance group.







 Changing the scaling method for an instance group 

If you start out with a static membership in your instance group, for example, you can change it to use the dynamic scaling method. (You can also switch from dynamic scaling method to the static scaling method.) With the dynamic scaling method, you set a minimum and maximum number of instances for the instance group. Then, you specify target policies that define the desired utilization of a metric (such as CPU) that you want the instance group to maintain.

To change an instance group from using static membership to dynamic scaling, complete the following steps:



1. From the menu in the upper right-hand corner of the instance group details page, select Switch scaling method.
2. On the Switch to dynamic page, click Switch to confirm that you want to change to the dynamic scaling method.
3. Specify the minimum and maximum number of instances that you want to have running in your instance group at any given time. You can edit these numbers later.
4. Specify the aggregation window. The aggregation window is the time period in seconds that the instance group manager monitors each instance and determines the average utilization.
5. Specify the cool down period, the number of seconds to pause further scaling actions after scaling has taken place.
6. Create one or more target policies that define a metric and target utilization that the instance group manager will use for auto scaling in your instance group. See Table 1 for more information.





Table 1. Target policies selections

 Field Value 

 Metric type Select the metric type that you want to associate with a target utilization value to use for adding or removing instances from your group.
Use steps 1 - 8 to configure the vmnics for the other vSphere hosts in your cluster.



Now, you need to add a port group for vMotion. You can create the group a Virtual Standard Switch (VSS) or Virtual Distributed Switch (VDS). Use the following steps to create a VSS switch.



1. Select the Configuration tab and select Networking.
2. Click Properties... for vSwitch0.
3. Click Add... to create a Port Group.
4. Select VMkernel and click Next.
5. Complete Port group properties with the following information:



* Network label: An appropriate name for the port group.
* VLAN ID (Optional): The VLAN ID for vMotion traffic (1101 for our example). The VLAN ID allows VMware to tag the traffic for the specific VLAN.
* Select Use this port group for vMotion.



6. Click Next.
7. Enter a Portable IP address for the VLAN. (You can get the port IP address from the control portal, Network > IP management > VLANs. Select the correct VLAN and under Subnets that you see a portable IP address range. If you have no available portable IP address or if you exhausted your current pool, follow the steps that are in 'Order private subnets and IP addresses' to order extra portable IP addresses.
8. Click Next and then Finish to complete.



Use the following steps to create a port group for VM data traffic.



1. Click Properties... for vSwitch0 and select Add virtual machine.
2. Complete the Port group properties with the following information:



* Network label: Enter the name of the port group, such as VM Data.
* VLAN ID (Optional): Enter a VLAN ID; 1101 was used for the example. The VLAN ID givess access to VMware to tag the traffic for the VLAN.









 Optional - Installing add-on VMware licenses (NSX, vRealize, vSAN)
If your workload already has redundancy built into the application, whether it is through clustering or replication, you might be considering a single link rather than a redundant link to reduce costs. Keep in mind that having a redundant link is still a better option because it eliminates the link as the single point of failure (SPOF) and provides more bandwidth to the server.

Note: Some of the older data centers provide only single link connection. In this case, make sure that your workload has redundancy that is built into the application. SEA01, for example is a single 1G connection. Data centers that support only single 10G connections include AMS01, DAL05/06/07, SJC01, and WDC01.





 Network interface controller 

The network interface controller (NIC) provides the link that connects your bare metal or virtual server to the network for communication. A common practice is to team two interfaces on the NIC to create a logical interface for redundancy and increase bandwidth. You have different options for teaming ports together:



1. Teaming the links with Link Aggregation Control Protocol (LACP). This protocol negotiates with the upstream switches to form the bundle, providing a better traffic distribution to and from the bare metal or virtual server.
2. Distribute traffic by using the operating system. This method provides switch-independent teaming.
3. Allow the IBM Cloud provisioning service to create the NIC teaming by using LACP or opt to do the NIC teaming yourself through different NIC team modes such as active-passive, round-robin, adaptive transmit load-balancing, or adapter load-balancing.



Zoom

![Two different types of bare metal deployment.](https://cloud.ibm.com/docs-content/v1/content/df269b100c3499f1efcbb7d030dce8dec25c539b/ha-infrastructure/images/HA-bmDeploymentTypes2x.svg)

Figure 1. Two different types of bare metal deployment. Option B with LACP nic bonding is recommended for higher availability.

Note: For VMware, LACP is not available, but other NIC teaming mode is allowed.
Known issues and limitations for projects 

Known issues and limitations include configuration management and user access to projects.



 Authorization 

Authorizing users to work in a project is complex as it requires users to be authorized to work with projects, toolchains, IBM Cloud® Schematics, and other tools in IAM. For more information about access, see [Assigning users access to projects](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-access-project).

Authorizing projects to deploy to a target account is managed by passing an API key into the deployable architecture. [Projects can be directly authorized by using a trusted profile](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-tp-project), but trusted profiles are not currently supported by all services. [API keys will continue to be supported](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-authorize-project), but a trusted profile is the preferred method for authorizing deployment to target accounts.





 Configuration management 

Configurations can be added, deleted, and renamed. Moving a configuration between projects must be done manually by editing project.json documents on both projects. If there are multiple configurations in a project, they can be organized only by naming conventions.





 Cost estimate 

Cost estimation is available for deployable architectures in the IBM Cloud catalog. Depending on the deployable architecture, a starting cost is estimated based on the available data. This estimated amount is subject to change as the architecture is customized within a project, and it does not include all resources, usage, licenses, fees, discounts, or taxes. In the future, aggregate costs across projects that can be grouped by various criteria will be available. For more information, see [Estimating architecture costs in a project](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-cost-estimate-project).





 API, SDK, and Terraform 

The projects API, SDK, and Terraform functionalities are beta for this release. Beta products are made solely available for evaluation and testing purposes.
Add swap space for SWPM. We are adding a minimum swap space to the system.

[root@sap-app-vsi ] dd if=/dev/zero of=/swapfile bs=1M count=8192
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB) copied, 24.701 s, 348 MB/s

[root@sap-app-vsi ] chmod 0600 /swapfile
[root@sap-app-vsi ] mkswap /swapfile
Setting up swapspace version 1, size = 8388604 KiB
no label, UUID=e7a63777-521a-44a7-abcc-0d17e1876a78



1. Add the following line to your /etc/fstab.



/swapfile none swap sw 0 0

1. Activate the swap space:

[root@sap-app-vsi ] swapon -a

You're now ready to install the SAP product of your choice. Your next step is to [download and install your SAP software and applications](https://cloud.ibm.com/docs/sap?topic=sap-download-install-media) if a single virtual server sample is sufficient for your needs.





 Step 5: Installing two virtual server instances in a 3-tier setup 

A more complex scenario involves installing two virtual servers. One server is the SAP NetWeaver Application Server (sap-app-vsi) and the other server is the database server for SAP NetWeaver. Given that we have two virtual servers of the same layout, per the example, Figures 8 and 9 are an overview of the virtual servers.

Zoom

![Figure 8. Virtual server instances](https://cloud.ibm.com/docs-content/v1/content/f89cc64b006ca59b35404693959c83d5747fee3e/sap//images/quickstudy-intel-vs-gen2-image14.png)

Figure 8.