vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Migrating and upgrading to VMware vSphere 

Expand or move your VMware cloud environments to any IBM Cloud® data center quickly and easily by using the VMware management control panel. To migrate and upgrade vSphere workloads, use the following steps as a guide.



1. Gather data.
2. Review the existing architecture:



1. Resource utilization (CPU/Memory/Storage).
2. Track and project growth rates.
3. Identify upcoming future projects.
4. Determine what assigned vlans/subnets/etc are deployed (available in the control portal).
5. Find the self-defined RFC1918 (private) subnets in use for the solution.



3. Review the VMWare documentation and join the VMWare communities:



* [VMware vSphere documentation](https://docs.vmware.com/en/VMware-vSphere/index.html)
* [VMware Technology Network](https://communities.vmware.com/welcome)



4. Update your admin team's training to support VMWare.
5. Plan and design a new architecture.
6. Select a data center that is based on compliance. Work with IBM Cloud® sales to refine your candidate location based on availability of products and services.
7. Define your required VLANs and subnets (portable public and private IPs).
8. Design the vSphere Servers:



1. Review the current IBM Cloud server catalog. Intel Xeon v3 Servers are recommended along with redundant uplinks, redundant power supplies, and RAID-1 for local (boot) disks.
2. Most customers with VMWare follow an N+1 hard capacity ceiling (all VMs can be comfortably allocated to servers with a single node removed (for maintenance/failure/etc).
3. Many customers want a higher "soft ceiling" of 80% (80% capacity on the 'n' server configuration) compared to the more standard 60-75% due to the short turn around of compute.
4.
Transit Key Encryption Keys (TKEKs) 10 pairs of RSA asymmetric key pairs, which are used to securely Bring Your Own Keys (BYOK) into Key Protect. 



The specific parameters that must be set to produce the correct keys can be acquired by opening an IBM Cloud service ticket indicating your desire to purchase Key Protect on Satellite. A Key Protect representative will contact you and initiate the process for you to acquire the necessary configuration information.

Many different tools can be used to create these keys. Consult with Thales technical support to find a secure way to create these keys based on your organization's security policy and compliance requirements.





 Gather the information needed to connect the HSM with the Key Protect console 

In order to [deploy Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-satellite-ui-deploy), you must provide the information to connect to the HSM and to perform the kinds of privileged actions on the HSM that are necessary for Key Protect to function.

You must provide this information for both HSMs.



* HSM IP address: The IP address of your HSM. This is needed in order to connect to the worker nodes that you assigned to Key Protect.
* HSM server certificate: The NTLS communications used by the Thales HSM requires certificate exchanges between the HSM and Key Protect. You must create a TLS certificate in your HSM and provide the certificate Key Protect will use to verify communications from the HSM.
* Partition label: The name of the partition that you created for Key Protect to use.
* Partition crypto officer password: The credential Key Protect needs to login to the relevant partition on the HSM to perform key operations.
* Master key label: Key Protect uses a Master Key Encryption Key in your partition. A label or name is assigned to this key and is used by Key Protect in PKCS#11 API to refer to the master key.
* Signing key label: A label or name for a key in a partition, which is used for data authentication such as data signing and verification.
* Import key label: Key Protect supports importing Bring Your Own Key (BYOK) by a DES3 encryption Key. A label or name is assigned to this key.
kube-aaaa3aaa333aa33aa33a-aaaaaaaaaaa-aaaaaaa-00003a33





 Actions to take before the maintenance period 

Follow these steps to prepare your workers for the maintenance period. Workers can't be scheduled on hosts that are scheduled for maintenance. You can avoid disruptions to your workload by rebooting or replacing your workers so that they move to different hosts that are not undergoing maintenance.



 Workers in Classic clusters 

Follow the steps to reboot the worker before the maintenance period begins.



1. Cordon the worker.

oc cordon <worker_id>
2. Drain the worker.

oc drain <worker_id>
3. Reboot the worker. Make sure you include the --hard option.

ibmcloud oc worker reboot --cluster <cluster_name_or_id> --worker <worker_id> --hard
4. Mark the worker as available to be scheduled.

oc uncordon <worker_id>







 Workers in VPC clusters 

For workers in VPC clusters, the steps to take depend on the flavor of the worker node. To check a worker node's flavor, run ibmcloud oc worker get --worker <worker_id> --cluster <cluster_name_or_id>.

For workers with the cx2., bx2., or mx2. flavors:



1. Cordon the worker.

oc cordon <worker_id>
2. Drain the worker.

oc drain <worker_id>
3. Reboot the worker. Make sure you include the --hard option.

ibmcloud oc worker reboot --cluster <cluster_name_or_id> --worker <worker_id> --hard
4. Mark the worker as available to be scheduled.

oc uncordon <worker_id>



For workers with the cx2d., bx2d., or mx2d. flavors:



1. Cordon the worker.
kube-aaaa3aaa333aa33aa33a-aaaaaaaaaaa-aaaaaaa-00003a33





 Actions to take before the maintenance period 

Follow these steps to prepare your workers for the maintenance period. Workers can't be scheduled on hosts that are scheduled for maintenance. You can avoid disruptions to your workload by rebooting or replacing your workers so that they move to different hosts that are not undergoing maintenance.



 Workers in Classic clusters 

Follow the steps to reboot the worker before the maintenance period begins.



1. Cordon the worker.

kubectl cordon <worker_id>
2. Drain the worker.

kubectl drain <worker_id>
3. Reboot the worker. Make sure you include the --hard option.

ibmcloud ks worker reboot --cluster <cluster_name_or_id> --worker <worker_id> --hard
4. Mark the worker as available to be scheduled.

kubectl uncordon <worker_id>







 Workers in VPC clusters 

For workers in VPC clusters, the steps to take depend on the flavor of the worker node. To check a worker node's flavor, run ibmcloud ks worker get --worker <worker_id> --cluster <cluster_name_or_id>.

For workers with the cx2., bx2., or mx2. flavors:



1. Cordon the worker.

kubectl cordon <worker_id>
2. Drain the worker.

kubectl drain <worker_id>
3. Reboot the worker. Make sure you include the --hard option.

ibmcloud ks worker reboot --cluster <cluster_name_or_id> --worker <worker_id> --hard
4. Mark the worker as available to be scheduled.

kubectl uncordon <worker_id>



For workers with the cx2d., bx2d., or mx2d. flavors:



1.
In this way, the strongSwan VPN pods for one tenant's Helm chart deployment only use the routes on that tenant's worker nodes to forward traffic over the VPN connection to the remote subnet.

Before you use this solution, review the following considerations and limitations.



* By default, Kubernetes places app pods onto any untainted worker nodes that are available. To make sure that this solution works correctly, each tenant must first ensure that they deploy their app pods only to workers that are tainted for the correct tenant. Additionally, each tainted worker node must also have a toleration to allow the app pods to be placed on the node. For more information about taints and tolerations, see the [Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/).
* Cluster resources might not be optimally utilized because neither tenant can place app pods on the shared non-tainted nodes.



The following steps for limiting strongSwan VPN traffic by worker node use this example scenario: Say that you have a multi-tenant Red Hat OpenShift on IBM Cloud cluster with six worker nodes. The cluster supports tenant A and tenant B. You taint the worker nodes in the following ways.



* Two worker nodes are tainted so that only tenant A pods are scheduled on the workers.
* Two worker nodes are tainted so that only tenant B pods are scheduled on the workers.
* Two worker nodes are not tainted because at least 2 worker nodes are required for the strongSwan VPN pods and the load balancer IP to run on.



To limit VPN traffic to tainted nodes for each tenant.



1. To limit the VPN traffic to only workers dedicated to tenant A in this example, you specify the following toleration in the values.yaml file for the tenant A strongSwan Helm chart.

tolerations:
- key: dedicated
operator: "Equal"
value: "tenantA"
effect: "NoSchedule"

This toleration allows the route daemon set to run on the two worker nodes that have the dedicated="tenantA" taint and on the two untainted worker nodes.
Kubernetes version 1.23 change log 

View information about version changes for major, minor, and patch updates that are available for your IBM Cloud® Kubernetes Service clusters that run version 1.23. Changes include updates to Kubernetes and IBM Cloud Provider components.



 Overview 

Unless otherwise noted in the change logs, the IBM Cloud Kubernetes Service provider version enables Kubernetes APIs and features that are at beta. Kubernetes alpha features, which are subject to change, are disabled.

For more information about major, minor, and patch versions and preparation actions between minor versions, see [Kubernetes versions](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions).

Check the [Security Bulletins on IBM Cloud Status](https://cloud.ibm.com/status?component=containers-kubernetes&selected=security) for security vulnerabilities that affect IBM Cloud Kubernetes Service. You can filter the results to view only Kubernetes Cluster security bulletins that are relevant to IBM Cloud Kubernetes Service. Change log entries that address other security vulnerabilities but don't also refer to an IBM security bulletin are for vulnerabilities that are not known to affect IBM Cloud Kubernetes Service in normal usage. If you run privileged containers, run commands on the workers, or execute untrusted code, then you might be at risk.

Some change logs are for worker node fix packs, and apply only to worker nodes. You must [apply these patches](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_update) to ensure security compliance for your worker nodes. These worker node fix packs can be at a higher version than the master because some build fix packs are specific to worker nodes. Other change logs are for master fix packs, and apply only to the cluster master. Master fix packs might not be automatically applied. You can choose to [apply them manually](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_update).
If you have multiple stand-alone worker nodes, remove one at a time.



1. List the worker nodes in your cluster and compare the private IP address from this command with the private IP address that you retrieved in the beginning to find your stand-alone worker nodes.

kubectl get nodes
2. Remove your stand-alone worker node. Use the ID of the worker node that you retrieved with the ibmcloud ks worker ls --cluster <cluster_name_or_ID> command.

ibmcloud ks worker rm --cluster <cluster_name_or_ID> --worker <worker_ID>
3. Repeat these steps until all your stand-alone worker nodes are removed.





What's next?
: Now that you updated your cluster to use worker pools, you can, improve availability by adding more zones to your cluster. Adding more zones to your cluster changes your cluster from a single zone cluster to a [multizone cluster](https://cloud.ibm.com/docs/containers?topic=containers-ha_clustersha_clusters). When you change your single zone cluster to a multizone cluster, your Ingress domain changes from <cluster_name>.<region>.containers.mybluemix.net to <cluster_name>.<region_or_zone>.containers.appdomain.cloud. The existing Ingress domain is still valid and can be used to send requests to your apps.
Debugging worker nodes 

Virtual Private Cloud

Classic infrastructure

Review the options to debug your worker nodes and find the root causes for failures.



 Check worker node notifications and maintenance updates 

Check the IBM Cloud health and status dashboard for any notifications or maintenance updates that might be relevant to your worker nodes. These notifications or updates might help determine the cause of the worker node failures.



1.
Classic clusters

Check the [health dashboard](https://cloud.ibm.com/gen1/infrastructure/health-dashboard) for any IBM Cloud emergency maintenance notifications that might affect classic worker nodes in your account. Depending on the nature of the maintenance notification, you might need to reboot or reload your worker nodes.
2. Check the IBM Cloud [status dashboard](https://cloud.ibm.com/status) for any known problems that might affect your worker nodes or cluster. If any of the following components show an error status, that component might be the cause of your worker node disruptions.



* For all clusters, check the Kubernetes Service and Container Registry components.
* For Red Hat Openshift clusters, check the Red Hat OpenShift on IBM Cloud component.
* For VPC clusters, check the Virtual Private Cloud, Virtual Private Endpoint and Virtual Server for VPC components.
* For Classic clusters, check the Classic Infrastructure Provisioning and Virtual Servers components.









 Quick steps to resolve worker node issues 

If your worker node is not functioning as expected, you can follow these steps to update your cluster and command line tools or run diagnostic tests. If the issue persists, see [Debugging your worker node](https://cloud.ibm.com/docs/openshift?topic=openshift-debug_worker_nodesworker-debug-steps) for additional steps.



1. [Update your cluster and worker nodes to the latest version](https://cloud.ibm.com/docs/containers?topic=containers-updateupdate).
2. [Update your command line tools](https://cloud.ibm.com/docs/openshift?topic=openshift-cli-update).
3.
In the RackWare web console, navigate to Replication > Waves.
2. When you create a wave, select Target Type as Autoprovision.
3. Enter source and target details.



If the source machine has a Linux® operating system and it has a boot volume greater than 100 GB, then leave ‘Provision disk’ textbox empty and select Convert to LVM option. This creates additional disk of required size and will convert all eligible volumes to LVM on the target. In case of Windows, no action is required. It is taken care automatically by RMM.



4. After you enter your source and target information, you need to provide your IBM Cloud VPC information.
5. From the edit option in Actions menu of your source, select the IBM Cloud VPC Options tab, enter the relevant information, and click Modify.
6. Run the replication.



Ensure that your VPC, subnet, and other necessary cloud components are set up before you add a cloud user in RMM.





 Assigning environment to wave 



1. In the RackWare web console, navigate to Replication > Waves.
2. Select the wave that needs to be migrated.
3. On the Wave Detail page, select the Autoprovision option as Not configured.
4. Select your cloud user for the Environment, enter the region where the virtual server instance needs to be provisioned, and apply the changes.



Auto-provision feature is not available if target is VPC bare metal. User needs to select Existing System as target type in this case.









 Step 3: Prepare source and target servers 

There are a few things that need to be done on the source and target server for the migration to work. The RMM server needs to SSH into the machines; thus, the RMM public SSH keys need to be copied onto both the source and target servers. In addition, if the source server has both public and private interfaces, host routes need to be added to ensure the communication between the source and target servers occurs over the transit gateway path. Complete the following steps to prepare your relevant servers.



 Linux systems 



1. Copy the RMM SSH public key to both the source and target servers.
2.
Instead, all a bare metal machine's resources are dedicated exclusively to the worker, so you don't need to worry about "noisy neighbors" sharing resources or slowing down performance. Bare metal servers are dedicated to you, with all its resources available for cluster usage.

Encrypted disks
: By default, every worker node is provisioned with two local SSD, AES 256-bit encrypted data partitions. The first partition contains the kernel image that is used to boot the worker node and is not encrypted. The second partition holds the container file system and is unlocked by using LUKS encryption keys. Each worker node in a cluster has its own unique LUKS encryption key, managed by Red Hat OpenShift on IBM Cloud. When you create a cluster or add a worker node to an existing cluster, the keys are pulled securely and then discarded after the encrypted disk is unlocked. Encryption can impact disk I/O performance. For workloads that require high-performance disk I/O, test a cluster with encryption both enabled and disabled to help you decide whether to turn off encryption.

SELinux
: Every worker node is set up with security and access policies that are enforced by [Security-Enhanced Linux (SELinux)](https://www.redhat.com/en/topics/linux/what-is-selinux) profiles that are loaded into the worker node during bootstrapping. SELinux profiles can't be changed by the user or owner of the machine.

SSH disabled
: By default, SSH access is disabled on the worker node to protect your cluster from malicious attacks. When SSH access is disabled, access to the cluster is forced via the Red Hat OpenShift API server. The Red Hat OpenShift API server requires every request to be checked against the policies that are set in the authentication, authorization, and admission control module before the request is executed in the cluster.
If no app pod exists on the same worker node as the load balancer service pod, the NLB forwards the request to a different worker node. The source IP address of the package is changed to the public IP address of the worker node where the load balancer service pod runs.

To preserve the original source IP address of the client request, you can [enable source IP](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/preserving-the-client-source-ip) for load balancer services. The TCP connection continues all the way to the app pods so that the app can see the actual source IP address of the initiator. Preserving the client’s IP is useful, for example, when app servers have to apply security and access-control policies.

After you enable the source IP, load balancer service pods must forward requests to app pods that are deployed to the same worker node only. Typically, load balancer service pods are also deployed to the worker nodes that the app pods are deployed to. However, some situations exist where the load balancer pods and app pods might not be scheduled onto the same worker node:



* You have edge nodes that are tainted so that only load balancer service pods can deploy to them. App pods are not permitted to deploy to those nodes.
* Your cluster is connected to multiple public or private VLANs, and your app pods might deploy to worker nodes that are connected only to one VLAN. Load balancer service pods might not deploy to those worker nodes because the NLB IP address is connected to a different VLAN than the worker nodes.



To force your app to deploy to specific worker nodes where load balancer service pods can also deploy to, you must add affinity rules and tolerations to your app deployment.



 Adding edge node affinity rules and tolerations
This is intended strictly for optimizing autoscaler algorithm latency and should not be used as a rate limit for scale-up. 1000 
 maxRetryGap The maximum time in seconds to retry after failing to connect to the service API. Use this parameter and the retryAttempts parameter to adjust the retry window for the cluster autoscaler. 60 
 parallelDrain Set to true to allow parallel draining of nodes. false 
 maxScaleDownParallelism The maximum number of nodes, both empty and still needing to be drained, that can be deleted in parallel. 10 
 maxDrainParallelism Maximum number of nodes that still need to be drained that can be drained and deleted in parallel. 1 
 nodeDeletionBatcherInterval How long in minutes that the autoscaler can gather nodes to delete them in batch. 0m 
 nodeDeleteDelayAfterTaint How long in seconds to wait before deleting a node after tainting it. 5s 
 enforceNodeGroupMinSize Set this value to true to scale up the worker pool to the configured min size if needed. false 
 resourcesLimitsCPU The maximum amount of worker node CPU that the ibm-iks-cluster-autoscaler pod can consume. 600m 
 resourcesLimitsMemory The maximum amount of worker node memory that the ibm-iks-cluster-autoscaler pod can consume. 600Mi 
 coresTotal The minimum and maximum number of cores in the cluster. Cluster autoscaler does not scale the cluster beyond these numbers. 0:320000 
 memoryTotal Minimum and maximum amount of memory in gigabytes for the cluster. Cluster autoscaler does not scale the cluster beyond these numbers. 0:6400000 
 resourcesRequestsCPU The minimum amount of worker node CPU that the ibm-iks-cluster-autoscaler pod starts with. 200m 
 resourcesRequestsMemory The minimum amount of worker node memory that the ibm-iks-cluster-autoscaler pod starts with. 200Mi 
 retryAttempts The maximum number of attempts to retry after failing to connect to the service API.
* If the ordering service has a system channel you will be taken back to the Channels tab and you can see a pending tile of the channel that you just created (under the Peer channels section).
* If the ordering service does not have a system channel you will be taken to the wizard to join orderer nodes. Select the orderer Ordering Service (osmsp) and click Join channel. You will now be taken back to the Channels tab.









 Task: Create a channel 



Table 14. Create a channel

 Field Name 

 Channel name channel1 
 Ordering Service Ordering Service 
 Organizations Org1 MSP 
 Channel update policy 1 out of 1 
 Access control list None 
 Channel creator MSP Org1 MSP 
 Identity Org1 MSP Admin 



The next step is to join a peer to this channel.









 Step five: Join your peer to the channel 

We are almost done. Joining the peer to the channel is the last step in setting up the basic infrastructure for your network. If you are not already there, navigate to the Channels tab in the left navigation.

Perform the following steps from your console:



1. Click the pending tile for channel1 to launch the side panel.
2. Select which peers you want to join to the channel. For purposes of this tutorial, click the box next to Peer Org1.
3. Leave the checkbox for Make anchor peer selected. It is a best practice for each organization to have at least one anchor peer on each channel, as anchor peers bootstrap the inter-organizational communication that enables features like [Private Data](https://hyperledger-fabric.readthedocs.io/en/release-2.2/private-data/private-data.html) and [Service Discovery](https://hyperledger-fabric.readthedocs.io/en/release-2.2/discovery-overview.html) to work. While it is only necessary to have one anchor peer on each channel, it does not hurt to make all peers anchor peers.