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 1344892 - memory section in domxml stay unchanged after memory hot-unplug
Summary: memory section in domxml stay unchanged after memory hot-unplug
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.3
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Peter Krempa
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-12 08:22 UTC by Ruifeng
Modified: 2016-11-03 18:46 UTC (History)
5 users (show)

Fixed In Version: libvirt-2.0.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-03 18:46:45 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2577 0 normal SHIPPED_LIVE Moderate: libvirt security, bug fix, and enhancement update 2016-11-03 12:07:06 UTC

Description Ruifeng 2016-06-12 08:22:42 UTC
Description of problem:
memory section in domxml stay unchanged after memory hot-unplug

Version-Release number of selected component (if applicable):
libvirt-1.3.5-1.el7.x86_64
qemu-kvm-rhev-2.6.0-5.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.
Start a domxml with memory configuration:
  <maxMemory slots="16" unit="KiB">2560000</maxMemory>
  <memory unit="KiB">1536000</memory>
  <currentMemory unit="KiB">1536000</currentMemory>
  <vcpu placement="static">4</vcpu>
  ...
  <cpu>
    <numa>
      <cell cpus="0-1" id="0" memory="512000" unit="KiB" />
      <cell cpus="2-3" id="1" memory="512000" unit="KiB" />
    </numa>
  ...
    <memory model="dimm">
      <target>
        <size unit="KiB">512000</size>
        <node>0</node>
      </target>
    </memory>


2. Hot-unplug with '--config' option:
# cat mem.xml
    <memory model='dimm'>
      <target>
        <size unit='KiB'>512000</size>
        <node>0</node>
      </target>
    </memory>

# virsh detach-device avocado-vt-vm1 mem.xml --config
Device detached successfully

3.
check the xml:
# virsh dumpxml avocado-vt-vm1 --inactive
...
  <maxMemory slots="16" unit="KiB">2560000</maxMemory>
  <memory unit="KiB">1536000</memory>    --> memory is not changed
  <currentMemory unit="KiB">1024000</currentMemory>
...



Actual results:
memory section in domxml stay unchanged after memory hot-unplug.

Expected results:
memory section should be changed.

infomation:

Comment 2 Peter Krempa 2016-06-17 08:42:02 UTC
Fixed upstream: 

commit a877a1635b8a2cb88170767ca3c28c0d755b21a8
Author: Peter Krempa <pkrempa>
Date:   Tue Jun 14 11:23:23 2016 +0200

    conf: Remove pre-calculation of initial memory size
    
    While we need to know the difference between the total memory stored in
    <memory> and the actual size not included in the possible memory modules
    we can't pre-calculate it reliably. This is due to the fact that
    libvirt's XML is copied via formatting and parsing the XML and the
    initial memory size can be reliably calculated only when certain
    conditions are met due to backwards compatibility.
    
    This patch removes the storage of 'initial_memory' and fixes the helpers
    to recalculate the initial memory size all the time from the total
    memory size. This conversion is possible when we also make sure that
    memory hotplug accounts properly for the update of the total memory size
    and thus the helpers for inserting and removing memory devices need to
    be tweaked too.
    
    This fixes a bug where a cold-plug and cold-remove of a memory device
    would increase the size reported in <memory> in the XML by the size of
    the memory device. This would happen as the persistent definition is
    copied before attaching the device and this would lead to the loss of
    data in 'initial_memory'.

Comment 4 Luyao Huang 2016-08-10 02:24:31 UTC
The problem described in the description have been fixed on libvirt-2.0.0-4.el7.x86_64:

1 prepare a running guest:
# virsh dumpxml r7
...
  <maxMemory slots='16' unit='KiB'>15243264</maxMemory>
  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
...
  <cpu>
    <numa>
      <cell id='0' cpus='0-3' memory='1048576' unit='KiB'/>
    </numa>
  </cpu>
...
    <memory model='dimm'>
      <target>
        <size unit='KiB'>1048576</size>
        <node>0</node>
      </target>
      <alias name='dimm0'/>
      <address type='dimm' slot='0' base='0x100000000'/>
    </memory>
...

2. cold-unplug memory device:

# virsh detach-device r7 memdevice1g.xml --config
Device detached successfully

# cat memdevice1g.xml 
    <memory model='dimm'>
      <target>
        <size unit='KiB'>1048576</size>
        <node>0</node>
      </target>
    </memory>

3. recheck guest inactive xml:

# virsh dumpxml r7 --inactive
...
  <maxMemory slots='16' unit='KiB'>15242882</maxMemory>
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
...
  <cpu>
    <numa>
      <cell id='0' cpus='0-3' memory='1048576' unit='KiB'/>
    </numa>
  </cpu>
...

4. test cold-plug for a running guest:

# virsh dumpxml r7
...
  <maxMemory slots='16' unit='KiB'>15243264</maxMemory>
  <memory unit='KiB'>3145728</memory>
  <currentMemory unit='KiB'>3145728</currentMemory>
  <vcpu placement='static' current='6'>10</vcpu>
...
  <cpu>
    <numa>
      <cell id='0' cpus='0-3' memory='1048576' unit='KiB'/>
    </numa>
  </cpu>
...
    <memory model='dimm'>
      <target>
        <size unit='KiB'>1048576</size>
        <node>0</node>
      </target>
      <alias name='dimm0'/>
      <address type='dimm' slot='0' base='0x100000000'/>
    </memory>
    <memory model='dimm'>
      <target>
        <size unit='KiB'>1048576</size>
        <node>0</node>
      </target>
      <alias name='dimm1'/>
      <address type='dimm' slot='1' base='0x140000000'/>
    </memory>
...

# virsh dumpxml r7 --inactive
...
  <maxMemory slots='16' unit='KiB'>15243264</maxMemory>
  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
  <vcpu placement='static' current='6'>10</vcpu>
...
  <cpu>
    <numa>
      <cell id='0' cpus='0-3' memory='1048576' unit='KiB'/>
    </numa>
  </cpu>
...
    <memory model='dimm'>
      <target>
        <size unit='KiB'>1048576</size>
        <node>0</node>
      </target>
    </memory>

# virsh attach-device r7 memdevice1g.xml --config
Device attached successfully

# virsh attach-device r7 memdevice1g.xml --config
Device attached successfully

# virsh dumpxml r7 --inactive
...
  <maxMemory slots='16' unit='KiB'>15243264</maxMemory>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
...
    <memory model='dimm'>
      <target>
        <size unit='KiB'>1048576</size>
        <node>0</node>
      </target>
    </memory>
    <memory model='dimm'>
      <target>
        <size unit='KiB'>1048576</size>
        <node>0</node>
      </target>
    </memory>
    <memory model='dimm'>
      <target>
        <size unit='KiB'>1048576</size>
        <node>0</node>
      </target>
    </memory>
...

Comment 5 Luyao Huang 2016-08-10 07:07:20 UTC
Hi Peter,

I found one problem during test the code introduce in patch:

if there is no numa in guest xml with memory device:

# virsh edit r7
...
  <memory unit='KiB'>1048576</memory>
...
    <memory model='dimm'>
      <target>
        <size unit='KiB'>1048576</size>
        <node>0</node>
      </target>
    </memory>
...

will get error:

error: XML error: Memory size must be specified via <memory> or in the <numa> configuration
Failed. Try again? [y,n,i,f,?]: 

This error looks not correct, since i specified memory in xml

Could you please help to check if this is a problem ?

Thanks,
Luyao

Comment 6 Peter Krempa 2016-08-16 14:19:23 UTC
Well, your configuration is wrong. You don't have any startup memory since the memory module size is identical to the size of memory. Unfortunately the error message is not entirely correct in this case but this is a very narrow corner case. If you think it should be fixed please file a new bug.

Comment 7 Luyao Huang 2016-08-17 01:15:16 UTC
(In reply to Peter Krempa from comment #6)
> Well, your configuration is wrong. You don't have any startup memory since
> the memory module size is identical to the size of memory. Unfortunately the
> error message is not entirely correct in this case but this is a very narrow
> corner case. If you think it should be fixed please file a new bug.

Thanks for your reply, i think no need to open a new bug for this corner issue.

And verify this bug with comment 4

Comment 10 errata-xmlrpc 2016-11-03 18:46:45 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2577.html


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