Created attachment 1017542 [details] Demo guest XML Description of problem: Attempting to start an OpenStack guest fails with the following error message: # virsh start instance-00000009 error: Failed to start domain instance-00000009 error: Failed to create controller cpu for group: No such file or directory This guest is special in that it has hugepages, numa topology + pinning and emulator pinning present. Version-Release number of selected component (if applicable): 1.2.9.2 How reproducible: Always Steps to Reproduce: 1. Boot attached XML Actual results: error: Failed to create controller cpu for group: No such file or directory Expected results: Guest boots Additional info:
FYI is a regression on the v1.2.9-maint branch - reverting the following backported patch fixes the problem commit e22677268cb6149c48e602f19c24c2b3b4536232 Author: Wang Rui <moon.wangrui> Date: Mon Nov 10 21:53:19 2014 +0800 qemu: fix domain startup failing with 'strict' mode in numatune If the memory mode is specified as 'strict' and with one node, we get the following error when starting domain. error: Unable to write to '$cgroup_path/cpuset.mems': Device or resource busy XML is configured with numatune as follows: <numatune> <memory mode='strict' nodeset='0'/> </numatune> It's broken by Commit 411cea638f6ec8503b7142a31e58b1cd85dbeaba which moved qemuSetupCgroupForEmulator() before setting cpuset.mems in qemuSetupCgroupPostInit. Directory '$cgroup_path/emulator/' is created in qemuSetupCgroupForEmulator. But '$cgroup_path/emulator/cpuset.mems' it not set and has a default value (all nodes, such as 0-1). Then we setup '$cgroup_path/cpuset.mems' to the nodemask (in this case it's '0') in qemuSetupCgroupPostInit. It must fail. This patch makes '$cgroup_path/emulator/cpuset.mems' is set before '$cgroup_path/cpuset.mems'. The action is similar with that in qemuDomainSetNumaParamsLive. Signed-off-by: Wang Rui <moon.wangrui> (cherry picked from commit c6e90248676126c209b3b6017ad27cf6c6a0ab8f)
Discovered it was caused by the following patch that should also have been backported. I've pushed this to v1.2.9-maint upstream, so next Fedora update will pull it in commit 91ced385f2b87bbe9b4377858c324319104c72e9 Author: Zhou yimin <zhouyimin> Date: Thu Oct 16 22:18:48 2014 +0800 qemu: move setting emulatorpin ahead of monitor showing up If VM is configured with many devices(including passthrough devices) and large memory, libvirtd will take seconds(in the worst case) to wait for monitor. In this period the qemu process may run on any PCPU though I intend to pin emulator to the specified PCPU in xml configuration. Actually qemu process takes high cpu usage during vm startup. So this is not the strict CPU isolation in this case. Signed-off-by: Zhou yimin <zhouyimin> (cherry picked from commit 411cea638f6ec8503b7142a31e58b1cd85dbeaba)
libvirt-1.2.9.3-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/libvirt-1.2.9.3-1.fc21
Package libvirt-1.2.9.3-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libvirt-1.2.9.3-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-7150/libvirt-1.2.9.3-1.fc21 then log in and leave karma (feedback).