Types


Types (140)
Type Description
configuration_model The configuration_model structure defines the global settings of the Content Library Service. Required for Read.
library_model The com.vmware.content.library_model structure represents a Content Library resource model.

A library_model is a container for a set of items which represent a usable set of files. The Content Library Service allows for multiple libraries to be created with separate authorization and sharing policies.

Each library_model is a container for a set of com.vmware.content.library.item_model instances. Each item is a logical object in a library, which may have multiple files.

A library_model may be local or subscribed. A local library has its source of truth about items within this Content Library Service. Items may be added to or removed from the library. A local library may also be private or published. When published, the library is exposed by a network endpoint and can be used by another Content Library Service for synchronization. A private local library cannot be used for synchronization.

A subscribed library is a library which gets its source of truth from another library that may be across a network in another Content Library Service. A subscribed library may have a different name and metadata from the library to which it subscribes, but the set of library items is always the same as those in the source library. Library items cannot be manually added to a subscribed library -- they can only be added by adding new items to the source library.

item_model The item_model structure represents a library item that has been stored in a library.

A item_model represents a single logical unit to be managed within a com.vmware.content.library_model. Items contain the actual content of a library, and their placement within a library determines policies that affect that content such as publishing.

A library item can have a specified type, indicated with the com.vmware.content.library.item_model.type field. This property is associated with a Content Library Service plugin that supports specific types and provides additional services. The types available in a specific Content Library Service can be queried using the com.vmware.content.type service. Items of an unknown or unspecified type are treated generically. Because subscribed library catalogs are synchronized as is, subscribing to a remote Content Library Service effectively gives you a library with the functionality of the remote service's type adapter plugins, even if they are not installed locally.

Items can be managed using the com.vmware.content.library.item service and, for items in subscribed libraries, the com.vmware.content.library.subscribed_item service.

publish_info The publish_info structure defines how a local library is published publicly for synchronization to other libraries.
storage_backing The storage_backing structure defines a storage location where content in a library will be stored. The storage location can either be a Datastore or Other type. Required for Create, Read.
subscription_info The subscription_info structure defines the subscription behavior for a subscribed library.
download_session_model The download_session_model structure provides information on an active com.vmware.content.library.item.download_session resource.
transfer_endpoint The transfer_endpoint structure encapsulates a URI along with extra information about it.
update_session_model The update_session_model structure provides information on an active com.vmware.content.library.item.update_session resource.
source_create_spec The source_create_spec structure contains the registration information for a metadata source.
source_info Metadata source info
authentication_info The authentication_info structure describes the authentication information. Authentication information could be specified for a package element, service elenent or an operation element.

Using the authentication scheme information, a client invoking an API call from any service can figure out what kind of credentials are needed for that API call.

component_data The component_data structure contains the authentication information of the component along with its fingerprint.
component_info The component_info structure contains authentication information of a component element.

For an explanation of authentication information contained within component elements, see com.vmware.vapi.metadata.authentication.component.

operation_info The operation_info structure contains authentication information of an operation element.
package_info The package_info structure contains authentication information of a package element.

For an explanation of authentication information contained within package elements, see com.vmware.vapi.metadata.authentication.package.

service_info The service_info structure contains authentication information of a service element.

For an explanation of authentication information contained within service elements, see com.vmware.vapi.metadata.authentication.service.

component_data The component_data structure contains the metamodel metadata information of a component element along with its fingerprint.
component_info The component_info structure contains metamodel metadata information about a component element.
constant_info The constant_info structure contains metamodel information of the constant elements.
constant_value The constant_value structure contains the metamodel information of the constant element.
element_map The element_map structure contains the metadata elements.

One of the sources for metadata is the annotations present in the interface definition language. When an annotation is represented in the element_map, element_map describes the data specified in the arguments for the annotation.

For example, in @UnionCase(tag="tag", value="SELECT"), ElementMap describes the keyword arguments tag and value.

element_value The element_value structure describes the value of the metadata element.
enumeration_info The enumeration_info structure contains the metamodel information of an enumeration element.
enumeration_value_info The enumeration_value_info structure describes the enumeration value in the enumerated type.
error_info The error_info structure contains the metadata information about the error elements contained in an operation element.
field_info The field_info structure contains metamodel information of a field element contained in a structure element.
generic_instantiation The generic_instantiation structure describes the type information of a typed element when the type is an instantiation of one of the generic types provided by the infrastructure.
operation_info The operation_info structure contains metamodel information of an operation element.
operation_result_info The operation_result_info structure contains the metamodel information of an operation result element.

An operation accepts a list of parameters and returns a result or an error. The operation_result_info describes the result element of an operation.

package_info The package_info structure contains the metamodel information of all the service elements, structure elements and enumeration elements contained in the package element.
primitive_value The primitive_value structure contains value of the constant element.
service_info The service_info structure contains the metamodel information of all the operation elements, structure elements and enumeration elements containted in a service element.
structure_info The structure_info structure contains the metamodel information of all the field elements, constant elements and enumeration elements contained in the structure element.

In the interface definition language, API designers have the ability to include all the fields from one structure to another structure. This is done by using an annotation @Include on the structure in which we want to add the fields. If this annotation is present, the list of fields in the structure_info will also contain the fields that are being included. The annotation information is also retained in the com.vmware.vapi.metadata.metamodel.structure_info.metadata element as well.

type The type structure describes the type information of a typed element in the interface definiton language. The following elements in the metamodel are typed: The type could be one of the three following categories:
  • Built-in types: These are types present in the interface definition language type system. They are provided by the infrastructure.
  • User defined named type: API designers can create custom types and use them for the typed elements. These types have a unique identifier.
  • Generic type instantiation: The language infrastructure also provides generic types such as list, map, set and so on. An instantiation of one of these generic types could also be used for the typed elements.
user_defined_type The user_defined_type structure contains the metamodel type information of a typed element whose type is a user defined named type.
component_data The component_data structure contains the privilege information of the component along with its fingerprint.
component_info The component_info structure contains the privilege information of a component element.

For an explanation of privilege information contained within component elements, see com.vmware.vapi.metadata.privilege.component.

operation_info The operation_info structure contains privilege information of an operation element.

For an explanation of containment within operation elements, see com.vmware.vapi.metadata.privilege.service.operation.

package_info The package_info structure contains the privilege information of a package element.

For an explanation of privilege information contained within package elements, see com.vmware.vapi.metadata.privilege.package.

privilege_info The privilege_info structure contains the privilege information for a parameter element in an operation element.
service_info The service_info structure contains privilege information of a service element.

For an explanation of privilege information contained within service elements, see com.vmware.vapi.metadata.privilege.service.

authentication_scheme The com.vmware.vapi.std.authentication_scheme class defines constants for authentication scheme identifiers for authentication mechanisms present in the vAPI infrastructure shipped by VMware.

A third party extension can define and implements it's own authentication mechanism and define a constant in a different IDL file.

dynamic_ID The dynamic_ID structure represents an identifier for a resource of an arbitrary type.
localizable_message The localizable_message structure represents a localizable string or message template. Services include one or more localizable message templates in the errors they report so that clients can display diagnostic messages in the native language of the user. Services can include localizable strings in the data returned from operations to allow clients to display localized status information in the native language of the user.
already_exists The already_exists error indicates that an attempt was made to create an entity but the entity already exists. Typically the entity has a name or identifier that is required to be unique in some context, but there is already an entity with that name or identifier in that context.

Examples:

  • Trying to create a new tag category when a tag category with the specified name already exists.
  • Trying to create a new tag in tag category when a tag with the specified name already exists the tag category.
  • Trying to create a LUN with a specific UUID on a node (for replication purposes) when a LUN with that UUID already exists on the node.
  • Trying to create a file in a directory or move or copy a file to a directory when a file with that name already exists in the directory.
already_in_desired_state The already_in_desired_state error indicates that an attempt to change the state of a resource or service had no effect because the resource or service is already in the desired state.

Examples:

  • Trying to power on a virtual machine that is already powered on.
argument_locations The argument_locations structure describes which part(s) of the input to the operation caused the error.

Some types of errors are caused by the value of one of the inputs to the operation, possibly due to an interaction with other inputs to the operation. This structure is intended to be used as the payload to identify those inputs when the operation reports errors like com.vmware.vapi.std.errors.invalid_argument or com.vmware.vapi.std.errors.not_found. See com.vmware.vapi.std.errors.error.data.

canceled The canceled error indicates that the operation canceled itself in response to an explicit request to do so. Operations being "canceled" for other reasons (for example the client connection was closed, a time out occured, or due to excessive resource consumption) should not report this error.

Examples:

  • A user is monitoring the progress of the operation in a GUI and sees that it is likely to take longer than he is willing to wait and clicks the cancel button.
  • A user invokes the operation using a command-line tool and decides that she didn't really want to invoke that operation, and presses CTRL-c.

Counterexamples:

  • The client's connection to the server was closed. Reporting an error is pointless since the client will not receive the error response because the connection has been closed.
  • The request is taking longer than some amount of time. The com.vmware.vapi.std.errors.timed_out error would be reported if the time was specified as part of the input or is documented in the API contract.
concurrent_change The concurrent_change error indicates that a data structure, entity, or resource has been modified since some earlier point in time. Typically this happens when the client is doing the write portion of a read-modify-write sequence and indicates that it wants the server to notify it if the data in the server has changed after it did the read, so that it can avoid overwriting that change inadvertantly.
error The error error describes thefields common to all standard errors.

This error serves two purposes:

  1. It is the error that clients in many programming languages can catch to handle all standard errors. Typically those clients will display one or more of the localizable messages from com.vmware.vapi.std.errors.error.messages to a human.
  2. It is the error that operations can report when they need to report some error, but the error doesn't fit into any other standard error, and in fact the only reasonable way for a client to react to the error is to display the message(s) to a human.
feature_in_use The feature_in_use error indicates that an action cannot be completed because a feature is in use.

Examples:

  • Trying to disable snapshots on a virtual machine which has a snapshot.
  • Trying to downgrade a license that has licensed features that are in use.
file_locations The file_locations structure identifies the file(s) that caused the operation to report the error.

Some types of errors are caused by a problem with one or more files. This structure is intended to be used as the payload to identify those files when the operation reports errors like com.vmware.vapi.std.errors.not_found. See com.vmware.vapi.std.errors.error.data.

internal_server_error The internal_server_error error indicates that the server encounters an unexpected condition that prevented it from fulfilling the request.

This error is reported by the API infrastructure, so it could occur in response to the invocation of any operation.

Examples:

  • The operation returns a value whose type doesn't match the type type the operation says it should return.
  • The operation reports an error that is not included in the list of errors the operation says that it can report.
invalid_argument The invalid_argument error indicates that the values received for one or more parameters are not acceptable.

This error is reported by the API infrastructure, so it could occur in response to the invocation of any operation. It may also be reported as the result of operation-specific validation.

Examples:

  • A parameter has a value that is not of the expected type.
  • A parameter has a value that is not in the required range.
  • A parameter has a value that is not one of the specifically allowed strings.
  • One field of a structure is the tag for a tagged union, and has a specific value but another field of the structure that is required to be specified when the tag has that value is not specified, or another field of the structure that is required to be unspecified when the tag has that value is specified.

Counterexamples:

invalid_element_configuration The invalid_element_configuration error indicates that an attempt to modify the configuration of an element or a group containing the element failed due to the configuraton of the element. A typical case is when the operation is am attempt to change the group membership of the element fails, in which case a configuration change on the element may allow the group membership change to succeed.

Examples:

  • Attempt to move a host with a fault tolerant virtual machine out of a cluster (i.e. make the host a standalone host).
  • Attempt to remove a host from a DRS cluster without putting the host into maintenance mode.
invalid_element_type The invalid_element_type error indicates that the server was unable to fulfil the request because an element of a specific type cannot be a member of particular group.

This error could be reported, for example, if an attempt is made to put an element into the wrong type of container.

Examples:

  • Attempt to put a virtual machine into a folder that can only contain hosts.
  • Attempt to attach a SCSI virtual disk to an IDE port.
Counterexamples:
invalid_request The invalid_request error indicates that the request is malformed in such a way that the server is unable to process it.

Examples:

  • The XML in a SOAP request is not well-formed so the server cannot parse the request.
  • The XML in a SOAP request is well-formed but does not match the structure required by the SOAP specification.
  • A JSON-RPC request is not valid JSON.
  • The JSON sent in a JSON-RPC request is not a valid JSON-RPC Request object.
  • The Request object from a JSON-RPC request does not match the structure required by the API infrastructure.

Counterexamples:

Some transport protocols (for example JSON-RPC) include their own mechanism for reporting these kinds of errors, and the API infrastructure for a programming language may expose the errors using a language specific mechanism, so this error might not be used.

not_allowed_in_current_state The not_allowed_in_current_state error indicates that the requested operation is not allowed with a resource or service in its current state. This could be because the operation is performing a configuration change that is not allowed in the current state or because operation itself is not allowed in the current state.

Examples:

  • Trying to add a virtual device that cannot be hot plugged to a running virtual machine.
  • Trying to upgrade the virtual hardware version for a suspended virtual machine.
  • Trying to power off, reset, or suspend a virtual machine that is not powered on.

Counterexamples:

not_found The not_found error indicates that a specified element could not be found.

Examples:

  • Invoke the operation to retrieve information about a virtual machine, passing an id that does not identify an existing virtual machine.
  • Invoke the operation to modify the configuration of a virtual nic, passing an id that does not identify an existing virtual nic in the specified virtual machine.
  • Invoke the operation to remove a vswitch, passing an id that does not identify an existing vswitch.
operation_not_found The operation_not_found error indicates that the operation specified in the request could not be found.

Every API request specifies a service identifier and an operation identifier along with the parameters. If the API infrastructure is unable to find the requested service or operation it reports this error.

This error can be reported by the API infrastructure for any operation, but it is specific to the API infrastructure, and should never be reported by the implementation of any operation.

Examples:

  • A client provides an invalid service or operation identifier when invoking the operation using a dynamic interface (for example REST).
  • A client invokes the operation from a service, but that service has not been installed.

Counterexamples:

  • A client invokes a task scheduling operation, but provides an invalid service identifier or operation identifier. The com.vmware.vapi.std.errors.not_found error would be used instead.
resource_busy The resource_busy error indicates that the operation could not be completed because a resource it needs is busy.

Examples:

  • Trying to power off a virtual machine that is in the process of being powered on.

Counterexamples:

resource_in_use The resource_in_use error indicates that the operation could not be completed because a resource is in use.

Examples:

  • Trying to remove a VMFS datastore when the is a virtual machine registered on any host attached to the datastore.
  • Trying to add a virtual switch if the physical network adapter being bridged is already in use.

Counterexamples:

resource_inaccessible The resource_inaccessible error indicates that the operation could not be completed because an entity is not accessible.

Examples:

  • Attempt to invoke some operation on a virtual machine when the virtual machine's configuration file is not accessible (for example due to a storage APD condition).

Counterexamples:

service_unavailable The service_unavailable error indicates that the service is unavailable.

Examples:

  • Attempt to invoke a operation when the server is too busy.
  • Attempt to invoke a operation when the server is undergoing maintenance.
  • An operation fails to contact VMware Tools running inside the virtual machine.

Counterexamples:

timed_out The timed_out error indicates that the operation did not complete within the allowed amount of time. The allowed amount of time might be:
  • provided by the client as an input parameter.
  • a fixed limit of the service implementation that is a documented part of the contract of the service.
  • a configurable limit used by the implementation of the service.
  • a dynamic limit computed by the implementation of the service.
The operation may or may not complete after the timed_out error was reported.

Examples:

  • The operation was unable to complete within the timeout duration specified by a parameter of the operation.

Counterexamples:

  • A server implementation that puts requests into a queue before dispatching them might delete a request from the queue if it doesn't get dispatched within n minutes. The com.vmware.vapi.std.errors.service_unavailable error would be used instead.
transient_indication The transient_indication structure indicates whether or not the error is transient.

Some types of errors are transient in certain situtations and not transient in other situtations. This error payload can be used to indicate to clients whether a particular error is transient. See com.vmware.vapi.std.errors.error.data.

unable_to_allocate_resource The unable_to_allocate_resource error indicates that the operation failed because it was unable to allocate or acquire a required resource.

Examples:

  • Trying to power on a virtual machine when there are not enough licenses to do so.
  • Trying to power on a virtual machine that would violate a resource usage policy.

Counterexamples:

unauthenticated The unauthenticated error indicates that the operation requires authentication and the user is not authenticated.

API requests may include a security context containing user credentials. For example, the user credentials could be a SAML token, a user name and password, or the session identifier for a previously established session.

Examples:

  • The SAML token in the request's security context has expired.
  • The user name and password in the request's security context are invalid.
  • The session identifier in the request's security context identifies a session that has expired.
Counterexamples:

For security reasons, the com.vmware.vapi.std.errors.error.data field in this error is unset, and the com.vmware.vapi.std.errors.error.messages field in this error does not disclose which part of the security context is correct or incorrect. For example the messages would not disclose whether a username or a password is valid or invalid, but only that a combination of username and password is invalid.

unauthorized The unauthorized error indicates that the user is not authorized to perform the operation.

API requests may include a security context containing user credentials. For example, the user credentials could be a SAML token, a user name and password, or the session identifier for a previously established session. Invoking the operation may require that the user identified by those credentials has particular privileges on the operation or on one or more resource identifiers passed to the operation.

Examples:

  • The operation requires that the user have one or more privileges on the operation, but the user identified by the credentials in the security context does not have the required privileges.
  • The operation requires that the user have one or more privileges on a resource identifier passed to the operation, but the user identified by the credentials in the security context does not have the required privileges.

Counterexamples:

For security reasons, the com.vmware.vapi.std.errors.error.data field in this error is unset, and the com.vmware.vapi.std.errors.error.messages field in this error does not disclose why the user is not authorized to perform the operation. For example the messages would not disclose which privilege the user did not have or which resource identifier the user did not have the required privilege to access. The API documentation should indicate what privileges are required.

unexpected_input The unexpected_input error indicates that the request contained a parameter or field whose name is not known by the server.

Every operation expects parameters with known names. Some of those parameters may be (or contain) structures, and the operation expects those structures to contain fields with known names. If the operation receives parameters or fields with names that is does not expect, this error may be reported.

This error can be reported by the API infrastructure for any operation, but it is specific to the API infrastructure, and should never be reported by the implementation of any operation.

Examples:

  • A client using stubs generated from the interface specification for version2 of a service invokes the operation passing one or more parameters that were added in version2, but they are communicating with a server that only supports version1 of the service.
  • A client provides an unexpected parameter or field name when invoking the operation using a dynamic interface (for example REST).
unsupported The unsupported error indicates that the operation is not supported by the service.

Examples:

  • Trying to hot-plug a CPU when the current configuration of the VM does not support hot-plugging of CPUs.
  • Trying to change the memory size to a value that is not within the acceptable guest memory bounds supported by the virtual machine's host.
category_model The category_model structure defines a category that is used to group one or more tags.
tag_model The tag_model structure defines a tag that can be attached to vSphere objects.
certificate_params The certificate_params structure contains information about the public key certificate used to sign the OVF package. This structure will only be returned if the OVF package is signed.

See deploy and filter.

Required for Read.
deployment_option The deployment_option structure contains the information about a deployment option as defined in the OVF specification.

This corresponds to the ovf:Configuration element of the ovf:DeploymentOptionSection in the specification. The ovf:DeploymentOptionSection specifies a discrete set of intended resource allocation configurations. This structure represents one item from that set.

See deploy and filter.

Required for Read.
deployment_option_params The deployment_option_params structure describes the possible deployment options as well as the choice provided by the user.

This information based on the ovf:DeploymentOptionSection.

See deploy and filter.

Required for Read.
extra_config The extra_config structure contains the information about a vmw:ExtraConfig element which can be used to specify configuration settings that are transferred directly to the .vmx file. The behavior of the vmw:ExtraConfig element is similar to the extraConfig property of the VirtualMachineConfigSpec object in the VMware vSphere API. Thus, the same restrictions apply, such as you cannot set values that could otherwise be set with other properties in the VirtualMachineConfigSpec object. See the VMware vSphere API reference for details on this.

vmw:ExtraConfig elements may occur as direct child elements of a VirtualHardwareSection, or as child elements of individual virtual hardware items.

See deploy and filter.

Required for Read.
extra_config_params The extra_config_params structure contains the parameters with information about the vmw:ExtraConfig elements in an OVF package.

vmw:ExtraConfig elements can be used to specify configuration settings that are transferred directly to the .vmx file.

The behavior of the vmw:ExtraConfig element is similar to the extraConfig property of the VirtualMachineConfigSpec object in the VMware vSphere API. Thus, the same restrictions apply, such as you cannot set values that could otherwise be set with other properties in the VirtualMachineConfigSpec object. See the VMware vSphere API reference for details on this.

See deploy and filter.

Required for Read.
ip_allocation_params The ip_allocation_params structure specifies how IP addresses are allocated to OVF properties. In particular, it informs the deployment platform whether the guest supports IPv4, IPv6, or both. It also specifies whether the IP addresses can be obtained through DHCP or through the properties provided in the OVF environment.

Ovf Property elements are exposed to the guest software through the OVF environment. Each Property element exposed in the OVF environment shall be constructed from the value of the ovf:key attribute. A Property element contains a key/value pair, it may optionally specify type qualifiers using the ovf:qualifiers attribute with multiple qualifiers separated by commas.

The settings in ip_allocation_params structure are global to a deployment. Thus, if a virtual machine is part of a virtual appliance, then its settings are ignored and the settings for the virtual appliance is used.

This information is based on the vmw:IpAssignmentSection in OVF package.

See deploy and filter.

Required for Read.
ovf_message The ovf_message structure describes a base OVF handling error message related to accessing, validating, deploying, or exporting an OVF package.

These messages fall into different categories defined in com.vmware.vcenter.ovf.ovf_message.category:

parse_issue The parse_issue structure contains the information about the issue found when parsing an OVF package during deployment or exporting an OVF package including:
  • Parsing and validation error on OVF descriptor (which is an XML document), manifest and certificate files.
  • OVF descriptor generating and device error.
  • Unexpected server error.
ovf_error The ovf_error structure describes an error related to accessing, validating, deploying, or exporting an OVF package.
ovf_warning The ovf_warning structure describes a warning related to accessing, validating, deploying, or exporting an OVF package.
ovf_info The ovf_info structure contains informational messages related to accessing, validating, deploying, or exporting an OVF package.
ovf_params The ovf_params structure defines the common fields for all OVF deployment parameters. OVF parameters serve several purposes:
  • Describe information about a given OVF package.
  • Describe default deployment configuration.
  • Describe possible deployment values based on the deployment environment.
  • Provide deployment-specific configuration.
Each OVF parameters structure specifies a particular configurable aspect of OVF deployment. An aspect has both a query-model and a deploy-model. The query-model is used when the OVF package is queried, and the deploy-model is used when deploying an OVF package.

Most OVF parameter structures provide both informational and deployment parameters. However, some are purely informational (for example, download size) and some are purely deployment parameters (for example, the flag to indicate whether registration as a vCenter extension is accepted).

See deploy and filter.

Required for Create, Read.
property The property structure contains the information about a property in an OVF package.

A property is uniquely identified by its [classid.]id[.instanceid] fully-qualified name (see com.vmware.vcenter.ovf.property.class_id, com.vmware.vcenter.ovf.property.id, and com.vmware.vcenter.ovf.property.instance_id). If multiple properties in an OVF package have the same fully-qualified name, then the property is excluded and cannot be set. We do warn about this during import.

See deploy and filter.

Required for Read.
property_params The property_params structure contains a array of OVF properties that can be configured when the OVF package is deployed.

This is based on the ovf:ProductSection.

See deploy and filter.

Required for Read.
scale_out_group The scale_out_group structure contains information about a scale-out group.

It allows a virtual system collection to contain a set of children that are homogeneous with respect to a prototypical virtual system or virtual system collection. It shall cause the deployment function to replicate the prototype a number of times, thus allowing the number of instantiated virtual systems to be configured dynamically at deployment time.

This is based on the ovf2:ScaleOutSection.

See deploy and filter.

Required for Read.
scale_out_params The scale_out_params structure contains information about the scale-out groups described in the OVF package.

When deploying an OVF package, a deployment specific instance count can be specified (see com.vmware.vcenter.ovf.scale_out_group.instance_count.

This is based on the ovf2:ScaleOutSection.

See deploy and filter.

Required for Read.
size_params The size_params structure contains estimates of the download and deployment sizes.

This information is based on the file references and the ovf:DiskSection in the OVF descriptor.

See deploy and filter.

Required for Read.
unknown_section The unknown_section structure contains information about an unknown section in an OVF package.
unknown_section_params The unknown_section_params structure contains a array of unknown, non-required sections.

See deploy and filter.

Required for Read.
vcenter_extension_params The vcenter_extension_params structure specifies that the OVF package should be registered as a vCenter extension. The virtual machine or virtual appliance will gain unrestricted access to the vCenter Server APIs. It must be connected to a network with connectivity to the vCenter server.

See deploy and filter.

Required for Read.
find_spec Specifies the properties that can be used as a filter to find libraries. When multiple fields are specified, all properties of the library must match the specification.
probe_result The probe_result structure defines the subscription information probe result. This describes whether using a given subscription URL is successful or if there are access problems, such as SSL errors.
info The info structure describes support for a specific type of data in an com.vmware.content.library.item_model. The info can be queried through the com.vmware.content.type service. Type support describes plugins in the Content Library which can provide metadata on library items and help manage the transfer process by adding dependent files when a current file is added.
find_spec The find_spec structure specifies the properties that can be used as a filter to find library items. When multiple fields are specified, all properties of the item must match the specification.
checksum_info Provides checksums for a com.vmware.content.library.item.file.info object.
info The info structure provides information about a file in Content Library Service storage.

A file is an actual stored object for a library item. An item will have zero files initially, but one or more can be uploaded to the item.

info The info structure is the expanded form of com.vmware.content.library.item.file.info that includes details about the storage backing for a file in a library item.
info The info structure defines the downloaded file.
add_spec The add_spec structure describes the properties of the file to be uploaded.
info The info structure defines the uploaded file.
validation_error The validation_error structure defines the validation error of a file in the session.
validation_result The validation_result structure defines the result of validating the files in the session.
info Represents data associated with an API session.
info The info structure contains the metadata source information.
create_spec The create_spec structure contains the registration information of a authentication source.
output_field_info The output_field_info structure describes the name used by the CLI to display a single field of a structure element in the interface definition language.
output_info The output_info structure describes the names used by the CLI to display the fields of a structure element in the interface definition language as well as the order in which the fields will be displayed.
option_info The option_info structure describes information about a specific input option of a command.
identity The identity structure uniquely identifies a command in the CLI commands tree.
info The info structure contains information about a command. It includes the identity of the command, a description, information about the service and operation that implement the command, and CLI-specific information for the command.
identity The identity structure uniquely identifies a namespace in the CLI namespace tree.
info The info structure contains information about a namespace. It includes the identity of the namespace, a description, information children namespaces.
info The info structure contains the metadata source information.
create_spec The create_spec structure contains the registration information of a CLI source.
info The info structure contains the metadata source information.
create_spec The create_spec structure contains the registration information of a metamodel source.
info The info structure contains the metadata source information.
create_spec The create_spec structure contains the registration information of a privilege source.
create_spec The create_spec structure is used to create a category.

Use the create operation to create a category defined by the create specification.

update_spec The update_spec structure describes the updates to be made to an existing category.

Use the update operation to modify a category. When you call the operation, specify the category identifier. You obtain the category identifier when you call the create operation. You can also retrieve an identifier by using the list operation.

create_spec The create_spec structure describes a tag.

Use the create operation to create a tag defined by the create specification.

update_spec The update_spec structure describes the updates to be made to an existing tag.

Use the update operation to modify a tag. When you call the operation, you specify the tag identifier. You obtain the tag identifier when you call the create operation. You can also retrieve an identifier by using the list operation.

info The info structure contains information about a datastore.
info The info structure contains information about a vCenter Server network.
info The info structure describes an export flag supported by the server.
info The info structure describes an import flag supported by the deployment platform.
deployable_identity The deployable_identity structure describes the resource created by a deployment, or the source resource from which library item can be created, by specifying its resource type and resource identifier.
resource_pool_deployment_spec The resource_pool_deployment_spec structure defines the deployment parameters that can be specified for the deploy operation where the deployment target is a resource pool. See deploy.
storage_group_mapping The storage_group_mapping structure defines the storage deployment target and storage provisioning type for a section of type vmw:StorageGroupSection in the OVF descriptor.
result_info The result_info structure defines the information returned along with the result of a create or deploy operation to describe errors, warnings, and informational messages produced by the server.
deployment_result The deployment_result structure defines the result of the deploy operation. See deploy.
deployment_target The deployment_target structure describes the location (target) where a virtual machine or virtual appliance should be deployed. It is used in the deploy and filter operations. See deploy and filter.
ovf_summary The ovf_summary structure defines the result of the filter operation. See filter. The fields in the structure describe parameterizable information in the OVF descriptor, with respect to a deployment target, for the deploy operation. See deploy.
create_target The create_target structure specifies the target library item when capturing a virtual machine or virtual appliance as an OVF package in a library item in a content library. The target can be an existing library item, which will be updated, creating a new version, or it can be a newly created library item in a specified library. See create.
create_spec The create_spec structure defines the information used to create or update a library item containing an OVF package.
create_result The create_result structure defines the result of the create operation. See create.

Copyright © 2014. All Rights Reserved.