Fix flapping disk info due to timing differences #369
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@nyoxi don't know if you want to check this also :) |
nyoxi
previously approved these changes
Jan 25, 2023
|
Looks good to me. |
mz-pdm
force-pushed
the
fix_hotplug_qga
branch
from
c75990d
to
66a1e1a
Compare
In commit 45903d0 there was code added to refresh the fs info earlier when a hotplug disk was added. Now this caused some side effect that when only that command was triggered, the info dict never contained 'disk.count', which caused us to change the diskMapping to the parsed data from fsinfo. Some minutes later when the disk command needed to be refreshed, it changed the diskMapping again, because (sometimes) the disks call returns more disks in comparision to the fsinfo call (for ex unmounted disks). Again a bit later, the fsinfo had to be refreshed, and the diskMapping was modified again. This occurs continiously, causing the device hash to change every time, and causing an excessive amount of dumpxml's also due to that. Fixed this by not setting the diskMapping when we have the _QEMU_DISKS_COMMAND in our caps. As this means somewhere else in time this command will refresh the disk info. Also refresh the disk info and not only fs info after a disk hotplug. Signed-off-by: Jean-Louis Dupond <jean-louis@dupond.be> Change-Id: I27a30e020a5221237d9d4ae7835a1cc4e69c0c59
dupondje
force-pushed
the
fix_hotplug_qga
branch
from
66a1e1a
to
6672410
Compare
|
Fixed the test and lint :) |
|
@dupondje, please fix the problems reported by the CI. |
|
Ah, you were faster, great. :-) |
|
/ost |
1 similar comment
|
/ost |
mz-pdm
approved these changes
Jan 26, 2023
|
/ost |
|
Thanks for the fix! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In commit 45903d0 there was code added to refresh the fs info earlier when a hotplug disk was added. Now this caused some side effect that when only that command was triggered, the info dict never contained 'disk.count', which caused us to change the diskMapping to the parsed data from fsinfo.
Some minutes later when the disk command needed to be refreshed, it changed the diskMapping again, because (sometimes) the disks call returns more disks in comparision to the fsinfo call (for ex unmounted disks).
Again a bit later, the fsinfo had to be refreshed, and the diskMapping was modified again.
This occurs continiously, causing the device hash to change every time, and causing an excessive amount of dumpxml's also due to that.
Fixed this by not setting the diskMapping when we have the _QEMU_DISKS_COMMAND in our caps. As this means somewhere else in time this command will refresh the disk info.
Also refresh the disk info and not only fs info after a disk hotplug.
Signed-off-by: Jean-Louis Dupond jean-louis@dupond.be
Change-Id: I27a30e020a5221237d9d4ae7835a1cc4e69c0c59