Bug 503784

virt-manager uses virDomainSetMemory - confirmed this behaviour with virsh:

$> virsh dumpxml rawhide | grep -i memory
  <memory>802816</memory>
  <currentMemory>802816</currentMemory>
$> virsh setmaxmem rawhide 1048576
$> virsh setmem rawhide 1048576
$> virsh dumpxml rawhide | grep -i memory
  <memory>1048576</memory>
  <currentMemory>1048576</currentMemory>
$> service libvirtd restart
Stopping libvirtd daemon:                                  [  OK  ]
Starting libvirtd daemon:                                  [  OK  ]
$> virsh dumpxml rawhide | grep -i memory
  <memory>802816</memory>
  <currentMemory>802816</currentMemory>

danpb says "the only officially defined way to make persistent config changes is to use virDomainDefineXML"

I seem to be suffering from a similar issue with the cpu count.

# rpm -q libvirt virt-manager
libvirt-0.6.2-11.fc11.x86_64
virt-manager-0.7.0-5.fc11.x86_64

It seems the core issue is likely similar so I won't bother with a new bug
unless you want me to file one.

Like memory, I was able to adjust the XML file and restart libvirtd for the
change to take effect.

Like the memory issue, if you change the cpu count, it disappears after
libvirtd is restarted otherwise.

Good call Erik - yes, virDomainSetVcpus() doesn't make persistent changes either

(In reply to comment #2)
> danpb says "the only officially defined way to make persistent config changes
> is to use virDomainDefineXML"  

I agree with the above, but unfortunately it means the libvirt qemu driver is buggy in this respect. SetMem and SetMaxMem should not be able to be run on inactive VMs, similar to AttachDevice: only altering the VM config for the life of libvirtd is horribly confusing.

What does xen do in this case? I think I recall 'xm setmem' making persistent changes, but then again I never noticed _this_ bug so clearly I'm not too observant :)

(In reply to comment #5)
> (In reply to comment #2)
> > danpb says "the only officially defined way to make persistent config changes
> > is to use virDomainDefineXML"  
> 
> I agree with the above, but unfortunately it means the libvirt qemu driver is
> buggy in this respect. SetMem and SetMaxMem should not be able to be run on
> inactive VMs, similar to AttachDevice: only altering the VM config for the life
> of libvirtd is horribly confusing.
> 
> What does xen do in this case? I think I recall 'xm setmem' making persistent
> changes, but then again I never noticed _this_ bug so clearly I'm not too
> observant :)  

No, the xm mem-set command (at least in RHEL-5 era Xen) is not persistent either.  That is, if you want a *persistent* change to the amount of memory you give to your Xen guest, you have to edit the /etc/xen configuration file, shutdown the guest, and start it again.

Chris Lalancette

We know alter the persistent config for any memory and vcpu changes in virt-manager, so this is fixed. Moving to POST.

Fairly annoying bug, so perhaps worth backporting to F-11:

  http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/f20131ec952b

Fixed for F-12 by virt-manager-0.8.0-1.fc12

virt-manager-0.7.0-6.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/virt-manager-0.7.0-6.fc11?_csrf_token=8d215225cd9b1943cd947603a037c8db9ad28548

virt-manager-0.7.0-6.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update virt-manager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9871

This should be fixed by virt-manager-0.7.0-7.fc11 now in stable. Closing.