Bug 714407

Summary: virt-manager fails to start a guest
Product: [Fedora] Fedora Reporter: Sam Varshavchik <mrsam>
Component: virt-managerAssignee: Cole Robinson <crobinso>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: berrange, crobinso, dowdle, hbrock, jforbes, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-01 14:29:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Sam Varshavchik 2011-06-19 02:54:55 UTC
Occasionally, after the host running for a while without any guest VMs running, an attempt to start a VM fails with the following error dialog:

Error starting domain: Unable to create cgroup for VWIN: No such file or directory

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 45, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/engine.py", line 959, in asyncfunc
  File "/usr/share/virt-manager/virtManager/domain.py", line 1128, in startup
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 330, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: Unable to create cgroup for VWIN: No such file or directory

Once this error occurs, every attempt to start the VM fails with this error. Rebooting the host clears it up, and the VM can be started without any issues after the reboot.

Comment 1 Scott Dowdle 2011-06-20 19:10:01 UTC
I get this error too... both trying to create a new VM or trying to start an existing one.

Comment 2 Scott Dowdle 2011-06-20 19:11:33 UTC
Restarting libvirtd seems to fix the issue.

Comment 3 Cole Robinson 2011-07-01 14:29:19 UTC

*** This bug has been marked as a duplicate of bug 678555 ***