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
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
(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.
(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