libvirt_mem: Add vhost configuration for SLES#6886
Open
sneh-3 wants to merge 1 commit into
Open
Conversation
1. check the running dostro and vm state 2. configures vhost max_mem_regions Signed-off-by: Sneh Shikha Yadav <syadav@linux.ibm.com>
WalkthroughA new inner helper function Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@libvirt/tests/src/libvirt_mem.py`:
- Around line 148-166: The verification failure for vhost max_mem_regions
configuration and the exception handler are downgrading setup errors to
warnings, allowing the test to continue in an invalid state. When verification
confirms the value is not set to "512" (around line 155-156), raise an exception
instead of just logging a warning. In the exception handler (around line
165-166), re-raise the caught exception instead of logging a warning and
continuing, so that SLES-targeted setup failures properly fail or cancel the
test path rather than silently proceeding.
- Around line 135-137: The current pipeline in the vm_check assignment combines
virsh and grep in a single command, which means the exit_status will reflect
grep's result rather than virsh's failure. If virsh list fails but grep runs
against empty output without error, the condition will incorrectly assess the
situation as safe to proceed. Split the command execution into two separate
steps: first run virsh list --state-running independently and check its exit
status, then only proceed to parse the output with grep if virsh succeeds. This
ensures virsh failures are explicitly caught before attempting to process
output.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 246a485b-d09a-43c6-957c-b8ee9d1ddada
📒 Files selected for processing (1)
libvirt/tests/src/libvirt_mem.py
Comment on lines
+135
to
+137
| vm_check = process.run("virsh list --state-running | grep -v 'Id\\|^$\\|^-'", | ||
| shell=True, ignore_status=True) | ||
| if vm_check.exit_status == 0 and vm_check.stdout_text.strip(): |
There was a problem hiding this comment.
Guard command can misclassify virsh failures as “safe to proceed.”
At Line 135, the pipeline status reflects grep, not virsh. If virsh list fails, this branch can still fall through and proceed with module reload. Please split command execution so virsh failure is handled explicitly before parsing output.
Suggested fix
- vm_check = process.run("virsh list --state-running | grep -v 'Id\\|^$\\|^-'",
- shell=True, ignore_status=True)
- if vm_check.exit_status == 0 and vm_check.stdout_text.strip():
+ vm_check = process.run("virsh list --state-running --name",
+ shell=True, ignore_status=True)
+ if vm_check.exit_status != 0:
+ logging.warning("Unable to determine running VMs; skipping vhost configuration")
+ return
+ running_vms = [name for name in vm_check.stdout_text.splitlines() if name.strip()]
+ if running_vms:
logging.warning("Running VMs detected, skipping vhost configuration for safety:")
- logging.warning("%s", vm_check.stdout_text.strip())
+ logging.warning("%s", "\n".join(running_vms))
return🧰 Tools
🪛 Ruff (0.15.15)
[error] 135-135: Function call with shell=True parameter identified, security issue
(S604)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@libvirt/tests/src/libvirt_mem.py` around lines 135 - 137, The current
pipeline in the vm_check assignment combines virsh and grep in a single command,
which means the exit_status will reflect grep's result rather than virsh's
failure. If virsh list fails but grep runs against empty output without error,
the condition will incorrectly assess the situation as safe to proceed. Split
the command execution into two separate steps: first run virsh list
--state-running independently and check its exit status, then only proceed to
parse the output with grep if virsh succeeds. This ensures virsh failures are
explicitly caught before attempting to process output.
Comment on lines
+148
to
+166
| if result.exit_status == 0: | ||
| logging.info("Successfully configured vhost max_mem_regions=512 at runtime") | ||
| verify_cmd = "cat /sys/module/vhost/parameters/max_mem_regions" | ||
| verify_result = process.run(verify_cmd, shell=True, ignore_status=True) | ||
| if verify_result.exit_status == 0: | ||
| current_value = verify_result.stdout_text.strip() | ||
| logging.info("Verified vhost max_mem_regions is set to: %s", current_value) | ||
| if current_value != "512": | ||
| logging.warning("Expected 512 but got %s", current_value) | ||
| else: | ||
| logging.debug("Could not verify vhost max_mem_regions setting") | ||
| else: | ||
| logging.warning("Failed to configure vhost at runtime: %s", | ||
| result.stderr_text) | ||
| else: | ||
| logging.debug("Non-SLES system detected, skipping vhost configuration") | ||
|
|
||
| except Exception as e: | ||
| logging.warning("Error setting up vhost max_mem_regions: %s", str(e)) |
There was a problem hiding this comment.
Setup precondition failures are downgraded to warnings, so the test can continue in invalid state.
At Line 155-156 and Line 165-166, failed verification and unexpected exceptions only log warnings. For SLES-targeted setup, this should fail/cancel the test path instead of silently continuing.
Suggested fix
- if current_value != "512":
- logging.warning("Expected 512 but got %s", current_value)
+ if current_value != "512":
+ test.cancel("vhost max_mem_regions verification failed: expected 512, got %s"
+ % current_value)
...
- else:
- logging.warning("Failed to configure vhost at runtime: %s",
- result.stderr_text)
+ else:
+ test.cancel("Failed to configure vhost at runtime: %s" % result.stderr_text)
...
- except Exception as e:
- logging.warning("Error setting up vhost max_mem_regions: %s", str(e))
+ except Exception as e:
+ test.cancel("Error setting up vhost max_mem_regions: %s" % str(e))📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| if result.exit_status == 0: | |
| logging.info("Successfully configured vhost max_mem_regions=512 at runtime") | |
| verify_cmd = "cat /sys/module/vhost/parameters/max_mem_regions" | |
| verify_result = process.run(verify_cmd, shell=True, ignore_status=True) | |
| if verify_result.exit_status == 0: | |
| current_value = verify_result.stdout_text.strip() | |
| logging.info("Verified vhost max_mem_regions is set to: %s", current_value) | |
| if current_value != "512": | |
| logging.warning("Expected 512 but got %s", current_value) | |
| else: | |
| logging.debug("Could not verify vhost max_mem_regions setting") | |
| else: | |
| logging.warning("Failed to configure vhost at runtime: %s", | |
| result.stderr_text) | |
| else: | |
| logging.debug("Non-SLES system detected, skipping vhost configuration") | |
| except Exception as e: | |
| logging.warning("Error setting up vhost max_mem_regions: %s", str(e)) | |
| if result.exit_status == 0: | |
| logging.info("Successfully configured vhost max_mem_regions=512 at runtime") | |
| verify_cmd = "cat /sys/module/vhost/parameters/max_mem_regions" | |
| verify_result = process.run(verify_cmd, shell=True, ignore_status=True) | |
| if verify_result.exit_status == 0: | |
| current_value = verify_result.stdout_text.strip() | |
| logging.info("Verified vhost max_mem_regions is set to: %s", current_value) | |
| if current_value != "512": | |
| test.cancel("vhost max_mem_regions verification failed: expected 512, got %s" | |
| % current_value) | |
| else: | |
| logging.debug("Could not verify vhost max_mem_regions setting") | |
| else: | |
| test.cancel("Failed to configure vhost at runtime: %s" % result.stderr_text) | |
| else: | |
| logging.debug("Non-SLES system detected, skipping vhost configuration") | |
| except Exception as e: | |
| test.cancel("Error setting up vhost max_mem_regions: %s" % str(e)) |
🧰 Tools
🪛 Ruff (0.15.15)
[error] 151-151: Function call with shell=True parameter identified, security issue
(S604)
[warning] 165-165: Do not catch blind exception: Exception
(BLE001)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@libvirt/tests/src/libvirt_mem.py` around lines 148 - 166, The verification
failure for vhost max_mem_regions configuration and the exception handler are
downgrading setup errors to warnings, allowing the test to continue in an
invalid state. When verification confirms the value is not set to "512" (around
line 155-156), raise an exception instead of just logging a warning. In the
exception handler (around line 165-166), re-raise the caught exception instead
of logging a warning and continuing, so that SLES-targeted setup failures
properly fail or cancel the test path rather than silently proceeding.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Uh oh!
There was an error while loading. Please reload this page.