vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more information, see [Change Controller password](https://docs.vmware.com/en/VMware-NSX-Data-Center-for-vSphere/6.2/com.vmware.nsx.admin.doc/GUID-2667DD9E-E2F5-4403-BAC2-C7D1BBC23228.html).
* You can change the password and the SSH settings for the customer-managed NSX ESG. This password is not displayed in the VMware Solutions console, but you can set a new password without the old password. For more information, see [Change CLI credentials](https://docs.vmware.com/en/VMware-NSX-Data-Center-for-vSphere/6.4/com.vmware.nsx.admin.doc/GUID-1DB9DE43-6B54-4FD1-903A-2DFFB87CD7FA.html?hWord=N4IghgNiBcIKYBMDmcAEAHMBnLB3A9gE4IgC+QA).
* Do not change the passwords for the management VMware NSX ESG and the related Distributed Logical Router.



* automation ID

The automation ID is a user account that is used by the automated operations that are provided in the VMware Solutions console.

Users and passwords for the automated operations in the console must not be changed because the console operations that depend on those credentials might fail.
* Service-specific user accounts

Each service creates an internal user account in VMware vCenter Server®. This account is necessary so that management operations that are associated to a service can connect to vCenter Server to perform the operations on the service.

To prevent outages and connection problems, if you change the user ID, password, or password expiration settings for this user account, ensure that you also update the information in the associated service.

The user ID for this account is in the format <service_name>-<truncated service_uuid>@test.local or <service_name>-<truncated service_uuid>@example-domain.local.
FAQs: Bare metal servers 



 What is UEFI boot mode? 

The Unified Extensible Firmware Interface (UEFI) is a specification for the software interface between an operating system and firmware.

IBM Cloud® support for BIOS boot mode is phasing out in favor of UEFI.

For more information about UEFI, see your hardware manufacturer documentation or go to [https://uefi.org/](https://uefi.org/).





 Why is my BIOS asking for a password? 

IBM Cloud® does not provide you with direct access to your BIOS. However, you can change the BIOS. If you need to modify anything in the BIOS, including boot order, create a support case by going to Support > Create a Case through the [IBM Cloud console](https://cloud.ibm.com/) and request the specific changes that you need.

This change requires a restart of your server, so be ready to approve a restart and provide a timeframe for when you want to implement like the changes.





 Do you provide complimentary OS Reloads? 

Automated OS reloads are free and are performed through the [IBM Cloud console](https://cloud.ibm.com/). Customized OS reloads (changing operating systems, addition or removal of control panels, and partition editing, and so on) are included. For more information about performing an OS Reload, see [OS Reload procedure](https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-reloading-the-os).





 The primary drive on my bare metal server shows up as /dev/sdb. What is wrong? 

This problem can be caused by the IPMI's Virtual Disk taking up the /dev/sda slot. You can safely disable the primary drive by connecting to IPMIView and clicking the Virtual Media tab. Select Options > Disable and click Apply to make the change. When the Bare Metal Servers is restarted next, the primary drive displays /dev/sda.





 Why is the CPU speed wrong?
* a) The Acme crashed into the concrete barrier.
* b) The sedan crashed into the concrete barrier.
* c) The Acme A-160 truck crashed into the concrete barrier.



You can handle the type system design in two ways:



1. Define two entity types: MANUFACTURER and VEHICLE. For the MANUFACTURER entity, define a VEHICLE role that can be used in addition to the default MANUFACTURER role.

Using this type system, the sentences are annotated as follows:



* a) The Acme is annotated as a MANUFACTURER entity, but with a role of VEHICLE, since it refers to an actual vehicle. So, its internal label is MANUFACTURER-VEHICLE.
* b) The sedan is annotated as entity type VEHICLE. It is automatically assigned the VEHICLE role, since no other role is defined.
* c) The Acme is annotated as entity type MANUFACTURER and truck is annotated as entity type VEHICLE. No roles are assigned, so the default roles are used.



2. Define two entity types only without roles: MANUFACTURER and VEHICLE.

Using this type system, the sentences are annotated as follows:



* a) The Acme is annotated as entity type VEHICLE.
* b) The sedan is annotated as entity type VEHICLE.
* c) The Acme is annotated as entity type MANUFACTURER and truck is annotated as entity type VEHICLE.





How do the two different type systems perform? Let's assume that a set of documents were annotated by human annotators. After the annotation pass, the following training events, which are manually labeled entities, are identified in the training corpus:



* Type system 1

MANUFACTURER-MANUFACTURER 800 events
MANUFACTURER-VEHICLE 200 events
VEHICLE-VEHICLE 400 events
* Type system 2

MANUFACTURER 800 events
VEHICLE 200 + 400 = 600 events



When the model processes new documents, it is likely that Acme will be labeled as a MANUFACTURER most of the time because the spelling of a word is a strong feature and the word Acme will probably be defined in the MANUFACTURER dictionary. It would take a lot of context to label it differently.
ID: abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
Format: generic
Project Name: myproject
Project ID: 01234567-abcd-abcd-abcd-abcdabcd1111
Age: 66s
Created: 2023-03-07 21:06:34 +0000 UTC

Data:
---
TARGET: TXkgbGl0ZXJhbCBzZWNyZXQ=

Notice that the value of the key TARGET for this generic secret is encoded. To display the secret data as decoded, use the --decode option with the secret get command.





 Creating a registry secret with the CLI 

A registry secret stores credentials to access a container registry.

The following example creates a registry secret that is named mysecret-registry to access an IBM Cloud Container Registry instance that is on the us.icr.io registry server and specifies credentials for username and password.

ibmcloud ce secret create --name mysecret-registry --format registry --server us.icr.io --username iamapikey --password API_KEY

To display the details of this secret,

ibmcloud ce secret get --name mysecret-registry

Example output

Getting secret 'mysecret-registry'...
OK

Name: mysecret-registry
ID: abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
Format: registry
Project Name: myproject
Project ID: 01234567-abcd-abcd-abcd-abcdabcd1111
Age: 66s
Created: 2023-03-07 20:00:45 +0000 UTC

Data:
---
email: ""
password: REDACTED
server: dXMuaWNyLmlv
username: aWFtYXBpa2V5

Notice that the value of the username and server keys for this registry secret is encoded, and the value of password is redacted.
* force-wsc.jar (from Force.com Web Service Connector (WSC))
* commons-beanutils.jar (from Apache Commons BeanUtils)



2. Compress the JAR files into a compressed file. You will upload the compressed file to Discovery in the next procedure.





 Connecting to a Salesforce data source 

From your Discovery project, complete the following steps:



1. From the navigation pane, choose Manage collections.
2. Click New collection.
3. Click Salesforce, and then click Next.
4. Name the collection.
5. If the language of the documents in Salesforce is not English, select the appropriate language.

For a list of supported languages, see [Language support](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-language-support).
6. Optional: Change the synchronization schedule.

For more information, see [Crawl schedule options](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-collectionscrawlschedule).
7. In the Specify what you want to crawl section, enter values in the following fields:

Username
: The username to call the Salesforce API.

Password
: The password of the specified user.

Security Token
: The security token of the user to call Salesforce API.

Jar zip archive file
: Upload a compressed file that contains the JAR files that you downloaded earlier. Or select a compressed file that you uploaded previously to reuse it.
8. Optional: Expand the Proxy settings section to add information that is required if you are using a proxy server to access the data source server.



* Enable proxy settings: Set the switch to On, and then add the following information:

Username
: The proxy server username to use to authenticate, if the proxy server requires authentication. If you do not know your username, you can get it from the administrator of your proxy server.

Password
: The proxy server password to use to authenticate, if the proxy server requires authentication.
For more information, see [Create a new stand-alone virtual machine](https://docs.vmware.com/en/VMware-Cloud-Director/10.1/VMware-Cloud-Director-Tenant-Portal-Guide/GUID-12E43116-1120-45FA-A1E7-AEBEE61373C1.html).



 Customizing virtual machine properties 

You can edit the properties of a VM, including the VM name and description, hardware and network settings, and operating system settings for a guest.

For more information about working with VMs, see [Working with virtual machines](https://docs.vmware.com/en/VMware-Cloud-Director/10.3/VMware-Cloud-Director-Tenant-Portal-Guide/GUID-DF0C111D-B638-4EC3-B805-CC33994F8D53.html).

If you use the tenant portal Password Reset field to change your Windows Administrator password, ensure that you adhere to Windows complexity requirements. If you change the password in the tenant portal without doing so, the password does not work in the Windows VM template.



 Changing the general properties of a virtual machine 

You can change the name, description, storage policy, and other general properties of a VM.



 Switching between storage properties 

Some disk settings cannot be changed while the VM is powered on. For example, you can increase the disk size while the VM is powered on, but you cannot decrease the disk size unless the VM is powered off. A message displays if you must power off the VM before you modify a disk setting. For more information, see [Power off a virtual machine](https://docs.vmware.com/en/VMware-Cloud-Director/10.0/com.vmware.vcloud.tenantportal.doc/GUID-2323B049-4E36-4510-999E-F2D4A77AC0F9.html).
Instead, to replicate specific documents, add the list of keys as an array in the doc_ids field.

See the following example replication of specific documents:

{
"source": "https://$USERNAME:$PASSWORD@example.org/example-database",
"target": "https://$USERNAME:$PASSWORD@127.0.0.1:5984/example-database",
"doc_ids": ["foo", "bar", "baz"]
}





 Replicating through a proxy 

If you want replication to pass through an HTTP proxy, provide the proxy details in the proxy field of the replication data.

See the following example that shows replication through a proxy:

{
"source": "https://$USERNAME:$PASSWORD@$ACCOUNT.cloudant.com/example-database",
"target": "https://$USERNAME:$PASSWORD@example.org/example-database",
"proxy": "https://my-proxy.com:8888"
}





 The user_ctx property and delegations 

Replication documents can have a custom user_ctx property. This property defines the user context under which a replication runs.

An older way of triggering replications, by making a POST to the /_replicate/ endpoint, didn't need the user_ctx property. The reason is that at the moment of triggering the replication, all the necessary information about the authenticated user is available.

By contrast, the replicator database is a regular database. The information about the authenticated user is only present at the moment that the replication document is written to the database. In other words, the replicator database implementation is similar to a _changes feed consumption application, with ?include_docs=true set.

For replication, this implementation difference means that for nonadmin users, a user_ctx property that includes the user's name and a subset of their roles must be defined in the replication document. This requirement is addressed by a validation function present in the default design document of the replicator database. The function validates each document update.
After a password is generated, you must capture it. If the password is lost or you get locked out of your account, you can generate a new password at any time.







 Procedure to access the VMware Cloud Director console 



1. On the VDC details page, click VMware Cloud Director console to access the console.
2. Use the admin username and password to log in to the VMware Cloud Director console for the first time.

After the admin is logged in to the VMware Cloud Director console, you can create extra users who have roles that allow them to access the VMware Cloud Director console.







 Related links 



* [Adding virtual data centers](https://cloud.ibm.com/docs/vmware-service?topic=vmware-service-vdc-adding)
* [Viewing and deleting virtual data centers](https://cloud.ibm.com/docs/vmware-service?topic=vmware-service-vdc-view-delete)
* [Viewing VMware as a Service instances](https://cloud.ibm.com/docs/vmware-service?topic=vmware-service-tenant-viewing)
db2cli validate -dsn <alias> -connect -user <user_id> -passwd <password>

where <alias> is a DSN alias that you created by using the db2cli writecfg command, <user_id> is your Db2 on Cloud user ID, and <password> is your Db2 on Cloud database password.



* To create a connection without SSL, complete the following steps:

a. Catalog the Db2 on Cloud node so that client applications can connect to it. Issue the following command:

db2 catalog tcpip node <node_name> remote <Db2_Warehouse_IP_address> server <port_number>

where:

<node_name> is your name for the node.

<Db2_Warehouse_IP_address> is the IP address of the Db2 on Cloud server.

<port_number> is the port that is used to connect to Db2 on Cloud without using an SSL connection. If you are using the default port, specify 50000.

b. Catalog the remote Db2 on Cloud database so that client applications can connect to it. Issue the following command:

db2 catalog database bludb as <db_alias> at node <node_name>

where <db_alias> is your name for the Db2 on Cloud database.

c. Test the non-SSL connection in one of the following ways:



* Test the connection by using CLP by issuing the following command to connect to the Db2 on Cloud database:

db2 connect to <db_alias> user <user_id>

where <user_id> is your Db2 on Cloud user ID. You are prompted to enter your password.
* Test the connection by using CLI by issuing the following command to connect to the Db2 on Cloud database:

db2cli validate -dsn <alias> -connect -user <user_id> -passwd <password>

where <alias> is a DSN alias that you created by using the db2cli writecfg command, <user_id> is your Db2 on Cloud user ID, and <password> is your Db2 Warehouse on Cloud password.
MANUFACTURER-MANUFACTURER 800 events
MANUFACTURER-VEHICLE 200 events
VEHICLE-VEHICLE 400 events
* Type system 2

MANUFACTURER 800 events
VEHICLE 200 + 400 = 600 events



When the model processes new documents, it is likely that Acme will be labeled as a MANUFACTURER most of the time because the spelling of a word is a strong feature and the word Acme will probably be defined in the MANUFACTURER dictionary. It would take a lot of context to label it differently. If we use type system 1, there are only 200 MANUFACTURER-VEHICLE training events, which is a disadvantage when compared to the 600 events of VEHICLE in type system 2. However, the training event clusters in type system 1 are all quite uniform, which leads to better performance. For type system 2, the set of 600 training events for VEHICLE is actually composed of two rather disjoint clusters: one contains manufacturer names that refer to actual vehicles, such as Acme and Ford, and the other contains vehicle types, such as sedan, SUV, and truck. Intuitively, each of these two clusters themselves are uniform, but by mixing them together, it dilutes the training cluster and presents a tougher problem to solve. If you keep doing annotation and adding more training events, performance in type system 1 keeps getting better, whereas, the problem of resolving two disjoint clusters that you get with type system 2 does not improve with more training.
In the Connect to Oracle Server dialog box, provide the following information.



* In the Database Service Name box, type the database instance.
* In the username box, type the name of a user who has sysdba privileges.
* In the Password box, type the password for the specified user.



6. Click Connect.
7. In the Create New Job dialog box, specify the following information.



* In the Name box, type a name for the backup job.
* In the Description box, type a description for the backup job. The description is optional.
* In the Destination list, select the vault where you want to save the backup data.

A vault appears in the list if it is assigned to the user, or if the user added it in the computer’s Vault Settings.
* In the Log File Options list, select the level of detail for job logging. For more information, see [log file options](https://cloud.ibm.com/docs/Backup?topic=Backup-configureOracleBackupODBLogfile).
* For new backup jobs, the encryption method is AES 256 bit. Existing jobs can have other encryption methods. For more information, see [encryption settings](https://cloud.ibm.com/docs/Backup?topic=Backup-configureOracleBackupODBEncrypt).
* In the Password and Confirm Password boxes, enter an encryption password. You can also enter a password hint in the Password Hint box.



8. In the Include in Backup box, select the database that you want to back up.
9. Click Save. The job is now created, and the View/Add Schedule dialog box appears. Next, you can create a schedule for running the backup. Click Cancel if you don't want to create a schedule now.







 Scheduling the backup job 



1. In the View/Add Schedule dialog box, click Add Schedule.
2. In the new schedule row, in the Retention list, click a retention type.
3. In the Schedule box, click the arrow.
4.
Then, you can register a virtual server for the SQL Server role in the Portal and create and run backup jobs on the virtual server. Backup jobs on a virtual server are automatically directed to the active cluster node and do not reseed after a failover.

To fully protect an SQL Server cluster, you must back up:



* The quorum disk,
* Each physical node in the cluster,
* Cluster volumes,
* The SQL Server databases to provide point-in-time database recovery.



When a cluster is fully protected, you can recover the cluster if components are lost, are corrupted, or fail.





 Advanced settings 



 Log file options 

When you create or edit a backup job, you can specify the level of detail for job logging. Select one of the following logging levels from the list.



* Files - this setting provides the most detailed information, and is typically used for troubleshooting. Provides information about files that are backed up.
* Directory - This setting provides less detail than the Files logging level. Provides information about folders that are backed up.
* Summary - This setting provides high-level information, including the vault and IBM Cloud Backup for Classic Agent version, and backup sizes.
* Minimal - This setting provides high-level information, including the vault and IBM Cloud Backup for Classic Agent version.



Changing the logging level affects only the log files that are created at that point and after. It does not affect previously created log files.





 Encryption settings and password 

Encryption settings specify the encryption type for backup data at rest on the vault. AES 256-bit encryption is the default encryption type available for new backup jobs. When you create a backup job, you must enter a password for the encrypted data. The password is case-sensitive. To recover the data, you must provide the encryption password that was entered when the files were backed up. You can also enter a password hint. When you want to restore data, you can view the password hint to remind you of the encryption password for this job.

If you forget the encryption password, you lose access to the data. You cannot retrieve the password from the system.







 Downloading the user guide
Use this key to [SSH log in to VSIs](https://cloud.ibm.com/vpc-ext/compute/sshKeys). Make sure SSH key exists in the same region where VPC is created.





 Required parameters for WebSphere Application Server 

deploy_was_topology
: The topology to install. Specify a supported topology, WAS.Base or WAS.Cell.

vsi_os_admin_password
: The password for vsi_os_admin_name to log in to a VSI. The password must have 12 or more characters and must contain only letters, numbers, and the -_=?.@#% special characters.

vsi_websphere_admin_password
: The password for vsi_websphere_admin_name to log in to the administrative console and VSI. The password must have 12 or more characters and must contain only letters, numbers, and the -_=?.@#% special characters.





 Optional parameters for WebSphere Application Server 

base_vsi_profile
: The instance profile for the WAS base VSI in a WAS.Base topology. The default is cx2-2x4. See [available profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-profiles) and [pricing](https://www.ibm.com/cloud/vpc/pricing).

cell_dmgr_vsi_profile
: The instance profile for the DMgr VSI in a WAS.Cell topology. The default is cx2-2x4. See [available profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-profiles) and [pricing](https://www.ibm.com/cloud/vpc/pricing).

cell_ihs_setup_vsi
: When set to true, sets up the IBM HTTP Server VSI in a WAS.Cell topology. The default is true. Only applicable when deploy_was_topology is WAS.Cell.

cell_ihs_vsi_profile
After the Windows instance is provisioned and ready, you need to retrieve the Administrator password and connect to it.









 Step 4: Connecting to your Windows VSI 

To be able to connect to the Windows VSI from your client, you need the Administrator password and a public IP address. The password is retrieved by the IBM Cloud command-line interface (CLI) whereas the public IP address - it is called Floating IP - can be created with the IBM Cloud console.



 Install CLI 

Before you can use the CLI to retrieve the Administrator password, you must [install the IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started) and [the VPC CLI plug-in](https://cloud.ibm.com/docs/vpc?topic=vpc-set-up-environmentcli-prerequisites-setup).





 Connect to IBM Cloud with the CLI 

Log in to IBM Cloud with your IBMid. If you have multiple accounts, you are prompted to select which account to use. ``` {: codeblock} ibmcloud login

If your credentials are rejected, you might be using a federated ID. To log in with a federated ID, use the --sso flag. See [Logging in with a federated ID](/docs/account?topic=account-federated_id) for more details.
{: tip}

 Set the target region (DC)

Look up your region code in the table that corresponds to the location of your VPC.

 Region Location 

 au-syd Sydney 
 jp-tok Tokyo 
 eu-de Frankfurt 
 eu-gb London 
 us-south Dallas 
 us-east Washington DC 

For example:

Show more

ibmcloud target -r eu-de

 Get the instance ID

ibmcloud is ins

Find the instance ID that is assigned to your VSI sap-wdb.

 Retrieve the Administrator password

ibmcloud is instance-initialization-values --private-key @sap-ssh-key

Take note of the password.

 Set the floating IP