On 03/07/2016 09:20 AM, Kothapally Madhu Pavan wrote: Can you show the error in the system log that you get when/if this fails? Using EACCES implies to a permission error. The check in virCgroupDenyDevicePath is: if (stat(path, &sb) < 0) { if (errno == EACCES && ignoreEacces) return 1; virReportSystemError(errno, _("Path '%s' is not accessible"), path); return -1; } If the path doesn't exist, then it should be a different error message (ENOENT perhaps). My other question would be, if you follow the attachment path, you'll see that if qemuHostdevPreparePCIDevices is successfully called, then qemuSetupHostdevCgroup is called after (and virCgroupAllowDevicePath is called). So, shouldn't the corollary be qemuTeardownHostdevCgroup followed by device reattachment. IOW: e.g, move the qemuTeardownHostdevCgroup in qemuDomainRemoveHostDevice to before the switch to qemuDomainRemove*HostDevice? I'd even think the StoreHostdevLabel call could move. None of the calls would head into an error path... I've posted a couple of patches which do this, see: http://www.redhat.com/archives/libvir-list/2016-March/msg01270.html John