- 21 2月, 2017 1 次提交
-
-
由 Peter Krempa 提交于
Add APIs that allow to dynamically register driver backends so that the list of available drivers does not need to be known during compile time. This will allow us to modularize the storage driver on runtime.
-
- 19 1月, 2017 2 次提交
-
-
由 Peter Krempa 提交于
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.
-
由 Peter Krempa 提交于
The storage driver helper functions that deal with parted were put into the disk backend code but are used commonly across.
-
- 18 1月, 2017 1 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1346566 If libvirt_parthelper is erroneously told to append the partition separator 'p' onto the generated output for a disk pool using device mapper that has 'user_friendly_names' set to true, then the error recovery path will fail to find volume resulting in the pool being in an unusable state. So, augment the documentation to provide the better hint that the part_separator='yes' should be set when user_friendly_names are not being used. Additionally, once we're in the error path where the returned name doesn't match the expected partition name try to see if the reason is because the 'p' was erroneosly added. If so alter the about to be removed vol->target.path so that the DiskDeleteVol code can find the partition that was created and remove it.
-
- 10 1月, 2017 2 次提交
-
-
由 John Ferlan 提交于
Commit id 'a48c674f' caused problems for systems without PARTED installed. So move the PARTED probing code back to storage_backend_disk.c and create a shim within storage_backend.c to call it if WITH_STORAGE_DISK is true; otherwise, just return -1 with the error.
-
由 John Ferlan 提交于
Rather than have the Disk code having to use PARTED to determine if there's something on the device, let's use the virStorageBackendDeviceProbe. and only fallback to the PARTED probing if the BLKID code isn't built in. This will also provide a mechanism for the other current caller (File System Backend) to utilize a PARTED parsing algorithm in the event that BLKID isn't built in to at least see if *something* exists on the disk before blindly trying to use. The PARTED error checking will not find file system types, but if there is a partition table set on the device, it will at least cause a failure. Move virStorageBackendDiskValidLabel and virStorageBackendDiskFindLabel to storage_backend and rename/rework the code to fit the new model. Update the virsh.pod description to provide a more generic description of the process since we could now use either blkid or parted to find data on the target device. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 02 12月, 2016 1 次提交
-
-
由 Yuri Chornoivan 提交于
-
- 11 5月, 2016 2 次提交
-
-
由 John Ferlan 提交于
Commit id 'df1011ca' modified virStorageBackendDiskDeleteVol to use "dmsetup remove --force" to remove the volume, but left things in an inconsistent state since the partition still existed on the disk and only the device mapper device (/dev/dm-#) was removed. Prior to commit '1895b421' (or '1ffd82bb' and '471e1c4e'), this could go unnoticed since virStorageBackendDiskRefreshPool wasn't called. However, the pool would be unusable since the /dev/dm-# device would be removed even though the partition was not removed unless a multipathd restart reset the link. That would of course make the volume appear again in the pool after a refresh or pool start after libvirt reload. This patch removes the 'dmsetup' logic and re-implements the partition deletion logic for device mapper devices. The removal of the partition via 'parted rm --script #' will cause udev device change logic to allow multipathd to handle removing the dm-* device associated with the partition.
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1265694 Commit id '020135dc' didn't quite get the algorithm correct when a device mapper source ended with a non numeric value (e.g. ends with an alphabet value). This patch modifies the 'part_separator' logic to add the "p" separator to the attempted target path name only when specified as part_separator='yes'. For a source name that already ends with a number, the logic doesn't change as the part separator would need to be there. For a source name that ends with something other than a number, this allows the possibility that a "p" separator can be added. The default for one of these source devices is to not add the separator. The key for device mapper and the need for a partition separator "p" is the presence of a number in the last character of the device name link in /dev/mapper. A name such as "/dev/mapper/mpatha1" would generate a "/dev/mapper/mpatha1p1" partition, while "/dev/mapper/mpatha" would generate partition "/dev/mapper/mpatha1". Similarly for a device mapper entry not using friendly names or an alias, a device such as "/dev/mapper/3600a0b80005b10ca00005ad656fd8d93" would generate a paritition "/dev/mapper/3600a0b80005b10ca00005ad656fd8d93p1", while a device such as "/dev/mapper/3600a0b80005b10ca00005e115729093f" would generate a partition "/dev/mapper/3600a0b80005b10ca00005e115729093f1". The long number is the WWID of the device. It's also possible to assign an alias for a device mapper entry, that alias follows the same rules with respect to ending with a number or not when adding a "p" to create the target device path.
-
- 20 1月, 2016 1 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1265694 In order to be able to process disk storage pool's using a multipath device to handle the partitions, libvirt_parthelper will need a way to not automatically add a partition separator "p" to the generated device name for each partition found. This is designed to mimic the multipath features known as 'user_friendly_names' and custom 'alias' name. If the part_separator attribute is set to "no", then generation of the multipath partition name will not include the "p" partition separator unless the source device path name ends with a number. The generated partition names that get passed back to libvirt are processed in order to find the device mapper multipath (dm-#) path device. For example, device path "/dev/mapper/mpatha" would create partitions "/dev/mapper/mpatha1", "/dev/mapper/mpatha2", etc. instead of "/dev/mapper/mpathap1", "/dev/mapper/mpathap2", etc. If the device path ends with a number "/dev/mapper/mpatha1", then the algorithm to generate names "/dev/mapper/mpatha1p1", "/dev/mapper/mpatha1p2", etc. would be utilized. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 10 12月, 2015 1 次提交
-
-
由 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.
-
- 05 10月, 2015 5 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1247987 Calculation of the extended and logical partition values for the disk pool is complex. As the bz points out an extended partition should have it's allocation initialized to 0 (zero) and keep the capacity as the size dictated by the extents read. Then for each logical partition found, adjust the allocation of the extended partition. Finally, previous logic tried to avoid recalculating things if a logical partition was deleted; however, since we now have special logic to handle the allocation of the extended partition, just make life easier by reading the partition table again - rather than doing the reverse adjustment.
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1251461 When 'starting' up a disk pool, we need to make sure the label on the device is valid; otherwise, the followup refreshPool will assume the disk has been properly formatted for use. If we don't find the valid label, then refuse the start and give a proper reason.
-
由 John Ferlan 提交于
Let's check to ensure we can find the Partition Table in the label and that libvirt actually recognizes that type; otherwise, when we go to read the partitions during a refresh operation we may not be reading what we expect. This will expand upon the types of errors or reason that a build would fail, so we can create more direct error messages.
-
由 John Ferlan 提交于
Modify virStorageBackendDiskValidLabel to add a 'writelabel' parameter. While initially for the purpose of determining whether the label should be written during DiskBuild, a future use during DiskStart could determine whether the pool should be started using the label found. Augment the error messages also to give a hint as to what someone may need to do or why the command failed.
-
由 John Ferlan 提交于
Create a new function virStorageBackendDiskValidLabel to handle checking whether there is a label on the device and whether it's valid or not. While initially for the purpose of determining whether the label can be overwritten during DiskBuild, a future use during DiskStart could determine whether the pool should be started using the label found.
-
- 23 6月, 2015 1 次提交
-
-
由 John Ferlan 提交于
Commit id '832a9256' adjusted the code to recognize when the default type of "unknown" was provided as the format type and to use "dos" if found. Since the pool is built with "dos" and it could cause some confusion when formatting the XML after building by seeing "unknown" in the output, let's just adjust the pool's setting to "dos" so that subsequent formats will see the value.
-
- 15 6月, 2015 1 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1225694 Check if the disk partition to be wiped is the extended partition, if so then disallow it. Do this via changing the wipeVol backend to check the volume before passing to the common virStorageBackendVolWipeLocal
-
- 29 5月, 2015 1 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1224018 The disk pool recalculates the pool allocation, capacity, and available values each time through processing a newly created disk partition. This created an issue with the allocation setting since the code used is shared with the refresh path. Each path calls virStorageBackendDiskReadPartitions which initializes the pool values and then processes the partition table from the 'libvirt_parthelper' utility output with the only difference being create passes a specific volume to be processed while refresh pass a NULL indicating to process all volumes. That passed volume is check during the virStorageBackendDiskMakeVol call to see if the current partition described by the volume key already exists. If it exists, then no adjustments are made to the allocation and the next entry in the output is checked. For the create path this resulted in only the most recently created partition size would be accounted for in the 'allocation' setting. This patch thus checks whether the incoming volume is NULL before clearing the pool allocation value.
-
- 24 5月, 2015 1 次提交
-
-
由 John Ferlan 提交于
Coverity points out it's possible for one of the virCommand{Output|Error}* API's to have not allocated 'output' and/or 'error' in which case the strstr comparison will cause a NULL deref Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 04 5月, 2015 1 次提交
-
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 10 4月, 2015 1 次提交
-
-
由 John Ferlan 提交于
Commit id '471e1c4e' only considered updating the pool if the extended partition was removed. As it turns out removing a primary partition would also need to update the freeExtent list otherwise the following sequence would fail (assuming a "fresh" disk pool for /dev/sde of 500M): $ virsh pool-info disk-pool ... Capacity: 509.88 MiB Allocation: 0.00 B Available: 509.84 MiB $ virsh vol-create-as disk-pool sde1 --capacity 300M $ virsh vol-delete --pool disk-pool sde1 $ virsh vol-create-as disk-pool sde1 --capacity 300M error: Failed to create vol sde1 error: internal error: no large enough free extent $ This patch will refresh the pool, rereading the partitions, and return
-
- 03 3月, 2015 1 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1181062 According to the formatstorage.html description for <source> element and "format" attribute: "All drivers are required to have a default value for this, so it is optional." As it turns out the disk backend did not choose a default value, so I added a default of "msdos" if the source type is "unknown" as well as updating the storage.html backend disk volume driver documentation to indicate the default format is dos.
-
- 02 3月, 2015 1 次提交
-
- 19 2月, 2015 1 次提交
-
-
由 Jiri Denemark 提交于
Not all files we want to find using virFileFindResource{,Full} are generated when libvirt is built, some of them (such as RNG schemas) are distributed with sources. The current API was not able to find source files if libvirt was built in VPATH. Both RNG schemas and cpu_map.xml are distributed in source tarball. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 29 1月, 2015 6 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1138516 If the provided volume name doesn't match what parted generated as the partition name, then return a failure. Update virsh.pod and formatstorage.html.in to describe the 'name' restriction for disk pools as well as the usage of the <target>'s <format type='value'>.
-
由 John Ferlan 提交于
When removing a volume that is the extended partition, all the logical volume partitions that exist within the extended partition will also be removed, so we need to refresh the pool to have the updated list
-
由 John Ferlan 提交于
During virStorageBackendDiskMakeDataVol processing, if we find an extended partition, then handle it specially when updating the capacity/allocation rather than calling virStorageBackendUpdateVolInfo. As it turns out, once a logical partition exists, any attempt to refresh the pool or after libvirtd restart/reload will result in a failure to open the extended partition device resulting in the inability to start the pool. The downside to this is we will lose the <permissions> and <timestamps> for the extended partition upon subsequent restart, refresh, reload since the stat() in virStorageBackendUpdateVolTargetInfoFD will not be called. However, since it's really only a container and shouldn't directly be used for storage that seems reasonable. Therefore, only use the existing code that already had a comment about getting the allocation wrong for extended partitions for just the setting of the extended partition data.
-
由 John Ferlan 提交于
While checking the existing partitions in virStorageBackendDiskPartFormat, the code would erroneously compare the volume target format type (eg, the virStoragePartedFsType) rather than the source partition type (eg, the virStorageVolTypeDisk) which is set during virStorageBackendDiskReadPartitions.
-
由 John Ferlan 提交于
During virStorageBackendDiskCreateVol if virStorageBackendDiskReadPartitions fails, then we were leaving with an error and a partition on the disk for which there was no corresponding volume and used space on the disk which could be reclaimable through direct parted activity. On a subsequent restart, reload, or refresh the volume may magically appear too.
-
由 John Ferlan 提交于
Move the API to before virStorageBackendDiskCreateVol in order to be able to call the DeleteVol API when virStorageBackendDiskReadPartitions fails so that we don't by chance leave a partition on the disk.
-
- 10 12月, 2014 1 次提交
-
-
由 Hao Liu 提交于
In old version of parted like parted-2.1-25, error message is shown in stdout when printing a disk info without disk label. Error: /dev/sda: unrecognised disk label This line has been moved to stderr in newer version of parted. So we should check both stdout and stderr when locating this message. This should fix bug: https://bugzilla.redhat.com/show_bug.cgi?id=1172468Signed-off-by: NHao Liu <hliu@redhat.com>
-
- 15 11月, 2014 1 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 11 9月, 2014 1 次提交
-
-
由 John Ferlan 提交于
Coverity complains that when multiplying to 32 bit values that eventually will be stored in a 64 bit value that it's possible the math could overflow unless one of the values being multiplied is type cast to the proper size. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 04 9月, 2014 1 次提交
-
-
由 Eric Blake 提交于
I'm about to add a syntax check that enforces our documented HACKING style of always using matching {} on if-else statements. This patch focuses on code shared between multiple drivers. * src/conf/domain_conf.c (virDomainFSDefParseXML) (virSysinfoParseXML, virDomainNetDefParseXML) (virDomainWatchdogDefParseXML) (virDomainRedirFilterUSBDevDefParseXML): Correct use of {}. * src/conf/interface_conf.c (virInterfaceDefParseDhcp) (virInterfaceDefParseIp, virInterfaceVlanDefFormat) (virInterfaceDefParseStartMode, virInterfaceDefParseBondMode) (virInterfaceDefParseBondMiiCarrier) (virInterfaceDefParseBondArpValid): Likewise. * src/conf/node_device_conf.c (virNodeDevCapStorageParseXML): Likewise. * src/conf/nwfilter_conf.c (virNWFilterRuleDetailsParse) (virNWFilterRuleParse, virNWFilterDefParseXML): Likewise. * src/conf/secret_conf.c (secretXMLParseNode): Likewise. * src/cpu/cpu_x86.c (x86Baseline, x86FeatureLoad, x86ModelLoad): Likewise. * src/network/bridge_driver.c (networkKillDaemon) (networkDnsmasqConfContents): Likewise. * src/node_device/node_device_hal.c (dev_refresh): Likewise. * src/nwfilter/nwfilter_gentech_driver.c (virNWFilterInstantiate): Likewise. * src/nwfilter/nwfilter_ebiptables_driver.c (_iptablesCreateRuleInstance): Likewise. * src/storage/storage_backend_disk.c (virStorageBackendDiskBuildPool): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 17 7月, 2014 1 次提交
-
-
由 Peter Krempa 提交于
For non-local storage drivers we can't expect to use the "scrub" tool to wipe the volume. Split the code into a separate backend function so that we can add protocol specific code later. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1118710
-
- 11 7月, 2014 1 次提交
-
-
由 Peter Krempa 提交于
For non-local storage drivers we can't expect to use the FDStream backend for up/downloading volumes. Split the code into a separate backend function so that we can add protocol specific code later.
-
- 16 5月, 2014 1 次提交
-
-
由 Eric Blake 提交于
The VIR_ENUM_DECL/VIR_ENUM_IMPL helper macros already append 'Type' to the enum name being converted; it looks silly to have functions with 'TypeType' in their name. Even though some of our enums have to have a 'Type' suffix, the corresponding string conversion functions do not. * src/conf/secret_conf.h (VIR_ENUM_DECL): Rename virSecretUsageType. * src/conf/storage_conf.h (VIR_ENUM_DECL): Rename virStoragePoolAuthType, virStoragePoolSourceAdapterType, virStoragePartedFsType. * src/conf/domain_conf.c (virDomainDiskDefParseXML) (virDomainFSDefParseXML, virDomainFSDefFormat): Update callers. * src/conf/secret_conf.c (virSecretDefParseUsage) (virSecretDefFormatUsage): Likewise. * src/conf/storage_conf.c (virStoragePoolDefParseAuth) (virStoragePoolDefParseSource, virStoragePoolSourceFormat): Likewise. * src/lxc/lxc_controller.c (virLXCControllerSetupLoopDevices): Likewise. * src/storage/storage_backend_disk.c (virStorageBackendDiskPartFormat): Likewise. * src/util/virstorageencryption.c (virStorageEncryptionSecretParse) (virStorageEncryptionSecretFormat): Likewise. * tools/virsh-secret.c (cmdSecretList): Likewise. * src/libvirt_private.syms (secret_conf.h, storage_conf.h): Export corrected names. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 02 5月, 2014 1 次提交
-
-
由 John Ferlan 提交于
Commit id 'ac9a0963' refactored out the 'withCapacity' for the virStorageBackendUpdateVolInfo() API. See: http://www.redhat.com/archives/libvir-list/2014-April/msg00043.html This resulted in a difference in how 'virsh vol-info --pool <poolName> <volume>' or 'virsh vol-list vol-list --pool <poolName> --details' outputs the capacity information for a directory pool with a qcow2 sparse file. For example, using the following XML mkdir /home/TestPool cat testpool.xml <pool type='dir'> <name>TestPool</name> <uuid>6bf80895-10b6-75a6-6059-89fdea2aefb7</uuid> <source> </source> <target> <path>/home/TestPool</path> <permissions> <mode>0755</mode> <owner>0</owner> <group>0</group> </permissions> </target> </pool> virsh pool-create testpool.xml virsh vol-create-as --pool TestPool temp_vol_1 \ --capacity 1048576 --allocation 1048576 --format qcow2 virsh vol-info --pool TestPool temp_vol_1 Results in listing a Capacity value. Prior to the commit, the value would be '1.0 MiB' (1048576 bytes). However, after the commit the output would be (for example) '192.50 KiB', which for my system was the size of the volume in my file system (eg 'ls -l TestPool/temp_vol_1' results in '197120' bytes or 192.50 KiB). While perhaps technically correct, it's not necessarily what the user expected (certainly virt-test didn't expect it). This patch restores the code to not update the target capacity for this path
-
- 25 4月, 2014 1 次提交
-
-
由 Nehal J Wani 提交于
Instead of hardcoding LIBEXECDIR as the location of the libvirt_parthelper binary, use virFileFindResource to optionally find it in the current build directory. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-