Hide Forgot
Description of problem: vm names might be recycled, unlike the UUIDs, and in some cases, an existing .save file for $VMNAME would not belong to a new VM with the same name, causing the new VM not to be able to start Version-Release number of selected component (if applicable): libvirt-0.8.7-18.el6.x86_64 How reproducible: always Steps to Reproduce: 1.create a VM 2.start it up and then in virt-manager go to virtual machine>shut down>save 3.when the VM goes down, delete it 4.create a new VM with the same name 5. try to run the VM Actual results: VM fails to run because the save file belongs to another VMs UUID Expected results: .save should be deleted when the related VM is deleted (I'll open another BZ for this) if the filename for the .save file was $VMUUID.save then it would not be picked up for the new VM, and would not cause a new clean VM to fail to start up Additional info:
BZ#719284 opened for the .save file not being deleted
I close the bug as WONTFIX for above reason.
What Osier is saying is that the right way to fix this is to fix the other BZ you filed so that the vmsave file is properly deleted when the VM is undefined. If the vmsave files are properly removed, then we will never get into this state. Since the vmsave files are more user friendly when named by the VM name, we should go that route.