vania-janet/multiturn-rag-retrieval-data huggingface dataset:
A newly created compute resource is deployed into this subnet and can also be attached to further subnets.



 Networking connectivity 

[IBM Cloud® Virtual Private Cloud network overview](https://cloud.ibm.com/docs/vpc?topic=vpc-about-networking-for-vpc) demonstrates the connectivity for the environment. Issues with network connectivity can cause delays for your project if you do not plan properly, regardless of how you plan to use your system.

In general, IBM Cloud VPC has a highly available, high-bandwidth network that is connected to every compute resource, be it bare metal servers or physical servers, which, in the VSI case, serve a hypervisor. Each physical server (host), which serves a hypervisor, divides the network into virtual network interfaces (vNICs) that are attached to the virtual server.

Depending on the profile of your virtual server, the total available network bandwidth to the virtual server is in the range of 4 Gbps to 64 Gbps. It's important to consider that each vNIC has a maximum throughput of 16 Gbps, so to achieve maximum throughput, up to 4 additional vNICs must be attached to the virtual server (that is, a virtual server might have a maximum of 5 vNICs attached).

If you need to connect to your virtual or bare metal server through the public internet (also known as inbound to a server), you can order a Floating IP and attach to the server's vNIC, in other words: you can attach one Floating IP per server.

If you want to connect to the public internet from your server (also known as outbound from a server), you need to attach a Public Gateway to the VPC. This gateway provides access to the internet for an entire subnet.

The following inter-connectivity options are available:



* VPC zone to zone,
* VPC to VPC,
* VPC to Classic Infrastructure,
* VPC to IBM Power Systems Infrastructure,
* VPC to on-premises data centers by using a VPC VPN Gateway



When a connection to the public internet is not acceptable because of security measures, you can deploy an IPsec Gateway into your VPC to connect to your server.
Cyber recovery with Bring Your Own appliances 

Cyber recovery is one of five functions that are described in the [NIST Cybersecurity framework](https://www.nist.gov/cyberframework). It is defined as the development and implementation of appropriate activities to maintain plans for resilience and to restore any capabilities or services that are impaired due to a cyber-security incident. The other four functions are identify, protect, detect, and respond.

This documentation describes a high-level architecture that can be used to assist with your custom cyber-recovery requirements. The solution architecture uses a IBM Cloud® for VMware Solutions vCenter Server®, and your choice of bring your own data mover with immutable data storage.

This solution is suitable for clients who want to extend their own existing backup solution with an isolated recovery environment while minimizing costs.

Zoom

![Architecture diagram](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/cr-byo-ire.svg)

Figure 1. Architecture for cyber-recovery isolated environment with bring your own data mover and immutable repository

Key elements of the solution architecture include:



* A vCenter Server instance used for cyber-recovery tasks only, deployed in an IBM Cloud account restricted to cyber-recovery activities. For more information about vCenter Server instances, see [Overview of VMware Solutions](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-solution_overview).
* The vCenter Server instance can use VMware vSAN or use NFS datastores, see [Physical storage design](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-design_physicalinfrastructuredesign_physicalinfrastructure-storage-design).
* The vCenter Server instance does not host production or disaster recovery workloads.
VMware NSX-T design 

VMware® NSX-T™ is designed to address application frameworks and architectures that have heterogeneous endpoints and technology stacks. In addition to VMware vSphere®, these environments can include other hypervisors, KVM, containers, and bare metal servers. NSX-T is designed to span a software defined network and security infrastructure across platforms other than just vSphere alone. While it is possible to deploy NSX-T components without needing vSphere, this design focuses on NSX-T and its integration primarily within a vCenter Server vSphere automated deployment.

As of version 3, NSX-T can run on the vSphere virtual distributed switch (VDS) version 7.0. All new deployments of VMware NSX and vSphere use NSX-T on VDS, and N-VDS is no longer used. Beginning with NSX-T 2.4, the manager VM and the controller VM functions are combined. As a result, three controller or manager VMs are deployed. If on the same subnet, they use an internal network load balancer. If across different subnets, an external load balancer is required.

NSX-T brings many advanced features, such as firewall policies, inclusion of guest introspection within firewall policies, and advanced netflow tracking. Describing these features is beyond the scope of this document. In this design, the NSX-T Management Infrastructure is deployed during the initial vCenter Server® cluster deployment. For more information about NSX-T, see the VMware documentation.



 NSX-T vs NSX-V 

For VMware vSphere Network NSX (NSX-V), review the following more well-known NSX-T objects with similar function to their NSX-V counterparts. Limitations and differences within a vSphere environment are also be discussed.

The following table shows the typically corresponding functions between NSX-T and NSX-V.



Table 1. NSX-V and NSX-T corresponding functions

 NSX-V or vSphere native NSX-T
* For backup services such as Veeam® and IBM Spectrum® Protect Plus, configure your backup job, optionally configure additional storage, and configure monitoring alerts.
* For networking and security services such as F5® BIG-IP and FortiGate Virtual Appliance, configure network interfaces, certificates, high availability (HA) configuration, and rules according to your network topology and other requirements.









 Active Directory 

Complete the following steps to ensure proper single sign-on (SSO) configuration and management.



* Configure the Active Directory® (AD) server update and restart schedule.
* If you choose the option to deploy AD servers into the VMware vSphere® cluster, provide Microsoft® Windows® licensing and activation for the servers to ensure compliance and availability.
* Establish mutual trust between the instance and your on-premises AD server.
* Integrate NSX VPN, if applicable, with AD SSO.
* Integrate VMware ESXi® hosts with AD SSO.







 Maintenance planning 

Complete the following steps to ensure proper planning for software maintenance.



* [Set up VMware Update Manager (VUM)](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vum-intro) through a proxy to obtain VMware updates.
* If applicable, set up vSAN through a proxy to maintain the vSAN Hardware Compatibility List (HCL) database.
* Plan regular maintenance for VMware components that are not supported by VUM. For example, VMware vCenter, PSC, and NSX.
* Review vSphere Enhanced vMotion Compatibility (EVC) configuration. Your cluster might not be configured with EVC enabled if the current version of vSphere does not support EVC for your hardware level.
* Plan regular maintenance for add-on services such as Veeam, Zerto, and F5 BIG-IP.







 Monitoring 

Ensure to plan for and implement the following solutions for monitoring your instance and instance components.



* A logging server that includes log forwarding or collection for all instance components and adequate log retention.
Configuring VPC resources 

Before you start deploying a High Availability (HA) Virtual Network Function (VNF), complete the following tasks:



1.  Create a VPC. For more information, see [Creating a VPC and subnet](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-using-the-ibm-cloud-console&interface=clicreating-a-vpc-and-subnet).
2.  Create a subnet that is to be shared between the VNF's data traffic interface and the Network Load Balancer (NLB).
3.  If the VNF requires a subnet for management traffic, create the subnet. This subnet can be shared between multiple VNFs to support clustering.
4.  Create any additional subnets that might be required for the virtual server instance's workloads that are to be routed through the NLB and VNFs.





  Next step 

[Configuring security groups](https://cloud.ibm.com/docs/vpc?topic=vpc-configure-security-groups)
+ Cloud Migration](https://cloud.ibm.com/docs/wanclouds-vpc-plus)VPC+ Cloud Migration PlatformNetworking[Bandwidth Metering for Classic](https://cloud.ibm.com/docs/bandwidth-metering)Bandwidth Metering for Classic Service[Citrix Netscaler VPX](https://cloud.ibm.com/docs/citrix-netscaler-vpx)Citrix Netscaler VPX Service[Cloud Internet Services (CIS)](https://cloud.ibm.com/docs/cis)Cloud Internet Services (CIS) Service[Content Delivery Network (CDN)](https://cloud.ibm.com/docs/CDN)Content Delivery Network (CDN) Service[DNS Services](https://cloud.ibm.com/docs/dns-svcs)DNS Services Service[Direct Link](https://cloud.ibm.com/docs/dl)Direct Link Service[Direct Link on Classic](https://cloud.ibm.com/docs/direct-link)Direct Link on Classic Service[FortiGate Security Appliance (
* UI
* CLI







 Enabling VRF and service endpoints 

When using the classic infrastructure, you connect to resources in your account over the IBM Cloud® public network by default. You can enable virtual routing and forwarding (VRF) to move IP routing for your account and all of its resources into a separate routing table. If VRF is enabled, you can then enable IBM Cloud service endpoints to connect directly to resources without using the public network.

Virtual Private Clouds (VPCs) are automatically enabled for virtual routing and forwarding (VRF). To enable service endpoints for your VPC, continue to [Enabling service endpoints](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointservice-endpoint).



 Before you begin 

Before you begin, ensure that you meet the following criteria:



* You need a billable account to enable virtual routing and forwarding and IBM Cloud service endpoints.
* You must have access to IBM Cloud infrastructure in your account. Go to the Navigation menu icon ![Navigation Menu icon](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/icons/icon_hamburger.svg) > Classic Infrastructure to verify that you have access.







 Enabling VRF in the console 

VRF allows multiple instances of a routing table to exist in a router and to work simultaneously. When you enable VRF, a separate routing table is created for your account, and connections to and from your account's resources are routed separately on the IBM Cloud network. VRF is enabled at the account level, so all resources are affected by this networking change. For more information about VRF technology and how it affects your account's network routing, see [Virtual routing and forwarding on IBM Cloud](https://cloud.ibm.com/docs/dl?topic=dl-overview-of-virtual-routing-and-forwarding-vrf-on-ibm-cloud).

Enabling VRF permanently alters networking for your account.
Viewing services for vCenter Server instances 

You can view the summary and detailed information of the services that were ordered for your VMware vCenter Server® instances.



  Procedure to view services for vCenter Server instances 



1.  From the IBM Cloud® for VMware Solutions console, click Resources > vCenter Server from the left navigation pane.
2.  In the vCenter Server table, click the instance for which you want to view services.
3.  Click the Services tab and click a service to review information about it, such as the service status and other details.
4.  Depending on the viewed service, you can access the service console by using the credentials that are provided on the service details page and you can manage the service from here.







  Related links 



*  [FAQ](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-faq-vmwaresolutions)
For more information, see [PowerCLI Gather complete Virtual Distributed Switch (VDS) information from VMware vCenter](http://vcloud-lab.com/entries/powercli/powercli-gather-complete-virtual-distributed-switch-vds--information-from-vmware-vcenter).

The VCSA supports a file-based backup and restore mechanism that helps with the recovery of the appliance after a failure. It is only possible to do a file-based backup by using the VCSA management user interface (UI). In the design, an SFTP/SMB share on the Repository server is used as the target directory. This directory, through a Veeam file copy job, is copied to the other region for extra resiliency.

For a file-based restore, the process consists of deploying a new VCSA and restoring the data from the file-based backup to the new appliance.





 NSX Manager 

NSX-T Manager provides the user interface and the API for creating, configuring, and monitoring the NSX-T components, such as virtual network segments, Tier-0 and Tier-1 gateways. NSX-T Manager implements both the management and the control planes for the NSX-T infrastructure. In the design, the protected region and the recovery region have their own NSX-T Manager cluster and the span of the Transport Zones is limited to the region. NSX-T managers per region enable service isolation so that each region is considered to be independent.

The use of the cluster virtual IP address provides high availability of the user interface and API of the NSX-T Manager cluster. The use of vSphere HA enables business continuity of a failed appliance.

Image-based backups of NSX-T manager are not supported. Therefore, it is recommended to configure a scheduled NSX-T appliance backup by using an SFTP server, as the only option with NSX-T. In the design, the SFTP server destination is a directory on the local Veeam Repository server. This Windows® server is configured as an SFTP server and used for the recovery of the backup files when needed.
You can order services for your instance based on your needs, for example, disaster recovery. For more information, see [Ordering services for vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_addingservices).

Add-on services support varies between vCenter Server with NSX-T™ and existing vCenter Server with NSX-V instances V4.7 and earlier.

If you want to migrate your F5 BIG-IP or Veeam services from VMware NSX-V to VMware NSX-T, open an IBM Support ticket by following the steps in [Contacting IBM Support](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-trbl_support).





 Capacity considerations 

For more information about capacity considerations, see [Scaling capacity](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-solution_scaling).





 Related links 



* [vCenter Server overview](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_vcenterserveroverview)
* [Ordering vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_orderinginstance-req)
* [Expanding and contracting capacity for vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_addingservers)
* [Ordering services for vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_addingservices)
vpn is.vpn-server.vpn-server-route.update VPN server route was updated 
 vpn is.vpn-server.vpn-server-route.read VPN server route was retrieved 
 vpn is.vpn-server.vpn-server-route.list VPN server routes were listed 









 Compute resources 

The following tables list the actions that are related to compute resources and the generation of events.



 Instance events 



Table 13. Actions that generate events for Instance

 Resource Action Description 

 instance is.instance.instance.create <br><br> * Instance was created<br> * Includes the state of the allow_ip_spoofing parameter, which disables source/destination checks for network interfaces that are created on the virtual server. When set to false, IP spoofing is not allowed on the interface.<br><br><br> 
 instance is.instance.instance.delete Instance was deleted 
 instance is.instance.instance.update Instance was updated 
 instance is.instance.instance.read One or more instances was retrieved 
 instance is.instance.action.create Instance action was created 
 instance is.instance.action.delete Pending instance action was deleted 
 instance is.instance.instance.start Instance was started 
 instance is.instance.instance.stop Instance was stopped 
 instance is.instance.console-access-token.create A console access token was created 
 instance is.instance.console.read Connection to the console was retrieved 
 instance is.instance.instance.volume-stop Instance was stopped because a volume was suspended when its encryption key was deleted 
 instance is.instance.network-interface_floating-ip.attach Floating IP was associated to instance network interface 
 instance is.instance.network-interface_floating-ip.detach Floating IP was disassociated from instance network interface 
 instance is.instance.volume-attachment.create Instance volume attachment was created 
 instance is.instance.volume-attachment.delete Instance volume attachment was deleted 
 instance is.instance.volume-attachment.update Instance volume attachment was updated 
 instance is.instance.volume-attachment.read One or more instance volume attachments was retrieved
The MPLS VPN allows for federating all edges of the cloud: Classic Infrastructure, Direct Link, and VPC.







 Address prefixes 

Address prefixes are the summary information that is used by a VPC's implicit routing function to locate a destination virtual server instance, regardless of the availability zone in which the destination virtual server instance is located. The primary function of address prefixes is to optimize routing over the MPLS VPN, while pathological routing cases are avoided. All subnets within a VPC must be contained in an address prefix so that all virtual server instances that are in the VPC are reachable from all other virtual server instances in the VPC.





 Cloud service endpoint source addresses 

Cloud service endpoint source addresses are the IP addresses that identify a VPC and zone combination outside of the VPC. For example, a source address is used when a service outside of the VPC is called through a cloud service endpoint. The IP address of the virtual server instance is replaced with an IPv4 address, the source address, which identifies the VPC to the cloud service endpoint. See the following diagram for details:

Zoom

![Address translation example](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc/images/cse-addr-translation.png)

Address translation example

The Cloud service endpoint source address in the diagram is labeled "VPC Address". This address is scoped outside of the customer VPC and so does not collide with customer VSI addresses.





 Data packet flows and the implicit router 

Six different types of virtual server instance data packet flows occur in a VPC. In ascending order of complexity, these flows are:



* Intra-subnet, intra-host (same hypervisor)
* Intra-subnet, inter-host
* Inter-subnet, intra-zone
* Inter-subnet, inter-zone
* Extra-VPC service (for IaaS or CSE access)
* Extra-VPC internet (for internet access)
* [FortiGate Virtual Appliance](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-fortinetvm_considerations)
* [Juniper vSRX](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-juniper-overview)
* [Red Hat OpenShift for VMware](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-ocp_overview)
* [VMware Aria Operations and VMware Aria Operations for Logs](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vrops_overview)



For more information about the services, see [Available services for vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_addingservicesvc_addingservices-available-services).





 Related links 



* [Summary](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_orderinginstance-order-summary)
* [Procedure to order vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_orderinginstance-procedure)
VMware Aria Operations for Networks 

The VMware Aria Operations™ for Networks (formerly known as VMware vRealize® Network Insight) environment consists of two virtual machines (VMs), a Platform (UI) and a controller node.

Zoom

![VMware Aria Operations for Networks diagram](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/opsmgmt-vrninw.svg)

Figure 1. VMware Aria Operations for Networks networking

The VMware Aria Operations for Networks Platform appliance provides the analytics, user interface, and data management and connects to the controller appliance, which collects from the various data sources such as NSX Edges, vCenter. All VMware Aria Operations for Networks components use IBM Cloud® Private portable IP addresses. VMware Aria Operations™ for Logs is configured as the syslog server for VMware Aria Operations for Networks.

Zoom

![VMware Aria Operations for Networks components](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/opsmgmt-vrnicomponents.svg)

Figure 2. VMware Aria Operations for Networks components



 System requirements 

This architecture supports 3000 VMs by using a Medium brick size.

Platform system requirements

Collector system requirements



Table 1. VMware Aria Operations for Networks Platform system requirements

 Attribute Specification 

 vCPU 8 
 Memory 32 GB 
 Disk (thin provisioned) 1 TB 







 Networking 

Deployment of the VMware Aria Operations for Networks appliance requires two IP addresses from the Tooling private portable subnet. Network connectivity VMware Aria Operations for Networks requires access to the following items:



* vCenter Appliance
* VMware Aria Operations for Logs Appliance
* NSX-T or NSX-V Appliances
gateway_interfaces = [module.ibm_vmware_solutions_shared_instance.external_networks_2]
}

service {
protocol = "any"
}
}

resource "vcd_nsxv_snat" "rule_ibm_private" {
edge_gateway = module.ibm_vmware_solutions_shared_instance.edge_gateway_name
network_type = "ext"
network_name = module.ibm_vmware_solutions_shared_instance.external_networks_2

original_address = "${vcd_network_routed.tutorial_network.gateway}/24"
translated_address = module.ibm_vmware_solutions_shared_instance.external_network_ips_2
}
Show more





 Create vApp and VM 

A vApp consists of one or more virtual machines that communicate over a network and use resources and services in a deployed environment. This section creates a vApp, attaches the routed network, and adds a virtual machine to it. The virtual machine is configured with 8 GB of RAM, 2 vCPUs, and based on a CentOS template from the Public catalog.

Zoom

![vApp VM](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution58-vmware-solutions-getting-started/vapp-vm.svg)

vApp VM

resource "vcd_vapp" "vmware_tutorial_vapp" {
name = "vmware-tutorial-vApp"
}

resource "vcd_vapp_org_network" "tutorial_network" {
vapp_name = vcd_vapp.vmware_tutorial_vapp.name
org_network_name = vcd_network_routed.tutorial_network.name
}

resource "vcd_vapp_vm" "vm_1" {