Bug 1301899

Summary: virt-manager fails to rename VM with snapshots: 'cannot delete inactive domain with 1 snapshots'
Product: [Community] Virtualization Tools Reporter: Jiri Prajzner <jprajzne>
Component: virt-managerAssignee: Cole Robinson <crobinso>
Status: CLOSED DEFERRED QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: berrange, crobinso, gscrivan, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-06-15 17:43:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jiri Prajzner 2016-01-26 10:13:06 UTC
Description of problem:
virt-mgr cannot rename VM with existing snapshots

Version-Release number of selected component (if applicable):
1.3.2

How reproducible:
Always

Steps to Reproduce:
1. have a VM
2. create snapshot(s)
3. try to rename the VM

Actual results:
Error apply changes: Requested operation is not valid: cannot delete inactive domain with 1 snapshots

Error apply changes: Requested operation is not valid: cannot delete inactive domain with 1 snapshots

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/details.py", line 1833, in config_apply
    ret = self.config_overview_apply()
  File "/usr/share/virt-manager/virtManager/details.py", line 1925, in config_overview_apply
    self.vm.define_name(self.widget("overview-name").get_text())
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 130, in define_name
    self.conn.rename_object(self, origxml, newxml, oldconnkey)
  File "/usr/share/virt-manager/virtManager/connection.py", line 697, in rename_object
    obj.delete(force=False)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1423, in delete
    self._backend.undefine()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2690, in undefine
    if ret == -1: raise libvirtError ('virDomainUndefine() failed', dom=self)
libvirtError: Requested operation is not valid: cannot delete inactive domain with 1 snapshots

Expected results:
The VM is renamed.

Additional info:
related: https://bugzilla.redhat.com/show_bug.cgi?id=1264687

Comment 1 Cole Robinson 2019-06-15 17:43:28 UTC
Yes unfortunately this is expected. There's not really any way to move snapshots to belong to a newly named VM. It's probably fixable but TBH I don't think it will ever actually be fixed, internal snapshots which is what virt-manager uses are not receiving much new development effort in libvirt or qemu these days. So I'm closing this

Comment 2 Jiri Prajzner 2019-06-17 11:33:12 UTC
(In reply to Cole Robinson from comment #1)
> Yes unfortunately this is expected. There's not really any way to move
> snapshots to belong to a newly named VM. It's probably fixable but TBH I
> don't think it will ever actually be fixed, internal snapshots which is what
> virt-manager uses are not receiving much new development effort in libvirt
> or qemu these days. So I'm closing this

it's not newly named vm, it's renamed one. i think it's quite serious flaw if i cannot do a simple rename operation and keep the snapshots. there should be some internal id that ties the vm and the snapshots together. it should not be tied by a vm/snapshot name.

Comment 3 Cole Robinson 2019-06-17 13:56:49 UTC
(In reply to Jiri Prajzner from comment #2)
> (In reply to Cole Robinson from comment #1)
> > Yes unfortunately this is expected. There's not really any way to move
> > snapshots to belong to a newly named VM. It's probably fixable but TBH I
> > don't think it will ever actually be fixed, internal snapshots which is what
> > virt-manager uses are not receiving much new development effort in libvirt
> > or qemu these days. So I'm closing this
> 
> it's not newly named vm, it's renamed one. i think it's quite serious flaw
> if i cannot do a simple rename operation and keep the snapshots. there
> should be some internal id that ties the vm and the snapshots together. it
> should not be tied by a vm/snapshot name.

Unfortunately in the libvirt sense a rename is not necssarily a simple operation. managedsave and snapshots track a copy of the VM config inside their data, which includes the old name, so that data would need to be edited. It's possible to implement, or to rearchitect things to behave differently, but I don't realistically expect it to happen. Hence closing this