Bug 1214434 - Unable to start guest with emulator pinning
Summary: Unable to start guest with emulator pinning
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 21
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2015-04-22 17:28 UTC by Daniel Berrangé
Modified: 2015-06-05 23:02 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-06-05 23:02:22 UTC
Type: Bug

Attachments (Terms of Use)
Demo guest XML (2.45 KB, text/plain)
2015-04-22 17:28 UTC, Daniel Berrangé
no flags Details

Description Daniel Berrangé 2015-04-22 17:28:23 UTC
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):

How reproducible:

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:

Comment 1 Daniel Berrangé 2015-04-22 17:29:37 UTC
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@huawei.com>
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:
        <memory mode='strict' nodeset='0'/>
    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
    Signed-off-by: Wang Rui <moon.wangrui@huawei.com>
    (cherry picked from commit c6e90248676126c209b3b6017ad27cf6c6a0ab8f)

Comment 2 Daniel Berrangé 2015-04-22 17:56:08 UTC
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@huawei.com>
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
    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@huawei.com>
    (cherry picked from commit 411cea638f6ec8503b7142a31e58b1cd85dbeaba)

Comment 3 Fedora Update System 2015-04-28 16:54:58 UTC
libvirt- has been submitted as an update for Fedora 21.

Comment 4 Fedora Update System 2015-04-29 13:06:07 UTC
Package libvirt-
* 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-'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

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