RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1024272 - Changing --hard-limit with memtune report invalid error when --swap-hard-limit is unlimited.
Summary: Changing --hard-limit with memtune report invalid error when --swap-hard-limi...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: 7.0
Assignee: Martin Kletzander
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-29 09:45 UTC by Hao Liu
Modified: 2014-06-18 00:58 UTC (History)
7 users (show)

Fixed In Version: libvirt-1.1.1-15.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 12:05:29 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Hao Liu 2013-10-29 09:45:24 UTC
Description of problem:
Changing --hard-limit with memtune report invalid error when --swap-hard-limit is unlimited.

Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux Server release 7.0 Beta
libvirt-1.1.1-10.el7.x86_64

How reproducible:
always

Command:
1. Prepare a running vm with unlimited memory.
# virsh start <vm-name>

2. Check memtune status.
# virsh memtune <vm-name> --live
hard_limit     : unlimited
soft_limit     : unlimited
swap_hard_limit: unlimited

3. Try to change --hard-limit with memtune.
# virsh memtune <vm-name> --hard-limit 100000000 --live

Result:
error: Unable to change memory parameters
error: invalid argument: memory hard_limit tunable value must be lower than swap_hard_limit

Expected result:
Change hard limit successfully.

Additional info:
This only happens for new started VM. 
After change limits manually to 'unlimited' with:

# virsh memtune <vm-name> --hard-limit -1 --swap-hard-limit -1 --live

, memtune works fine with step 3.

Comment 1 Hao Liu 2013-10-29 10:01:59 UTC
In the following part of qemuDomainSetMemoryParameters() in src/qemu/qemu_driver.c ,
when the VM is fresh started, vm->def->mem.swap_hard_limit is 0, then the
comparison is true.
when --swap-hard-limit is manually set to -1, then vm->def->mem.swap_hard_limit
is the maximum ulong, then this comparison is false.

    if (set_swap_hard_limit || set_hard_limit) {
        unsigned long long mem_limit = vm->def->mem.hard_limit;
        unsigned long long swap_limit = vm->def->mem.swap_hard_limit;

        if (set_swap_hard_limit)
            swap_limit = swap_hard_limit;

        if (set_hard_limit)
            mem_limit = hard_limit;

        if (virCompareLimitUlong(mem_limit, swap_limit) > 0) {
            virReportError(VIR_ERR_INVALID_ARG, "%s",
                           _("memory hard_limit tunable value must be lower "
                             "than swap_hard_limit"));
            goto cleanup;
        }
    }

So this might be caused by ambiguous representation of unlimited memory.

Comment 3 Jincheng Miao 2013-11-19 02:28:37 UTC
Need to adopt this patch from upstream:

commit 19e7c04dce34afeb9a762471e09777de7d219db8
Author: Bing Bu Cao <mars.ibm.com>
Date:   Fri Oct 11 14:50:33 2013 +0800

    util: fix two virCompareLimitUlong bugs
    
    The helper function virCompareLimitUlong compares limit values,
    where value of 0 is equal to unlimited. If the latter parameter is 0,
    it should return -1 instead of 1, hence the user can only set hard_limit whe
    swap_hard_limit currently is unlimited.
    
    Worse, all callers pass 2 64-bit values, but on 32-bit platforms,
    the second argument was silently truncated to 32 bits, which
    could lead to incorrect computations.

Comment 4 Martin Kletzander 2013-11-19 09:05:07 UTC
Thanks for the info, but unfortunately that's not enough since upstream is currently a bit broken as well.

Comment 5 Martin Kletzander 2013-12-10 08:02:57 UTC
Rest of the upstream code is waiting for review (don't mind the misleading subject):

https://www.redhat.com/archives/libvir-list/2013-December/msg00434.html
and
https://www.redhat.com/archives/libvir-list/2013-December/msg00501.html

Comment 8 Hao Liu 2013-12-16 05:21:37 UTC
This fix is VERIFIED.

Verification Steps:
Same as https://bugzilla.redhat.com/show_bug.cgi?id=1024272#c0
In step 3:
for libvirt-1.1.1-14.el7:
# virsh memtune <vm-name> --live --hard-limit 100000000
error: Unable to change memory parameters
error: invalid argument: memory hard_limit tunable value must be lower than swap_hard_limit

for libvirt-1.1.1-15.el7:
# virsh memtune <vm-name> --live --hard-limit 100000000

# virsh memtune <vm-name> --live 
hard_limit     : 100000000
soft_limit     : unlimited
swap_hard_limit: unlimited

So this bug is fixed and VERIFIED.

Comment 9 Ludek Smid 2014-06-13 12:05:29 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.


Note You need to log in before you can comment on or make changes to this bug.