A session identifier is expected as part of the request.

A side effect of invoking this operation may be a change to the session's last accessed time to the current time if this is supported by the session implementation. Invoking any other operation in the API will also update the session's last accessed time.

This API is meant to serve the needs of various front end projects that may want to display the name of the user. Examples of this include various web based user interfaces and logging facilities.

This is an incremental update to the library. Any field in the content.library_model structure that is unset will not be modified.

This operation will only update the common properties for all library types. This will not, for example, update the content.library_model.publish_info of a local library, nor the content.library_model.subscription_info of a subscribed library. Specific properties are updated in update and update.

Copying a library item allows a duplicate to be made within the same or different library. The copy occurs by first creating a new library item, whose identifier is returned. The content of the library item is then copied asynchronously. This copy can be tracked as a task.

If the copy fails, Content Library Service will roll back the copy by deleting any content that was already copied, and removing the new library item. A failure during rollback may require manual cleanup by an administrator.

A library item cannot be copied into a subscribed library.

A new library item is created without any content. After creation, content can be added through the content.library.item.update_session and content.library.item.updatesession.file services.

A library item cannot be created in a subscribed library.

This operation will immediately remove the item from the library that owns it. The content of the item will be asynchronously removed from the storage backings. The content deletion can be tracked with a task. In the event that the task fails, an administrator may need to manually remove the files from the storage backing.

This operation cannot be used to delete a library item that is a member of a subscribed library. Removing an item from a subscribed library requires deleting the item from the original published local library and syncing the subscribed library.

This is an incremental update to the library item. Fields that are unset in the update specification are left unchanged.

This operation cannot update a library item that is a member of a subscribed library. Those items must be updated in the source published library and synchronized to the subscribed library.

Removing a download session leaves any current transfers for that session in an indeterminate state (there is no guarantee that the transfers will be able to complete). However there will no longer be a means of inspecting the status of those downloads except by seeing the effect on the library item.

Download sessions for which there is no download activity or which are complete will automatically be expired and then deleted after a period of time.

This is useful in transmitting client side failures (for example, not being able to download a file) to the server side.

If there is no activity for a download session for a certain period of time, the download session will expire. The download session expiration timeout is configurable in the Content Library Service system configuration. The default is five minutes. Invoking this operation enables a client to specifically extend the lifetime of an active download session.

This operation is not allowed if the session has been already completed.

Cancelling an update session will cancel any in progress transfers (either uploaded by the client or pulled by the server). Any content that has been already received will be scheduled for deletion.

This operation requires the session to be in the ACTIVE state.

Depending on the type of the library item associated with this session, a type adapter may be invoked to verify the validity of the files uploaded. The user can explicitly validate the session before completing the session by using the validate operation.

Modifications are not visible to other clients unless the session is completed and all necessary files have been received.

Content Library Service allows only one single update session to be active for a specific library item.

Removing an update session leaves any current transfers for that session in an indeterminate state (there is no guarantee that the server will terminate the transfers, or that the transfers can be completed). However there will no longer be a means of inspecting the status of those uploads except by seeing the effect on the library item.

Update sessions for which there is no upload activity or which are complete will automatically be deleted after a period of time.

This is useful in transmitting client side failures (for example, not being able to access a file) to the server side.

If there is no activity for an update session after a period of time, the update session will expire, then be deleted. The update session expiration timeout is configurable in the Content Library Service system configuration. The default is five minutes. Invoking this operation enables a client to specifically extend the lifetime of the update session.

This is an incremental update to the update session. Any field in the content.library.item.update_session_model structure that is unset will not be modified.

This operation will only update the property content.library.item.update_session_model.warning_behavior of the update session. This will not, for example, update the content.library.item.update_session_model.library_item_id or content.library.item.update_session_model.state of an update session.

This operation requires the session to be in the ACTIVE state.

When importing a file directly from storage, where the source endpoint is a file or datastore URI, you will need to have the ContentLibrary.ReadStorage privilege on the library item. If the file is located in the same directory as the library storage backing folder, the server will move the file instead of copying it, thereby allowing instantaneous import of files for efficient backup and restore scenarios. In all other cases, a copy is performed rather than a move.

This operation allows the cached content of a library item to be removed to free up storage capacity. This operation will only work when a library item is synchronized on-demand. When a library is not synchronized on-demand, it always attempts to keep its cache up-to-date with the published source. Evicting the library item will set content.library.item_model.cached to false.

Synchronizing an individual item will update that item's metadata from the remote source. If the source library item on the remote library has been deleted, this operation will delete the library item from the subscribed library as well.

The default behavior of the synchronization is determined by the content.library.subscription_info of the library which owns the library item.

• If content.library.subscription_info.on_demand is true, then the file content is not synchronized by default. In this case, only the library item metadata is synchronized. The file content may still be forcefully synchronized by passing true for the force_sync_content parameter.
• If content.library.subscription_info.on_demand is false, then this call will always synchronize the file content. The force_sync_content parameter is ignored when the subscription is not on-demand.

This operation will return immediately and create an asynchronous task to perform the synchronization.

This is an incremental update to the subscription. Except for the content.library.subscriptions.update_spec_placement structure, fields that are unset in the update specification will be left unchanged. If spec#subscribedLibraryPlacement is specified, all fields of the current subscribed library placement will be replaced by this placement.

Deleting a local library will remove the entry immediately and begin an asynchronous task to remove all cached content for the library. If the asynchronous task fails, file content may remain on the storage backing. This content will require manual removal.

This is an incremental update to the local library. Fields that are unset in the update specification will be left unchanged.

Once created, the subscribed library will be empty. If the content.library_model.subscription_info property is set, the Content Library Service will attempt to synchronize to the remote source. This is an asynchronous operation so the content of the published library may not immediately appear.

Deleting a subscribed library will remove the entry immediately and begin an asynchronous task to remove all cached content for the library. If the asynchronous task fails, file content may remain on the storage backing. This content will require manual removal.

This operation allows the cached content of a subscribed library to be removed to free up storage capacity. This operation will only work when a subscribed library is synchronized on-demand.

Synchronizing a subscribed library forcefully with this operation will perform the same synchronization behavior as would run periodically for the library. The content.library.subscription_info.on_demand setting is respected. Calling this operation on a library that is already in the process of synchronizing will have no effect.

This is an incremental update to the subscribed library. Fields that are unset in the update specification will be left unchanged.

The result of this operation can be queried by calling the cis/tasks/{task-id} where the task-id is the response of this operation.

The fingerprint provides clients an efficient way to check if the metadata for a particular component has been modified on the server. The client can do this by comparing the result of this operation with the fingerprint returned in the result of get.

The vapi.metadata.authentication.component_data contains the authentication information about the component element and it's fingerprint. It contains information about all the package elements that belong to this component element.

The fingerprint provides clients an efficient way to check if the metadata for commands has been modified on the server.

The fingerprint provides clients an efficient way to check if the metadata for namespaces has been modified on the server.

The fingerprint provides clients an efficient way to check if the metadata for a particular component element has been modified on the server. The client can do this by comparing the result of this operation with the fingerprint returned in the result of get.

The vapi.metadata.metamodel.component_data contains the metamodel information about the component and it's fingerprint. It contains information about all the package elements that are contained in this component element.

The vapi.metadata.metamodel.enumeration_info contains the metamodel information about the enumeration value element contained in the enumeration element.

The vapi.metadata.metamodel.structure service provides operations to retrieve more details about the structure elements corresponding to the identifiers returned by this operation.

The vapi.metadata.metamodel.service_info contains the metamodel information for the operation elements, structure elements and enumeration elements contained in the service element.

The list of service elements is an aggregate list of all the service elements contained in all the package elements.

The vapi.metadata.metamodel.structure_info contains the metamodel information about the structure element. It contains information about all the field elements and enumeration elements contained in this structure element.

The fingerprint provides clients an efficient way to check if the metadata for a particular component has been modified on the server. The client can do this by comparing the result of this operation with the fingerprint returned in the result of get.

The vapi.metadata.privilege.component_data contains the privilege information about the component element and its fingerprint. It contains information about all the package elements that belong to this component element.

After this operation completes, the services using the certificate will be restarted for the new certificate to take effect.

After this operation completes, the services using the certificate will be restarted for the new certificate to take effect.

1. When the CSR is created and the private key is already stored, this operation can replace the certificate. The certificate but not the private key and root certificate must be provided as input.
2. When the certificate is signed by a third party certificate authority/VMCA and the root certificate of the third party certificate authority/VMCA is already one of the trusted roots in the trust store, this operation can replace the certificate and private key. The certificate and the private key but not the root certificate must be provided as input.
3. When the certificate is signed by a third party certificate authority and the root certificate of the third party certificate authority is not one of the trusted roots in the trust store, this operation can replace the certificate, private key and root CA certificate. The certificate, private key and root certificate must be provided as input.

The above three scenarios are only supported from vsphere 7.0 onwards.

After this operation completes, the services using the certificate will be restarted for the new certificate to take effect.

The result of this operation can be queried by calling the get operation where task is the response of this operation.

Retrieving a report involves two steps:

• Step 1: Invoke the get operation to provision a token and a URI.
• Step 2: Make an HTTP GET request by using the URI and the token returned in step 1 to retrieve the report.

The HTTP GET request will:

• Return 401 (Not Authorized) if the download URI is recognized, but the token is invalid, 404 if the URL is not recognized otherwise return 200 (OK)
• Provide the CSV contents as the output of the request. The API accepts the file name as input, reads the contents of that CSV file, and returns this text as the result of the API.

The result of this operation can be queried by calling the get operation where task is the response of this operation.

Retrieving a support bundle involves two steps:

• Step 1: Invoke operation to provision a token and a URI.
• Step 2: Make an HTTP GET request using URI and one time used token returned in step 1 to generate the support bundle and return it.

The HTTP GET request will:

• return 401 (Not Authorized) if the download URL is recognized, but the token is invalid.
• otherwise return 200 (OK), mark the token used (invalidating it for any future use), open a application/tar download stream for the client, and start the bundle process. As part of its work, the API will orchestrate support bundling on the worker nodes of a cluster. If a failure occurs during the collection of support bundle from worker node, the API will not abort the request, but will log a warning and move on to processing other worker nodes' bundles. The API will only abort its operation if the content of the stream has been corrupted. When the API has to abort its operation (and the response stream), it will not provide any indication of failures to the client. The client will need to verify validity of the resultant file based on the format specified in the response's Content-Disposition header.

The supported flags are:

PRESERVE_MAC

Include MAC addresses for network adapters.

EXTRA_CONFIG

Include extra configuration in OVF export.

Future server versions might support additional flags.

The supported flags are:

LAX

Lax mode parsing of the OVF descriptor.

Future server versions might support additional flags.

This operation creates a library item in content library whose content is an OVF package derived from a source virtual machine or virtual appliance, using the supplied create specification. The OVF package may be stored as in a newly created library item or in an in an existing library item. For an existing library item whose content is updated by this operation, the original content is overwritten. Meta data such as name and description is not updated for the exisitng library item.

This operation deploys an OVF package which is stored in the library item specified by ovf_library_item_id. It uses the deployment specification in deployment_spec to deploy the OVF package to the location specified by target.

This operation retrieves information from the descriptor of the OVF package stored in the library item specified by ovf_library_item_id. The information returned by the operation can be used to populate the deployment specification (see vcenter.ovf.library_item.resource_pool_deployment_spec when deploying the OVF package to the deployment target specified by target.

Import a boot_imgdb.tgz file which contains metadata that describes a trusted ESX base image. A boot_imgdb.tgz file can be downloaded from a representative host.

The key server will use this certificate to validate the client connection. If a client certificate already exists, it will be replaced.

An optional private key can be specified if the certificate has already been provisioned.

The CSR will allow the certificate to be signed by a third party. Once the CSR is signed, certificate may be added as a client certificate.

Calling the API repeatedly will result in a generating a new CSR each time.

The CSR will allow the certificate to be signed by a third party. Once the CSR is signed, certificate may be added as a client certificate.

Contacts the configured key servers and attempts to retrieve their certificates. These certificates might not yet be trusted.

If the returned certificates are to be considered trustworthy, then it must be added to the list of trusted server certificates by adding to the certificates returned by get and invoking update with the updated array of certificates.

The client will use these certificates to validate the server connection. The existing list of trusted certificates will be overwritten.

The client will not trust the server connection until a server certificate has been set.

For forced failover, Active node immediately initiates a failover. This may result into a data loss after failover.

For planned failover, Active node flushes all the state to the Passive node, waits for the flush to complete before causing a failover. After the failover, Passive node starts without any data loss.

A failover is allowed only in the following cases:

1. Cluster's mode is enabled and all cluster members are present.
2. Cluster's mode is maintenance and all cluster members are present.

If the VCHA cluster is in a transition state and not configured, then the VCHA cluster specific information is removed.

VCHA Cluster configuration remains intact in any of the cluster modes.

The VMRC ticket contains the IP address or the DNS resolvable name of the vCenter server. This ticket requires installation of VMware Workstation, VMware Fusion or VMRC to be installed on the machine where the ticket has to be opened. This ticket can be acquired even when the VM is turned off.

The WEBMKS ticket contains the IP address of the DNS resolvable name of the ESX server. This ticket requires user to embed this ticket in a HTML page using VMware HTML Console SDK - https://www.vmware.com/support/developer/html-console This ticket can be acquired only when the VM is turned on.

For a powered-off virtual machine, the update operation may be used to configure the virtual CD-ROM device to start in the connected state when the virtual machine is powered on.

For a powered-off virtual machine, the update operation may be used to configure the virtual CD-ROM device to start in the disconnected state when the virtual machine is powered on.

For a powered-off virtual machine, the update operation may be used to configure the virtual Ethernet adapter to start in the connected state when the virtual machine is powered on.

For a powered-off virtual machine, the update operation may be used to configure the virtual Ethernet adapter to start in the disconnected state when the virtual machine is powered on.

For a powered-off virtual machine, the update operation may be used to configure the virtual floppy drive to start in the connected state when the virtual machine is powered on.

For a powered-off virtual machine, the update operation may be used to configure the virtual floppy floppy to start in the disconnected state when the virtual machine is powered on.

For a powered-off virtual machine, the update operation may be used to configure the virtual parallel port to start in the connected state when the virtual machine is powered on.

For a powered-off virtual machine, the update operation may be used to configure the virtual parallel port to start in the disconnected state when the virtual machine is powered on.

For a powered-off virtual machine, the update operation may be used to configure the virtual serial port to start in the connected state when the virtual machine is powered on.

For a powered-off virtual machine, the update operation may be used to configure the virtual serial port to start in the disconnected state when the virtual machine is powered on.