Bug 714407
| Summary: | virt-manager fails to start a guest | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Sam Varshavchik <mrsam> |
| Component: | virt-manager | Assignee: | Cole Robinson <crobinso> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | berrange, crobinso, dowdle, hbrock, jforbes, virt-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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: | --- | Target Upstream Version: | |
| Embargoed: | |||
I get this error too... both trying to create a new VM or trying to start an existing one. Restarting libvirtd seems to fix the issue. *** This bug has been marked as a duplicate of bug 678555 *** |
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 vm.startup() File "/usr/share/virt-manager/virtManager/domain.py", line 1128, in startup self._backend.create() 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.