The file became a garbage dump for all kinds of utility functions over
time. Move them to a separate file so that the files can become a clean
interface for the storage backends.

We had a lot of rados_conf_set and check works.
Use helper virStorageBackendRBDRADOSConfSet for them.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

No sense opening a connection only to fail because we don't support the
type of build being attempted.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than use stack allocated state context pointers, let's allocate and
free the state context pointer.  In doing so, we'll shrink the code a bit
since many routines perform the same initialization sequence.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Since none of the callers check the status, let's just alter it to
a static void.

While we're at it - scrap the local runtime variable and just do the
math in the VIR_DEBUG directly.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Remove unnessary translated message marker _()
for the VIR_WARN messages.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

s/failed/failed to
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

Move the enum into a new src/util/virsecret.h, rename it to be
virSecretLookupType. Add a src/util/virsecret.h in order to perform
a couple of simple operations on the secret XML and virSecretLookupTypeDef
for clearing and copying.

This includes quite a bit of collateral damage, but the goal is to remove
the "virStorage*" and replace with the virSecretLookupType so that it's
easier to to add new lookups that aren't necessarily storage pool related.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than inline code secret lookup for rbd/iscsi, use the common function.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Add a new helper that sanitizes error semantics of base64_encode_alloc.

After the recent commits the build didn't work for me. Fix it by
using size_t as the callback argument is using and the correct
formatter. The attempted fixup to use %llu as a formatter was wrong.

%zu is for size_t variables, not uint64 ones. This causes a warning when building on
a 32 bit linux.

%zu is not always synonymous with uint64_t; on 32-bit machines,
size_t is only 32 bits.  Prefer "%lld"/'unsigned long long' when
the variable is under our control, and "%"PRIu64 when we are
stuck with 'uint64_t' from RBD.

Fixes errors such as:

../../src/storage/storage_backend_rbd.c: In function 'virStorageBackendRBDVolWipe':
../../src/storage/storage_backend_rbd.c:1281:15: error: format '%zu' expects argument of type 'size_t', but argument 8 has type 'uint64_t {aka long long unsigned int}' [-Werror=format=]
     VIR_DEBUG("Need to wipe %zu bytes from RBD image %s/%s",
               ^
../../src/util/virlog.h:90:73: note: in definition of macro 'VIR_DEBUG_INT'
     virLogMessage(src, VIR_LOG_DEBUG, filename, linenr, funcname, NULL, __VA_ARGS__)
                                                                         ^
../../src/storage/storage_backend_rbd.c:1281:5: note: in expansion of macro 'VIR_DEBUG'
     VIR_DEBUG("Need to wipe %zu bytes from RBD image %s/%s",
     ^
Signed-off-by: NEric Blake <eblake@redhat.com>

Checking whether x > 0 before looping over [0..x] items doesn't make
sense and multi-line body must have curly brackets around it.

Best viewed with '-w'.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Since Ceph version Infernalis (9.2.0) the new fast-diff mechanism
of RBD allows for querying actual volume usage.

Prior to this version there was no easy and fast way to query how
much allocation a RBD volume had inside a Ceph cluster.

To use the fast-diff feature it needs to be enabled per RBD image
and is only supported by Ceph cluster running version Infernalis
(9.2.0) or newer.

Without the fast-diff feature enabled libvirt will report an allocation
identical to the image capacity. This is how libvirt behaves currently.

'virsh vol-info rbd/image2' might output for example:

  Name:           image2
  Type:           network
  Capacity:       1,00 GiB
  Allocation:     124,00 MiB

Newly created volumes will have the fast-diff feature enabled if the
backing Ceph cluster supports it.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

In commit 0b15f920 there is a #ifdef which requires LIBRBD_VERSION_CODE
266 or newer for rbd_diff_iterate2()

rbd_diff_iterate2() is available since 266, so this if-statement should
require anything newer than 265.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

As more and more features are added to RBD volumes we will need to
call this method more often.

By moving it into a internal function we can re-use code inside the
storage backend.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

This was only used in debugging messages and not in any real code.

Ceph/RBD uses uint64_t for sizes internally and they can be printed
with %zu without any need for casting.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

Through the years the RBD storage pool code hasn't maintained the
same or correct coding standard which applies to libvirt.

This patch doesn't change any logic in the code, it only applies
the proper coding standards to the code where possible without
making large changes.

This way the code style used in this storage pool is consistent
throughout the whole file.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

By opening a RBD volume in Read-Only we do not register a
watcher on the header object inside the Ceph cluster.

Refreshing a volume only calls rbd_stat() which is a operation
which does not write to a RBD image.

This allows us to use a cephx user which has no write
permissions if we would want to use the libvirt storage pool
for informational purposes only.

It also saves us a write into the Ceph cluster which should
speed up refreshing a RBD pool.

rbd_open_read_only() is available in all librbd versions which
also support rbd_open().
Signed-off-by: NWido den Hollander <wido@widodh.nl>

RBD supports cloning by creating a snapshot, protecting it and create
a child image based on that snapshot afterwards.

The RBD storage driver will try to find a snapshot with zero deltas between
the current state of the original volume and the snapshot.

If such a snapshot is found a clone/child image will be created using
the rbd_clone2() function from librbd.

rbd_clone2() is available in librbd since Ceph version Dumpling (0.67) which
dates back to August 2013.

It will use the same features, strip size and stripe count as the parent image.

This implementation will only create a single snapshot on the parent image if
never changes. This reduces the amount of snapshots created for that RBD image
which benefits the performance of the Ceph cluster.

During build the decision will be made to use either rbd_diff_iterate() or
rbd_diff_iterate2().

The latter is faster, but only available on Ceph versions after 0.94 (Hammer).

Cloning is only supported if RBD format 2 is used. All images created by libvirt
are already format 2.

If a RBD format 1 image is used as the original volume the backend will report
a VIR_ERR_OPERATION_UNSUPPORTED error.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

Using VIR_STORAGE_VOL_WIPE_ALG_TRIM a RBD volume can be trimmed down
to 0 bytes using rbd_discard()

Effectively all the data on the volume will be lost/gone, but the volume
remains available for use afterwards.

Starting at offset 0 the storage pool will call rbd_discard() in stripe
size * count increments which is usually 4MB. Stripe size being 4MB and
count 1.

rbd_discard() is available since Ceph version Dumpling (0.67) which dates
back to August 2013.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

This new algorithm adds support for wiping volumes using TRIM.

It does not overwrite all the data in a volume, but it tells the
backing storage pool/driver that all bytes in a volume can be
discarded.

It depends on the backing storage pool how this is handled.

A SCSI backend might send UNMAP commands to remove all data present
on a LUN.

A Ceph backend might use rbd_discard() to instruct the Ceph cluster
that all data on that RBD volume can be discarded.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

When wiping the RBD image will be filled with zeros started
at offset 0 and until the end of the volume.

This will result in the RBD volume growing to it's full allocation
on the Ceph cluster. All data on the volume will be overwritten
however, making it unavailable.

It does NOT take any RBD snapshots into account. The original data
might still be in a snapshot of that RBD volume.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

This was reported in bug #1298024 where r would be filled with the
return code of rbd_open().

Should rbd_snap_unprotect() fail for any reason the virReportSystemError
call would return 'Success' since rbd_open() succeeded.

https://bugzilla.redhat.com/show_bug.cgi?id=1298024Signed-off-by: NWido den Hollander <wido@widodh.nl>

If no port number was provided for a storage pool libvirt defaults to
port 6789; however, librbd/librados already default to 6789 when no port
number is provided.

In the future Ceph will switch to a new port for the Ceph monitors since
port 6789 is already assigned to a different application by IANA.

Port 6789 is assigned to SMC-HTTPS and Ceph now has port 3300 assigned as
the 'Ceph monitor' port.

In this case it is the best solution to not hardcode any port number into
libvirt and let librados handle the connection.

Only if a user specifies a different port number we pass it down to librados,
otherwise we leave it blank.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

merge

It could happen that rbd_list() returns X names, but that while
refreshing the pool one of those RBD images is removed from Ceph
through a different route then libvirt.

We do not need to error out in such case, we can simply ignore the
volume and continue.

  error : volStorageBackendRBDRefreshVolInfo:289 :
    failed to open the RBD image 'vol-998': No such file or directory

It could also be that one or more Placement Groups (PGs) inside Ceph
are inactive due to a system failure.

If that happens it could be that some RBD images can not be refreshed
and a timeout will be raised by librados.

  error : volStorageBackendRBDRefreshVolInfo:289 :
    failed to open the RBD image 'vol-893': Connection timed out

Ignore the error and continue to refresh the rest of the pool's
contents.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

It could be that we error out while the RBD image has not been
opened yet. This would cause us to call rbd_close() on pointer
which has not been initialized.

Set it to NULL by default and only close if it is not NULL.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

This used to return 'unkown' and that was not correct.

A vol-dumpxml now returns:

<volume type='network'>
  <name>image3</name>
  <key>libvirt/image3</key>
  <source>
  </source>
  <capacity unit='bytes'>10737418240</capacity>
  <allocation unit='bytes'>10737418240</allocation>
  <target>
    <path>libvirt/image3</path>
    <format type='raw'/>
  </target>
</volume>

The RBD driver will now error out if a different format than RAW
is provided when creating a volume.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

The initial commit '74951ead' did not include the proper check for whether
any flags are supported by the driver.

Even though the driver doesn't support VIR_STORAGE_VOL_DELETE_ZEROED,
it still checks and allows the processing to continue

Also add the new VIR_STORAGE_VOL_DELETE_WITH_SNAPSHOTS since it is handled
as of commit id '3c7590e0'.

When a RBD volume has snapshots it can not be removed.

This patch introduces a new flag to force volume removal,
VIR_STORAGE_VOL_DELETE_WITH_SNAPSHOTS.

With this flag any existing snapshots will be removed prior to
removing the volume.

No existing mechanism in libvirt allowed us to pass such information,
so that's why a new flag was introduced.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

As of commit id '155ca616' a 'refreshVol' is called after the buildVol
succeeds in storageVolCreateXML, thus the volStorageBackendRBDRefreshVolInfo
call in virStorageBackendRBDBuildVol is no longer necessary.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Resolving an error reporting bug introduced by commit id '761491eb' which
just took the return of virStorageBackendRBDCreateImage and used it as
the basis for the message generated. This would generate EPERM regardless
of error seen.

We used to look at the librbd code version and depending on that
we would invoke rbd_create3() or rbd_create().

Since librbd version 0.67.9 we can however tell RBD that it should
create rbd format 2 images even if we invoke rbd_create().

The less options we pass to librbd, the more we can lean on the sane
defaults it uses.

For rbd_create3() we had things like the stripe count and unit hardcoded
in libvirt and that might cause problems down the road.
Signed-off-by: NWido den Hollander <wido@widodh.nl>

RBD API returns negative value of errno, in that case we can silently
ignore if RBD tries to delete a non-existent volume, just like FS
backend does.

The tool creating the image can get the capacity from the backing
storage. Just refresh the volume afterwards.

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

Since virSecretFree will call virObjectUnref anyway, let's just use that
directly so as to avoid the possibility that we inadvertently clear out
a pending error message when using the public API.

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Replace the authType, chap, and cephx unions in virStoragePoolSource
with a single pointer to a virStorageAuthDefPtr.  Adjust all users of
the previous chap/cephx and secret unions with the source->auth data.