core interfaces for the libvirt library

Provides the interfaces of the libvirt library to handle virtualized domains Daniel Veillard <veillard@redhat.com>

error handling interfaces for the libvirt library

Provides the interfaces of the libvirt library to handle errors raised while using the library. Daniel Veillard <veillard@redhat.com> Macro providing the version of the library as version * 1,000,000 + minor * 1000 + micro This macro is to be used in conjunction with virDomainGetVcpus() and virDomainPinVcpu() APIs. VIR_COPY_CPUMAP macro extract the cpumap of the specified vcpu from cpumaps array and copy it into cpumap to be used later by virDomainPinVcpu() API. This macro is to be used in conjunction with virDomainPinVcpu() API. It returns the length (in bytes) required to store the complete CPU map between a single virtual & all physical CPUs of a domain. This macro is to be used in conjunction with virDomainGetVcpus() API. VIR_CPU_USABLE macro returns a non zero value (true) if the cpu is usable by the vcpu, and 0 otherwise. Macro providing the field length of virSchedParameter This macro is to be used in conjunction with virDomainGetVcpus() and virDomainPinVcpu() APIs. VIR_GET_CPUMAP macro returns a pointer to the cpumap of the specified vcpu from cpumaps array. This macro is to calculate the total number of CPUs supported but not necessary active in the host. Macro providing the maximum length of the virSecurityModel doi string. Macro providing the maximum length of the virSecurityLabel label string. Note that this value is based on that used by Labeled NFS. Macro providing the maximum length of the virSecurityModel model string. This macro is to be used in conjunction with virDomainPinVcpu() API. USE_CPU macro reset the bit (CPU not usable) of the related cpu in cpumap. This macro is to be used in conjunction with virDomainPinVcpu() API. USE_CPU macro set the bit (CPU usable) of the related cpu in cpumap. This macro provides the length of the buffer required for virDomainGetUUID() This macro provides the length of the buffer required for virDomainGetUUIDString() a virConnectPtr is pointer to a virConnect private structure, this is the type used to reference a connection to the Hypervisor in the API. A pointer to a virDomainBlockStats structure a virDomainInfoPtr is a pointer to a virDomainInfo structure. A pointer to a virDomainInterfaceStats structure a virDomainPtr is pointer to a virDomain private structure, this is the type used to reference a domain in the API. a virInterfacePtr is pointer to a virInterface private structure, this is the type used to reference a virtual interface in the API. a virNetworkPtr is pointer to a virNetwork private structure, this is the type used to reference a virtual network in the API. A virNodeDevicePtr is a pointer to a virNodeDevice structure. Get one via virNodeDeviceLookupByKey, virNodeDeviceLookupByName, or virNodeDeviceCreate. Be sure to Call virNodeDeviceFree when done using a virNodeDevicePtr obtained from any of the above functions to avoid leaking memory. a virNodeInfoPtr is a pointer to a virNodeInfo structure. a virSchedParameterPtr is a pointer to a virSchedParameter structure. a virSecurityLabelPtr is a pointer to a virSecurityLabel. a virSecurityModelPtr is a pointer to a virSecurityModel. a virStoragePoolPtr is pointer to a virStoragePool private structure, this is the type used to reference a storage pool in the API. a virStorageVolPtr is pointer to a virStorageVol private structure, this is the type used to reference a storage volume in the API. Copy the content of the last error caught on that connection This method is not protected against access from multiple threads. In a multi-threaded application, always use the global virGetLastError() API which is backed by thread local storage. If the connection object was discovered to be invalid by an API call, then the error will be reported against the global error object. Since 0.6.0, all errors reported in the per-connection object are also duplicated in the global error object. As such an application can always use virGetLastError(). This method remains for backwards compatability. One will need to free the result with virResetError() Provide a pointer to the last error caught on that connection This method is not protected against access from multiple threads. In a multi-threaded application, always use the global virGetLastError() API which is backed by thread local storage. If the connection object was discovered to be invalid by an API call, then the error will be reported against the global error object. Since 0.6.0, all errors reported in the per-connection object are also duplicated in the global error object. As such an application can always use virGetLastError(). This method remains for backwards compatability. The error object is kept in thread local storage, so separate threads can safely access this concurrently. Reset the last error caught on that connection Set a connection error handling function, if @handler is NULL it will reset to default which is to pass error back to the global library handler. This function closes the connection to the Hypervisor. This should not be called if further interaction with the Hypervisor are needed especially if there is running domain which need further monitoring by the application. A callback function to be registered, and called when a domain event occurs Removes a Domain Event Callback. De-registering for a domain callback will disable delivery of this event type Adds a Domain Event Callback. Registering for a domain callback will enable delivery of the events The virDomainPtr object handle passed into the callback upon delivery of an event is only valid for the duration of execution of the callback. If the callback wishes to keep the domain object after the callback Reads native configuration data describing a domain, and generates libvirt domain XML. The format of the native data is hypervisor dependant. Reads a domain XML configuration document, and generates generates a native configuration file describing the domain. The format of the native data is hypervisor dependant. Talks to a storage backend and attempts to auto-discover the set of available storage pool sources. e.g. For iSCSI this would be a set of iSCSI targets. For NFS this would be a list of exported paths. The srcSpec (optional for some storage pool types, e.g. local ones) is an instance of the storage pool's source element specifying where to look for the pools. srcSpec is not required for some types (e.g., those querying local storage resources only) Provides capabilities of the hypervisor / driver. This returns the system hostname on which the hypervisor is running (the result of the gethostname(2) system call). If we are connected to a remote system, then this returns the hostname of the remote system. Provides the maximum number of virtual CPUs supported for a guest VM of a specific type. The 'type' parameter here corresponds to the 'type' attribute in the <domain> element of the XML. Get the name of the Hypervisor software used. This returns the URI (name) of the hypervisor connection. Normally this is the same as or similar to the string passed to the virConnectOpen/virConnectOpenReadOnly call, but the driver may make the URI canonical. If name == NULL was passed to virConnectOpen, then the driver will return a non-NULL URI which can be used to connect to the same hypervisor later. Get the version level of the Hypervisor running. This may work only with hypervisor call, i.e. with privileged access to the hypervisor, not with a Read-Only connection. list the defined but inactive domains, stores the pointers to the names in @names list the inactive networks, stores the pointers to the names in @names Provides the list of names of inactive storage pools upto maxnames. If there are more than maxnames, the remaining names will be silently ignored. Collect the list of active domains, and store their ID in @maxids Collect the list of physical host interfaces, and store their names in @names Collect the list of active networks, and store their names in @names Provides the list of names of active storage pools upto maxnames. If there are more than maxnames, the remaining names will be silently ignored. Provides the number of defined but inactive domains. Provides the number of inactive networks. Provides the number of inactive storage pools Provides the number of active domains. Provides the number of interfaces on the physical host. Provides the number of active networks. Provides the number of active storage pools This function should be called first to get a connection to the Hypervisor and xen store This function should be called first to get a connection to the Hypervisor. If necessary, authentication will be performed fetching credentials via the callback This function should be called first to get a restricted connection to the library functionalities. The set of APIs usable are then restricted on the available methods to control the domains. Increment the reference count on the connection. For each additional call to this method, there shall be a corresponding call to virConnectClose to release the reference count, once the caller no longer needs the reference to this object. This method is typically useful for applications where multiple threads are using a connection, and it is required that the connection remain open until all threads have finished using it. ie, each new thread using a connection would increment the reference count. Copy the content of the last error caught at the library level The error object is kept in thread local storage, so separate threads can safely access this concurrently. One will need to free the result with virResetError() Default routine reporting an error to stderr. Create a virtual device attachment to backend. This function allows you to read the contents of a domain's disk device. Typical uses for this are to determine if the domain has written a Master Boot Record (indicating that the domain has completed installation), or to try to work out the state of the domain's filesystems. (Note that in the local case you might try to open the block device or file directly, but that won't work in the remote case, nor if you don't have sufficient permission. Hence the need for this call). 'path' must be a device or file corresponding to the domain. In other words it must be the precise string returned in a <disk><source dev='...'/></disk> from virDomainGetXMLDesc. 'offset' and 'size' represent an area which must lie entirely within the device or file. 'size' may be 0 to test if the call would succeed. 'buffer' is the return buffer and must be at least 'size' bytes. NB. The remote driver imposes a 64K byte limit on 'size'. For your program to be able to work reliably over a remote connection you should split large requests to <= 65536 bytes. This function returns block device (disk) stats for block devices attached to the domain. The path parameter is the name of the block device. Get this by calling virDomainGetXMLDesc and finding the <target dev='...'> attribute within //domain/devices/disk. (For example, "xvda"). Domains may have more than one block device. To get stats for each you should make multiple calls to this function. Individual fields within the stats structure may be returned as -1, which indicates that the hypervisor does not support that particular statistic. This method will dump the core of a domain on a given file for analysis. Note that for remote Xen Daemon the file path will be interpreted in the remote host. launch a defined domain. If the call succeed the domain moves from the defined to the running domains pools. Deprecated after 0.4.6. Renamed to virDomainCreateXML() providing identical functionality. This existing name will left indefinitely for API compatability. Launch a new guest domain, based on an XML description similar to the one returned by virDomainGetXMLDesc() This function may requires privileged access to the hypervisor. The domain is not persistent, so its definition will disappear when it is destroyed, or if the host is restarted (see virDomainDefineXML() to define persistent domains). Define a domain, but does not start it. This definition is persistent, until explicitly undefined with virDomainUndefine(). A previous definition for this domain would be overriden if it already exists. Destroy the domain object. The running instance is shutdown if not down already and all resources used by it are given back to the hypervisor. This does not free the associated virDomainPtr object. This function may require privileged access Destroy a virtual device attachment to backend. Free the domain object. The running instance is kept alive. The data structure is freed and should not be used thereafter. Provides a boolean value indicating whether the domain configured to be automatically started when the host machine boots. Provides the connection pointer associated with a domain. The reference counter on the connection is not increased by this call. WARNING: When writing libvirt bindings in other languages, do not use this function. Instead, store the connection and the domain object together. Get the hypervisor ID number for the domain Extract information about a domain. Note that if the connection used to get the domain is limited only a partial set of the information can be extracted. Retrieve the maximum amount of physical memory allocated to a domain. If domain is NULL, then this get the amount of memory reserved to Domain0 i.e. the domain where the application runs. Provides the maximum number of virtual CPUs supported for the guest VM. If the guest is inactive, this is basically the same as virConnectGetMaxVcpus. If the guest is running this will reflect the maximum number of virtual CPUs the guest was booted with. Get the public name for that domain Get the type of domain operation system. Get the scheduler parameters, the @params array will be filled with the values. Get the scheduler type. Extract security label of an active domain. Get the UUID for a domain Get the UUID for a domain as string. For more information about UUID see RFC4122. Extract information about virtual CPUs of domain, store it in info array and also in cpumaps if this pointer isn't NULL. Provide an XML description of the domain. The description may be reused later to relaunch the domain with virDomainCreateXML(). This function returns network interface stats for interfaces attached to the domain. The path parameter is the name of the network interface. Domains may have more than network interface. To get stats for each you should make multiple calls to this function. Individual fields within the stats structure may be returned as -1, which indicates that the hypervisor does not support that particular statistic. Try to find a domain based on the hypervisor ID number Note that this won't work for inactive domains which have an ID of -1, in that case a lookup based on the Name or UUId need to be done instead. Try to lookup a domain on the given hypervisor based on its name. Try to lookup a domain on the given hypervisor based on its UUID. Try to lookup a domain on the given hypervisor based on its UUID. This function allows you to read the contents of a domain's memory. The memory which is read is controlled by the 'start', 'size' and 'flags' parameters. If 'flags' is VIR_MEMORY_VIRTUAL then the 'start' and 'size' parameters are interpreted as virtual memory addresses for whichever task happens to be running on the domain at the moment. Although this sounds haphazard it is in fact what you want in order to read Linux kernel state, because it ensures that pointers in the kernel image can be interpreted coherently. 'buffer' is the return buffer and must be at least 'size' bytes. 'size' may be 0 to test if the call would succeed. NB. The remote driver imposes a 64K byte limit on 'size'. For your program to be able to work reliably over a remote connection you should split large requests to <= 65536 bytes. Migrate the domain object from its current host to the destination host given by dconn (a connection to the destination host). Flags may be one of more of the following: VIR_MIGRATE_LIVE Attempt a live migration. If a hypervisor supports renaming domains during migration, then you may set the dname parameter to the new name (otherwise it keeps the same name). If this is not supported by the hypervisor, dname must be NULL or else you will get an error. Since typically the two hypervisors connect directly to each other in order to perform the migration, you may need to specify a path from the source to the destination. This is the purpose of the uri parameter. If uri is NULL, then libvirt will try to find the best method. Uri may specify the hostname or IP address of the destination host as seen from the source. Or uri may be a URI giving transport, hostname, user, port, etc. in the usual form. Refer to driver documentation for the particular URIs supported. The maximum bandwidth (in Mbps) that will be used to do migration can be specified with the bandwidth parameter. If set to 0, libvirt will choose a suitable default. Some hypervisors do not support this feature and will return an error if bandwidth is not 0. To see which features are supported by the current hypervisor, see virConnectGetCapabilities, /capabilities/host/migration_features. There are many limitations on migration imposed by the underlying technology - for example it may not be possible to migrate between different processors even with the same architecture, or between different types of hypervisor. Dynamically change the real CPUs which can be allocated to a virtual CPU. This function requires privileged access to the hypervisor. Reboot a domain, the domain object is still usable there after but the domain OS is being stopped for a restart. Note that the guest OS may ignore the request. Increment the reference count on the domain. For each additional call to this method, there shall be a corresponding call to virDomainFree to release the reference count, once the caller no longer needs the reference to this object. This method is typically useful for applications where multiple threads are using a connection, and it is required that the connection remain open until all threads have finished using it. ie, each new thread using a domain would increment the reference count. This method will restore a domain saved to disk by virDomainSave(). Resume an suspended domain, the process is restarted from the state where it was frozen by calling virSuspendDomain(). This function may requires privileged access This method will suspend a domain and save its memory contents to a file on disk. After the call, if successful, the domain is not listed as running anymore (this may be a problem). Use virDomainRestore() to restore a domain after saving. Configure the domain to be automatically started when the host machine boots. Dynamically change the maximum amount of physical memory allocated to a domain. If domain is NULL, then this change the amount of memory reserved to Domain0 i.e. the domain where the application runs. This function requires privileged access to the hypervisor. Dynamically change the target amount of physical memory allocated to a domain. If domain is NULL, then this change the amount of memory reserved to Domain0 i.e. the domain where the application runs. This function may requires privileged access to the hypervisor. Change the scheduler parameters Dynamically change the number of virtual CPUs used by the domain. Note that this call may fail if the underlying virtualization hypervisor does not support it or if growing the number is arbitrary limited. This function requires privileged access to the hypervisor. Shutdown a domain, the domain object is still usable there after but the domain OS is being stopped. Note that the guest OS may ignore the request. TODO: should we add an option for reboot, knowing it may not be doable in the general case ? Suspends an active domain, the process is frozen without further access to CPU resources and I/O but the memory used by the domain at the hypervisor level will stay allocated. Use virDomainResume() to reactivate the domain. This function may requires privileged access. Undefine a domain but does not stop it if it is running Signature of a function to use when there is an error raised by the library. Part of the EventImpl, this callback Adds a file handle callback to listen for specific events. The same file handle can be registered multiple times provided the requested event sets are non-overlapping If the opaque user data requires free'ing when the handle is unregistered, then a 2nd callback can be supplied for this purpose. Part of the EventImpl, this user-defined callback handles adding an event timeout. If the opaque user data requires free'ing when the handle is unregistered, then a 2nd callback can be supplied for this purpose. Callback for receiving file handle events. The callback will be invoked once for each event which is pending. Part of the EventImpl, this user-provided callback is notified when an fd is no longer being listened on. If a virEventHandleFreeFunc was supplied when the handle was registered, it will be invoked some time during, or after this function call, when it is safe to release the user data. Part of the EventImpl, this user-defined callback removes a timer If a virEventTimeoutFreeFunc was supplied when the handle was registered, it will be invoked some time during, or after this function call, when it is safe to release the user data. callback for receiving timer events Part of the EventImpl, this user-provided callback is notified when events to listen on change Part of the EventImpl, this user-defined callback updates an event timeout. Resets and frees the given error. Provide a pointer to the last error caught at the library level The error object is kept in thread local storage, so separate threads can safely access this concurrently. Provides two information back, @libVer is the version of the library while @typeVer will be the version of the hypervisor type @type against which the library was compiled. If @type is NULL, "Xen" is assumed, if @type is unknown or not available, an error code will be returned and @typeVer will be 0. Initialize the library. It's better to call this routine at startup in multithreaded applications to avoid potential race when initializing the library. Activate an interface (ie call "ifup") Define an interface (or modify existing interface configuration) deactivate an interface (ie call "ifdown") This does not remove the interface from the config, and does not free the associated virInterfacePtr object. Free the interface object. The interface itself is unaltered. The data structure is freed and should not be used thereafter. Provides the connection pointer associated with an interface. The reference counter on the connection is not increased by this call. WARNING: When writing libvirt bindings in other languages, do not use this function. Instead, store the connection and the interface object together. Get the MAC for a interface as string. For more information about MAC see RFC4122. Get the public name for that interface Provide an XML description of the interface. The description may be reused later to recreate the interface with virInterfaceCreateXML(). Try to lookup an interface on the given hypervisor based on its MAC. Try to lookup an interface on the given hypervisor based on its name. Increment the reference count on the interface. For each additional call to this method, there shall be a corresponding call to virInterfaceFree to release the reference count, once the caller no longer needs the reference to this object. This method is typically useful for applications where multiple threads are using a connection, and it is required that the connection remain open until all threads have finished using it. ie, each new thread using a interface would increment the reference count. Undefine an interface, ie remove it from the config. This does not free the associated virInterfacePtr object. Create and start a defined network. If the call succeed the network moves from the defined to the running networks pools. Create and start a new virtual network, based on an XML description similar to the one returned by virNetworkGetXMLDesc() Define a network, but does not create it Destroy the network object. The running instance is shutdown if not down already and all resources used by it are given back to the hypervisor. This does not free the associated virNetworkPtr object. This function may require privileged access Free the network object. The running instance is kept alive. The data structure is freed and should not be used thereafter. Provides a boolean value indicating whether the network configured to be automatically started when the host machine boots. Provides a bridge interface name to which a domain may connect a network interface in order to join the network. Provides the connection pointer associated with a network. The reference counter on the connection is not increased by this call. WARNING: When writing libvirt bindings in other languages, do not use this function. Instead, store the connection and the network object together. Get the public name for that network Get the UUID for a network Get the UUID for a network as string. For more information about UUID see RFC4122. Provide an XML description of the network. The description may be reused later to relaunch the network with virNetworkCreateXML(). Try to lookup a network on the given hypervisor based on its name. Try to lookup a network on the given hypervisor based on its UUID. Try to lookup a network on the given hypervisor based on its UUID. Increment the reference count on the network. For each additional call to this method, there shall be a corresponding call to virNetworkFree to release the reference count, once the caller no longer needs the reference to this object. This method is typically useful for applications where multiple threads are using a connection, and it is required that the connection remain open until all threads have finished using it. ie, each new thread using a network would increment the reference count. Configure the network to be automatically started when the host machine boots. Undefine a network but does not stop it if it is running Create a new device on the VM host machine, for example, virtual HBAs created using vport_create. Destroy the device object. The virtual device is removed from the host operating system. This function may require privileged access Dettach the node device from the node itself so that it may be assigned to a guest domain. Depending on the hypervisor, this may involve operations such as unbinding any device drivers from the device, binding the device to a dummy device driver and resetting the device. If the device is currently in use by the node, this method may fail. Once the device is not assigned to any guest, it may be re-attached to the node using the virNodeDeviceReattach() method. Drops a reference to the node device, freeing it if this was the last reference. Just return the device name Accessor for the parent of the device Fetch an XML document describing all aspects of the device. Lists the names of the capabilities supported by the device. Lookup a node device by its name. Accessor for the number of capabilities supported by the device. Re-attach a previously dettached node device to the node so that it may be used by the node again. Depending on the hypervisor, this may involve operations such as resetting the device, unbinding it from a dummy device driver and binding it to its appropriate driver. If the device is currently in use by a guest, this method may fail. Increment the reference count on the dev. For each additional call to this method, there shall be a corresponding call to virNodeDeviceFree to release the reference count, once the caller no longer needs the reference to this object. This method is typically useful for applications where multiple threads are using a connection, and it is required that the connection remain open until all threads have finished using it. ie, each new thread using a dev would increment the reference count. Reset a previously dettached node device to the node before or after assigning it to a guest. The exact reset semantics depends on the hypervisor and device type but, for example, KVM will attempt to reset PCI devices with a Function Level Reset, Secondary Bus Reset or a Power Management D-State reset. If the reset will affect other devices which are currently in use, this function may fail. This call returns the amount of free memory in one or more NUMA cells. The @freeMems array must be allocated by the caller and will be filled with the amount of free memory in kilobytes for each cell requested, starting with startCell (in freeMems[0]), up to either (startCell + maxCells), or the number of additional cells in the node, whichever is smaller. provides the free memory available on the Node Note: most libvirt APIs provide memory sizes in kilobytes, but in this function the returned value is in bytes. Divide by 1024 as necessary. Extract hardware information about the node. Extract the security model of a hypervisor. Collect the list of node devices, and store their names in @names If the optional 'cap' argument is non-NULL, then the count will be restricted to devices with the specified capability Provides the number of node devices. If the optional 'cap' argument is non-NULL, then the count will be restricted to devices with the specified capability Reset the error being pointed to Reset the last error caught at the library level. The error object is kept in thread local storage, so separate threads can safely access this concurrently, only resetting their own error object. Save the last error into a new error object. Set a library global error handling function, if @handler is NULL, it will reset to default printing on stderr. The error raised there are those for which no handler at the connection level could caught. Build the underlying storage pool Starts an inactive storage pool Create a new storage based on its XML description. The pool is not persistent, so its definition will disappear when it is destroyed, or if the host is restarted Define a new inactive storage pool based on its XML description. The pool is persistent, until explicitly undefined. Delete the underlying pool resources. This is a non-recoverable operation. The virStoragePoolPtr object itself is not free'd. Destroy an active storage pool. This will deactivate the pool on the host, but keep any persistent config associated with it. If it has a persistent config it can later be restarted with virStoragePoolCreate(). This does not free the associated virStoragePoolPtr object. Free a storage pool object, releasing all memory associated with it. Does not change the state of the pool on the host. Fetches the value of the autostart flag, which determines whether the pool is automatically started at boot time Provides the connection pointer associated with a storage pool. The reference counter on the connection is not increased by this call. WARNING: When writing libvirt bindings in other languages, do not use this function. Instead, store the connection and the pool object together. Get volatile information about the storage pool such as free space / usage summary Fetch the locally unique name of the storage pool Fetch the globally unique ID of the storage pool Fetch the globally unique ID of the storage pool as a string Fetch an XML document describing all aspects of the storage pool. This is suitable for later feeding back into the virStoragePoolCreateXML method. Fetch list of storage volume names, limiting to at most maxnames. Fetch a storage pool based on its unique name Fetch a storage pool based on its globally unique id Fetch a storage pool based on its globally unique id Fetch a storage pool which contains a particular volume Fetch the number of storage volumes within a pool Increment the reference count on the pool. For each additional call to this method, there shall be a corresponding call to virStoragePoolFree to release the reference count, once the caller no longer needs the reference to this object. This method is typically useful for applications where multiple threads are using a connection, and it is required that the connection remain open until all threads have finished using it. ie, each new thread using a pool would increment the reference count. Request that the pool refresh its list of volumes. This may involve communicating with a remote server, and/or initializing new devices at the OS layer Sets the autostart flag Undefine an inactive storage pool Create a storage volume within a pool based on an XML description. Not all pools support creation of volumes Create a storage volume in the parent pool, using the 'clonevol' volume as input. Information for the new volume (name, perms) are passed via a typical volume XML description. Delete the storage volume from the pool Release the storage volume handle. The underlying storage volume continues to exist. Provides the connection pointer associated with a storage volume. The reference counter on the connection is not increased by this call. WARNING: When writing libvirt bindings in other languages, do not use this function. Instead, store the connection and the volume object together. Fetches volatile information about the storage volume such as its current allocation Fetch the storage volume key. This is globally unique, so the same volume will have the same key no matter what host it is accessed from Fetch the storage volume name. This is unique within the scope of a pool Fetch the storage volume path. Depending on the pool configuration this is either persistent across hosts, or dynamically assigned at pool startup. Consult pool documentation for information on getting the persistent naming Fetch an XML document describing all aspects of the storage volume Fetch a pointer to a storage volume based on its globally unique key Fetch a pointer to a storage volume based on its name within a pool Fetch a pointer to a storage volume based on its locally (host) unique path Increment the reference count on the vol. For each additional call to this method, there shall be a corresponding call to virStorageVolFree to release the reference count, once the caller no longer needs the reference to this object. This method is typically useful for applications where multiple threads are using a connection, and it is required that the connection remain open until all threads have finished using it. ie, each new thread using a vol would increment the reference count.