RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

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.