- 15 8月, 2018 1 次提交
-
-
由 Michal Privoznik 提交于
The virSecretGetSecretString() helper looks up a secret for given pool and returns its value in @secret_value and its length in @secret_value_size. However, the trailing '\0' is not included in either of the variables. This is because usually the value of the secret is passed to some encoder (usually base64 encoder) where the trailing zero must not be accounted for. However, in two places we actually want the string as we don't process it any further. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 13 8月, 2018 3 次提交
-
-
由 Clementine Hayat 提交于
Signed-off-by: NClementine Hayat <clem@lse.epita.fr> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Clementine Hayat 提交于
The code to set the connection and connect using libiscsi will always be the same. Add function to avoid code duplication. Signed-off-by: NClementine Hayat <clem@lse.epita.fr> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Clementine Hayat 提交于
The size of blocks inside a volume and the number of blocks are needed later. Having a function that return thoses information will avoid code duplication. Signed-off-by: NClementine Hayat <clem@lse.epita.fr> Signed-off-by: NMichal Privoznik <mprivozn@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>
-
- 06 8月, 2018 3 次提交
-
-
由 Clementine Hayat 提交于
Change the SetContext function to be able to take the session type in argument. Took the function findPoolSources of iscsi backend and wired it to my function since the formatting is essentially the same. Signed-off-by: NClementine Hayat <clem@lse.epita.fr> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Clementine Hayat 提交于
We need here libiscsi for the storgae pool backend. For the iscsi-direct storage pool, only checkPool and refreshPool should be necessary for basic support. The pool is state-less and just need the informations within the volume to work. Signed-off-by: NClementine Hayat <clem@lse.epita.fr> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Clementine Hayat 提交于
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>
-
- 25 7月, 2018 2 次提交
-
-
由 Michal Privoznik 提交于
After a new iSCSI interface is successfully set up, we issue a sendtargets command. However, after 56057900 we don't update the host config which in turn makes login fail because iscsiadm is unable to find any matching record for the interface. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
When scanning for targets, iSCSI might give different results depending on the interface used. This is basically just name of config file under /etc/iscsi/ifaces to use. The file contains initiator IQN thus different results claim. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@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>
-
- 11 7月, 2018 1 次提交
-
-
由 Shichangkuo 提交于
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>
-
- 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>
-
- 12 6月, 2018 1 次提交
-
-
由 Anya Harter 提交于
And remove NULL checking from all callers. Signed-off-by: NAnya Harter <aharter@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>
-
- 05 6月, 2018 1 次提交
-
-
由 John Ferlan 提交于
Modify virStorageBackendLogicalLVCreate to ensure if encryption is requested that only type LUKS is supported; otherwise, error. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
- 29 5月, 2018 1 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1560946 Similar to the the Logical backend, use qemu-img on the created disk partition device to set up for LUKS encryption. Secret mgmt for the device can be complicated by a reboot possibly changing the path to the device if the infrastructure changes. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
- 25 5月, 2018 1 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1400475 In order to avoid a possible error as a result of kernel interactions with the partition helper, let's use virWaitForDevices to force things to settle down before attempting to open and read the partition. This is related to https://bugzilla.redhat.com/show_bug.cgi?id=1264719. Although perhaps overkill to have too many places to settle, since we know that the act of reading the partitions via libvirt_parthelper will cause udev activity/events - we just need to ensure udev has been settled before proceding with usage of the device. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> ACKed-by: NMichal Privoznik <mprivozn@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 2 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Andrea Bolognani 提交于
The latter is impossible to mock on platforms that use the gnulib implementation, such as FreeBSD, while the former doesn't suffer from this limitation. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-