Bug 2104852
| Summary: | [memtune] qemu process limit is not updated after updating vm memory hard_limit at run-time | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Fangge Jin <fjin> |
| Component: | libvirt | Assignee: | Virtualization Maintenance <virt-maint> |
| libvirt sub component: | General | QA Contact: | liang cong <lcong> |
| Status: | CLOSED MIGRATED | Docs Contact: | |
| Severity: | low | ||
| Priority: | low | CC: | lcheng, lcong, lmen, virt-maint, xuzhang, yisun |
| Version: | 9.1 | Keywords: | MigratedToJIRA, Triaged |
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-07-07 20:31:37 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Note that the 'max locked-in memory' size obtained by prlimit is not exactly the memory hard limit. The value obtained by prlimit is the maximum memory the process can decide to lock into memory, while the hard limit is the amount of memory the guest can use. Said that, we actually allow the guest to lock memory up to the 'hard_limit' if it is provided and the 'prlimit' system function seems to allow changing it for an existing process so we can actually consider changing it if the memory hard limit is being modified. (In reply to Peter Krempa from comment #1) > Note that the 'max locked-in memory' size obtained by prlimit is not exactly > the memory hard limit. The value obtained by prlimit is the maximum memory > the process can decide to lock into memory, while the hard limit is the > amount of memory the guest can use. > > Said that, we actually allow the guest to lock memory up to the 'hard_limit' > if it is provided and the 'prlimit' system function seems to allow changing > it for an existing process so we can actually consider changing it if the > memory hard limit is being modified. Thanks for you explanation, I understand the difference of "max locked-in memory" and "max used host memory" now. Now I think we should not change the value of "max locked-in memory" unless it is needed(e.g. when do zerocopy/rdma migration) |
Description of problem: Start vm, update vm memory hard_limit by "virsh memtune <domain> --hard-limit <n>" at run-time. Then check qemu process limit by "prlimit", the hard limit is not updated accordingly. If I set hard_limit in vm xml when vm is shutoff, then start vm. The hard limit printed by prlimit will be same as the hard_limit setting in vm xml. I'm not sure which one is expected, but the above two behaviors are not consistent. Version-Release number of selected component: libvirt-8.5.0-1.el9.x86_64 qemu-kvm-7.0.0-8.el9.x86_64 How reproducible: 100% Steps to Reproduce: 1. Start a vm 2. Check qemu process memory hard limit, it seems the default value is 64M if no hard_limit is set in vm xml: # prlimit -p `pidof qemu-kvm` -l RESOURCE DESCRIPTION SOFT HARD UNITS MEMLOCK max locked-in-memory address space 67108864 67108864 bytes 3. Update vm memory hard_limit: # virsh memtune uefi --hard-limit 262144 # virsh memtune uefi hard_limit : 262144 soft_limit : unlimited swap_hard_limit: unlimited # virsh dumpxml uefi |grep limit <hard_limit unit='KiB'>262144</hard_limit> 4. Check qemu process memory hard limit: # prlimit -p `pidof qemu-kvm` -l RESOURCE DESCRIPTION SOFT HARD UNITS MEMLOCK max locked-in-memory address space 67108864 67108864 bytes Actual results: As above