Introducing the pool as a noop. Integration inside the build
system. Implementation will be in the following commits.
Signed-off-by: NClementine Hayat <clem@lse.epita.fr>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When re-defining an active storage pool, due to a bug the config
file on disk is not changed. This is because we are passing old
definition instead of new one to virStoragePoolObjSaveDef.
This issue was introduced by bfcd8fc9,
Signed-off-by: NChangkuo Shi <shi.changkuo@h3c.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

And remove NULL checking from all callers.
Signed-off-by: NAnya Harter <aharter@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Ensuring that we don't call the virDrvConnectOpen method with a NULL URI
means that the drivers can drop various checks for NULL URIs. These were
not needed anymore since the probe functionality was split
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Declare what URI schemes a driver supports in its virConnectDriver
struct. This allows us to skip trying to open the driver entirely
if the URI scheme doesn't match.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Add a localOnly flag to the virConnectDriver struct which allows a
driver to indicate whether it is local-only, or permits remote
connections. Stateful drivers running inside libvirtd are generally
local only. This allows us to remote the check for uri->server != NULL
from most drivers.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

This variable is not actually used in the function. Especially
after 31869efe.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Since its introduction in 5d5c732d it has been never used.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The storagePoolLookupByTargetPath() method in the storage driver is used
by the QEMU driver during block migration. If there's a valid use case
for this in the QEMU driver, then external apps likely have similar
needs. Exposing it in the public API removes the direct dependancy from
the QEMU driver to the storage driver.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The virStorageTranslateDiskSourcePool method modifies a virDomainDiskDef
to resolve any storage pool reference. For some reason this was added
into the storage driver code, despite working entirely in terms of the
public APIs. Move it into the domain conf file and rename it to match the
object it modifies.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Now that we can open connections to the secondary drivers on demand,
there is no need to pass a virConnectPtr into all the backend
functions.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Allow the possibility of opening a connection to only the storage
driver, by defining storage:///system and storage:///session URIs
and registering a fake hypervisor driver that supports them.

The hypervisor drivers can now directly open a storage driver
connection at time of need, instead of having to pass around a
virConnectPtr through many functions. This will facilitate the later
change to support separate daemons for each driver.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

By convention the last thing in the driver.c files should be the driver
callback table and function to register it.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

For a disk backend, the deleteVol code will clear all the
volumes in the pool and perform a pool refresh, thus the
storageVolDeleteInternal should not use access @voldef
after deleteVol succeeds.

Use a bool as that's how the variable is used in the function.

Now that the storage pools are self locking, we can reduce the number
of places that need to take the big hammer storage driver lock

Now that we have a private storage pool list, we can take the next
step and convert to using objects. In this case, we're going to use
RWLockable objects (just like every other driver) with two hash
tables for lookup by UUID or Name.

Along the way the ForEach and Search API's will be adjusted to use
the related Hash API's and the various FindBy functions altered and
augmented to allow for HashLookup w/ and w/o the pool lock already
taken.

After virStoragePoolObjRemove we will need to virObjectUnref(obj)
after to indicate the caller is "done" with it's reference. The
Unlock occurs during the Remove.

The NumOf, GetNames, and Export functions all have their own callback
functions to return the required data and the FindDuplicate code
can use the HashSearch function callbacks.

Move the structure into virstorageobj.c.

Use the virStoragePoolObjListNew allocator to fill in the @pools for
the storage driver and test driver.

Commit id '5ab746b8' introduced the function as perhaps a copy
of storageVolLookupByPath; however, it did not use the @cleanpath
variable even though it used the virFileSanitizePath. So in essance
the only "check" being done for failure is whether it was possible
to strdup the path.

Looking at the virStoragePoolDefParseXML one will note that the
target.path is stored using the result of virFileSanitizePath.
Therefore, this function should sanitize and use the input @path
for the argument to storagePoolLookupByTargetPathCallback which
is comparing against stored target.path values.

Additionally, if there was an error we should use the proper error
of VIR_ERR_NO_STORAGE_POOL (instead of VIR_ERR_NO_STORAGE_VOL).

Commit id '5d5c732d' had an incorrect assignment and was found
by travis build:

storage/storage_driver.c:1668:14: error: equality comparison with extraneous
      parentheses [-Werror,-Wparentheses-equality]
    if ((obj == virStoragePoolObjListSearch(&driver->pools,

         ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Now that we're moved the object into virstorageobj, let's make the
code use the lockable object.

Create an API to search through the storage pool objects looking for
a specific truism from a callback API in order to return the specific
storage pool object that is desired.

Create an API to walk the pools->objs[] list in order to perform a
callback function for each element of the objs array that doesn't care
about whether the action succeeds or fails as the desire is to run the
code over every element in the array rather than fail as soon as or if
one fails.

For now it'll just call the virStoragePoolObjUnlock, but a future
adjustment will do something different. Since the new API will check
for a NULL object before the Unlock call, callers no longer need to
check for NULL before calling.

The virStoragePoolObjUnlock is now private/static to virstorageobj.c
with a short term forward reference.

Resolve a storage driver crash as a result of a long running
storageVolCreateXML when the virStorageVolPoolRefreshThread is
run as a result of when a storageVolUpload completed and ran the
virStoragePoolObjClearVols without checking if the creation
code was currently processing a buildVol after incrementing
the driver->asyncjob count.

The refreshThread will now check the pool asyncjob count before
attempting to pursue the pool refresh. Adjust the documentation
to describe the condition.

Crash from valgrind is as follows (with a bit of editing):

==21309== Invalid read of size 8
==21309==    at 0x153E47AF: storageBackendUpdateVolTargetInfo
==21309==    by 0x153E4C30: virStorageBackendUpdateVolInfo
==21309==    by 0x153E52DE: virStorageBackendVolRefreshLocal
==21309==    by 0x153DE29E: storageVolCreateXML
==21309==    by 0x562035B: virStorageVolCreateXML
==21309==    by 0x147366: remoteDispatchStorageVolCreateXML
...
==21309==  Address 0x2590a720 is 64 bytes inside a block of size 336 free'd
==21309==    at 0x4C2F2BB: free
==21309==    by 0x54CB9FA: virFree
==21309==    by 0x55BC800: virStorageVolDefFree
==21309==    by 0x55BF1D8: virStoragePoolObjClearVols
==21309==    by 0x153D967E: virStorageVolPoolRefreshThread
...
==21309==  Block was alloc'd at
==21309==    at 0x4C300A5: calloc
==21309==    by 0x54CB483: virAlloc
==21309==    by 0x55BDC1F: virStorageVolDefParseXML
==21309==    by 0x55BDC1F: virStorageVolDefParseNode
==21309==    by 0x55BE5A4: virStorageVolDefParse
==21309==    by 0x153DDFF1: storageVolCreateXML
==21309==    by 0x562035B: virStorageVolCreateXML
==21309==    by 0x147366: remoteDispatchStorageVolCreateXML
...

Missed from merge from commit id 'b0652192' into commit id 'bfcd8fc9'
were a couple of obj->def-> references.

In preparation for privatizing the object, use the accessor to fetch
the obj->def instead of the direct reference.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Move the virSecretUsageType into the util.

This commit adds new events for two methods and operations: *PoolBuild() and
*PoolDelete(). Using the event-test and the commands set below we have the
following outputs:

$ sudo ./event-test
Registering event callbacks
myStoragePoolEventCallback EVENT: Storage pool test Defined 0
myStoragePoolEventCallback EVENT: Storage pool test Created 0
myStoragePoolEventCallback EVENT: Storage pool test Started 0
myStoragePoolEventCallback EVENT: Storage pool test Stopped 0
myStoragePoolEventCallback EVENT: Storage pool test Deleted 0
myStoragePoolEventCallback EVENT: Storage pool test Undefined 0

Another terminal:
$ sudo virsh pool-define test.xml
Pool test defined from test.xml

$ sudo virsh pool-build test
Pool test built

$ sudo virsh pool-start test
Pool test started

$ sudo virsh pool-destroy test
Pool test destroyed

$ sudo virsh pool-delete test
Pool test deleted

$ sudo virsh pool-undefine test
Pool test has been undefined

This commits can be a solution for RHBZ #1475227.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1475227Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Use the new accessor API for storage_driver.

Use the new accessor APIs for storage_driver.

Since it's been used that way anyway, let's just convert it to a bool
and only make the external representation be an int.

Use the new accessor APIs for storage_driver and test_driver.

Use the new accessor APIs for storage_driver, test_driver, and
gluster backend.

Use the new accessor API for storage_driver.

Use the new accessor APIs for storage_driver and test_driver.

Create/use virStoragePoolObjAddVol in order to add volumes onto list.

Create/use virStoragePoolObjRemoveVol in order to remove volumes from list.

Create/use virStoragePoolObjGetVolumesCount to get count of volumes on list.

For the storage driver, the logic alters when the volumes.obj list grows
to after we've fetched the volobj. This is an optimization of sorts, but
also doesn't "needlessly" grow the volumes.objs list and then just decr
the count if the virGetStorageVol fails.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1437797

Rather than using refreshVol which essentially only updates the
allocation, capacity, and permissions for the volume, but not
the format which does get updated in a pool refresh - let's use
the same helper that pool refresh uses in order to update the
volume target.

Currently, @port is type of string. Well, that's overkill and
waste of memory. Port is always an integer. Use it as such.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>