virt-manager-0.7.0-5.fc11.x86_64 libvirt-0.6.2-11.fc11.x86_64 qemu-kvm-tools-0.10.4-5.fc11.x86_64.rpm I set up my vm (using v-m-m) and assigned it 384M to the vm. Later I go into v-m-m and change it to 512M memory. Everything works fine as long as the host OS is up. The next time the host os (not the guest os) reboots the guest is back to having the original 384M memory.
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.