vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Adding virtual data centers 

With a IBM Cloud® for VMware as a Service single tenant instance, you can control and manage the capacity that is used to run VMware® workloads. You can add virtual data centers (VDCs) to the instance to deploy and run VMware virtualized networking and to run VMware workloads.

You can deploy one or more VDCs in a VMware as a Service single tenant instance. The minimum instance configuration consists of two hosts (2 Sockets - 32 Cores and 192 GB RAM). You can order up to 100 efficiency edges or one performance edge of medium size until more hosts are added to one of the clusters in the provider virtual data center (PVDC).

You must create a Cloud Director site before you create virtual data centers. You can only deploy virtual data centers to an existing Cloud Director site.



 Virtual data center name 

The VDC name is set to vdc-xx by default, where xx represents two randomly generated alphabetic characters.

You can also specify a VDC name that meets the following requirements:



* The maximum length is 128 characters.
* Only alphanumeric, dash (-), and underscore (_) characters are allowed.
* The name must be unique within all active VDCs in your account. You can create a VDC that has the same name as a previously deleted VDC.







 Fast provisioning of virtual machines 

Fast provisioning saves time by using linked clones for virtual machine (VM) provisioning. You can enable fast provisioning for any VDC created within the PVDC. If not enabled, all provisioning operations use full clones.

You can enable or disable fast provisioning from the Data center details page when the VDC is in Available status. For more information, see [Procedure to view the VDC details](https://cloud.ibm.com/docs/vmware-service?topic=vmware-service-vdc-view-deletevdc-view-delete-details).





 Procedure to add virtual data centers 



1. In the VMware Solutions console, click Resources > VMware as a Service from the left navigation pane.
2.
For more information about assigning resource access and roles, see [Managing IAM access for VMware Solutions](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-iam) and [Roles and permissions for Cloud Director](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-iam_vcd&interface=ui).



 Resource Group based access policy updates 

For VMware Shared V4.8 and later, if you have multiple resource groups with different virtual data centers from one specific location, only the resource group that contains the first virtual data center of that location (based on creation date) applies to all of the virtual data centers in that location. Policies apply to the resource group that contains the first virtual data center or you can set a policy at the VMware Solutions service level.

If all of your virtual data centers are in a single location and belong to only one resource group access policy, your site automatically belongs to the same resource group as the virtual data center.

Your existing group membership now has sites that are listed instead of virtual data centers. The site for a virtual data center now belongs to a resource group only if the virtual data center was the first virtual data center of the site.





 Virtual data center based access policy updates 

For VMware Shared V4.8 and later, a new access policy is required at the VMware Solutions service level for all of your resources.

Virtual data center based access policies are now named after the site. If you did not make the required policy updates before the V4.8 release, your virtual data center based policy is ineffective.









 Technical specifications for VMware Shared 

The following components are included in your virtual data center:



 Compute 

Compute processing is allocated to virtual data centers in vCPU increments. Each vCPU increment represents a single 2.0 GHz core. Compute memory is allocated in GB increments.





 Networking 

By default, every virtual data center comes configured with one advanced edge gateway with five public IP addresses and one private service IP address. The advanced edge gateway is customer configurable and can be customized.
vSphere includes a user-configurable events and alarms subsystem, which tracks events that occur throughout the vSphere environment and stores the data in log files and the vCenter database. This subsystem also enables system administrators to specify the conditions under which alarms are triggered. Alarms change state from warnings to more serious alerts as system conditions change, and can trigger automated alarm actions such as to email the system administrator team. This function is useful when you want to be informed, or take immediate action, when certain events or conditions occur for a specific inventory object, or group of objects.

More tools such as those incorporated into the Operations Management on IBM Cloud architecture provide greater assistance with; identifying symptoms, isolating the affected components and proposing a fix or workaround.



 Guidelines 

The following guidelines are considered best practices for troubleshooting your IBM Cloud for VMware Solutions issue.



* Approach troubleshooting and problem-solving systematically.
* Are the symptoms related to; availability, usage, or configuration:



* Availability - These symptoms relate to the availability of hardware and software components and are typified by a no response. Often high availability design masks these issues so that they do not impact your workloads and users directly.
* Usage - These symptoms relate to capacity and performance and are typified by slow-running or in-ability to load. Proactively managing capacity drastically reduces these issues.
* Configuration - These issues are typically discovered in the provision of new services or a result to applying a change. Incorrect settings can surface as either availability or usage symptoms. For example, an incorrect IP address is displayed as an availability issue, whereas low virtual machine (VM) RAM settings cause usage symptoms.



* Try to isolate the issue to a component in the environment.
* Take notes so you can trace your steps.
* Understand and document you software versions.
* Document your subnets and IP address usage, including VIP and NAT addresses.
* Have diagrams of your network. You need a number of diagrams that show the physical (underlay) and logical (overlay) layers.
* Understand any recent changes to the environment.
* Research the impact of the fix, do not lock yourself out of any management interfaces.
VMware HCX on IBM Cloud overview 

The VMware HCX service is not available to Business Partner users.

VMware HCX™ on IBM Cloud extends the networks of on-premises data centers into IBM Cloud®, and it helps you migrate virtual machines (VMs) to and from IBM Cloud without any conversion or change. HCX creates an abstraction layer that enables application mobility and infrastructure hybridity through securely stretched networks. You can modernize your VMware® environment without the need to refactor or modify your existing application, as HCX enables a seamless transformation. With HCX, you can bring your IP subnet ranges into IBM Cloud and ensure the IP consistency through a hybrid deployment and by providing high-level security with end-to-end Suite B encryptions. VMware HCX on IBM Cloud is a non-IBM product that is offered under terms and conditions from VMware, not IBM.

The HCX version available for deployment is periodically updated to the most recent version of HCX. VMware® requires you to be on one of their supported versions in order for you to open a support request for HCX. For more information, see [VMware HCX release notes](https://docs.vmware.com/en/search//VMware%20HCX%204.0.1%20Release%20Notes).

For VMware vCenter Server with NSX-T™ instances, HCX is supported for NSX-T 3.1 or later and for VMware vSphere® 7. HCX requires you to use one of the following licenses from IBM Cloud:



* NSX Data Center SP Base
* NSX Data Center SP Professional
* NSX Data Center SP Advanced
* NSX Data Center SP Enterprise Plus



For vCenter Server® with NSX-V instances (VMware Solutions V4.7 and earlier), HCX is supported for vSphere 6.7. HCX requires you to use one of the following licenses from IBM Cloud:



* NSX Advanced
* NSX Enterprise
The primary private subnet ends in /26 and provides private IPs for up to 62 worker nodes.

You might exceed the initial 14 public and 62 private IPs for worker nodes by having a large cluster or several smaller clusters in the same location on the same VLAN. When a public or private subnet reaches the limit of worker nodes, another primary subnet in the same VLAN is ordered.

To ensure that workers in these primary subnets on the same VLAN can communicate, you must turn on VLAN spanning. For instructions, see [Enable or disable VLAN spanning](https://cloud.ibm.com/docs/vlans?topic=vlans-vlan-spanningvlan-spanning).

To check if VLAN spanning is already enabled, use the ibmcloud ks vlan spanning get --region <region>[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_vlan_spanning_get).





 Managing subnet routing for gateway appliances 

When you create a cluster, a portable public and a portable private subnet are ordered on the VLANs that the cluster is connected to. These subnets provide IP addresses for Ingress application load balancer (ALB) and network load balancer (NLB) services.

However, if you have an existing router appliance, such as a [Virtual Router Appliance (VRA)](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-about-the-vraabout-the-vra), the newly added portable subnets from those VLANs that the cluster is connected to are not configured on the router. To use NLBs or Ingress ALBs, you must ensure that network devices can route between different subnets on the same VLAN by enabling a [Virtual Router Function (VRF)](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf) for your IBM Cloud infrastructure account.
The Direct Link product is meant for your remote networks to be able to privately communicate with your IBM Cloud infrastructure.
6. Be aware if you use Classic IaaS, that infrastructure uses the 10.x.x.x network and you cannot overlap your on-premises hosts within IBM Cloud or with the IBM Cloud services network (10.0.0.0/14, 10.198.0.0/15, and 10.200.0.0/14).
7. Virtual Routing and Forwarding (VRF) is not compatible with IBM Cloud SSL and IPsec VPN services. An alternative is to use the Direct Link itself for management of your servers, or run your own VPN solution (such as a Vyatta) that can be configured with different types of VPNs.

After migrating to a VRF, SSL VPN typically works when a VPN connection is made to the same data center location as the compute that's being accessed, but does not allow access globally.
8. Direct Link Cloud requires Border Gateway Protocol (BGP) to implement routes to a customer's remote network.
9. If you choose to use auto-assign IP addressing, IBM will assign two IP addresses from this network, 169.254.0.0/16 for the BGP point-to-point addresses.

IBM will use the first IP address in the /30 subnet. The customer can use the second IP address from this subnet.
* Ensure you have the [Writer or Manager IBM Cloud IAM service access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) for the default namespace.
* When cluster nodes are reloaded or when a cluster master update includes a new keepalived image, the load balancer virtual IP is moved to the network interface of a new node. When this occurs, any long-lasting connections to your load balancer must be re-established. Consider including retry logic in your application so that attempts to re-establish the connection are made quickly.



To create an NLB 1.0 service in a single-zone cluster:



1. [Deploy your app to the cluster](https://cloud.ibm.com/docs/containers?topic=containers-deploy_appapp_cli). Ensure that you add a label to your deployment in the metadata section of your configuration file. This label is needed to identify all pods where your app runs so that they are in the load balancing.
2. Create a load balancer service for the app that you want to expose to the public internet or a private network.



1. Create a service configuration file that is named, for example, myloadbalancer.yaml.
2. Define a load balancer service for the app that you want to expose.

apiVersion: v1
kind: Service
metadata:
name: myloadbalancer
annotations:
service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: <public_or_private>
service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
spec:
type: LoadBalancer
selector:
<selector_key>: <selector_value>
ports:
- protocol: TCP
port: 8080
targetPort: 8080 Optional. By default, the targetPort is set to match the port value unless specified otherwise.
loadBalancerIP: <IP_address>
Show more
Although a single data center connection between the on-premises network and Megaport network is possible, best practice is to select two different port locations to provide redundancy.



3. Open an IBM Support case against the Power Systems Virtual Server team to configure the Megaport network to the Power Systems Virtual Server router by using VXCs. Remember to include the following pieces of information in your case:

Customer name and contact:
Customer account ID
Service ID (VxC Identifier):

Customer network subnet:
Customer router IP Address:
Power Systems Virtual Server customer network IP address:
Power Systems Virtual Server network ASN: 64999 for WDC04 and 64997 for DAL13
Customer Network ASN:

Customer subnets to be advertised:
Power Systems Virtual Server customer Private Network ID (1):
Power Systems Virtual Server customer Private Network ID (2):
Power Systems Virtual Server customer Private Network ID (3):



The Power Systems Virtual Server router is the default gateway for your Power virtual server instances. This router is operated by the Power Systems Virtual Server team and you have no direct access or control.





 Connecting two Power virtual server environments 

In this deployment topology, [Megaport](https://www.megaport.com/) or Direct Link (2.0) Connect is used to provide connectivity between Power virtual server environments located at two different data centers.

Zoom

![Connecting Power virtual server environments](https://cloud.ibm.com/docs-content/v1/content/1d36273917990fbf48078805e201d2e85e2fcb27/power-iaas/images/network-connect-to-pvs2pvs.svg)

Figure 4. Connecting Power virtual server environments

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.

The key features of this Connect-to-classic topology are as follows:



1.
Managing classic infrastructure VLANs (ibmcloud sl vlan) 

Virtual local area networks (VLANs) are used by IBM Cloud® to isolate broadcast traffic on the public and private networks. VLANs are assigned as needed to fulfill other offerings.

Use the following commands from the IBM Cloud Command Line Interface to manage classic infrastructure VLANs.



 ibmcloud sl vlan create 

Create a new VLAN:

ibmcloud sl vlan create [OPTIONS]

Command options:

-t, --vlan-type
: The type of the VLAN, either public or private.

-r, --router
: The host name of the router.

-d, --datacenter
: The short name of the datacenter.

-n, --name
: The name of the VLAN.

-f, --force
: Force operation without confirmation.

Examples:

ibmcloud sl vlan create -t public -d dal09 -n myvlan

This command creates a public VLAN that is located in datacenter dal09 and name is myvlan.





 ibmcloud sl vlan cancel 

Cancel a VLAN:

ibmcloud sl vlan cancel IDENTIFIER [OPTIONS]

Command options:

-f, --force
: Force operation without confirmation.

Examples:

ibmcloud sl vlan cancel 12345678 -f

This command cancels VLAN with ID 12345678 without asking for confirmation.





 ibmcloud sl vlan detail 

Get details about a VLAN:

ibmcloud sl vlan detail IDENTIFIER [OPTIONS]

Command options:

--no-vs
: Hide virtual server listing.

--no-hardware
: Hide hardware listing.

Examples:

ibmcloud sl vlan detail 12345678 --no-vs --no-hardware

This command shows details of VLAN with ID 12345678, and not list virtual server or hardware server.





 ibmcloud sl vlan edit 

Edit the details about a VLAN:
For more information, see [Working with networks in a vApp](https://docs.vmware.com/en/VMware-Cloud-Director/10.1/VMware-Cloud-Director-Tenant-Portal-Guide/GUID-FCBC791B-3183-4CD9-A194-856E98CC32D3.html).





 Creating a vApp Network for VMware as a Service 

If not already completed, create a vApp containing at least two VMs. For more information, see [Working with vApps](https://docs.vmware.com/en/VMware-Cloud-Director/10.1/VMware-Cloud-Director-Tenant-Portal-Guide/GUID-AC48FB5E-4ADC-4835-AACE-B949B297A147.html).



1. From the tenant portal, click the Menu icon at the upper left of the page and select Data Centers.
2. From the main page under Virtual Data Center, click the virtual data center where you would like to create the vApp network.
3. In the left pane under Compute, click vApps.
4. Click the vApp you would like to add a vApp network to.
5. Click the Networks tab, and click NEW in the vApp Fencing section.
6. Select vApp Network Type.
7. Complete the Name and Gateway CIDR fields. For example, Web and 192.168.33.1/24.
8. (Optional) Provide the DNS information.
9. Leave the Static IP Pools section blank.
10. Set the slider to Connect to an organization VDC network.
11. Click Add.
The remaining host capacity for your VMs depends on several factors, such as oversubscription rate, VM sizing, and workload performance requirements.

For more management resource requirements when you deploy the HCX service, see [HCX overview](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcx_considerationshcx_considerations).





 Infrastructure hybridity 

This layer provides an abstraction of resources between the on-premises sites and IBM Cloud sites so that you can move workloads back and forth securely and easily without the need to change VM characteristics such as their IP addresses.

Based on VMware HCX, you can create loosely coupled interconnects among on-premises and IBM Cloud sites to enable bulk migration of VMs or live vMotion of VMs without downtime.







 Technical specifications for vCenter Server with Hybridity Bundle instances 

The following components are included in your vCenter Server with Hybridity Bundle instance:

The availability and pricing of standardized hardware configurations might vary based on the IBM Cloud data center that is selected for deployment.



 Bare metal server 

Your instance contains four or more IBM Cloud bare metal servers with the server configuration that is selected at initial deployment.





 Networking 

Your instance contains the following networking components:



* 10 Gbps dual public and private network uplinks.
* Three VLANs (Virtual LANs): one public VLAN and two private VLANs.
* One VXLAN (Virtual eXtensible LAN) with DLR (Distributed Logical Router) for potential east-west communication between local workloads that are connected to layer 2 (L2) networks. The VXLAN is deployed as a sample routing topology, which you can modify, build on it, or remove it. You can also add security zones by attaching more VXLANs to new logical interfaces on the DLR.
* Two VMware NSX Edge Services Gateways (ESGs):



* A secure management services ESG for outbound HTTPS management traffic, which is deployed by IBM as part of the management networking typology. This ESG is used by the IBM management VMs to communicate with specific external IBM management components that are related to automation.
The [Virtual Router Appliance (VRA)](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-about-the-vra) provides the latest Vyatta 5600 operating system for x86 bare metal servers. You can use a VRA as VPN gateway to securely connect to an on-premises network.

All public and private network traffic that enters or exits the cluster VLANs is routed through a VRA. You can use the VRA as a VPN endpoint to create an encrypted IPSec tunnel between servers in IBM Cloud infrastructure and on-premises resources. For example, the following diagram shows how an app on a private-only worker node in IBM Cloud Kubernetes Service can communicate with an on-premises server via a VRA VPN connection:

Zoom

![Expose an app in IBM Cloud Kubernetes Service by using a load balancer.](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_vpn_vyatta.png)

Figure 2. Expose an app in IBM Cloud Kubernetes Service by using a load balancer



1. An app in your cluster, myapp2, receives a request from an Ingress or LoadBalancer service and needs to securely connect to data in your on-premises network.
2. Because myapp2 is on a worker node that is on a private VLAN only, the VRA acts as a secure connection between the worker nodes and the on-premises network. The VRA uses the destination IP address to determine which network packets to send to the on-premises network.
3. The request is encrypted and sent over the VPN tunnel to the on-premises data center.
4. The incoming request passes through the on-premises firewall and is delivered to the VPN tunnel endpoint (router) where it is decrypted.
5.
Do not use the internal IP address for the virtual server on classic infrastructure. To find the gateway IP address, select the relevant IBM Cloud service endpoint source IP address in your Virtual Private Cloud Infrastructure.



 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). You can add Secrets Manager to network zones as a service reference to allow Secrets Manager to access resources and services in your account that are the subject of a rule.

The serviceRef attribute for Secrets Manager is secrets-manager.

You can determine which services are available by checking for [reference targets](https://cloud.ibm.com/apidocs/context-based-restrictionslist-available-serviceref-targets).

Example payload to add Secrets Manager to a network zone.

{
"name": "Example zone 1",
"description": "",
"addresses": [
{
"type": "serviceRef",
"ref": {
"service_name": "secrets-manager",
"account_id": "ACCOUNT-ID"
}
}
]
}

Example payload to add multiple services, IP addresses, and VPCs to a network zone.

{
"name": "zone",
"description": "",
"addresses": [
{
"type": "ipAddress",
"value": "192.168.0.0"
},
{
"type": "vpc",
"value": "crn:v1:bluemix:public:is:us-east:a/CRN"
},
{
"type": "vpc",
"value": "crn:v1:bluemix:public:is:us-south:a/CRN"
},
{
"type": "serviceRef",
"ref": {