- 20 9月, 2018 1 次提交
-
-
由 Erik Skultety 提交于
It doesn't really make sense for us to have stdlib.h and string.h but not stdio.h in the internal.h header. Signed-off-by: NErik Skultety <eskultet@redhat.com> Acked-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 17 9月, 2018 1 次提交
-
-
由 Shi Lei 提交于
Signed-off-by: NShi Lei <shi_lei@massclouds.com>
-
- 12 9月, 2018 3 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1613737 When processing the inputvol for encryption, we need to handle the case where the inputvol is encrypted. This then allows for the encrypted inputvol to be used either for an output encrypted volume or an output volume of some XML provided type. Add tests to show the various conversion options when either input or output is encrypted. This includes when both are encrypted. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
Commit 39cef12a altered/fixed the inputvol processing to create a multistep process when using an inputvol to create an encrypted output volume; however, it unnecessarily assumed/restricted the inputvol to be of 'raw' format only. Modify the processing code to allow the inputvol format to be checked and used in order to create the encrypted volume. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
There's really no need for it to be there since it's only ever used inside virStorageBackendCreateQemuImgCmdFromVol Signed-off-by: NJohn Ferlan <jferlan@redhat.com> ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 24 8月, 2018 2 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1613746 When shrinking the capacity of a qcow2 or luks volume using the qemu-img program, the --shrink qualifier must be added. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Shivaprasad G Bhat 提交于
The vol-dumpxml shows the volume target format type as raw for encrypted volumes. The error message when attempting to resize with prealloc is confusing here. Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 09 8月, 2018 1 次提交
-
-
由 Daniel P. Berrangé 提交于
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 24 7月, 2018 1 次提交
-
-
由 Michal Privoznik 提交于
After my change to the original patch that resulted in commit 8ed874b3 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: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
- 06 7月, 2018 1 次提交
-
-
由 Julio Faracco 提交于
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=1565004Signed-off-by: NJulio Faracco <jcfaracco@gmail.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 27 6月, 2018 7 次提交
-
-
由 John Ferlan 提交于
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: NJohn Ferlan <jferlan@redhat.com> ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
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: NJohn Ferlan <jferlan@redhat.com> ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
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: NJohn Ferlan <jferlan@redhat.com> ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
Remove the checks for qcow encryption since both callers (create and resize) would have already disallowed usage. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1526382 Since commit c4eedd79 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: NJohn Ferlan <jferlan@redhat.com> ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
Change from @enc to @encinfo leaving @enc for the vol->target.encryption in the storageBackendCreateQemuImgSetOptions code path. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
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: NJohn Ferlan <jferlan@redhat.com> ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 07 6月, 2018 1 次提交
-
-
由 Katerina Koukiou 提交于
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=1468422Signed-off-by: NKaterina Koukiou <kkoukiou@redhat.com>
-
- 16 5月, 2018 12 次提交
-
-
由 John Ferlan 提交于
Extract out command line setup and run from storageBackendCreateQemuImg as we'll need to run it twice soon. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
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: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
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: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
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: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
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: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
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: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
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: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
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: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Rename to storageBackendCreateQemuImgOpts - which is what it's doing. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Commit id 'a48c7141' 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: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Remove the != NULL checks, use !! for setting info.encryption. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Perform some code cleanup in areas that are about to be altered. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 07 5月, 2018 1 次提交
-
-
由 Ján Tomko 提交于
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: NJán Tomko <jtomko@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 04 5月, 2018 1 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 11 4月, 2018 1 次提交
-
-
由 Wim ten Have 提交于
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: NWim ten Have <wim.ten.have@oracle.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 01 2月, 2018 2 次提交
-
-
由 Daniel P. Berrangé 提交于
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>
-
由 Daniel P. Berrangé 提交于
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: NDaniel P. Berrangé <berrange@redhat.com>
-
- 30 1月, 2018 1 次提交
-
-
由 Peter Krempa 提交于
Commit 000e9504 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
-
- 03 1月, 2018 1 次提交
-
-
由 Julio Faracco 提交于
After commit a693fdba '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=1529663Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
-
- 27 10月, 2017 3 次提交
-
-
由 John Ferlan 提交于
Create a shim that will allow other backends to make use of qemu-img functionality to create or possibly modify the volume.
-
由 John Ferlan 提交于
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.
-
由 John Ferlan 提交于
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.
-