Please provide virt-manager --debug and /var/log/libvirt/qemu/$vmname.log output when reproducing this issue.

Created attachment 525071 [details]
debug info

Created attachment 525072 [details]
/var/log/libvirt/qemu/win7.log

Hmm, looks life virt-manager is doing everything fine. Can you provide virsh dumpxml $vmname just to confirm?

Reassigning to libvirt for further triage.

Created attachment 525246 [details]
win7.xml

this file is output by virsh dumpxml $guest_name when change current mem to 1024 and shutdown the vm. in xml the current mem actually change to 1024, but if i start the vm again, the current mem back to 2048 :
#virsh dumpxml win7
.....
<domain type='kvm' id='7'>
  <name>win7</name>
  <uuid>02058b1f-3564-8e99-cd26-916d0b8ec261</uuid>
  <memory>2097152</memory>
  <currentMemory>2097152</currentMemory>
.....
it's strange for force off the vm,the current mem change to 1024 automatic.
#virsh dumpxml win7
....
 <name>win7</name>
  <uuid>02058b1f-3564-8e99-cd26-916d0b8ec261</uuid>
  <memory>2097152</memory>
  <currentMemory>1048576</currentMemory>
....

I'm wondering if this is a limitation in the memory balloon response of the guest.  If the guest is offline, then the change only affects the xml configuration; but if the guest is online, then changing current memory requires cooperation from the guest, and if the virtio memballoon driver is not present in the guest, that might explain why the guest is not seeing the desired lower memory limits.  At any rate, I'll try and reproduce this locally, to see if this is just a case of inherent problems in balloon design or whether libvirt really is doing something wrong.

Does this occur with different version of the guest OS?
If no, could you check for installed drivers? As Eric mentioned in comment #7, it might depend on the guest OS to be able to coordinate the change through virtio memory balloon.

Thanks

I re-test this with pkg:
libvirt-0.9.10-21.el6.x86_64

I only use virsh command to do this:
step:
1: prepare winxp 32 bit guest os
2: start the guest (with maxmem 2048 ,current mem 2048)
  #virsh dominfo winxp_32
Id:             17
Name:           winxp_32
UUID:           4cf43017-495b-9f14-32bb-2b62bb593f35
OS Type:        hvm
State:          running
CPU(s):         1
CPU time:       27.4s
Max memory:     2097152 kB
Used memory:    2097152 kB
Persistent:     yes
Autostart:      disable
Managed save:   no
Security model: selinux
Security DOI:   0
Security label: system_u:system_r:svirt_t:s0:c149,c982 (permissive)

3: in console run command"
  #virsh setmem winxp_32 --size=1G --live --config
  #virsh dominfo winxp_32
Id:             17
Name:           winxp_32
UUID:           4cf43017-495b-9f14-32bb-2b62bb593f35
OS Type:        hvm
State:          running
CPU(s):         1
CPU time:       27.4s
Max memory:     2097152 kB
Used memory:    2097152 kB       ------->issue here,should become to 1G,this worked on rhel guest, windows(win7 winxp win2003) guest all not changed.
Persistent:     yes
Autostart:      disable
Managed save:   no
Security model: selinux
Security DOI:   0
Security label: system_u:system_r:svirt_t:s0:c149,c982 (permissive)

4: shutdown the guest 
 #virsh destroy winxp_32
 check dominfo
 #virsh dominfo winxp_32
Id:             -
Name:           winxp_32
UUID:           4cf43017-495b-9f14-32bb-2b62bb593f35
OS Type:        hvm
State:          shut off
CPU(s):         1
Max memory:     2097152 kB
Used memory:    1048576 kB    ----> change to 1G,because use --config
Persistent:     yes
Autostart:      disable
Managed save:   no
Security model: selinux
Security DOI:   0

5: start the guest again
 #virsh start winxp_32
 #virsh dominfo winxp_32
Id:             19
Name:           winxp_32
UUID:           4cf43017-495b-9f14-32bb-2b62bb593f35
OS Type:        hvm
State:          running
CPU(s):         1
CPU time:       0.7s
Max memory:     2097152 kB
Used memory:    2097152 kB     ----->issue here, current mem change back to 2G.
Persistent:     yes
Autostart:      disable
Managed save:   no
Security model: selinux
Security DOI:   0
Security label: system_u:system_r:svirt_t:s0:c107,c513 (permissive)

you said installed drivers? is virtio-win driver,i don't do it before when testing setmem, is it necessary?

I'd lie if I said I'm sure about how much the guest is involved in this, but from what I know, the driver should be installed (to be able to communicate with the host about how to change the memory). This is also how it works (IMHO) after starting the machine. It gets the maximum memory and current memory is shrunk using hte driver. Could you please try it with the driver installed and updated to latest version? Thanks.

re-test with install virtio-drivers:
virtio-win-prewhql-0.1-28

the issue occued same with this bug.

I change guest current memory with option --config & --live, and shut-off the guest,the current mem should changed in guest xml,and affect the next boot of a persistent guest,but now,the current mem not changed.

(In reply to comment #13)

What definitely is an issue, is the point 5 in comment #11 and if that one got away with the installation, then it *may* be OK because when you are trying to shrink the memory from 2G to 1G live, then it's not always definitive that it will be successful. The action may depend on how much memory there is _free_ in the guest (you cannot take 1G when it's not there).

From what I tried with different system, not supporting virtio, I got an error when trying to change the current memory. This is maybe what could be improved; in case the memory was not changed, show a message that it wasn't successful. But that's another story.

I'm reassigning this to Peter, because he will be more Windows oriented colleague, but I'll ask you to try 2 more things. When decreasing the memory, is it possible to decrease it live by only a few megabytes? And when started with half of the memory, are you able to increase it to maximum (also live)?

Thanks

(In reply to comment #14)
> (In reply to comment #13)
> 
> What definitely is an issue, is the point 5 in comment #11 and if that one
> got away with the installation, then it *may* be OK because when you are
> trying to shrink the memory from 2G to 1G live, then it's not always
> definitive that it will be successful. The action may depend on how much
> memory there is _free_ in the guest (you cannot take 1G when it's not there).
> 
> From what I tried with different system, not supporting virtio, I got an
> error when trying to change the current memory. This is maybe what could be
> improved; in case the memory was not changed, show a message that it wasn't
> successful. But that's another story.
> 
> I'm reassigning this to Peter, because he will be more Windows oriented
> colleague, but I'll ask you to try 2 more things. When decreasing the
> memory, is it possible to decrease it live by only a few megabytes? And when
> started with half of the memory, are you able to increase it to maximum
> (also live)?
> 
> Thanks

sorry for late response,
i have try this:
1: use command to decrease a few megabytes
# virsh setmem winxp --kilobytes 2000000 --live --config
# virsh dominfo winxp
Id:             8
Name:           winxp
UUID:           803784bf-ced3-37d4-8832-ac6f911611a7
OS Type:        hvm
State:          running
CPU(s):         1
CPU time:       25.2s
Max memory:     2097152 kB
Used memory:    2097152 kB
Persistent:     yes
Autostart:      disable
Managed save:   no
Security model: selinux
Security DOI:   0
Security label: system_u:system_r:svirt_t:s0:c222,c266 (enforcing)

restart the guest, mem also not changed.

2: i can't do this

i define a guest with xml
.......
 <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <vcpu placement='static'>1</vcpu>
.......
then start the guest
strangely currentMemory always change to 2G automatically, so i can't started with half of the memory. both on win7 and winxp with virtio drivers.

To remove memory from the guest system, you need to have the memory balloon driver installed and _loaded_. As this driver is loaded by the guest OS, you need to wait until its loaded. A typical run looks like this:

Windows 7 guest with 1G of RAM and virtio balloon driver installed:

virsh # dominfo win7
Id:             3
Name:           win7
UUID:           33b33155-0751-fee3-2f26-b325946340e8
OS Type:        hvm
State:          running
CPU(s):         2
CPU time:       84.6s
Max memory:     1048576 KiB
Used memory:    1048576 KiB
Persistent:     yes
Autostart:      disable
Managed save:   no

Remove some memory from the guest:

virsh # setmem win7 --size 800M --live --config

virsh # dominfo win7
Id:             3
Name:           win7
UUID:           33b33155-0751-fee3-2f26-b325946340e8
OS Type:        hvm
State:          running
CPU(s):         2
CPU time:       120.2s
Max memory:     1048576 KiB
Used memory:    819200 KiB
Persistent:     yes
Autostart:      disable
Managed save:   no

Memory is removed and returned to host.

Now shutdown the guest and start it again.

virsh # start win7
Domain win7 started

Right after the hypervisor starts the virtio balloon driver is not yet loaded so the guest has access to all of the memory:

virsh # dominfo win7
Id:             4
Name:           win7
UUID:           33b33155-0751-fee3-2f26-b325946340e8
OS Type:        hvm
State:          running
CPU(s):         2
CPU time:       1.6s
Max memory:     1048576 KiB
Used memory:    1048576 KiB
Persistent:     yes
Autostart:      disable
Managed save:   no

After some time the guest boots and loads the balloon driver that returns the memory to the guest:

virsh # dominfo win7
Id:             4
Name:           win7
UUID:           33b33155-0751-fee3-2f26-b325946340e8
OS Type:        hvm
State:          running
CPU(s):         2
CPU time:       21.3s
Max memory:     1048576 KiB
Used memory:    819200 KiB
Persistent:     yes
Autostart:      disable
Managed save:   no

I'm closing as NOTABUG as this this behavior is correct. Feel free to reopen if the memory is not returned after the guest boots, please reopen this bug.