Bug 736966 - can't delete first guest created after starting virt-manager
Summary: can't delete first guest created after starting virt-manager
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: 16
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Cole Robinson
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-09 08:02 UTC by Jens Petersen
Modified: 2012-02-07 14:20 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-02-07 14:20:56 UTC

Attachments (Terms of Use)

Description Jens Petersen 2011-09-09 08:02:22 UTC
Description of problem:
Somehow the first guest created after starting virt-manager
can't be deleted.  (It might be the first created guest after booting say
not 100% sure.)

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

How reproducible:

Steps to Reproduce:
1. boot, login and start virt-manager
2. install a new guest
3. shutdown guest
4. try to delete it
Actual results:
4. Delete is disabled in menu for new guest

Expected results:
to be able to delete new guest

Additional info:
Workaround is to restart virt-manager and the guest can be deleted.
Other existing guests can always be deleted without problem -
this only affect the first newly created guest.

Comment 1 Cole Robinson 2011-09-26 15:49:07 UTC
Hmm, can't seem to reproduce. Can you run virt-manager from the command line with the --debug flag and reproduce steps 1-4, and post the output here? Thanks

Comment 2 Jens Petersen 2011-10-12 09:58:45 UTC
It happened to me (again) on F16 when I ran v-m for the first time
after installing.  I admit it seems a little harder to reproduce
than I had at least thought.

So one may to reproduce is probably to add a step 0:

0. Install Fedora with @virtualization.

If that still doesn't help, I can try to pindown
the exact steps - it also happens to me sometimes on
an existing install, so I don't think it is only
right after system installation.

Comment 3 Jens Petersen 2011-11-28 00:33:21 UTC
I haven't seen this in quite a while now - so I am assuming it is fixed
in both current f15 and f16.

Let me reopen again if it should reoccur.

Comment 4 Massimiliano 2011-12-01 00:10:18 UTC
I found this issue in my F16:

# rpm -qa \*virt\*

I can't delete the guest (not running), while I'm able to start/stop it.
I suspect that restarting the libvirtd daemon could be the cause.
Fortunatly there is a workaround: disconnect and reconnect the virtmanager to the qemu hypervisor let me delete the guest vm.

It could be related to bug #518536.

Comment 5 Jens Petersen 2011-12-01 04:26:56 UTC
Ok I haven't seen this recently, but reopening back on previous comment.

I think we still need to work out how to reproduce this since
I have not found it easy to.

Comment 6 Jaromír Cápík 2011-12-22 11:13:55 UTC

The same happened to me with my second guest (I configured the type as QEMU instead of KVM in this case). I remember I started the guest and immediately stopped. And repeated few times (don't remember exactly). I also tried to create a new guest with the same name (just used capital letter in the name). Unfortunately I don't exactly remember the order of the mentioned steps.

Hard to guess if this information is helpful.


Comment 7 Jaromír Cápík 2011-12-22 11:18:25 UTC
Maybe one more note ... The guest was not running, but the "Pause" entry was active. The problem disappeared after virt-manager restart.

Comment 8 Cole Robinson 2012-02-06 20:17:12 UTC
Is everyone using kvm or xen? Can anyone reliably reproduce with the virt-manager package in updates-testing?

And where exactly is the 'delete' option disabled? In the right-click menu of the main manager window?

Comment 9 Jens Petersen 2012-02-07 08:31:37 UTC
(I am using kvm but haven't seen this issue in quite a while.)

> And where exactly is the 'delete' option disabled? In the right-click menu of
> the main manager window?

Yes, that is how I remember it.

Comment 10 Cole Robinson 2012-02-07 14:20:56 UTC
Okay, I'm going to close this WORKSFORME as I can't reproduce.

If anyone still hits it, please provide ~/.virt-manager/virt-manager.log from the failed run.

Note You need to log in before you can comment on or make changes to this bug.