This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 503784 - memory/vcpus changes in virt-manager do not persist across libvirtd restart
memory/vcpus changes in virt-manager do not persist across libvirtd restart
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
11
All Linux
high Severity medium
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F11VirtTarget
  Show dependency treegraph
 
Reported: 2009-06-02 13:40 EDT by Eric Paris
Modified: 2009-10-07 08:26 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-07 08:26:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Eric Paris 2009-06-02 13:40:45 EDT
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.
Comment 1 Mark McLoughlin 2009-06-05 06:18:17 EDT
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>
Comment 2 Mark McLoughlin 2009-06-05 06:20:43 EDT
danpb says "the only officially defined way to make persistent config changes is to use virDomainDefineXML"
Comment 3 Erik Jacobson 2009-06-08 16:07:36 EDT
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.
Comment 4 Mark McLoughlin 2009-06-09 03:26:19 EDT
Good call Erik - yes, virDomainSetVcpus() doesn't make persistent changes either
Comment 5 Cole Robinson 2009-06-16 18:17:13 EDT
(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 :)
Comment 6 Chris Lalancette 2009-06-17 04:20:34 EDT
(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
Comment 7 Cole Robinson 2009-07-14 22:09:42 EDT
We know alter the persistent config for any memory and vcpu changes in virt-manager, so this is fixed. Moving to POST.
Comment 8 Mark McLoughlin 2009-08-07 09:42:15 EDT
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
Comment 9 Fedora Update System 2009-09-18 11:45:22 EDT
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
Comment 10 Fedora Update System 2009-09-24 01:18:06 EDT
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
Comment 11 Cole Robinson 2009-10-07 08:26:36 EDT
This should be fixed by virt-manager-0.7.0-7.fc11 now in stable. Closing.

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