Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Tue, 25 Aug 2015 08:35:49 +0000 (UTC)
From: "ASF subversion and git services (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.12827443.1430863046000.156543.1440491749841@Atlassian.JIRA>
In-Reply-To: <JIRA.12827443.1430863046000@Atlassian.JIRA>
References: <JIRA.12827443.1430863046000@Atlassian.JIRA>
 <JIRA.12827443.1430863046425@arcas>
Subject: [jira] [Commented] (CLOUDSTACK-8443) Support CentOS7 as KVM host
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CLOUDSTACK-8443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14710882#comment-14710882 ] 

ASF subversion and git services commented on CLOUDSTACK-8443:
-------------------------------------------------------------

Commit c0fde9a12bf32d0d4009792d05b1648f7c6ea419 in cloudstack's branch refs/heads/master from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c0fde9a ]

Merge pull request #731 from remibergsma/centos7-kvm

CLOUDSTACK-8443: Support CentOS 7 as KVM hypervisorThis adds support for CentOS 7 as a KVM hypervisor. As discussed in the Jira issue, the root cause of the issue was the `cloudstack-setup-agent` script that added this line to `/etc/libvirt/qemu.conf`:

`cgroup_controllers=["cpu"]`

On CentOS 6 this 'works', but since by default no cgroups are mounted, this setting is ignored by `libvirtd`. On CentOS 7 is does not work, because the `cpu` and `cpuacct` are 'co-mounted'. This simpy means you cannot use one without the order. The config line above instructs `libvirtd` to only use the `cpu` cgroup, which it can't.

There was code added to make sure the `cpu` cgroup was not co-mounted. It did this with a shell script, but after a reboot it was gone. It wasn't reliable and not even a solution at all. I went ahead and removed the code, because the co-mounted cgroups work fine. The real issue was the config line we put in `/etc/libvirt/qemu.conf` so much better to fix that instead.

The default for `libvirtd` is to use only cgroups that are mounted. When you remove the 'cgroup_controllers' line, 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, that's a nice way to control it.
This works just fine for both RHEL/CentOS 6 and RHEL/CentOS 7.

Along the debugging, I came across some small issues here and there which I also fixed in this PR.

If you test this, be sure to build RPMs from this branch and install those on the KVM hypervisor.

At Schuberg Philis we run KVM hypervisors on CentOS 7 for months with these fixes. Now I took the time to fix the issues in CloudStack, rather than work around them.

@bhaisaab @karuturi could you please review this? Thanks!

Please note:
The next step is to fix CLOUDSTACK-8625 (Systemd profile for KVM Agent) as currently a sysvinit script is still used. Although it works, we do not have any systemd benefits. As it is a separate issue, I'll try to address it in a separate PR.

* pr/731:
  CLOUDSTACK-8443: detect CentOS 7.x as RHEL 7 alike
  CLOUDSTACK-8443: mention the correct logfile
  CLOUDSTACK-8443: display the right hypervisor type
  CLOUDSTACK-8443: don't try to fix co-mounted cgroups

Signed-off-by: Remi Bergsma <github@remi.nl>


> 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.5.1, 4.6.0
>            Reporter: Rohit Yadav
>            Assignee: Remi Bergsma
>            Priority: Critical
>             Fix For: 4.6.0
>
>
> 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)