CA-311475: do not change a domain's memory allocation while it is being…#6890
Open
edwintorok wants to merge 1 commit intoxapi-project:masterfrom
Open
CA-311475: do not change a domain's memory allocation while it is being…#6890edwintorok wants to merge 1 commit intoxapi-project:masterfrom
edwintorok wants to merge 1 commit intoxapi-project:masterfrom
Conversation
Member
Author
|
Draft, tested this on the same machine again, and now it doesn't change the VM's maxmem while it is being built. |
edwintorok
force-pushed
the
private/edvint/squeeze-me-not
branch
from
35ddca5 to
c05f997
Compare
…ng built When a domain takes a long time to be built (e.g. >1TiB) then squeezed might run and attempt to change maxmem, causing the domain build to fail to complete. ``` 2026-02-04T13:59:12.915844+00:00 orca squeezed: [debug||9 ||squeeze_xen] Xenctrl.domain_setmaxmem domid=717 max=6370254848 (was=0) 2026-02-04T13:59:22.878301+00:00 orca squeezed: [debug||3 ||squeeze_xen] Xenctrl.domain_setmaxmem domid=717 max=2075287552 (was=6370254848) ``` Squeezed shouldn't change the maxmem setting on domains that have never been run (other than to initialize it if 0). In fact another module in Squeezed had code to detect whether a domain has ever been run, which has been replaced with checking whether it has an active balloon driver (if it hasn't reported a balloon driver it is still not very safe to change it too early). But that check missed one place that was still setting maxmem, ignoring the balloon driver's presence. Fix this (hopefully last!) place: if there is no balloon driver and we attempt to decrease maxmem then just log a message instead. Fixes: 9819bdb ("CA-32810: prevent the memory ballooning daemon capping a domain's memory usage before it has written feature-balloon.") Signed-off-by: Edwin Török <edwin.torok@citrix.com>
edwintorok
force-pushed
the
private/edvint/squeeze-me-not
branch
from
c05f997 to
0c3aaca
Compare
edwintorok
changed the title
edwintorok
changed the title
Member
Author
|
Actually the underlying bug here is a 64-bit -> 32-bit truncation bug in Xenctrl, but anyway we should still fix squeezed. |
Member
Author
|
This passed the DMC tests in the BST (there is one failed test in the BST related to a reverted blktap bug, unrelated to this change). |
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.
… built
When a domain takes a long time to be built (e.g. >1TiB) then squeezed might run and attempt to change maxmem, causing the domain build to fail to complete.
Squeezed shouldn't change the maxmem setting on domains that have never been run (other than to initialize it if 0). In fact another module in Squeezed had code to detect whether a domain has ever been run, which has been replaced with checking whether it has an active balloon driver (if it hasn't reported a balloon driver it is still not very safe to change it too early).
But that check missed one place that was still setting maxmem, ignoring the balloon driver's presence. Fix this (hopefully last!) place: if there is no balloon driver and we attempt to decrease maxmem then just log a message instead.
Fixes: 9819bdb ("CA-32810: prevent the memory ballooning daemon capping a domain's memory usage before it has written feature-balloon.")