- 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 2月, 2017 3 次提交
-
-
由 John Ferlan 提交于
Create a virscsihost.c and place the functions there. That removes the last #ifdef __linux__ from virutil.c. Take the opporunity to also change the function names and in one case the parameters slightly
-
由 John Ferlan 提交于
Use the new virNodeDeviceGetParentName instead. Modify the callers to build the node device scsi_host# name string in order to call the new function so that proper lookup occurs.
-
由 John Ferlan 提交于
Rather than have them mixed in with the virutil apis, create a separate virvhba.c module and move the vHBA related calls into there. Soon there will be more added. Also modify the names of the functions and some arguments to be more indicative of what is really happening. Adjust the callers respectively. While I was changing fchosttest, rather than the non-descriptive names test1...test6, rename them to match what the test is doing.
-
- 19 1月, 2017 3 次提交
-
-
由 Peter Krempa 提交于
They are used only in the SCSI backend driver so there's no need to pollute the headers.
-
由 Peter Krempa 提交于
The iSCSI backend driver was using stuff from the SCSI driver without making sure that it's compiled in. Move the common code into the storage_util.c since it does not contain any specific code.
-
由 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.
-
- 07 1月, 2017 1 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1349696 As it turns out using only the 'parent' to achieve the goal of a consistent vHBA parent has issues with reboots where the scsi_hostX parent could change to scsi_hostY causing either failure to create the vHBA or usage of the wrong HBA for our vHBA. Thus add the ability to search for the "parent" by the parent wwnn/ wwpn values or just a fabric_name if someone only cares to ensure usage of the same SAN for the vHBA.
-
- 05 1月, 2017 3 次提交
-
-
由 John Ferlan 提交于
Remove duplicated code - make one simple path through Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Move the check for an already existing vHBA to the top of the function. No sense in first decoding a provided parent if the next thing we're going to do is fail if a provided wwnn/wwpn already exists. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Use the ret = -1, goto cleanup, etc. rather than current hodgepodge. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 24 6月, 2016 4 次提交
-
-
由 Ján Tomko 提交于
Do not call it with a magic constant matching the length of the pattern.
-
由 Ján Tomko 提交于
Switch from opendir to virDirOpen everywhere we need to report an error.
-
由 Ján Tomko 提交于
The directories we iterate over are unlikely to contain any entries starting with a dot, other than '.' and '..' which is already skipped by virDirRead.
-
由 Ján Tomko 提交于
Introduce a helper that only calls closedir if DIR* is non-NULL and sets it to NULL afterwards.
-
- 02 5月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
We had both and the only difference was that the latter also included information about multifunction setting. The problem with that was that we couldn't use functions made for only one of the structs (e.g. parsing). To consolidate those two structs, use the one in virpci.h, include that in domain_conf.h and add the multifunction member in it. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 29 3月, 2016 1 次提交
-
-
由 Nitesh Konkar 提交于
If the pool creation thread happens to detect the luns in the scsi target, the size parameters will be calculated as part of the refreshPool called from storagePoolCreate(). This means the virStoragePoolFCRefreshThread (commit id '512b8747') waiting to run and "refresh" the pool will essentially double the allocation and capacity values. A separate refresh would correct the values. To avoid this, the FCRefreshThread needs to reinitialize the pool size values prior to calling virStorageBackendSCSIFindLUs which eventually calls virStorageBackendSCSINewLun and updates the size values for each volume found.
-
- 10 12月, 2015 2 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1276198 Prior to commit id '98322052' failure to saferead the block device would cause an error to be logged and the device to be skipped while attempting to discover/create a stable target path for a new LUN (NPIV). This was because virStorageBackendSCSIFindLUs ignored errors from processLU and virStorageBackendSCSINewLun. Ignoring the failure allowed a multipath device with an "active" and "ghost" to be present on the host with the "ghost" block device being ignored. This patch will return a -2 to the caller indicating the desire to ignore the block device since it cannot be used directly rather than fail the pool startup.
-
由 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.
-
- 12 11月, 2015 2 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1277781 The virStoragePoolFCRefreshThread had passed a pointer to the pool obj in the virStoragePoolFCRefreshInfoPtr; however, we cannot assume that the pool exists still since we don't keep the pool lock throughout the duration of the thread. Therefore, instead of passing the pool obj pointer, pass the UUID of the pool and perform a lookup. If found, then we can perform the refresh using the locked pool obj pointer; otherwise, we just exit the thread since the pool is now gone.
-
由 John Ferlan 提交于
Change the field name from 'name' to 'fchost_name' to better id it.
-
- 24 6月, 2015 1 次提交
-
-
由 John Ferlan 提交于
Related to : https://bugzilla.redhat.com/show_bug.cgi?id=1171933 Rather than ignore the return status from virStorageBackendSCSIFindLUs, cause a failure to start the pool if a -1 is returned. Issue was noted during testing of the bz for iscsi that 'scsi' and 'fc' pools don't fail.
-
- 18 6月, 2015 1 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1224233 Currently it's not possible to determine the difference between a fatal memory allocation or failure to open/read the directory error with a perhaps less fatal, I didn't find the "block" device in the directory (which may be a disk entry without a block device). In the case of the latter, we shouldn't cause failure to continue searching in the caller (virStorageBackendSCSIFindLUs), rather we should allow trying reading the next directory entry. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 15 6月, 2015 2 次提交
-
-
由 Michal Privoznik 提交于
Instead of initializing return value to zero (success) and overwriting it on every failure just before the control jumps onto 'out' label, let's initialize to an error value and set to zero only when we are sure about the success. Just follow the pattern we have in the rest of the code. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Instead of initializing return value to zero (success) and overwriting it on every failure just before the control jumps onto 'out' label, let's initialize to an error value and set to zero only when we are sure about the success. Just follow the pattern we have in the rest of the code. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 27 4月, 2015 1 次提交
-
-
由 John Ferlan 提交于
commit id '1e13eff4' didn't init found when changed from a bool to an int in virStoragePoolFCRefreshThread and Coverity...
-
- 21 4月, 2015 3 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1171933 Adjust the processLU error returns to be a bit more logical. Currently, the calling code cannot determine the difference between a non disk/lun volume and a processed/found disk/lun. It can also not differentiate between perhaps real/fatal error and one that won't necessarily stop the code from finding other volumes. After this patch virStorageBackendSCSIFindLUsInternal will stop processing as soon as a "fatal" message occurs rather than continuting processing for no apparent reason. It will also only set the *found value when at least one of the processLU's was successful. With the failed return, if the reason for the stop was that the pool target path did not exist, was /dev, was /dev/, or did not start with /dev, then iSCSI pool startup and refresh will fail.
-
由 John Ferlan 提交于
Rather than passing/returning a pointer to a boolean to indicate that perhaps we should try again - adjust the return of the call to return the count of LU's found during processing, then let the caller decide what to do with that value.
-
由 John Ferlan 提交于
Use virStorageBackendPoolUseDevPath API to determine whether creation of stable target path is possible for the volume. This will differentiate a failed virStorageBackendStablePath which won't need to be fatal. Thus, we'll add a -2 return value to differentiate that the failure was a result of either the inability to find the symlink for the device or failure to open the target path directory
-
- 17 4月, 2015 1 次提交
-
-
由 John Ferlan 提交于
Invert the logical of retval and clean up code paths, especially goto's Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 02 4月, 2015 2 次提交
-
-
由 John Ferlan 提交于
Seems to be a remnant that was never cleaned up from original submit... Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Erik Skultety 提交于
In order to be able to use 'checkPool' inside functions which do not have any connection reference, 'conn' attribute needs to be discarded from the checkPool's signature, since it's not used by any storage backend anyway.
-
- 02 3月, 2015 1 次提交
-
- 01 12月, 2014 1 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1159180 Move the API from the backend to storage_conf and rename it to virStoragePoolGetVhbaSCSIHostParent. A future patch will need to use this functionality from storage_conf
-
- 20 11月, 2014 2 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1152382 When libvirt create's the vport (VPORT_CREATE) for the vHBA, there isn't enough "time" between the creation and the running of the following backend->refreshPool after a backend->startPool in order to find the LU's. Population of LU's happens asynchronously when udevEventHandleCallback discovers the "new" vHBA port. Creation of the infrastructure by udev is an iterative process creating and discovering actual storage devices and adjusting the environment. Because of the time it takes to discover and set things up, the backend refreshPool call done after the startPool call will generally fail to find any devices. This leaves the newly started pool appear empty when querying via 'vol-list' after startup. The "workaround" has always been to run pool-refresh after startup (or any time thereafter) in order to find the LU's. Depending on how quickly run after startup, this too may not find any LUs in the pool. Eventually though given enough time and retries it will find something if LU's exist for the vHBA. This patch adds a thread to be executed after the VPORT_CREATE which will attempt to find the LU's without requiring the external run of refresh-pool. It does this by waiting for 5 seconds and searching for the LU's. If any are found, then the thread completes; otherwise, it will retry once more in another 5 seconds. If none are found in that second pass, the thread gives up. Things learned while investigating this... No need to try and fill the pool too quickly or too many times. Over the course of creation, the udev code may 'add', 'change', and 'delete' the same device. So if the refresh code runs and finds something, it may display it only to have a subsequent refresh appear to "lose" the device. The udev processing doesn't seem to have a way to indicate that it's all done with the creation processing of a newly found vHBA. Only the Lone Ranger has silver bullets to fix everything.
-
由 John Ferlan 提交于
Fix a problem in the getBlockDevice and processLU where retval initialized to zero causing some failures to erroneously continue through to the virStorageBackendSCSINewLun with an attempt to find a path for "/dev/(null)". This would fail approximately 10 seconds later with debug message: virStorageBackendSCSINewLun:203 : No stable path found for '/dev/(null)' in '/dev/disk/by-path' The root cause of the issue is for many /sys/bus/scsi/devices/<lun path> there is no "block*" device found for the vHBA's, where "<lun path>" are the various paths created for the vHBA, such as "17:0:0:0", "17:0:1:0", "17:0:2:0", "17:0:3:0", etc. If the block device isn't found, then the directory should just be ignored rather than attempting to process it. The bug was that in getBlockDevice the assumption was "block" would exist and either getNewStyleBlockDevice or getOldStyleBlockDevice would fill in @block_device. However, if 'block*' doesn't exist, then the code returned NULL for block_device *and* a good (zero) retval value. This caused the processLU code to attempt the virStorageBackendSCSINewLun which failed "at some point in time" in the future. After this change - on test system the refresh-pool didn't have a noticable pause of about 20 seconds - it completed within a second since no longer was there an attempt/need to find "/dev/(null)". Additionally, the virStorageBackendSCSIFindLU's shouldn't be declaring found unless the processLU actually returns success. This will be important in the followup patch which relies on whether a LU was found.
-
- 15 11月, 2014 1 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 12 11月, 2014 3 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1160926 Introduce a 'managed' attribute to allow libvirt to decide whether to delete a vHBA vport created via external means such as nodedev-create. The code currently decides whether to delete the vHBA based solely on whether the parent was provided at creation time. However, that may not be the desired action, so rather than delete and force someone to create another vHBA via an additional nodedev-create allow the configuration of the storage pool to decide the desired action. During createVport when libvirt does the VPORT_CREATE, set the managed value to YES if not already set to indicate to the deleteVport code that it should delete the vHBA when the pool is destroyed. If libvirtd is restarted all the memory only state was lost, so for a persistent storage pool, use the virStoragePoolSaveConfig in order to write out the managed value. Because we're now saving the current configuration, we need to be sure to not save the parent in the output XML if it was undefined at start. Saving the name would cause future starts to always use the same parent which is not the expected result when not providing a parent. By not providing a parent, libvirt is expected to find the best available vHBA port for each subsequent (re)start. At deleteVport, use the new managed value to decide whether to execute the VPORT_DELETE. Since we no longer save the parent in memory or in XML when provided, if it was not provided, then we have to look it up.
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1160926 Passing a copy of the storage pool adapter to a function just changes the copy of the fields in the particular function and then when returning to the caller those changes are discarded. While not yet biting us in the storage clean-up case, it did cause an issue for the fchost storage pool startup case, createVport. The issue was at startup, if no parent is found in the XML, the code will search for the 'best available' parent and then store that in the in memory copy of the adapter. Of course, in this case it was a copy, so when returning to the virStorageBackendSCSIStartPool that change was discarded (or lost) from the pool->def->source.adapter which meant at shutdown (deleteVport), the code assumed no adapter was passed and skipped the deletion, leaving the vHBA created by libvirt still defined requiring an additional stop of a nodedev-destroy to remove. Adjusted the createVport to take virStoragePoolDefPtr instead of the adapter copy. Then use the virStoragePoolSourceAdapterPtr when processing. A future patch will need the 'def' anyway, so this just sets up for that.
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1160565 The existing code assumed that the configuration of a 'parent' attribute was correct for the createVport path. As it turns out, that may not be the case which leads errors during the deleteVport path because the wwnn/wwpn isn't associated with the parent. With this change the following is reported: error: Failed to start pool fc_pool_host3 error: XML error: Parent attribute 'scsi_host4' does not match parent 'scsi_host3' determined for the 'scsi_host16' wwnn/wwpn lookup. for XML as follows: <pool type='scsi'> <name>fc_pool</name> <source> <adapter type='fc_host' parent='scsi_host4' wwnn='5001a4aaf3ca174b' wwpn='5001a4a77192b864'/> </source> Where 'nodedev-dumpxml scsi_host16' provides: <device> <name>scsi_host16</name> <path>/sys/devices/pci0000:00/0000:00:04.0/0000:10:00.0/host3/vport-3:0-11/host16</path> <parent>scsi_host3</parent> <capability type='scsi_host'> <host>16</host> <unique_id>13</unique_id> <capability type='fc_host'> <wwnn>5001a4aaf3ca174b</wwnn> <wwpn>5001a4a77192b864</wwpn> ... The patch also adjusts the description of the storage pool to describe the restrictions. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-