[
https://issues.apache.org/jira/browse/CLOUDSTACK-8443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14705455#comment-14705455
]
Remi Bergsma commented on CLOUDSTACK-8443:
------------------------------------------
Did some more research on the subject:
The script serviceConfig.py has a separate section for RedHat alike systems.
There indeed the 'cgroups_controllers' option is set in /etc/libvirt/qemu.conf.
On CentOS 6 this works, because by default no cgroup is mounted and qemu then
just ignores the setting, as described here [1]. On CentOS 6 we set option
"cpu" but it is ignored because it is not mounted. In our documentation there
is no instruction to even mount it. It seems to me it is useless to set it like
this. It's been there since 2011, not sure why it was put there.
When you remove the line, as suggested above, then the default kicks in.
According to the qemu.conf file, the default is:
cgroup_controllers = ["cpu", "devices", "memory", "blkio", "cpuacct", "net_cls"]
Then again, if it's not mounted, it's not used.
So, why do we have an issue on CentOS 7? Well, because "cpu" is co-mounted with
"cpuacct". We specify "cpu" but that is impossible, since the mount has two.
Then qemu reports:
Controller 'cpuacct' is not wanted, but 'cpu' is co-mounted: Invalid argument
I think we should get rid of the setting, because then we'll rely on the
default. On CentOS 6 nothing is mounted, so it is ignored (like "cpu" is
ignored now). On CentOS 7, they are all mounted by systemd and thus can all be
used. That'd be the way to be backwards compatible and support CentOS 7 as well.
I'll work on this in the coming days and send a PR to fix it. We probably also
need to get rid of some of the code that checks the 'co-mount', as the co-mount
itself is not the issue. It's the setting we put there in the first place.
[1] https://libvirt.org/cgroups.html
> Support CentOS7 as KVM host
> ---------------------------
>
> Key: CLOUDSTACK-8443
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8443
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Affects Versions: 4.5.0, 4.6.0, 4.5.1
> Reporter: Rohit Yadav
> Assignee: Rohit Yadav
> Priority: Critical
>
> CentOS7 as KVM host fails with exception:
> 2015-05-05 21:39:45,395{GMT} WARN [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-5:) LibvirtException
> org.libvirt.LibvirtException: Controller 'cpuacct' is not wanted, but 'cpu'
> is co-mounted: Invalid argument
> at org.libvirt.ErrorHandler.processError(Unknown Source)
> at org.libvirt.Connect.processError(Unknown Source)
> at org.libvirt.Connect.processError(Unknown Source)
> at org.libvirt.Connect.domainCreateXML(Unknown Source)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1267)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3828)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1361)
> After umounting cpuacct (umount /sys/fs/cgroup/cpuacct), and restarting host,
> the exception seen is: (also seen after upgrading linux kernel to 4.0.1)
> 2015-05-05 21:40:15,875{GMT} WARN [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-5:) LibvirtException
> org.libvirt.LibvirtException: unsupported configuration: CPU tuning is not
> available on this host
> at org.libvirt.ErrorHandler.processError(Unknown Source)
> at org.libvirt.Connect.processError(Unknown Source)
> at org.libvirt.Connect.processError(Unknown Source)
> at org.libvirt.Connect.domainCreateXML(Unknown Source)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1267)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
