vania-janet/multiturn-rag-retrieval-data huggingface dataset:
However, to get a complete picture of what is happening in your VMware deployment, you should centralized all your logs to an external service such as IBM Log Analysis where you can troubleshoot problems across all components and be alerted of potential issues that need looking into. Log Analysis offers administrators, DevOps teams, and developers advanced features to filter, search, and tail log data, define alerts, and design custom views to monitor application and system logs. For more information, see [Log Analysis getting started](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-getting-started).





 Types of logs 

A VMware deployment generates multiple types of logs.



* Events
* vCenter logs
* ESXi logs
* NSX logs
* Guest Introspection (GI) logs





 Events 

Events are audit records that report user actions or system actions on objects in the vCenter Server or on a host.



* You can send events that are generated by the vCenter Server Appliance. For example, an event can report when a virtual machine is powered off.
* The maximum length of syslog messages is 1024 characters. Events with a size greater than 1024 characters are split into multiple syslog messages.



An event log record includes information about who made the request, when the event occurred, and what type of event is.

The format of an event is the following.

<syslog-prefix> : Event [eventId] [partInfo] [createdTime] [eventType] [severity] [user] [target] [chainId] [desc]

Where



* syslog-prefix: Displays the syslog prefix that is defined by the remote syslog server.
* eventId: Displays the unique ID of the event.
* partInfo: Displays whether the message is split into parts. The format is [1-X]. For example, [1-1] indicates 1 message only.
* createdTime: Displays the time when the event is generated.
* eventType: Displays the event type.
* severity: Displays whether the event is informational, a warning message, or an error.
[Deployment completes](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/inventory-4.svg)

Figure 4. Deployment completes





 Promote to further environments 

You can promote and deploy from any branch to another one.

Zoom

![Promotion using a PR from staging to prod branch](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/inventory-5.svg)

Figure 5. Promotion using a PR from staging to prod branch





 Inventory landscape 

The current deployed state contains the content to deploy to an environment. Every promoted commit in the target branches contains the relevant Pipeline Run ID and Change Request ID as a tag. Some commits can have multiple tags, for example, when you are retrying a failed deployment or deploying again. The Inventory holds every piece of information to replay the deployments.

Zoom

![Deployment flow diagram with tags](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/inventory-6.svg)

Figure 6. Deployment flow diagram with tags



 Use of tags 



Table 1. Inventory tags

 Tag Description 

 latest Tags the current, successfully deployed, and concluded state of the inventory on a branch. 
 pipeline run id Tags the current inventory state in the branch, with the pipeline run ID or build number of the actual deployment. To avoid inventory content overlap when parallel deployments are triggered, use this tag to refer to the actual inventory point hash in the branch history. 
 change request id [optional] Tags the current state of a change request ID to track the change request IDs in the inventory, in a historical representation.
</xsd:annotation>
</xsd:element>
<xsd:element name="description" type="xsd:string" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The object description.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>

Show more



The top level module object has the following five fields:

![toplevelmodulefivefields](https://cloud.ibm.com/docs-content/v1/content/2781097afe16f2d329d7a606ddd260fb1a3e355c/services/cognos-dashboard-embedded/toplevelmodule.jpg)

Label can be whatever the caller chooses. All identifier fields in the scheme, must be made of alphanumeric characters, or the ‘_’ character, and must start with a letter. The main two parts of the module schema are the source and the table fields.

The source field, identifies where the source is located, and what credentials are used to access the data source. Two types of sources are currently supported in Cognos Dashboard Embedded, JDBC sources, and CSV sources. You can encrypt the fields of the sources section to keep credentials from being in plain text form in the browser, and only accessed from the server. For more information, see [Encrypting data source information](https://cloud.ibm.com/docs/services/cognos-dashboard-embedded?topic=cognos-dashboard-embedded-encryptingdatasourceinformationencryptingdatasourceinformation).

When your DDE application initially shows, a + icon is availble to add a data source. You are advised to listen to the event (user clicks + icon) by using the following code:
For example, to set the prefix for all variable names of keys in secret secretName to CUSTOM_, use the value CUSTOM_=secretName. If the secret secretName contains KEY_A, the environment variable name is CUSTOM_KEY_A.
* To add environment variables for individual keys, use the format NAME:KEY_A,KEY_B. For example, to add an environment variable for a single key key1 in a secret that is named secretName, use the value secretName:key1. To assign a different name to a referenced key, use the format NAME:NEW_NAME=KEY_A. For example, to add an environment variable named myKey for a single key key1 in a secret that is named secretName, use the value secretName:myKey=key1.



This value is optional.

--ephemeral-storage, --es
: The amount of ephemeral storage for this job run. Use M for megabytes or G for gigabytes. This value is optional.

--force, -f
: Do not verify the existence of specified configmap and secret references. Configmap references are specified with the --env-from-configmap option. Secret references are specified with the --env-from-secret or --registry-secret options. This value is optional. The default value is false.

--image, -i
: The name of the image that is used for this job run. The format is REGISTRY/NAMESPACE/REPOSITORY:TAG where REGISTRY and TAG are optional. If REGISTRY is not specified, the default is docker.io. If TAG is not specified, the default is latest. If you do not specify the --job option, the --name and the --image values are required. This value is optional.

--instances, --is
: Specifies the number of instances that are used for this job run. When you use this option, the system converts to array indices. For example, if you specify instances of 5, the system converts to array-indices of 0 - 4. This option can only be specified if the --array-indices option is not specified.
This event is always followed by the toolchain.tool-instance.deploy event. 
 toolchain.tool-instance.read View the configuration of a tool integration 
 toolchain.tool-instance.update Save configuration changes to a tool integration 
 toolchain.tool-instance.delete Remove a tool integration from a toolchain. This event is always preceded by the toolchain.tool-instance.undeploy event. 







 Events for DevOps Insights 

The following table lists the actions that generate DevOps Insights management events:



Table 4. Actions that generate DevOps Insights management events

 Action Description 

 toolchain.insights-tag.create Create a tag 
 toolchain.insights-tag.read View a tag 
 toolchain.insights-tag.update Update a tag 
 toolchain.insights-tag.delete Delete a tag 
 toolchain.insights-decision.evaluate Make a gate decision on a build 



The following table lists the actions that generate DevOps Insights data events:



Table 5. Actions that generate DevOps Insights data events

 Action Description 

 toolchain.insights.read View any build, deploy, or test record 
 toolchain.insights.update Publish a new build, deploy, or test record. The event's metadata includes toolchainId (unique identifier for toolchain) and might also contain the build_artifact (name of application), build_id (id of build), branch (Git branch of build), environment_name (name of environment where the test ran), and operationId (indicates how the update was completed, such as postBuild, postResults, postDeployment, postResultsById, postLifeCycleStage, postBuildArtifactMetaData, putLifeCycleStage, putLifeCycleStagesOrder, and resultsMultipart) values. The values that are included in the event's metadata is determined by the type of record (build, deployment, or test) that is published. 
 toolchain.insights-policy.create Create a policy 
 toolchain.insights-policy.read View a policy 
 toolchain.insights-policy.update Update a policy.
Project JSON 

Each configuration in a project is stored as JSON in a file called project.json. Projects require governance over configuration changes that are stored in project.json, for example, requiring approvals and ensuring that automated checks pass before changes are saved.

You can export and edit a project JSON to a public or private Git repository of your choice and push direct edits to the code. For more information, see [Exporting a JSON](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-setup-projectjson-export).



 What's in my Project.json file? 

The project.json file has several parts:



* The project ID and description, which are user-defined values.
* The project metadata, which includes project CRN, location, resource group, and state.
* An array of configuratons that contains a reference to the deployable architecture and all of the input values.



It's recommended to create your initial project.json from the [Projects page](https://cloud.ibm.com/projects) in the console. This provides an initial project.json file that can be edited. When you create a project in the console, the project.json is automatically created for you.



 Project metadata 

Project metadata might contain cumulative_needs_attention_view, if there are events that have happened related to the project that the user must now take action on. event_notifications_crn is also an optional value, if the project is configured as a source for Event Notifications. For more information, see [Enabling event notifications for projects](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-event-notifications-events&interface=ui).

...
"id": "cfbf9050-ab8e-ac97-b01b-ab5af830be8a",
"name": "CRA Test",
"description": "",
"metadata": {
For a complete listing of options, see the [ibmcloud ce job create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-job-create) command.

Before you begin



* Set up your [Code Engine CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-install-cli) environment.
* [Create and work with a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).



The following job create command creates a job configuration that is named myjob and uses the container image icr.io/codeengine/firstjob.

ibmcloud ce job create --name myjob --image icr.io/codeengine/firstjob

Example output

Creating job 'myjob'...
OK

The following table summarizes the options that are used with the job create command in this example. For more information about the command and its options, see the [ibmcloud ce job create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-job-create) command.



Table 1. Command options

 Option Description 

 --image The name of the image that is used for runs of the job. This value is required. The format is REGISTRY/NAMESPACE/REPOSITORY:TAG where REGISTRY and TAG are optional. If TAG is not specified, the default is latest. For images in [Docker Hub](https://hub.docker.com/), you can specify the image with NAMESPACE/REPOSITORY, as the default for REGISTRY is docker.io. For other registries, use REGISTRY/NAMESPACE/REPOSITORY or REGISTRY/NAMESPACE/REPOSITORY:TAG. 
 --name The name of the job. Use a name that is unique within the project.
Go to the [list of snapshots](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-view&interface=uisnapshots-vpc-view-list-ui).
2. Locate an available snapshot created by user. (Snapshots that were created by a backup policy are identified as created by Backup policy.)
3. In the Tags column, snapshots with tags show a number that indicates the tags that are already applied. Snapshots without tags have an Add tags link. Click Add tags.
4. In the new window, type a tag in the User tags text box.
5. Click Save.







 Adding tags from the snapshot details page 

use the following steps to add tags from the snapshot details page.



1. Go to the [list of snapshots](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-view&interface=uisnapshots-vpc-view-list-ui).
2. Click the name of a snapshot in the list.
3. On the snapshot details page, click the Add tags link.
4. In the new window, enter a user tag or access management tag in the respective fields.
5. Click Save.



When the user tags are matched with a backup policy, a backup is triggered based on the backup plan schedule. For more information, see [Creating a backup policy](https://cloud.ibm.com/docs/vpc?topic=vpc-backup-policy-create).







 Adding tags to a snapshot from the CLI 

You can add tags to a snapshot from the CLI.

Specify a snapshot-update command with the --tags option to add user tags to a volume.

Use the same option to add tags to a volume when you create a snapshot by using ibmcloud is snapshot-create.

The following example adds user tags env:test and env:prod to a volume that is identified by its ID.
Enter a name for the administrator, and enter the personal identification number (PIN) for the smart card on the smart card reader PIN pad.

An administrator signature key is generated and stored on the smart card. Each smart card can contain only one signature key. If you want to set up multiple administrators, repeat this step by using different EP11 smart cards.
2. To generate the master key parts for service instance initialization, on the Smart card tab, click Generate key part.

If prompted, insert an EP11 smart card in smart card reader 2 and enter the smart card PIN. Enter a description for the key part.

A random master key part is generated and stored on the smart card.

To create more master key parts, repeat this step.

You need to generate at least two master key parts to load a master key. For added security, you can generate a maximum of three master key parts. To improve security, you can choose to generate signature keys and master key parts on separate smart cards and assign each smart card to a different person. For more information, see [Smart card setup recommendations](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-faq-provisioning-operationsfaq-smart-card-setup).
3. (Optional) If you want to create a backup copy of an EP11 smart card, click Copy smart card on the Smart card tab and follow the prompts.







 Step 2: Select the crypto units where the master key is to be loaded 

Select the Crypto units tab. A list of

crypto unitsin the target resource group under the current user account is displayed. The SELECTED column shows what crypto units you're going to work with in later commands.

For more information about how to retrieve your service instance ID, see [Retrieving your instance ID](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-retrieve-instance-ID).



* To select extra crypto units to work with, click Add crypto units and enter the CRYPTO UNIT NUM (crypto unit numbers) of the extra crypto units you want to work with.
* Install the [Docker Engine CLI](https://www.docker.com/products/container-runtime//download). For Windows® 8, or OS X Yosemite 10.10.x or earlier, install [Docker Desktop](https://docs.docker.com/desktop/) instead. For more information about the version of Docker that is supported by IBM Cloud Container Registry, see [Support for Docker](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewdocker).
* Install [Podman](https://podman.io/).



2. Download (pull) the image to your local computer. Replace <source_image> with the repository of the image and <tag> with the [tag](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_tag) of the image that you want to use, for example, latest. For example, depending on the tool that you are using, run one of the following commands.



* If you are using Docker, run the following command.

docker pull <source_image>:<tag>

Example, where <source_image> is hello-world and <tag> is latest:

docker pull hello-world:latest

If you have problem when you try to pull a Docker image, see [Why can't I push or pull a Docker image?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-push-pull-docker) for assistance. If you can't pull the most recent image by using the latest tag, see [Why can't I pull the newest image by using the latest tag?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-docker-latest) for assistance.
* If you are using Podman, run the following command.

podman pull <source_image>:<tag>

Example, where <source_image> is hello-world and <tag> is latest:
A "Major Component", in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.The Corresponding Source for a work in source code form is that same work.<-- </section "id="section-en-notice-source-code" "> --><-- <section "id="section-en-notice-permissions" "> --> 2. Basic Permissions All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law.You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright.
Return to Veeam Backup and Replication, enter the share path of the mount point in the Shared folder field and click Next. Veeam Backup and Replication attempts to establish a connection with the mount point. If the connection attempt fails, go back and verify that the network settings for the AltaVault appliance are correct before you try again.
6. Enter a value to limit maximum concurrent tasks to the number of resources that are available. This value is the maximum number of tasks a backup proxy can send to the selected share. The default number of concurrent tasks is 4. AltaVault suggests that you start with five concurrent tasks and increasing or decreasing this value as resources allow. This value can be adjusted after the backup repository is created.
7. Click Next.
8. If needed, specify the vPower NFS settings. If the Enable vPower NFS server selection is left clear, then Veeam Backup and Replication uses vPower for recovery and recovery verification. Click Next.
9. On the Review screen, confirm that all your settings are correct and click Next.
10. Click Finish to exit the wizard. You can now begin backing up your data.







 Backing up the environment 

Follow these steps to create a backup of a complete virtual environment.



1. From the Backup Infrastructure screen, click Backup and Replication.
2. In the Backup and Replication window, click Jobs > Backup Job.
3. Enter a unique name in the Name field. Optionally, you can enter a Description. Click Next.
4. Select which VMs that you want to back up by clicking Add Objects and click through the tree structure to select the VMs. Click Add after you select the appropriate VMs. \n If only specific parts of the VMs are to be backed up (the start disk), click Exclusions and specify the parts. Otherwise, click Next.
5. Select the backup repository that you created by using the Backup repository drop-down menu.



For optimal performance, make sure that you change the data deduplication and compression settings.



 Optimize the backup performance 

Use the following steps to optimize the backup performance.
[menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) > VPC Infrastructure > Storage > Block storage volumes.
2. Locate the volume from the list that you want to add user tags.
3. In the tags column, click Add tags.
4. In the Add tags menu, enter the user tags that you want to apply to this volume. Tags display as you type.

You can also add access management tags to a volume from the Add tags menu. For more information about creating and adding access management tags, see [Apply access management tags to a volume](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-block-storagestorage-add-access-mgt-tags).
5. When you're done adding tags, click Save. When you refresh the screen, the list of Block Storage for VPCshows the number of tags that are added in the Tags column.



You can also add tags from the volume details page. To do so, follow these steps.



1. Go to the list of Block Storage for VPC volumes.
2. On the volume details, click Add tags next to the volume name.
3. In the Add tags menu, enter the user tags that you want to apply to this volume. When finished, click Save.







 Adding user tags that are associated with a backup policy to a volume in the UI 

You can add user tags that are associated with a backup policy to a Block Storage for VPC volume. Backup policies schedule automatic creation of backup snapshots. When one volume tag matches a backup policy tag for target resources, it triggers a backup of the volume contents. A backup policy defines a backup plan that schedules when backup snapshots are taken.

From the [volume details](https://cloud.ibm.com/docs/vpc?topic=vpc-viewing-block-storage&interface=uiview-vol-details-ui) page, you can view the backup policies that are applied to the volume and add user tags that are associated with a backup policy.



1.