- 22 6月, 2016 2 次提交
-
-
由 John Ferlan 提交于
Create a helper virStorageBackendCreateQemuImgSetBacking to perform the backing store set Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Since we support QEMU 0.12 and later, checking for support of specific flags added prior to that isn't necessary. Thus start with the base of having the "-o options" available for the qemu-img create option and then determine whether we have the compat option for qcow2 files (which would be necessary up through qemu 2.0 where the default changes to compat 0.11). Adjust test to no long check for NONE and FLAG options as well was removing results of tests that would use that option. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 07 6月, 2016 1 次提交
-
-
由 John Ferlan 提交于
Create helper virStorageBackendCreateQemuImgSetInput to set the input Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 06 6月, 2016 1 次提交
-
-
由 John Ferlan 提交于
Split out a helper from virStorageBackendCreateQemuImgCmdFromVol to check the encryption - soon a new encryption sheriff will be patroling and that'll mean all sorts of new checks. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 26 4月, 2016 1 次提交
-
-
由 John Ferlan 提交于
Change 'ephemeral' to 'isephemeral' and 'private' to 'isprivate' since both are bools.
-
- 20 4月, 2016 3 次提交
-
-
由 Cole Robinson 提交于
Remove all the plumbing needed for the different qcow-create/kvm-img non-raw file creation. We can drop the error messages because CreateQemuImg will thrown an error for us but with slightly less fidelity (unable to find qemu-img), which I think is acceptable given the unlikeliness of that error in practice.
-
由 Cole Robinson 提交于
This an ubuntu/debian packaging convention. At one point it may have been an actually different binary, but at least as of ubuntu precise (the oldest supported ubuntu distro, released april 2012) kvm-img is just a symlink to qemu-img for back compat. I think it's safe to drop support for it
-
由 Cole Robinson 提交于
qcow-create was a crippled qemu-img impl that shipped with xen. I think supporting this was only relevant for really old distros that didn't have a proper qemu package, like early RHEL5. I think it's fair to drop support
-
- 15 4月, 2016 5 次提交
-
-
由 Olga Krishtal 提交于
In case of ploop volume, target path of the volume is the path to the directory that contains image file named root.hds and DiskDescriptor.xml. While using uploadVol and downloadVol callbacks we need to open root.hds itself. Upload or download operations with ploop volume are only allowed when images do not have snapshots. Otherwise operation fails. Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Olga Krishtal 提交于
Refreshes meta-information such as allocation, capacity, format, etc. Ploop volumes differ from other volume types. Path to volume is the path to directory with image file root.hds and DiskDescriptor.xml. https://openvz.org/Ploop/format Due to this fact, operations of opening the volume have to be done once again. get the information. To decide whether the given volume is ploops one, it is necessary to check the presence of root.hds and DiskDescriptor.xml files in volumes' directory. Only in this case the volume can be manipulated as the ploops one. Such strategy helps us to resolve problems that might occure, when we upload some other volume type from ploop source. Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Olga Krishtal 提交于
Returns error in case of vol-wipe cmd for a ploop volume Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>
-
由 Olga Krishtal 提交于
Changes the size of given ploop volume via ploop resize tool. Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>
-
由 Olga Krishtal 提交于
These callbacks let us to create ploop volumes in dir, fs and etc. pools. If a ploop volume was created via buildVol callback, then this volume is an empty ploop device with DiskDescriptor.xml. If the volume was created via .buildFrom - then its content is similar to input volume content. Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 11 2月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
Do not store the return value of called functions in the same variable as the (future) return value of the current function. This makes tracking the origin of the value easier and reduces the chance of introducing a new point of exit without resetting the return value back to -1.
-
- 30 1月, 2016 1 次提交
-
-
由 Wido den Hollander 提交于
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>
-
- 29 1月, 2016 1 次提交
-
-
由 Wido den Hollander 提交于
Use the cast of (virStorageVolWipeAlgorithm) adding the missing case:'s (VIR_STORAGE_VOL_WIPE_ALG_ZERO and VIR_STORAGE_VOL_WIPE_ALG_LAST). Additionally, the old code would also still run the SCRUB command on default since it didn't go to cleanup when a invalid flag was supplied. We now go to cleanup and exit if a invalid flag would be provided. Signed-off-by: NWido den Hollander <wido@widodh.nl>
-
- 17 12月, 2015 4 次提交
-
-
由 Ján Tomko 提交于
It is not used by the caller.
-
由 Ján Tomko 提交于
The only caller always passes 0 for the extent start. Drop the 'extent_start' parameter, as well as the mention of extents from the function name. Change off_t extent_length to unsigned long long wipe_len, as well as the 'remain' variable.
-
由 Ján Tomko 提交于
We do not need to pass a zero-filled buffer as an argument, the function can allocate its own.
-
由 Ján Tomko 提交于
Return -1: * on all failures of fdatasync. Instead of propagating -errno all the way up to the virStorageVolWipe API, which is documented to return 0 or -1. * after a partial wipe. If safewrite failed, we would re-use the non-negative return value of lseek (which should be 0 in this case, because that's the only offset we seek to).
-
- 10 12月, 2015 5 次提交
-
-
由 John Ferlan 提交于
I found this useful while processing a volume that wouldn't end up showing up in the resulting list of block volumes. In this case, the partition type wasn't found in the disk_types table.
-
由 John Ferlan 提交于
Similar to the openflags VIR_STORAGE_VOL_OPEN_NOERROR processing, if some read processing operation fails, check the readflags for the corresponding error flag being set. If so, rather then causing an error - use VIR_WARN to flag the error, but return -2 which some callers can use to perform specific actions. Use a new VIR_STORAGE_VOL_READ_NOERROR flag in a new VolReadErrorMode enum.
-
由 John Ferlan 提交于
While processing the volume for lseek, virFileReadHeaderFD, and virStorageFileGetMetadataFromBuf - failure would cause an error, but ret would not be set. That would result in an error message being sent, but successful status being returned.
-
由 John Ferlan 提交于
Just so it's clearer what to expect upon input and what types of return values could be generated. These were loosely copied from existing virStorageBackendUpdateVolTargetInfoFD.
-
由 John Ferlan 提交于
Similar to the openflags which allow VIR_STORAGE_VOL_OPEN_NOERROR to be passed to avoid open errors, add a 'readflags' variable so that in the future read failures could also be ignored.
-
- 21 11月, 2015 2 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1282288 Rather than using just open on the path, allow for the possibility that the path to be opened resides on an NFS root-squash target and was created under a different uid/gid. Without using virFileOpenAs an attempt to get the volume size data may fail if the current user doesn't have permissions to read the volume, such as would be the case if mode wasn't supplied in the volume XML and the default VIR_STORAGE_DEFAULT_VOL_PERM_MODE (e.g. 0600) was used. Under this scenario the owner/group is not root:root, thus this path run under root would fail to open/read the volume. NB: The virFileOpenAs code using OPEN_FORK will only work when the failure is not EACESS/EPERM and the path resolves to a shared file system.
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1282288 Although commit id '77346f27' resolves part of the problem regarding creating a qemu-img image in an NFS root-squash environment, it really didn't fix the entire problem. Unfortunately it only masked the problem. It seems qemu-img must open/create the image using 0644, which if used by target.perms would result in the chmod not being called since the mode desired and set match. Although qemu-img could conceivably ignore the mode when creating, libvirt has more knowledge of the environment and can make the adjustment to the mode far more easily by using virFileOpenAs with VIR_FILE_OPEN_FORCE_MODE. If that's successful, then we know on return the file will have the right owner and mode, so we can declare success
-
- 04 11月, 2015 3 次提交
-
-
由 John Ferlan 提交于
After successfully returning from virFileOpenAs, if subsequent calls fail, then we need to remove the file since our caller expects that failures after creation will remove the created file.
-
由 John Ferlan 提交于
After a successful qemu-img/qcow-create of the backing file, if we fail to stat the file, change it owner/group, or mode, then the cleanup path should remove the file.
-
由 John Ferlan 提交于
Currently the code does not handle the NFS root squash environment properly since if the file gets created, then the subsequent chmod will fail in a root squash environment where we're creating a file in the pool with qemu tools, such as seen via: $ virsh vol-create-from $pool $file.xml file.img --inputpool $pool assuming $file.xml is creating a file of "<format type='qcow2'"> from an existing file.img in the pool of "<format type='raw'>". This patch will utilize the virCommandSetUmask when creating the file in the NETFS pool. The virCommandSetUmask API was added in commit id '0e1a1a8c', which was after the original code was developed in commit id 'e1f27784' to attempt to handle the root squash environment. Also, rather than blindly attempting to chmod, check to see if the st_mode bits from the stat match what we're trying to set and only make the chmod if they don't. Also, a slight adjustment to the fallback algorithm to move the virCommandSetUID/virCommandSetGID inside the if (!filecreated) since they're only useful if we need to attempt to create the file again.
-
- 14 10月, 2015 1 次提交
-
-
由 John Ferlan 提交于
Rework the code in order to use the "ret = -1;" and goto cleanup; coding style. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 08 10月, 2015 1 次提交
-
-
由 John Ferlan 提交于
Cleanup calls to virStorageBackendCopyToFD a bit. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 02 9月, 2015 1 次提交
-
-
由 John Ferlan 提交于
Commit id '7c2d65dd' changed the default value of mode to be -1 if not supplied in the XML, which should cause creation of the volume using the default mode of VIR_STORAGE_DEFAULT_VOL_PERM_MODE; however, the check made was whether mode was '0' or not to use default or provided value. This patch fixes the issue to check if the 'mode' was provided in the XML and use that value.
-
- 24 8月, 2015 1 次提交
-
-
由 Guido Günther 提交于
While a zero allocation in safezero should be fine it isn't when we use posix_fallocate which returns EINVAL on a zero allocation. While we could skip the zero allocation in safezero_posix_fallocate it's an optimization to do it for all allocations. This fixes vm installation via virtinst for me which otherwise aborts like: Starting install... Retrieving file linux... | 5.9 MB 00:01 ... Retrieving file initrd.gz... | 29 MB 00:07 ... ERROR Couldn't create storage volume 'virtinst-linux.sBgds4': 'cannot fill file '/var/lib/libvirt/boot/virtinst-linux.sBgds4': Invalid argument' The error was introduced by e30297b0 as spotted by Chunyan Liu
-
- 24 7月, 2015 1 次提交
-
-
由 Chris J Arges 提交于
In commit 155ca616, a change was introduced that no longer allowed defining volumes via XML with a capacity of '0'. Because we check for info.size_arg to be non-zero, this use-case fails. This patch allows info.size_arg to be zero if no backing store is specified. Signed-off-by: NChris J Arges <chris.j.arges@canonical.com>
-
- 10 7月, 2015 2 次提交
-
-
由 Prerna Saxena 提交于
When virsh vol-clone is attempted on a raw file where capacity > allocation, the resulting cloned volume has a size that matches the virtual-size of the parent; in place of matching its actual, disk size. This patch fixes the cloned disk to have same _allocated_size_ as the parent file from which it was cloned. Ref: http://www.redhat.com/archives/libvir-list/2015-May/msg00050.html Also fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1130739Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Ján Tomko 提交于
Instead of storing the remaining bytes, store the position of the first unallocated byte. This will allow changing the amount of bytes copied by virStorageBackendCopyToFD without changing the safezero call. No functional impact.
-
- 26 5月, 2015 1 次提交
-
-
由 Cole Robinson 提交于
The XML parser sets a default <mode> if none is explicitly passed in. This is then used at pool/vol creation time, and unconditionally reported in the XML. The problem with this approach is that it's impossible for other code to determine if the user explicitly requested a storage mode. There are some cases where we want to make this distinction, but we currently can't. Handle <mode> parsing like we handle <owner>/<group>: if no value is passed in, set it to -1, and adjust the internal consumers to handle it.
-
- 28 4月, 2015 1 次提交
-
-
由 Cole Robinson 提交于
Trying to use qemu:///session to create a storage pool pointing at /tmp will usually fail with something like: $ virsh pool-start tmp error: Failed to start pool tmp error: cannot open volume '/tmp/systemd-private-c38cf0418d7a4734a66a8175996c384f-colord.service-kEyiTA': Permission denied If any volume in an FS pool can't be opened by the daemon, the refresh fails, and the pool can't be used. This causes pain for virt-install/virt-manager though. Imaging a user downloads a disk image to /tmp. virt-manager wants to import /tmp as a storage pool, so we can detect what disk format it is, and set the XML correctly. However this case will likely fail as explained above. Change the logic here to skip volumes that fail to open. This could conceivably cause user complaints along the lines of 'why doesn't libvirt show $ROOT-OWNED-VOLUME-FOO', but figuring that currently the pool won't even startup, I don't think there are any current users that care about that case. https://bugzilla.redhat.com/show_bug.cgi?id=1103308
-
- 21 4月, 2015 1 次提交
-
-
由 John Ferlan 提交于
Fix the if (!STRPREFIX(path, "/dev")) to be if (!STRPREFIX(path, "/dev/")) to ensure a path such as "/device" isn't declared stable.
-