vania-janet/multiturn-rag-retrieval-data huggingface dataset:
If the traffic is matched, then it is sent to a named destination service (or subset/version of it) defined in the registry. Run the below command to send all reviews traffic to v1:

oc create -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.2/samples/bookinfo/networking/virtual-service-all-v1.yaml

The VirtualService defines a rule that captures all HTTP traffic coming in to reviews service, and routes 100% of the traffic to pods of the service with label "version: v1". A subset or version of a route destination is identified with a reference to a named service subset which must be declared in a corresponding DestinationRule.
3. View the bookinfo application in your browser tab. You should only get the v1 of the BookInfo application, i.e., no stars for ratings.
4. To enable the Istio service mesh for A/B testing against the new service version, modify the original VirtualService rule to send only Firefox traffic to v2. You may change the user-agent to any other installed browser on your machine:

cat <<EOF | oc replace -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- match:
- headers:
user-agent:
regex: '.Firefox.'
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v3
EOF
Show more

In Istio VirtualService rules, there can be only one rule for each service and therefore when defining multiple [HTTPRoute](https://istio.io/latest/docs/reference/config/networking/virtual-service/HTTPRoute) blocks, the order in which they are defined in the yaml matters.
Viewing and deleting virtual data centers 

View the summary and detailed information of the virtual data centers (VDCs) in your IBM Cloud® for VMware as a Service instance.



 Procedure to view a summary of VDCs 



1. In the VMware Solutions console, click Resources > VMware as a Service from the left navigation pane.
2. In the VMware as a Service table, ensure that the Virtual data centers tab is selected.
3. Review the VDCs information: name, location, Cloud Director site, and status.
4. Click the VDC name to view details.







 Procedure to view the VDC details 

You can view the VDC details through the Cloud Director site details page.



1. In the VMware as a Service table, click the Cloud director sites tab.
2. In the Cloud director sites table, expand the Cloud Director site row to view the list of VDCs that are provisioned for that instance.
3. In the Virtual data centers table, review the VDC name, provider VDC (PVDC) name, network edge, and status.
4. Click a VDC name to review the complete summary of VDC details.
5. On the Summary tab, review the following information:



* The VDC name, resource group, site, and provider VDC (PVDC) name.
* The creation date, network edge type, and the globally unique ID of the VDC. This ID can be helpful if you need to open an IBM Support ticket.
* The 6 public IP addresses that are assigned to the VDC. The IP addresses can be assigned to support public egress and ingress against the VDC and are not intended to enable VDC creation. It is recommended to use the included VDC firewalls when you are using the public IP addresses.



6. Use the toggle to either enable or disable fast provisioning.
7. To access the service and to create and manage networking and workloads, click VMware Cloud Director console.
* Classic clusters: Enable a [Virtual Router Function (VRF)](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf) for your IBM Cloud infrastructure account. To enable VRF, see [Enabling VRF](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf). To check whether a VRF is already enabled, use the ibmcloud account show command. If you can't or don't want to enable VRF, enable [VLAN spanning](https://cloud.ibm.com/docs/vlans?topic=vlans-vlan-spanningvlan-spanning). When a VRF or VLAN spanning is enabled, the Ingress controller can route packets to various subnets in the account.







 Publicly exposing apps in clusters with a public cloud service endpoint 

Classic clusters

Virtual Private Cloud

If your cluster is created on classic infrastructure, or if your cluster is created on VPC infrastructure and you enabled the public cloud service endpoint when you created it, you can use the default public Ingress controller to expose apps in your cluster to receive requests that are from the public network.

Before you begin:



* Review the Ingress [prerequisites](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-public-exposeingress-public-prereqs).
* [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).





 Step 1: Deploy apps and create app services 

Start by deploying your apps and creating Kubernetes services to expose them.



1. [Deploy your app to the cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_apps). Ensure that you add a label to your deployment in the metadata section of your configuration file, such as app: code.
Each IBM Cloud Direct Link service is not redundant, however, diversity can be engineered by using multiple Direct Links and BGP. For more information, see [Models for diversity and redundancy in Direct Link (2.0)](https://cloud.ibm.com/docs/dl?topic=dl-models-for-diversity-and-redundancy-in-direct-link).





 Connecting to on-premises by using Megaport 

In this deployment topology, [Megaport](https://www.megaport.com/) or Direct Link Connect is used to provide connectivity from your on-premises (remote) networks to your Power Systems Virtual Server subnets.

Zoom

![Connect to on-premises](https://cloud.ibm.com/docs-content/v1/content/1d36273917990fbf48078805e201d2e85e2fcb27/power-iaas/images/network-connect-to-onprem.svg)

Figure 3. Connect to on-premises

IBM Cloud Connect is a managed network service that uses Megaport services. This service is available only in the United States. You can also use Megaport to connect your on-premises network to Power Systems Virtual Server directly.

Review the following characteristics about Megaport connectivity services: * Megaport operates a global network infrastructure that enables on-demand connectivity to hundreds of global services in Asia Pacific, North America, Europe, and the Middle East. * A port is the physical point of connection between your organization’s network and the Megaport network. While a single data center connection is possible, best practice is to select two different port locations to provide redundancy. * Megaport has a number of cloud service providers including IBM Cloud. * Virtual Cross Connects (VXCs) provide connections between any of the locations and services on the Megaport network. Ordering a VXC (by using the Megaport portal or API) allows you to connect into the Power virtual server environment and, optionally, the classic/VPC infrastructure environments or other clouds.
VMware HCX component-level target architecture with NSX-T deployments 

Review the architecture of each VMware® HCX™ component that is deployed within the IBM Cloud® environment with NSX-T™.



 NSX-T Services Edge Tier 0 Gateway 

The components that are configured first within the IBM Cloud are the existing NSX-T virtual machines (VMs). These VMs provide public connectivity for the HCX Cloud Virtual appliance.

The services edge is configure with Destination NAT (DNAT) rule and related firewall rules to allow connectivity to HCX Cloud through the Internet. Also, Source NAT (SNAT) is used for lisence registration and services update.





 HCX Manager 

The HCX Manager component is the first appliance that is deployed after the NSX-T services T0 are configured on the target. This appliance is used as the main interface into the cloud environment for the source components.

HCX Manager provides an abstracted networking user interface that can be used to add, edit, and delete networks, and to design and configure routing without direct use of NSX. As a result of the vCenter and NSX integration, the HCX Manager appliance is assigned a private portable IP address on the management VLAN.



Table 1. HCX Manager

 Component Configuration 

 CPU 4 vCPU 
 RAM 12 GB 
 Disk 60 GB VMDK resident on shared storage 



Additionally, it is configured to access vCenter and NSX with a specific user.





 HCX-IX Interconnect Appliance 

A virtual appliance is deployed after a connection is established from the source to the target cloud. This appliance is the HCX-IX Interconnect Appliance (CGW) and is used to maintain a secure channel between vSphere environment that is designated as the source and the IBM Cloud. The following table shows the sizing specification of the CGW appliance that is deployed within the IBM Cloud.



Table 2. HCX-IX Interconnect Appliance deployment

 Component Configuration 

 CPU 8 vCPU 
 RAM 3 GB 
 Disk 2 GB VMDK resident on shared storage
* If ICMP is selected in the Protocol menu, select the ICMP Type.
* For Translated IP/Range, type the IP address of the VM on the private Organization virtual data center that you want to connect.
* For Translated Port, select the port on the previous VM that the servicer is listening on. In the Windows RDP example, port 3389 is the default remote desktop port.
* Optionally, provide a description.



From the virtual data center for that edge gateway, add a firewall rule to enable port forwarding. For more information, see [Add an NSX data center for vSphere Edge Gateway firewall rule](https://docs.vmware.com/en/VMware-Cloud-Director/10.1/VMware-Cloud-Director-Tenant-Portal-Guide/GUID-97ADAF42-598B-44B2-80EF-8B215B743C78.html).

Review the following notes for destination NAT definition and port forwarding.



* For Source, optionally define the source if you want to restrict access to the internal Organization virtual data center VM to a specific IP or IP range.
* For Destination, set the value to the tenant-external IP address used for Original IP/Range in the DNAT rule.
* For Service, set the Protocol to TCP and the Destination Port to the tenant-external IP address used in the DNAT rule. In our example, port 8000 is used.



To test the configuration, use the remote desktop client and connect to the tenant-external IP address:port number as the destination in the Computer field.







 Enabling VM access to IBM Cloud Services by using the private network 

You can configure vApps and VMs running inside of the virtual data center to use the IBM Cloud private network to access IBM Cloud services. Accessing IBM Cloud services through a private network can save on outbound public networking costs and can provide a higher degree of reliability and security. Virtual data centers route to the IBM Cloud private network through a virtual data center service network that is configured as an available external network on virtual data centers edge.

VMware Shared fully enables access to IaaS endpoints for IBM Cloud Virtual Private Cloud (VPC).
Network Address Translation (NAT) masquerade, is a commonly used approach to securing the access to Internet hosted service from private networks. In NAT masquerade, private IP addresses are translated to the IP address of the out-bound public interface in a many-to-one relationship, shielding the private IP address from public view.

This tutorial presents the setup of Network Address Translation (NAT) masquerade on a Virtual Router Appliance (VRA) to connect to a secured subnet on the IBM Cloud private network. It builds on the [Isolating workloads with a secure private network](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-secure-network-enclosuresecure-network-enclosure) tutorial, adding a Source NAT (SNAT) configuration, where the source address is obfuscated and firewall rules are used to secure out-bound traffic. More complex NAT configurations can be found in the [supplemental VRA documentation](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-supplemental-vra-documentationsupplemental-vra-documentation).



 Objectives 



* Setup Source Network Address Translation (SNAT) on a Virtual Router Appliance (VRA)
* Setup firewall rules for Internet access



Zoom

![Architecture](https://cloud.ibm.com/docs-content/v1/content/01ccb31b85637ed5f03008c920c9596354caaf98/virtual-router-appliance/includes/solution-tutorials/includes/solution-tutorials/images/solution35-nat-config-private/vra-nat.png)

Figure 1. Architecture diagram of the tutorial



1. Document required Internet services.
2. Setup NAT.
3. Create Internet firewall zone and rules.







 Before you begin
Network Address Translation (NAT) masquerade, is a commonly used approach to securing the access to Internet hosted service from private networks. In NAT masquerade, private IP addresses are translated to the IP address of the out-bound public interface in a many-to-one relationship, shielding the private IP address from public view.

This tutorial presents the setup of Network Address Translation (NAT) masquerade on a Virtual Router Appliance (VRA) to connect to a secured subnet on the IBM Cloud private network. It builds on the [Isolating workloads with a secure private network](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-secure-network-enclosuresecure-network-enclosure) tutorial, adding a Source NAT (SNAT) configuration, where the source address is obfuscated and firewall rules are used to secure out-bound traffic. More complex NAT configurations can be found in the [supplemental VRA documentation](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-supplemental-vra-documentationsupplemental-vra-documentation).



 Objectives 



* Setup Source Network Address Translation (SNAT) on a Virtual Router Appliance (VRA)
* Setup firewall rules for Internet access



Zoom

![Architecture](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution35-nat-config-private/vra-nat.png)

Figure 1. Architecture diagram of the tutorial



1. Document required Internet services.
2. Setup NAT.
3. Create Internet firewall zone and rules.







 Before you begin
The network is 192.168.253.0/30 and it cannot be changed currently or the DCG feature does not work as described. The active ESG weight is 60 and the stand-by weight of 30.





 Procedure to add a stretched network 

Add a stretched network to use the cross-virtual data center networking.



1. From the main navigation bar of the IBM Cloud for VMware Solutions console, select Data Centers.
2. On the Stretched Networks tab, click ADD.
3. For New Stretched Network enter a name, the gateway CIDR, and click CREATE. The new network is now available for BGP across the virtual data centers of the data center group.



You are now ready to put VMs on the cross-virtual data center network and build out your use case.







 Enabling VMware Chargeback 

The VMware Chargeback (formerly known as VMware Aria® Operations™ Tenant App for VMware Cloud Director) feature is enabled by default when your organization is provisioned. From the Cloud Director tenant portal, click More > Operations Manager to access VMware Chargeback.

If the Operations Manager option is not available in the More menu, open an IBM ServiceNow ticket, and submit a request to enable the VMware Chargeback feature in your organization.

After the VMware Chargeback feature is enabled for an organization, the users who are defined in the organization have access to it.

For more information, see [Using VMware Chargeback as a tenant](https://docs.vmware.com/en/Management-Packs-for-vRealize-Operations/8.10/vmware-chargeback-for-vcd-for-a-tenant/GUID-4D7030B6-AF73-464B-8FE8-75B879EE76B8.html).

The billing link in VMware Chargeback is disabled. All billing for VMware Shared is processed through the VMware Solutions console.





 Deleting the OpenID Connect configuration in your VMware Cloud Director Organization
[IBM Cloud Object Storage](https://cloud.ibm.com/docs/vpc?topic=vpc-connecting-vpc-cos) s3.direct.xxx.cloud-object-storage.appdomain.cloud 



Enabling access to the service network is done in two edge configuration steps.



 Adding the NAT rule for VMware Solutions Shared 

Add a NAT rule for translating internal network addresses into the service network IP address space.



1. Log in to the VMware Cloud Director tenant portal.
2. Click the virtual data center Edges tab and open the single preconfigured edge.
3. In the External Networks section, click the IP Settings link. Find the name of the service network and the IP address that is assigned for the service network interface from the table displayed. The format for the service network name is <datacenter>-w<idx>-service<idx>, for example, dal13-w02-service02.
4. Click SERVICES to open the Edge Gateway configuration page. Click the NAT tab and click + SNAT RULE to add a SNAT rule.
5. Select the service network next to the Applied on field and add the IP addresses or range from one of the virtual data center Organization networks to the Original Source IP/Range field.
6. In the Translated Source IP/Range field, click Select. From the Network menu, select the service network. From the IP Address menu, select the service IP address that you want to use.
7. Set the Destination IP Address to the service network address identified in step 3 and optionally define the Description field.
8. Verify Enabled is selected and click KEEP.
9. Click Save Changes.







 Adding the NAT rule for VMware as a Service 

Add a NAT rule for translating internal network addresses into the service network IP address space.



1. Log in to the VMware Cloud Director tenant portal.
2. From the main page under Virtual Data Center, click the virtual data center where you want to add the NAT rule.
3.
Partial failover is used to potentially increase the availability of the services by allowing to run and recover some of the services in DR while all the others are still running production on the customer data center.

Partial failover carries a lot more complexity in the network design that is associated with the solution, as it requires an extension of production site networks to the DR site that can happen on Layer 2 (such as L2TPv3, Cisco Overlay Transport Virtualization), Layer 3 (such as Cisco Locator/ID Separation protocol (LISP), Virtual Private LAN Services (VPLS), or Software Defined Network technique.

Additional considerations might imply the full control of the landing DR Hypervisor, so techniques like VXLAN overlays that are included in solutions like VMware NSX might not be applicable where this control is missing.

From a network perspective, this extension implies additional thinking because of possible impacts on security and performances, at least because the servers that were previously in the local LAN are now placed over a longer distance (WAN).

These impacts must be evaluated in two flavors: from a server to user perspective and from a server to server perspective, especially for time-sensitive applications or services.



 User to DR server 

Consider the scenario where only a server (Server A) has been failed over and is running at the DR data center in a partial failover situation.

The user-to-server A session reaches the server A DR-VLAN through the existing customer routing and security running on premises. For the customer-managed routing perspective, Server A is still on source-VLAN, in other words, the fact that source-VLAN is extended in the DR data center is transparent for the customer-managed router.

So, the customer-managed router places an address resolution protocol (ARP) frame for server A on source-VLAN. This broadcast frame is seen and picked up by the Network Extension Device/Function at the customer location, encapsulated in the L2TPv3 tunnel, and sent to the Network Extension Device/Function in the DR site. The frame is then placed on DR-VLAN where server A is running.

If the customer-managed router has static ARP table for Server A, this does not work or the static entry needs to be replaced.
Give the network a different Name, such as App and a different Gateway CIDR, such as 192.168.101.1/24.







 Validating that the network is connected to the edge 

Use the steps to add a static route to validate that the Organization virtual data center networks that you defined earlier are listed as static routes. When you click Create (+), locate the Next Hop field, and confirm that 52.117.132.2 is displayed. This value is the internal interface of the edge gateway.

For more information, see [Add a static route](https://docs.vmware.com/en/VMware-Cloud-Director/10.1/VMware-Cloud-Director-Tenant-Portal-Guide/GUID-1C8D8FF7-7C24-4A44-875B-04DB961FB780.html).





 Configuring DHCP on the edge gateway 

Optionally, you can configure DHCP on the edge gateway to assign IP addresses automatically to the VMs connected to the Organization virtual data center networks. This step is not necessary if you are using static IP addresses.

From the virtual data center for that edge gateway, configure the DHCP. Repeat the procedure for extra Organization virtual data center networks that are attached to the edge that requires DHCP services. For more information, see [Add a DHCP IP pool](https://docs.vmware.com/en/VMware-Cloud-Director/10.1/VMware-Cloud-Director-Tenant-Portal-Guide/GUID-EF0B4C79-F6F7-4C75-825C-0B76B888856D.html).

Review the following notes for configuring DHCP on the edge gateway.



* The IP Range is a range from the Organization virtual data center network that is attached to the edge.
* You can define the names for the Primary Name Server and the Secondary Name Server now or update the names later.
* The Default Gateway is the gateway CIDR or the Organization virtual data center network that is attached to the edge.
* Ensure to set the DHCP service status to enabled.
For more information about networking components that are ordered when you deploy the HCX service, see [HCX overview](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcx_considerationshcx_considerations).





 Virtual Server Instances 

Your existing instance contains the following virtual server instances (VSIs):



* A VSI for IBM CloudDriver.
* A single Microsoft® Windows® Server VSI for Microsoft Active Directory™ (AD) or two high availability Microsoft Windows VMs on the management cluster that was chosen at initial deployment.







 vSAN storage 

vSAN storage offers customized configurations, with various options for disk type and quantity:



* Disk quantity: 2, 4, 6, 8, or 10
* Storage disk: 960 GB SSD SED, 1.9 TB SSD SED, or 3.8 TB SSD SED

In addition, two cache disks of 960 GB are included per host.
* High Performance with Intel® Optane: this option provides two extra capacity disk bays. This option depends on the CPU model.







 IBM-provided licenses and fees 

The following licenses are included in your instance.



* VMware vSphere Enterprise Plus 6.7u3
* VMware NSX Service Providers Edition (Advanced or Enterprise) 6.4
* VMware vSAN (Advanced or Enterprise) 6.6



More support and services fees might apply.







 Technical specifications for vCenter Server with Hybridity Bundle expansion nodes 

Each vCenter Server with Hybridity Bundle expansion node deploys and incurs charges for the following components in your IBM Cloud account.



 Hardware for expansion nodes 

One bare metal server with the configuration presented in [Technical specifications for vCenter Server with Hybridity Bundle instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_hybrid_overviewvc_hybrid_overview-specs).





 Licenses and fees for expansion nodes 



* One VMware vSphere Enterprise Plus 6.73
* One VMware NSX Service Providers Edition (Advanced or Enterprise) 6.4
* One Support and Services fee