Commit Graph

63 Commits

Author SHA1 Message Date
Michal Privoznik
fa18da2d81 storage_util: Prefer generic FICLONE over btrfs/xfs defines
After my change to the original patch that resulted in commit
8ed874b39b it was brought to my attention that all three defines
are the same: FICLONE = BTRFS_IOC_CLONE = XFS_IOC_CLONE (as
documented in ioctl_ficlone(2)). Therefore we should prefer
generic FICLONE over 'specific' defines for btrfs/xfs.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-07-24 15:15:34 +02:00
Julio Faracco
8ed874b39b storage: Rename btrfsCloneFile to support other filesystems.
This commit renames and adds other macros to support aother filesystems
when a reflink is performed. After that, XFS filesystems (and others)
with reflink support will be able to clone.

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

Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2018-07-06 16:56:56 +02:00
John Ferlan
39cef12a95 storage: Add support for using inputvol for encryption
Starting with QEMU 2.9, encryption convert processing requires
a multi-step process in order to generate an encrypted image from
some non encrypted raw image.

Processing requires to first create an encrypted image using the
sizing parameters from the input source and second to use the
--image-opts, -n, and --target-image-opts options along with inline
driver options to describe the input and output files, generating
two commands such as:

  $ qemu-img create -f luks \
      --object secret,id=demo.img_encrypt0,file=/path/to/secretFile \
      -o key-secret=demo.img_encrypt0 \
      demo.img 500K
  Formatting 'demo.img', fmt=luks size=512000 key-secret=demo.img_encrypt0
  $ qemu-img convert --image-opts -n --target-image-opts \
      --object secret,id=demo.img_encrypt0,file=/path/to/secretFile \
      driver=raw,file.filename=sparse.img \
      driver=luks,file.filename=demo.img,key-secret=demo.img_encrypt0
  $

This patch handles the convert processing by running the processing
in a do..while loop essentially reusing the existing create logic and
arguments to create the target vol from the inputvol and then converting
the inputvol using new arguments.

This then allows the following virsh command to work properly:

  virsh vol-create-from default encrypt1-luks.xml data.img --inputpool default

where encrypt1-luks.xml would provided the path and secret for
the new image, while data.img would be the source image.

Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-06-26 14:02:43 -04:00
John Ferlan
40f0e0348d storage: Remove storageBackendGenerateSecretData
Since we no longer support creating qcow2 encryption format
volumes, we no longer have to possibly create some secret and
have no real need for the function, so move the remaining
functionality to build the secret path back into the caller
storageBackendCreateQemuImg.

Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-06-26 14:02:43 -04:00
John Ferlan
9b753116f0 storage: Clean up storageBackendCreateQemuImgOpts
Since we only generate the @encinfo when there's a secret object
and thus we need to reference it in the options,

Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-06-26 14:02:43 -04:00
John Ferlan
9fe597dd09 storage: Clean up storageBackendCreateQemuImgCheckEncryption
Remove the checks for qcow encryption since both callers (create
and resize) would have already disallowed usage.

Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-06-26 14:02:43 -04:00
John Ferlan
8f83af6823 storage: Disallow create/resize of qcow2 encrypted images
https://bugzilla.redhat.com/show_bug.cgi?id=1526382

Since commit c4eedd793 disallowed qcow2 encrypted images to be
used for domains, it no longer makes sense to allow a qcow2
encrypted volume to be created or resized.

Add a test that will exhibit the failure of creation as well
as the xml2xml validation of the format still being correct.

Update the documentation to note the removal of the capability
to create and use qcow/default encrypted volumes.

Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-06-26 14:02:43 -04:00
John Ferlan
af0e6580cd storage: Rename encryption info variable for clarity
Change from @enc to @encinfo leaving @enc for the vol->target.encryption
in the storageBackendCreateQemuImgSetOptions code path.

Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-06-26 14:02:43 -04:00
John Ferlan
b056e09b28 storage: Don't allow encryption secretPath to be NULL
Allowing a NULL @secretPath for virStorageBackendCreateQemuImgCmdFromVol
would result in a generated command line with a dangling "file=" output.
So let's make sure the @secretPath exists before processing.

This means we should pass a dummy path from the storage test.

Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-06-26 14:02:43 -04:00
Katerina Koukiou
fab2e49d3c storage: fix crash in luks encrypted volume creation
Fix the case when creating a luks encrypted volume
via an xml file without 'secret' element.
libvirtd was receiving SIGSEGV, now proper error is reported for
the missing element.

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

Signed-off-by: Katerina Koukiou <kkoukiou@redhat.com>
2018-06-06 18:02:59 +02:00
John Ferlan
352e549450 storage_util: Introduce storageBackendDoCreateQemuImg
Extract out command line setup and run from storageBackendCreateQemuImg
as we'll need to run it twice soon.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2018-05-15 16:57:24 -04:00
John Ferlan
e1e1fcf769 storage_util: Introduce storageBackendCreateQemuImgSetInput
Split up virStorageBackendCreateQemuImgCmdFromVol into two parts.
It's too long anyway and virStorageBackendCreateQemuImgCmdFromVol
should just handle the command line processing.

NB: Requires changing info.* into info->* references.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2018-05-15 16:57:24 -04:00
John Ferlan
4b9055c930 storage_util: Move @type into _virStorageBackendQemuImgInfo
We're about to split up the code a bit more, so we'll need this
to be in the local struct.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2018-05-15 16:57:24 -04:00
John Ferlan
b5c8c547b7 storage_util: Split preallocate set in storageBackendCreateQemuImgOpts
The only way preallocate could be set is if the info->format was
not RAW (see storageBackendCreateQemuImgSetBacking), so let's just
extract it from the if/else surrounding the application of the
encryption options.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2018-05-15 16:57:24 -04:00
John Ferlan
c46fc572be storage_util: Split backing_fmt set in storageBackendCreateQemuImgOpts
The only way backing_fmts could be set is if the info->format was
not RAW (see storageBackendCreateQemuImgSetBacking), so let's just
extract it from the if/else surrounding the application of the
encryption options.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2018-05-15 16:57:24 -04:00
John Ferlan
3d14408c17 storage_util: Remove luks distinction from secret path and alias
Remove the "luks" distinction as the code is about to become more
generic and be able to support qcow encryption as well.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2018-05-15 16:57:24 -04:00
John Ferlan
9118e23f6d storage_util: Move secretPath generation
Move generation of secretPath to storageBackendGenerateSecretData
and simplify a bit since we know vol->target.encryption is set plus
we have a local @enc.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2018-05-15 16:57:24 -04:00
John Ferlan
3d1db851ca storage_util: Generate the qcow secret earlier
Rather than having storageBackendCreateQemuImgCheckEncryption
perform the virStorageGenerateQcowEncryption, let's just do that
earlier during storageBackendCreateQemuImg so that the check
helper is just a check helper rather doing something different
based on whether the format is qcow[2] or raw based encryption.

This fixes an issue in the storageBackendResizeQemuImg processing
for qcow encryption where if a secret was not available for a
volume, a new secret will not be generated and instead an error
message will be generated.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2018-05-15 16:55:09 -04:00
John Ferlan
9629fe258f storage_util: Rename virQEMUBuildLuksOpts
Rename to storageBackendCreateQemuImgOpts - which is what it's doing.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2018-05-15 16:54:58 -04:00
John Ferlan
8fc9949caa storage_util: Remove unnecessary check
Commit id 'a48c71411' altered the logic a bit and didn't
remove an unnecessary check as info.encryption is true when
vol->target.encryption != NULL, so if we enter the if segment
with info.format == VIR_STORAGE_FILE_RAW && vol->target.encryption
!= NULL, then there's no way info.encryption could be false.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2018-05-15 16:54:58 -04:00
John Ferlan
f78c814c5c storage_util: Cleanup usage of target.encryption
Remove the != NULL checks, use !! for setting info.encryption.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2018-05-15 16:54:58 -04:00
John Ferlan
9cfd507367 storage_util: Some code cleanup
Perform some code cleanup in areas that are about to be altered.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2018-05-15 16:54:58 -04:00
Ján Tomko
e5261d8fe3 storage: remove qemu-img help scraping
We have been checking whether qemu-img supports the -o compat
option by scraping the -help output.

Since we require QEMU 1.5.0 now and this option was introduced in 1.1,
assume we support it and ditch the help parsing code along with the
extra qemu-img invocation.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-05-07 10:23:20 +02:00
Martin Kletzander
d80b84c68b storage/: Remove spaces after casts
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-05-03 22:31:37 +02:00
Wim ten Have
c9ec7088c7 storage: extend preallocation flags support for qemu-img
This patch adds support to qcow2 formatted filesystem object storage by
instructing qemu-img to build them with preallocation=falloc whenever the
XML described storage <allocation> matches its <capacity>.  For all other
cases the filesystem stored objects are built with preallocation=metadata.

Signed-off-by: Wim ten Have <wim.ten.have@oracle.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2018-04-11 10:15:58 +02:00
Daniel P. Berrangé
31869efe2a storage: remove virConnectPtr from all backend functions
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: Daniel P. Berrangé <berrange@redhat.com>
2018-01-31 18:34:48 +00:00
Daniel P. Berrangé
a494f7fd4f storage: open secret driver connection at time of use
Instead of passing around a virConnectPtr object, just open a connection
to the secret driver at time of use. Opening connections on demand will
be beneficial when the secret driver is in a separate daemon. It also
solves the problem that a number of callers just pass in a NULL
connection today which prevents secret lookup working at all.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-01-31 18:34:48 +00:00
Peter Krempa
b2c5f28a72 storage: util: Properly ignore errors when backing volume is inaccessible
Commit 000e950455 tried to fix improper bracketing when refreshing disk
volume stats for a backing volume. Unfortunately the condition is still
wrong as in cases as the backing store being inaccessible
storageBackendUpdateVolTargetInfo returns -2 if instructed to ignore
errors. The condition does not take this into account.

Dumping XML of a volume which has inacessible backing store would then
result into:

 # virsh vol-dumpxml http.img --pool default
 error: An error occurred, but the cause is unknown

Properly ignore -2 for backing volumes.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1540022
2018-01-30 11:41:59 +01:00
Julio Faracco
d0307a9a76 storage: Fixing missing 'backingStore' tag from volume XML dumps.
After commit a693fdb 'vol-dumpxml' missed the ability to show backingStore
information. This commit adds a volume type for files that fixes this
problem.

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

Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
2018-01-03 16:04:24 +01:00
John Ferlan
29c5c7d27e storage: Introduce virStorageBackendCreateVolUsingQemuImg
Create a shim that will allow other backends to make use of qemu-img
functionality to create or possibly modify the volume.
2017-10-27 05:46:35 -04:00
John Ferlan
becb383a63 storage: Properly resize a local volume using LUKS
https://bugzilla.redhat.com/show_bug.cgi?id=1490279

Turns out the virStorageBackendVolResizeLocal did not differentiate
whether the target volume was a LUKS volume or not and just blindly
did the ftruncate() on the target volume.

Follow the volume creation logic (in general) and create a qemu-img
resize command to resize the target volume for LUKS ensuring that
the --object secret is provided as well as the '--image-opts' used
by the qemu-img resize logic to describe the path and secret ensuring
that it's using the luks driver on the volume of course.
2017-10-27 05:34:36 -04:00
John Ferlan
03984ae543 storage: Alter storageBackendCreateQemuImgSecretObject args
Since all that was really needed was a couple of fields and building
the object can be more generic, let's alter the args a bit. This will
be useful shortly for adding the secret object for a volume resize
operation on a luks volume that will need a secret object.
2017-10-27 05:31:19 -04:00
John Ferlan
07731f9917 storage: Add error path for virStorageBackendCreateQemuImgCmdFromVol
Rather than inline the various free's and return NULL, just create
an error label.
2017-10-27 05:31:19 -04:00
John Ferlan
ae94084b76 storage: Alter args to storageBackendResizeQemuImg
Rather than passing just the path, pass the virStorageVolDefPtr as we're
going to need it shortly.

Also fix the order of code and stack variables in the calling function
virStorageBackendVolResizeLocal.
2017-10-27 05:31:19 -04:00
Peter Krempa
0a294a8e28 util: storagefile: Add helpers to check presence of backing store
Add helpers that will simplify checking if a backing file is valid or
whether it has backing store. The helper virStorageSourceIsBacking
returns true if the given virStorageSource is a valid backing store
member. virStorageSourceHasBacking returns true if the virStorageSource
has a backing store child.

Adding these functions creates a central points for further refactors.
2017-10-17 06:19:18 +02:00
John Ferlan
c0682800cd storage: Use virStoragePoolObjGetDef accessor for storage_util
In preparation for privatizing the object, use the accessor.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2017-10-06 07:09:47 -04:00
Pavel Hrdina
000e950455 storage: Fix incorrect parenthesis placement
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1498528

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-10-04 18:52:54 +02:00
Ján Tomko
3f702f5ab1 virStorageFileResize: fallocate the whole capacity
We have been trying to implement the ALLOCATE flag to mean
"the volume should be fully allocated after the resize".

Since commit b0579ed9 we do not allocate from the existing
capacity, but from the existing allocation value.
However this value is a total of all the allocated bytes,
not an offset.

For a sparsely allocated file:
$ perl -e 'print "x"x8192;' > vol1
$ fallocate -p -o 0 -l 4096 vol1
$ virsh vol-info vol1 default
Capacity:       8.00 KiB
Allocation:     4.00 KiB

Treating allocation as an offset would result in an incompletely
allocated file:
$ virsh vol-resize vol1 --pool default 16384 --allocate
Capacity:       16.00 KiB
Allocation:     12.00 KiB

Call fallocate from zero on the whole requested capacity to fully
allocate the file. After that, the volume is fully allocated
after the resize:
$ virsh vol-resize vol1 --pool default 16384 --allocate
$ virsh vol-info vol1 default
Capacity:       16.00 KiB
Allocation:     16.00 KiB
2017-09-27 14:40:44 +02:00
John Ferlan
40630a8e45 storage: Introduce storage volume add, delete, count APIs
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: John Ferlan <jferlan@redhat.com>
2017-09-19 08:28:50 -04:00
John Ferlan
7c2945b854 storage: Introduce virStorageBackendRefreshVolTargetUpdate
Create a separate function to handle the volume target update
via probe processing.
2017-08-30 15:32:13 -04:00
John Ferlan
d062dfd9d9 storage: Fix return value checks for virAsprintf
Use the < 0 rather than == -1 (consistently) for virAsprintf errors.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2017-07-21 14:51:47 -04:00
Michal Privoznik
1f43aa67c5 Introduce virStorageVol{Download,Upload}Flags
These flags to APIs will tell if caller wants to use sparse
stream for storage transfer. At the same time, it's safe to
enable them in storage driver frontend and rely on our backends
checking the flags. This way we can enable specific flags only on
some specific backends, e.g. enable
VIR_STORAGE_VOL_DOWNLOAD_SPARSE_STREAM for filesystem backend but
not iSCSI backend.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-05-18 07:42:13 +02:00
Michal Privoznik
895479647b fdstream: Implement sparse stream
Basically, what is needed here is to introduce new message type
for the messages passed between the event loop callbacks and the
worker thread that does all the I/O. The idea is that instead of
a queue of read buffers we will have a queue where "hole of size
X" messages appear. That way the event loop callbacks can just
check the head of the queue and see if the worker thread is in
data or a hole section and how long the section is.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-05-18 07:42:13 +02:00
John Ferlan
e8b0212458 storage: Introduce virStorageBackendZeroPartitionTable
Create a wrapper/helper that can be used to call the storage backend
wipe helper - storageBackendVolWipeLocalFile for future use by logical
and disk backends to clear out the partition table rather than having
each open code the same algorithm.
2017-04-26 07:28:08 -04:00
John Ferlan
859a2d162a storage: Modify storageBackendWipeLocal to allow zero from end of device
Add bool 'zero_end' and logic that would allow a caller to wipe specific
portions of a target device either from the beginning (the default) or
from the end when zero_end is true.

This will allow for this code to wipe out partition table information
from a device.
2017-04-26 07:28:08 -04:00
John Ferlan
98f424d503 disk: Force usage of parted when checking disk format for "bsd"
https://bugzilla.redhat.com/show_bug.cgi?id=1439132

Add "bsd" to the list of format types to not checked during blkid
processing even though it supposedly knows the format - for some
(now unknown) reason it's returning partition table not found. So
let's just let PARTED handle "bsd" too.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2017-04-07 11:58:36 -04:00
John Ferlan
f2a1232031 disk: Resolve issues with disk partition build/start checks
https://bugzilla.redhat.com/show_bug.cgi?id=1439132

Commit id 'a48c674fb' added a check for format types "dvh" and "pc98"
to use the parted print processing instead of using blkid processing
in order to validate the label on the disk was what is expected for
disk pool startup. However, commit id 'a4cb4a74f' really messed things
up by missing an else condition causing PARTEDFindLabel to always
return DIFFERENT.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2017-04-07 11:58:36 -04:00
Andrea Bolognani
611ddefc16 storage: Avoid leak in virStorageUtilGlusterExtractPoolSources()
The contents of volname would be leaked if the function were
to be passed an invalid pooltype by the caller.

Make sure the memory is released instead.
2017-04-06 10:03:26 +02:00
Peter Krempa
dff04e0af0 storage: gluster: Use volume name as "<name>" field in the XML
For native gluster pools the <dir> field denotes a directory inside the
pool. For the actual pool name the <name> field has to be used.
2017-04-04 16:36:15 +02:00
Peter Krempa
5df6992e1c storage: Fix XPath for looking up gluster volume name
Use the relative lookup specifier rather than the global one. Otherwise
only the first name would be looked up. Add a test case to cover the
scenario.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1436574
2017-04-04 16:36:15 +02:00