Red Hat Bugzilla – Bug 243768
Error seen during modification of Xen Guest resources
Last modified: 2008-03-12 16:23:46 EDT
Description of problem: I had a Xen guest running with 1 CPU and 1 disk (file). I added another disk (file) from virt-manager and then deleted the disk. The disk reappeared on rebooting the guest. I also found that I could not increase the CPU count from virt-manager. So I used the following procedure to modify the resources virsh dumpxml [guest] > [xmlfile] Edited the XML and then load it back into XenD. I removed the second disk from the xml file and increased the CPU count to 2 and ran virsh define [xmlfile] This cleared out the disk but the CPU count showed max cpu allocation showed 32, instead of 2. The value corrected itself to 2 after rebooting the guest. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
The first part of your description is actually not a bug. At the moment, virt-manager and libvirt cannot persist changes to a running guest (so if you make a change to a running guest, that change will disappear unless you make it again on reboot). This is why your disk reappeared when you restarted the guest. You can't increase the CPU count beyond the defined maximum for the guest unless the guest is not running, so that part is also not a bug. Can you post the xml you used to redefine the guest here, and also let me know if the guest was running when you did virsh define [dumpxml]? I need to see if there was a maxcpus element in your XML... Thanks.
I ran "virsh define [xmlfile] " to redefine the guest. I am not sure if the guest was running at the time I ran the command. I am unable to find the original xml dump file, but I dumped another file today and it does not have the maxcpus element. I am also unable to get the details window to open for my guest. I apologize for the delay in responding as I was away from my office and did not have access to the test system.
change QA contact
Since this hasn't been reported by anyone else and this issue is 9 months old, and the reporter themselves couldn't reproduce, I'm closing this as NOTABUG.