vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Initial configuration 

The IBM Cloud® for VMware Solutions automation configures the vCenter Server® Appliance (VCSA) with a default gateway set to the IBM Cloud Backend Customer Router (BCR). However, no route to the internet though the BCR exists. The standard route to the internet from the VMware® vCenter Server instance for management components is through the services T0. As it isn't advised changing the configuration of the VCSA or the services T0, a proxy server implementation on the customer subnet is recommended to enable VMware Update Manager (VUM).

This approach means that you don't need to reconfigure the VCSA or the services T0, however, a small virtual machine (VM) must be installed. A proxy server is a system, which sits between two endpoint devices and acts as an intermediate device. In this case, it sits between the VCSA and the update servers at VMware.

When VUM requests a resource from the update server at VMware, the request is sent to the proxy server first, and the proxy server then sends the request to the update server. After the resource is obtained by the proxy server, it sends the resource to VUM. A proxy server can be used to facilitate security, administrative controls, and caching services.

You can use a proxy server based on Linux and Squid. Squid Proxy is an open source caching proxy for the web and supports many protocols that include HTTP and HTTPS. A number of VM and appliance-based proxies are available, and you must select the appropriate one based on your enterprise’s requirements and install and configure following the vendor’s guidance. If you select to use a Squid implementation, continue with the following process.



* Download the Linux ISO to a jump server.
* Create a vCenter Library.
* Upload the ISO to the vCenter Library.
* Create a VM, install, and configure Linux, and install Squid.





 Finding the subnet information 

Before you can start this task, collect the information to populate the following table. Review the suggested values and ensure that they are appropriate for your environment.
* [Virtual Servers for VPC](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-conceptscompute-vsi)
* [Dedicated hosts](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-conceptscompute-dedicated-hosts)
* [Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-conceptscompute-openshift)



* [Storage](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-conceptsstorage)
* [Next steps](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-conceptsnext-steps)



[VPC with virtual servers reference architecture](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-detailed-vsivpc-architecture-detailed-vsi)



* [Architecture diagram](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-detailed-vsivpc-vsi-diagram)
* [Management VPC](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-detailed-vsivpc-architecture-detailed-management)



* [Regions and zones](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-detailed-vsivpc-architecture-detailed-management-regions-zones)
For more information about service endpoints, see [Services that support service endpoints](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointuse-service-endpoint). After you provision a service as a private endpoint, ping the endpoint from your virtual server instance to verify that the endpoint is reachable.

You can also use VPN for VPC to access service endpoints. For more information, see [Access service endpoints through VPN](https://cloud.ibm.com/docs/vpc?topic=vpc-using-vpn).





 IaaS endpoints 

Infrastructure services are available by using certain DNS names from the adn.networklayer.com domain, and they resolve to 161.26.0.0/16 addresses. Services that you can reach include:



* DNS resolvers
* Ubuntu and Debian APT (Advanced Packaging Tool) Mirrors
* Network Time Protocol (NTP)
* IBM Cloud Object Storage



The following ports must be open to allow ADN network traffic to flow for the following services.



Table 2. Ports required for network traffic

 Protocol Port Service 

 UDP 53 DNS 
 TCP 80 HTTP 
 TCP 443 HTTPS 







 Virtual private endpoints 

IBM Cloud services available through IBM Cloud Virtual Private Endpoints (VPE) for VPC are listed at [VPE supported services](https://cloud.ibm.com/docs/vpc?topic=vpc-vpe-supported-services). VPE supports both service and IaaS endpoints. For more information about private connectivity and VPE, see [About virtual private endpoint gateways](https://cloud.ibm.com/docs/vpc?topic=vpc-about-vpe).



 DNS resolver endpoints 

IBM Cloud DNS Services provide private DNS to VPC users. Private DNS zones are resolvable only on IBM Cloud, and only from explicitly permitted networks in an account.
VPC Infrastructure Services Virtual Private Cloud <br><br> * Operator to use an existing VPC<br> * Admin or Editor to create new VPCs<br><br><br> 
 Floating IP for VPC <br><br> * Operator to attach Floating IP<br> * Admin or Editor to create a Floating IP<br><br><br> 
 Subnet <br><br> * either Admin or Editor<br><br><br> 
 Block Storage for VPC <br><br> * either Admin or Editor<br><br><br> 
 Block Storage Snapshots for VPC <br><br> * either Admin or Editor<br><br><br> 
 Security Group for VPC <br><br> * either Admin or Editor<br><br><br> 
 SSH Key for VPC <br><br> * Operator to select existing keys<br> * either Admin or Editor to create new keys<br><br><br> 
 Image Service for VPC <br><br> * Operator<br><br><br> 
 Security Group for VPC <br><br> * either Admin or Editor<br><br><br> 
 Public Gateway <br><br> * either Admin or Editor<br><br><br> 
 Virtual Server for VPC <br><br> * either Admin or Editor<br><br><br> 
 Dedicated Host for VPC <br><br> * either Admin or Editor<br><br><br> 
 Functions All Resources <br><br> * Admin and Manager<br><br><br> 
 Cloud Object Storage All Resources <br><br> * Admin and Manager<br><br><br> 
 Databases for Redis All Resources <br><br> * Editor<br><br><br> 





1. In the IBM Cloud console, go to Manage > Access (IAM) and select Users.
2. Identify the user's name that you want to update access for, select the Actions menu, and click Assign Access.
3.
Common services design 

Common services provide the services that are used by other services in the cloud management platform. The common services of the solution include identity and access services, domain name services, NTP services, SMTP services, and certificate authority services.

Zoom

![Common services](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/vcsv4radiagrams-ra-commonservices.svg)

Figure 1. Common services



 Identity and access services 

In this design, Microsoft® Active Directory (MSAD) is used for Identity Management. The design deploys one or two Active Directory virtual machines (VMs) as part of the vCenter Server deployment automation. vCenter is configured to use the MSAD authentication.



 Microsoft Active Directory 

By default, a single Active Directory VSI is deployed onto the IBM Cloud® infrastructure.

The design also provides the option to deploy two highly available MSAD servers as dedicated Microsoft Windows® Server VMs in the management cluster.

If you choose the option with two highly available MSAD servers, you're responsible to provide Microsoft licensing and activation.

Active Directory serves to authenticate accesses to manage the VMware® instance only and not to house users of the workloads in the deployed instances. The forest root domain name of the Active Directory server equals to the Domain Name Services (DNS) domain name that you specify. This domain name is specified only for the primary vCenter Server instance if multiple instances are linked. For linked instances, each instance contains an Active Directory server that sits in the forest root replica ring. The DNS zone files are also replicated on the Active Directory servers.





 vSphere Single Sign On (SSO) domain 

The vSphere Single Sign On (SSO) domain is used as the initial authentication mechanism for a single instance or multiple linked instances. The SSO domain also serves to connect a VMware instance or multiple linked instances to the MSAD server. The following SSO configuration is applied:
VMware HCX overview 

VMware® HCX™ seamlessly integrates on-premises vSphere® vCenter™ networks into IBM Cloud® for VMware Solutions deployments. Hybrid networking extends on-premises vSphere vCenter networks into the IBM Cloud, supporting bidirectional virtual machine (VM) mobility.

HCX owns the source and destination encryption and decryption processes, ensuring consistent security and providing admission for hybrid workflows such as VM migration and network extension.

This offering creates an optimized, software-defined WAN to increase stretched network performance, enabling performance that approaches LAN speed. HCX also enables bidirectional workload migration to IBM Cloud Networking services. HCX integrates with vSphere vCenter and is managed from the vSphere Web Client.



 HCX services 

IBM Cloud for VMware Solutions provides the following HCX services.



 Interconnect 

This service creates and secures connections between HCX installations, supporting management, migration, replication, and disaster recovery operations. This service is deployed as a virtual appliance.





 WAN optimization 

The WAN Optimization service works with the HCX Interconnect service to improve the network performance through a combination of deduplication, compression, and line conditioning techniques. This service is deployed as a virtual appliance.





 Network extension 

This service extends the VM networks from an HCX-enabled source site to an HCX-enabled remote site. VMs that are migrated or created on the extended segment at the remote site are Layer 2 next to VMs placed on the origin network. This service is deployed as a virtual appliance.





 Bulk migration 

This service uses VMware vSphere® Replication protocol to move VMs in parallel between HCX enabled sites.





 vMotion migration 

This migration method uses the VMware vMotion protocol to move a single VM between HCX enabled sites with no service interruption.





 Disaster Recovery 

The HCX Disaster Recover service replicates and protects VMs to a remote data center.







 Components of HCX 

The VMware HCX service deploys four virtual appliance types that are installed and configured on both the on-premises datacenter and the IBM Cloud target.
Add-on services 

Add-on services are available for your security and compliance, data resiliency and migration, workload solution, professional services, transformation and modernization, and management tool needs.

Add-on services are not supported for all offerings.



 Security and compliance services 



* [Caveonix RiskForesight](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-caveonix_considerations)
* [FortiGate Virtual Appliance](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-fortinetvm_considerations)
* [Entrust CloudControl](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-entrust-cc_considerations)
* [KMIP for VMware](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-kmip_standalone_considerations)
* [F5 BIG-IP](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-f5_considerations)
* [Juniper vSRX](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-juniper-overview)







 Data resilience and migration services 



* [HCX](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcx_considerations)
* [Veeam](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-veeamvm_overview)
* [PrimaryIO HDM](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-managing_pio)
Learning about VMware as a Service architecture and workload isolation 

The IBM Cloud® for VMware as a Service architecture is based on two logical entities that are created uniquely per supported cloud region.



* Management domain - Hosts the IBM® operations tools and all the single-tenant customer management tools except for the networking edges that are used by customer workloads.
* Customer workload domain - Hosts single-tenant IBM Cloud IaaS, networking edges, and customer deployed networking and workload.



Zoom

![VMware as a Service region](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/includes/vmware-service/common/includes/vmware-service/images/vmware-aas-region.svg)

Figure 1. VMware as a Service region

The architecture details VMware as a Service solution components and different architecture layers to provide a dedicated and private implementation for customers. The architecture provides standardized and customizable deployment choices of VMware Cloud Director™ based virtual data center environments.

With single tenant Cloud Director instances and its virtual data center instances, customers can migrate or deploy VMware workloads to the cloud on the IBM-hosted and managed VMware infrastructure. Customer workloads that consist of networking configurations and VMs are isolated to single tenant dedicated infrastructure.



 VMware as a Service management domain architecture 

The management domain contains the components for managing the virtual infrastructure of the workload domains in VMware as a Service. The management domain also provides the foundation for deploying solutions for workload provisioning and operations management.

The management domain consists of tools to support the virtual infrastructure, cloud operations, cloud automation, business continuity, and security and compliance components for VMware as a Service. VMware as a Service allocates separate workload domains per customer instance. Each workload domain is managed by a separate vCenter Server instance and a dedicated NSX-T Manager cluster for scalability. The vCenter Server and VMware NSX-T™ Manager components for these workload domains are running in the management domain too.
In the Select IP Address Network menu, select the service network and choose one of the service network addresses that were assigned to your virtual data center.
* Optionally, enter the destination IP addresses.
* Optionally, enter the destination port.
* Optionally, enter the description. A description can be useful to identify the SNAT rule later.
* Set to Enabled.
* Optionally, enable logging. Logs are not preserved. If you want to have historical data, you must set up a syslog server.



If the DHCP services are enabled on the edge, you can test for internet connectivity by logging in to one of the VMs that are attached to the network for which the firewall and DNAT rules are defined.

The steps differ depending on the VM operating system and network configuration:



* For a Windows VM, renew the DHCP lease. Open a command line and issue the ipconfig /renew command.
* For a Linux VM, type systemctl restart NetworkManager.service. Depending on the type and version of Linux, this command might vary. From the command line, ping 8.8.8.8 or 9.9.9.9. If everything is configured correctly, you receive a reply. If the name resolution is required and no DNS server was defined yet, you can configure either 9.9.9.9 or 8.8.8.8 on the VM, edit the DHCP pool and define it there.







 Destination NAT definition and port forwarding 

A destination NAT allows an outside host, in this case on the internet, to connect to an inside host on the Organization virtual data center network. The destination NAT maps one IP address or port to another IP address or port. The following instructions are an example of configuring DNAT and port forwarding to allow a Windows remote desktop connection to a Windows VM in the Organization virtual data center. Port forwarding is optional.

From the virtual data center for that edge gateway, create the destination NAT definition.
Virtual infrastructure design 

The virtual infrastructure layer includes the VMware® software components that virtualize the compute, storage, and network resources provided in the physical infrastructure layer: VMware vSphere ESXi®, VMware NSX-T™, and optionally VMware vSAN™.

Zoom

![Virtual infrastructure](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/nsx-t-3-ra-diagrams-virtual-infrastructure.svg)

Figure 1. Virtual infrastructure



 VMware vSphere design 

The vSphere ESXi configuration consists of the following aspects:



* Boot configuration
* Time synchronization
* Host access
* User access
* DNS configuration



The following table outlines the specifications for each aspect. After the configuration and installation of ESXi, the host is added to a VMware vCenter Server® and is managed from there.

With this design, you can access the virtual hosts through Direct Console User Interface (DCUI) and vSphere Web Client. Secure Shell (SSH) and ESXi Shell are disabled after provisioning as a best practice.

By default, the only users who can log in directly are the root and ibmvmadmin users for the physical machine of the host. The administrator can add users from the Microsoft® Active Directory™ (MSAD) domain to enable user access to the host. All hosts in the vCenter Server solution design are configured to synchronize with a central NTP server.



Table 1. vSphere ESXi configuration

 Attribute Configuration parameter 

 ESXi boot location In some cases, uses local disks that are configured in RAID 1; in other cases, uses single M.2 boot drive 
 Time synchronization Uses IBM Cloud® NTP server 
 Host access Supports DCUI. SSH and ESXi Shell are supported but not enabled by default 
 User access Local authentication and MSAD
API examples: Public virtual servers profiles 

The following information displays Rest API examples for provisioning public virtual servers that use pre-set profiles.

For more robust API examples, see the following resources:



* [Softlayer_Virtual_Guest API examples](https://sldn.softlayer.com/reference/services/SoftLayer_Virtual_Guest/)
* [Getting a profile list](https://softlayer.github.io/article/vsiflavors/)





 Provisioning a public virtual server with Create Object 

The SoftLayer_Virtual_Guest/createObject API service is the simplest way to provision a public virtual server that uses pre-set profiles.

Not applicable for transient virtual servers.

To provision a public virtual server by using REST, a POST request would be submitted to [https://softlayer.github.io/reference/services/SoftLayer_Virtual_Guest/createObject/](https://softlayer.github.io/reference/services/SoftLayer_Virtual_Guest/createObject/) with the following JSON in the request body.

The following JSON request body is a generic example.



 JSON Request Body 1 

{
"parameters":[
{
"hostname": "public-01-mex01",
"domain": "softlayer.local",
"datacenter": {
"name": "mex01"
},
"operatingSystemReferenceCode": "CENTOS_LATEST",
"networkComponents":
{
"maxSpeed": 100
}
],
"hourlyBillingFlag": false,
"supplementalCreateObjectOptions": {
"flavorKeyName": "B1_1X2X25"
}
}
]
}
Show more







 Provisioning a public virtual server with Place Order Object 

Provisioning a public virtual server that uses pre-set profiles is done by using the SoftLayer_Product_Order/placeOrder API service.

Not applicable for transient virtual servers.
Virtual Server Instances <br><br> * [Auto scale](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-auto-scale-instance-group)<br><br><br> VPC Infrastructure Services (is) 
 Various VPC Infrastructure Services - Block Storage Volume, Security Groups, Subnets <br><br> * [IBM Kubernetes Service](https://cloud.ibm.com/docs/containers)<br><br><br> IBM Kubernetes Service (containers-kubernetes) 
 Secrets Manager <br><br> * [Client-to-site VPN](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-client-to-site-overview)<br> * [Load balancers](https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-vs-elb)<br><br><br> VPC Infrastructure Services (is) 







 Creating network zones by using the API 

You can create network zones by using the create-zone command. For more information, see the [API docs](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-zone).

The serviceRef attribute for VPC Infrastructure Services is is and Cloud Block Storage is server-protect.

{
"name": "Example zone 1",
"description": "",
"addresses": [
{
"type": "serviceRef",
"ref": {
"service_name": "is"
}
}
]
}

{
"name": "Example zone 1",
"description": "",
"addresses": [
{
"type": "serviceRef",
"ref": {
"service_name": "server-protect"
}
}
]
}





 Creating network zones by using the CLI 



1.
Click Create.
6. If your virtual server instance was running when you added the network interface, you must configure the network interface for the instance. You can either stop and then restart the instance, or you can manually configure the interface in the guest operating system. For example, on a Linux-based operating system, you can use the ip link set dev <interface> up to retrieve the IP address configuration for the interface.









 Configuring a virtual server instance with multiple interfaces 

Sometimes virtual servers instances communicate with other instances through multiple network interfaces, for example, to use different subnets for different communication purposes. You might want one subnet for data communication and another subnet for control communication. Because a virtual server instance is configured with a single default route that is associated with the primary network interface, communication on other interfaces might not work initially. (IP spoofing checks for security purposes can also prevent the communication flow on nonprimary network interfaces.)

You can establish communication for a secondary network interface by using one of the following options. These examples are for a Linux platform such as Ubuntu.



* Add a static route for the second subnet.
* Add a separate routing table for the second subnet.



The routing tables for virtual server instances are generated by default when an instance is provisioned. Modifying the generated routing table is a nontrivial task. If you need to modify the routing table of a virtual server instance, when you provision the instance you can include user-data to describe and reconfigure the instance's routing table. Another option is to use a custom image to provision an instance and control what is created for multiple network interfaces. When you use the default images to provision instances, the network configuration is created for you. You have limited control of what is generated.

The following sections describe these solutions in more detail.

Example virtual server setup:



* Two virtual servers (Virtual-server-1 and Virtual-server-2) where both virtual servers belong to the same VPC.
* Each virtual server has two interfaces from two subnets:



* Virtual-server-1 has interface eth0 from net_1_0, and interface eth1 from net_1_1.