from:"Sven Vogel \(JIRA\)"

[jira] [Updated] (CLOUDSTACK-10127) 4.9 / 4.10 KVM + openvswitch + vpc + static nat / secondary ip on eth2?

2017-11-01 Thread Sven Vogel (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sven Vogel updated CLOUDSTACK-10127:

Description: 
We have the following Problem. 

  1. KVM
   2. Bridges
   bond with two interfaces and trunk (0,129,180,100-1500) to cloudbr0
   Cloudbr0 (0 - guest network)
   Fakebridge pub129 (public network)
   Fakebridge sto180 (secondary storage network)
   Fakebridge  mgmt0 (management)

   If I have a vpc all things work until I add a secondary ip and add a static 
nat.

   The following will happen, first address will be on the the correct 
interface 146.0.122.134/26 but static nat will be on the false network.
Its on the eth2…

{{   root@r-29-VM:~# ip a
   1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
   2: eth0:  mtu 1500 qdisc pfifo_fast state 
UP qlen 1000
   link/ether 0e:00:a9:fe:03:81 brd ff:ff:ff:ff:ff:ff
   inet 169.254.3.129/16 brd 169.254.255.255 scope global eth0
   3: eth1:  mtu 1500 qdisc pfifo_fast state 
UP qlen 1000
   link/ether 1e:00:2c:00:00:68 brd ff:ff:ff:ff:ff:ff
   inet 146.0.122.134/26 brd 146.0.122.191 scope global eth1
   4: eth2:  mtu 1500 qdisc pfifo_fast state 
UP qlen 1000
   link/ether 02:00:57:07:00:0c brd ff:ff:ff:ff:ff:ff
   inet 192.168.1.254/24 brd 192.168.1.255 scope global eth2
   inet 146.0.122.135/26 brd 146.0.122.191 scope global eth2}}

Normally I think the secondary ip should be on signed to eth1 not eth2!
It sets my ip on the guest network vlan range on my cloudbr0 but it should be 
pub129. vnet6 has 1353 guest tag and not the public tag.

[root@kvm01 ~]# ovs-vsctl list-br
cloud0
cloudbr0
mgmt0
pub129
sto180

[root@kvm01 ~]# virsh domiflist r-29-VM
Interface  Type   Source Model   MAC
---
vnet4  bridge cloud0 virtio  0e:00:a9:fe:03:81
vnet5  bridge pub129 virtio  1e:00:2c:00:00:68
vnet6  bridge cloudbr0   virtio  02:00:57:07:00:0c

   Bridge "cloud0"
   Port "vnet4"
   Interface "vnet4"

   Port "vnet5"
   tag: 129
   Interface "vnet5"
   Port "vnet6"
   tag: 1353
   Interface "vnet6"

root@r-29-VM:~# cat /etc/cloudstack/ips.json {
  "eth0": [
{
  "add": true,
  "broadcast": "169.254.255.255",
  "cidr": "169.254.3.129/16",
  "device": "eth0",
  "gateway": "None",
  "netmask": "255.255.0.0",
  "network": "169.254.0.0/16",
  "nic_dev_id": "0",
  "nw_type": "control",
  "one_to_one_nat": false,
  "public_ip": "169.254.3.129",
  "size": "16",
  "source_nat": false
}
  ],
  "eth1": [
{
  "add": true,
  "broadcast": "146.0.122.191",
  "cidr": "146.0.122.134/26",
  "device": "eth1",
  "first_i_p": true,
  "gateway": "146.0.122.130",
  "netmask": "255.255.255.192",
  "network": "146.0.122.128/26",
  "new_nic": false,
  "nic_dev_id": 1,
  "nw_type": "public",
  "one_to_one_nat": false,
  "public_ip": "146.0.122.134",
  "size": "26",
  "source_nat": true,
  "vif_mac_address": "1e:00:2c:00:00:68"
}
  ],
  "eth2": [
{
  "add": true,
  "broadcast": "146.0.122.191",
  "cidr": "146.0.122.135/26",
  "device": "eth2",
  "first_i_p": true,
  "gateway": "146.0.122.130",
  "netmask": "255.255.255.192",
  "network": "146.0.122.128/26",
  "new_nic": false,
  "nic_dev_id": 2,
  "nw_type": "public",
  "one_to_one_nat": true,
  "public_ip": "146.0.122.135",
  "size": "26",
  "source_nat": true,
  "vif_mac_address": "1e:00:2c:00:00:68"
},
{
  "add": false,
  "broadcast": "146.0.122.191",
  "cidr": "146.0.122.136/26",
  "device": "eth2",
  "first_i_p": true,
  "gateway": "146.0.122.130",
  "netmask": "255.255.255.192",
  "network": "146.0.122.128/26",
  "new_nic": false,
  "nic_dev_id": 2,
  "nw_type": "public",
  "one_to_one_nat": true,
  "public_ip": "146.0.122.136",
  "size": "26",
  "source_nat": true,
  "vif_mac_address": "1e:00:2c:00:00:68"
},
{
  "add": true,
  "broadcast": "192.168.1.255",
  "cidr": "192.168.1.254/24",
  "device": "eth2",
  "gateway": "192.168.1.254",
  "netmask": "255.255.255.0",
  "network": "192.168.1.0/24",
  "nic_dev_id": "2",
  "nw_type": "guest",
  "one_to_one_nat": false,
  "public_ip": "192.168.1.254",
  "size": "24",
  "source_nat": false
}
  ],
  "id": "ips"
}

Frank Maximus from Nuage analysed the problem.
{quote}
That seems to be a bug in the lookup of the device number, in case of 
openvswitch.
The

[jira] [Updated] (CLOUDSTACK-10127) 4.9 / 4.10 KVM + openvswitch + vpc + static nat / secondary ip on eth2?

2017-11-01 Thread Sven Vogel (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sven Vogel updated CLOUDSTACK-10127:

Environment: CentOS 7.4.1708 + KVM + OpenvSwitch 2.3-2.8  (was: CentOS 
7.4.1708 + OpenvSwitch 2.3-2.8)

>  4.9 / 4.10 KVM + openvswitch + vpc + static nat / secondary ip on eth2?
> 
>
> Key: CLOUDSTACK-10127
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10127
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VPC
>Affects Versions: 4.7.0, 4.8.0, 4.9.0, 4.10.0.0
> Environment: CentOS 7.4.1708 + KVM + OpenvSwitch 2.3-2.8
>Reporter: Sven Vogel
>Priority: Critical
>
> We have the following Problem. 
>   1. KVM
>2. Bridges
>bond with two interfaces and trunk (0,129,180,100-1500) to cloudbr0
>Cloudbr0 (0 - guest network)
>Fakebridge pub129 (public network)
>Fakebridge sto180 (secondary storage network)
>Fakebridge  mgmt0 (management)
>If I have a vpc all things work until I add a secondary ip and add a 
> static nat.
>The following will happen, first address will be on the the correct 
> interface 146.0.122.134/26 but static nat will be on the false network.
> Its on the eth2…
>root@r-29-VM:~# ip a
>1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
>link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>inet 127.0.0.1/8 scope host lo
>2: eth0:  mtu 1500 qdisc pfifo_fast state 
> UP qlen 1000
>link/ether 0e:00:a9:fe:03:81 brd ff:ff:ff:ff:ff:ff
>inet 169.254.3.129/16 brd 169.254.255.255 scope global eth0
>3: eth1:  mtu 1500 qdisc pfifo_fast state 
> UP qlen 1000
>link/ether 1e:00:2c:00:00:68 brd ff:ff:ff:ff:ff:ff
>inet 146.0.122.134/26 brd 146.0.122.191 scope global eth1
>4: eth2:  mtu 1500 qdisc pfifo_fast state 
> UP qlen 1000
>link/ether 02:00:57:07:00:0c brd ff:ff:ff:ff:ff:ff
>inet 192.168.1.254/24 brd 192.168.1.255 scope global eth2
>inet 146.0.122.135/26 brd 146.0.122.191 scope global eth2
> Normally I think the secondary ip should be on signed to eth1 not eth2!
> It sets my ip on the guest network vlan range on my cloudbr0 but it should be 
> pub129. vnet6 has 1353 guest tag and not the public tag.
> [root@kvm01 ~]# ovs-vsctl list-br
> cloud0
> cloudbr0
> mgmt0
> pub129
> sto180
> [root@kvm01 ~]# virsh domiflist r-29-VM
> Interface  Type   Source Model   MAC
> ---
> vnet4  bridge cloud0 virtio  0e:00:a9:fe:03:81
> vnet5  bridge pub129 virtio  1e:00:2c:00:00:68
> vnet6  bridge cloudbr0   virtio  02:00:57:07:00:0c
>Bridge "cloud0"
>Port "vnet4"
>Interface "vnet4"
>Port "vnet5"
>tag: 129
>Interface "vnet5"
>Port "vnet6"
>tag: 1353
>Interface "vnet6"
> root@r-29-VM:~# cat /etc/cloudstack/ips.json {
>   "eth0": [
> {
>   "add": true,
>   "broadcast": "169.254.255.255",
>   "cidr": "169.254.3.129/16",
>   "device": "eth0",
>   "gateway": "None",
>   "netmask": "255.255.0.0",
>   "network": "169.254.0.0/16",
>   "nic_dev_id": "0",
>   "nw_type": "control",
>   "one_to_one_nat": false,
>   "public_ip": "169.254.3.129",
>   "size": "16",
>   "source_nat": false
> }
>   ],
>   "eth1": [
> {
>   "add": true,
>   "broadcast": "146.0.122.191",
>   "cidr": "146.0.122.134/26",
>   "device": "eth1",
>   "first_i_p": true,
>   "gateway": "146.0.122.130",
>   "netmask": "255.255.255.192",
>   "network": "146.0.122.128/26",
>   "new_nic": false,
>   "nic_dev_id": 1,
>   "nw_type": "public",
>   "one_to_one_nat": false,
>   "public_ip": "146.0.122.134",
>   "size": "26",
>   "source_nat": true,
>   "vif_mac_address": "1e:00:2c:00:00:68"
> }
>   ],
>   "eth2": [
> {
>   "add": true,
>   "broadcast": "146.0.122.191",
>   "cidr": "146.0.122.135/26",
>   "device": "eth2",
>   "first_i_p": true,
>   "gateway": "146.0.122.130",
>   "netmask": "255.255.255.192",
>   "network": "146.0.122.128/26",
>   "new_nic": false,
>   "nic_dev_id": 2,
>   "nw_type": "public",
>   "one_to_one_nat": true,
>   "public_ip": "146.0.122.135",
>   "size": "26",
>   "source_nat": true,
>   "vif_mac_address": "1e:00:2c:00:00:68"
> },
> {
>   "add": false,
>   "broadcast": "146.0.122.191",
>   "cidr": "146.0.122.136/26",
>   "device":

[jira] [Created] (CLOUDSTACK-10127) 4.9 / 4.10 KVM + openvswitch + vpc + static nat / secondary ip on eth2?

2017-11-01 Thread Sven Vogel (JIRA)

Sven Vogel created CLOUDSTACK-10127:
---

 Summary:  4.9 / 4.10 KVM + openvswitch + vpc + static nat / 
secondary ip on eth2?
 Key: CLOUDSTACK-10127
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10127
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: VPC
Affects Versions: 4.10.0.0, 4.9.0, 4.8.0, 4.7.0
 Environment: CentOS 7.4.1708 + OpenvSwitch 2.3-2.8
Reporter: Sven Vogel
Priority: Critical


We have the following Problem. 

  1. KVM
   2. Bridges
   bond with two interfaces and trunk (0,129,180,100-1500) to cloudbr0
   Cloudbr0 (0 - guest network)
   Fakebridge pub129 (public network)
   Fakebridge sto180 (secondary storage network)
   Fakebridge  mgmt0 (management)

   If I have a vpc all things work until I add a secondary ip and add a static 
nat.

   The following will happen, first address will be on the the correct 
interface 146.0.122.134/26 but static nat will be on the false network.
Its on the eth2…

   root@r-29-VM:~# ip a
   1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
   2: eth0:  mtu 1500 qdisc pfifo_fast state 
UP qlen 1000
   link/ether 0e:00:a9:fe:03:81 brd ff:ff:ff:ff:ff:ff
   inet 169.254.3.129/16 brd 169.254.255.255 scope global eth0
   3: eth1:  mtu 1500 qdisc pfifo_fast state 
UP qlen 1000
   link/ether 1e:00:2c:00:00:68 brd ff:ff:ff:ff:ff:ff
   inet 146.0.122.134/26 brd 146.0.122.191 scope global eth1
   4: eth2:  mtu 1500 qdisc pfifo_fast state 
UP qlen 1000
   link/ether 02:00:57:07:00:0c brd ff:ff:ff:ff:ff:ff
   inet 192.168.1.254/24 brd 192.168.1.255 scope global eth2
   inet 146.0.122.135/26 brd 146.0.122.191 scope global eth2

Normally I think the secondary ip should be on signed to eth1 not eth2!
It sets my ip on the guest network vlan range on my cloudbr0 but it should be 
pub129. vnet6 has 1353 guest tag and not the public tag.

[root@kvm01 ~]# ovs-vsctl list-br
cloud0
cloudbr0
mgmt0
pub129
sto180

[root@kvm01 ~]# virsh domiflist r-29-VM
Interface  Type   Source Model   MAC
---
vnet4  bridge cloud0 virtio  0e:00:a9:fe:03:81
vnet5  bridge pub129 virtio  1e:00:2c:00:00:68
vnet6  bridge cloudbr0   virtio  02:00:57:07:00:0c

   Bridge "cloud0"
   Port "vnet4"
   Interface "vnet4"

   Port "vnet5"
   tag: 129
   Interface "vnet5"
   Port "vnet6"
   tag: 1353
   Interface "vnet6"

root@r-29-VM:~# cat /etc/cloudstack/ips.json {
  "eth0": [
{
  "add": true,
  "broadcast": "169.254.255.255",
  "cidr": "169.254.3.129/16",
  "device": "eth0",
  "gateway": "None",
  "netmask": "255.255.0.0",
  "network": "169.254.0.0/16",
  "nic_dev_id": "0",
  "nw_type": "control",
  "one_to_one_nat": false,
  "public_ip": "169.254.3.129",
  "size": "16",
  "source_nat": false
}
  ],
  "eth1": [
{
  "add": true,
  "broadcast": "146.0.122.191",
  "cidr": "146.0.122.134/26",
  "device": "eth1",
  "first_i_p": true,
  "gateway": "146.0.122.130",
  "netmask": "255.255.255.192",
  "network": "146.0.122.128/26",
  "new_nic": false,
  "nic_dev_id": 1,
  "nw_type": "public",
  "one_to_one_nat": false,
  "public_ip": "146.0.122.134",
  "size": "26",
  "source_nat": true,
  "vif_mac_address": "1e:00:2c:00:00:68"
}
  ],
  "eth2": [
{
  "add": true,
  "broadcast": "146.0.122.191",
  "cidr": "146.0.122.135/26",
  "device": "eth2",
  "first_i_p": true,
  "gateway": "146.0.122.130",
  "netmask": "255.255.255.192",
  "network": "146.0.122.128/26",
  "new_nic": false,
  "nic_dev_id": 2,
  "nw_type": "public",
  "one_to_one_nat": true,
  "public_ip": "146.0.122.135",
  "size": "26",
  "source_nat": true,
  "vif_mac_address": "1e:00:2c:00:00:68"
},
{
  "add": false,
  "broadcast": "146.0.122.191",
  "cidr": "146.0.122.136/26",
  "device": "eth2",
  "first_i_p": true,
  "gateway": "146.0.122.130",
  "netmask": "255.255.255.192",
  "network": "146.0.122.128/26",
  "new_nic": false,
  "nic_dev_id": 2,
  "nw_type": "public",
  "one_to_one_nat": true,
  "public_ip": "146.0.122.136",
  "size": "26",
  "source_nat": true,
  "vif_mac_address": "1e:00:2c:00:00:68"
},
{
  "add": true,
  "broadcast": "192.168.1.255",
  "cidr": "192.168.1.254/24",
  "device": "eth2",
  "gateway": "192.168.1.254",

[jira] [Commented] (CLOUDSTACK-10112) Template registration errors out when the URL is https

2017-10-23 Thread Sven Vogel (JIRA)


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

Sven Vogel commented on CLOUDSTACK-10112:
-

Hi Wei Zhou,

yes i think its the same problem like your pull request 
https://github.com/apache/cloudstack/pull/2271

its a duplicate.

i use too 4.10 ... is the pull request the fix?

> Template registration errors out when the URL is https 
> ---
>
> Key: CLOUDSTACK-10112
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10112
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Sudhansu Sahu
>Assignee: Sudhansu Sahu
>
> While creating a  template with https URL the following error occours:
>  
> sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

2016-12-01 Thread Sven Vogel (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sven Vogel resolved CLOUDSTACK-9590.

   Resolution: Fixed
Fix Version/s: 4.9.1.0

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Fix For: 4.9.1.0
>
> Attachments: agent.log, cloudstack-startup.log, management-server.zip
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

2016-12-01 Thread Sven Vogel (JIRA)


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

Sven Vogel commented on CLOUDSTACK-9590:


i found the solution with help of Dag Sonstebo. I used Java 1.8 and changed it 
to 1.7. After this Agent comes up fast.

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: agent.log, cloudstack-startup.log, management-server.zip
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

2016-11-14 Thread Sven Vogel (JIRA)


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

Sven Vogel commented on CLOUDSTACK-9590:


in Management Server i see always things like

{code}
2016-11-14 16:44:56,034 WARN  [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Monitor 
NetworkOrchestrator says there is an error in the connect process for 70 due to 
Unable to get an answer to the Check
NetworkCommand from agent: 70
2016-11-14 16:44:56,034 INFO  [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Host 70 is 
disconnecting with event AgentDisconnected
2016-11-14 16:44:56,040 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) The next status of 
agent 70is Alert, current status is Connecting
2016-11-14 16:44:56,040 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Deregistering link for 
70 with state Alert
2016-11-14 16:44:56,040 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Remove Agent : 70
2016-11-14 16:44:56,040 DEBUG [c.c.a.m.ConnectedAgentAttache] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Processing Disconnect.
2016-11-14 16:44:56,040 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Sending Disconnect to 
listener: com.cloud.hypervisor.xenserver.discoverer.XcpServerDiscoverer
2016-11-14 16:44:56,040 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Sending Disconnect to 
listener: com.cloud.hypervisor.hyperv.discoverer.HypervServerDiscoverer
2016-11-14 16:44:56,040 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Sending Disconnect to 
listener: com.cloud.storage.secondary.SecondaryStorageListener
2016-11-14 16:44:56,040 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Sending Disconnect to 
listener: com.cloud.storage.listener.StoragePoolMonitor
2016-11-14 16:44:56,040 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Sending Disconnect to 
listener: com.cloud.vm.ClusteredVirtualMachineManagerImpl
2016-11-14 16:44:56,040 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Sending Disconnect to 
listener: com.cloud.network.security.SecurityGroupListener
2016-11-14 16:44:56,040 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Sending Disconnect to 
listener: com.cloud.deploy.DeploymentPlanningManagerImpl
2016-11-14 16:44:56,040 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Sending Disconnect to 
listener: org.apache.cloudstack.engine.orchestration.NetworkOrchestrator
2016-11-14 16:44:56,040 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Sending Disconnect to 
listener: com.cloud.network.SshKeysDistriMonitor
2016-11-14 16:44:56,040 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Sending Disconnect to 
listener: com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl
2016-11-14 16:44:56,041 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Sending Disconnect to 
listener: com.cloud.storage.LocalStoragePoolListener
2016-11-14 16:44:56,041 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Sending Disconnect to 
listener: com.cloud.capacity.StorageCapacityListener
2016-11-14 16:44:56,041 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Sending Disconnect to 
listener: com.cloud.capacity.ComputeCapacityListener
2016-11-14 16:44:56,041 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Sending Disconnect to 
listener: com.cloud.network.SshKeysDistriMonitor
2016-11-14 16:44:56,041 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Sending Disconnect to 
listener: com.cloud.network.router.VirtualNetworkApplianceManagerImpl
2016-11-14 16:44:56,041 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Sending Disconnect to 
listener: com.cloud.storage.upload.UploadListener
2016-11-14 16:44:56,041 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Sending Disconnect to 
listener: com.cloud.network.NetworkUsageManagerImpl$DirectNetworkStatsListener
2016-11-14 16:44:56,041 DEBUG [c.c.n.NetworkUsageManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e) Disconnected called on 
70 with status Alert
2016-11-14 16:44:56,041 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-15:ctx-f99e936f) (logid:6cdf713e)

[jira] [Comment Edited] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

2016-11-14 Thread Sven Vogel (JIRA)


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

Sven Vogel edited comment on CLOUDSTACK-9590 at 11/14/16 3:11 PM:
--

1. first of all i add the host from cs management
2. Management Host {code} cloudstack-setup-agent  -m 192.168.85.25 -z 3 -p 3 -c 
9 -g 6e6cff15-3183-3cca-9389-ed1a78f6236a -a --pubNic=cloudbr2 
--prvNic=cloudbr0 --guestNic=cloudbr1 --hypervisor=kvm {code}
3. agent will be dead after add the host
4. restart agent
6. agent reconnect to server and wait with alert


was (Author: sven.vogel):
1. first of all i add the host from cs management
2. Management Host 
--  {code} cloudstack-setup-agent  -m 192.168.85.25 -z 3 -p 3 -c 9 -g 
6e6cff15-3183-3cca-9389-ed1a78f6236a -a --pubNic=cloudbr2 --prvNic=cloudbr0 
--guestNic=cloudbr1 --hypervisor=kvm {code}
3. agent will be dead after add the host
4. restart agent
6. agent reconnect to server and wait with alert

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: agent.log, cloudstack-startup.log, management-server.zip
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

2016-11-14 Thread Sven Vogel (JIRA)


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

Sven Vogel commented on CLOUDSTACK-9590:


1. first of all i add the host from cs management
2. Management Host 
--  {code} cloudstack-setup-agent  -m 192.168.85.25 -z 3 -p 3 -c 9 -g 
6e6cff15-3183-3cca-9389-ed1a78f6236a -a --pubNic=cloudbr2 --prvNic=cloudbr0 
--guestNic=cloudbr1 --hypervisor=kvm {code}
3. agent will be dead after add the host
4. restart agent
6. agent reconnect to server and wait with alert

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: agent.log, cloudstack-startup.log, management-server.zip
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

2016-11-14 Thread Sven Vogel (JIRA)


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

Sven Vogel commented on CLOUDSTACK-9590:


no maintenance mode. the host are fresh installed and added to cs. after that 
they stay for lime in alert mode.

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: agent.log, cloudstack-startup.log, management-server.zip
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

2016-11-11 Thread Sven Vogel (JIRA)


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

Sven Vogel commented on CLOUDSTACK-9590:


a how i fix this??!?

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: agent.log, cloudstack-startup.log, management-server.zip
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

2016-11-11 Thread Sven Vogel (JIRA)


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

Sven Vogel commented on CLOUDSTACK-9590:


Hi Wei,

what does this say to me?

thanks

Sven

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: agent.log, cloudstack-startup.log, management-server.zip
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

2016-11-10 Thread Sven Vogel (JIRA)


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

Sven Vogel commented on CLOUDSTACK-9590:


i upload the management-server.log

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: agent.log, cloudstack-startup.log, management-server.zip
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

2016-11-10 Thread Sven Vogel (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sven Vogel updated CLOUDSTACK-9590:
---
Attachment: management-server.zip

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: agent.log, cloudstack-startup.log, management-server.zip
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

2016-11-10 Thread Sven Vogel (JIRA)


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

Sven Vogel commented on CLOUDSTACK-9590:


ip upload the agent.log

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: agent.log, cloudstack-startup.log
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

2016-11-10 Thread Sven Vogel (JIRA)


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

Sven Vogel commented on CLOUDSTACK-9590:


i dont see anything like an error. you?

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: agent.log, cloudstack-startup.log
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

2016-11-10 Thread Sven Vogel (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sven Vogel updated CLOUDSTACK-9590:
---
Attachment: agent.log

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: agent.log, cloudstack-startup.log
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

2016-11-10 Thread Sven Vogel (JIRA)


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

Sven Vogel commented on CLOUDSTACK-9590:


Hi Wei,

thanks for answer.

when you look the startup it looks good. the agent starts and host are very 
long in alert mode.

what could be the problem?

thanks

Sven

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: cloudstack-startup.log
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

2016-11-10 Thread Sven Vogel (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sven Vogel updated CLOUDSTACK-9590:
---
Attachment: cloudstack-startup.log

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: cloudstack-startup.log
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

2016-11-10 Thread Sven Vogel (JIRA)

Sven Vogel created CLOUDSTACK-9590:
--

 Summary: KVM + CentOS 7.2 + Agent in Alert State for long time
 Key: CLOUDSTACK-9590
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: cloudstack-agent
Affects Versions: 4.9.0
 Environment: entOS Linux release 7.2.1511 (Core)
cloudstack-agent-4.9.0-1.el7.centos.x86_64
Reporter: Sven Vogel


Hi,

When i add a new host to cloudstack management server it take some time to get 
host out from alert state.

1. i add the host and host add not possible
2. values are correct set to agent.properties, restart cloustack agent
3. agent says connected to server
4. management server says "alert"

management-server.log

2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
(AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
state = Enabled, Agent event = AgentDisconnected, Host
id = 51, name = kvm02.oscloud.local]
2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
(AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
of to disconnect
2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
connection: com.cloud.exception.Connection
Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51

is there any way to speed up the alert state? is it normal that it take so long?

thanks

Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8812) CentOS 7 - systemd-tmpfiles - Operation not permitted

2015-10-15 Thread Sven Vogel (JIRA)


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

Sven Vogel commented on CLOUDSTACK-8812:


‎PermissionsStartOnly=true

That is important

Mit freundlichen Grüßen

Sven Vogel

-

Sven Vogel
Systems Engineer / Consultant
Kupper Computer GmbH

Prager Straße 15
04103 Leipzig


Registergericht Leipzig: HRB 19970

Geschäftsführer: Dipl.-Ing. Andreas Kupper

Tel: +49 (0)341 305 36 0
Fax:+49 (0)341 305 36 63
 Web:http://www.kupper-computer.com
 http://www.kupper-websolutions.de
Mail:mailto:sven.vo...@kupper-computer.com
  Originalnachricht
Von: ASF GitHub Bot (JIRA)
Gesendet: Donnerstag, 15. Oktober 2015 13:14
An: Vogel, Sven
Betreff: [jira] [Commented] (CLOUDSTACK-8812) CentOS 7 - systemd-tmpfiles - 
Operation not permitted


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

ASF GitHub Bot commented on CLOUDSTACK-8812:


Github user karuturi commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/888#discussion_r42110792

--- Diff: packaging/centos7/cloud-management.service ---
@@ -15,22 +15,19 @@
 # specific language governing permissions and limitations
 # under the License.

-# Systemd unit file for CloudStack Management server
-#
-# clone tomcat service, see /usr/lib/systemd/system/tomcat.service
-
 [Unit]
 Description=CloudStack Management Server
 After=syslog.target network.target

 [Service]
 Type=forking
-ExecStart=/usr/sbin/tomcat-sysd start
-ExecStop=/usr/sbin/tomcat-sysd stop
+PermissionsStartOnly=true
+ExecStartPre=/usr/bin/systemd-tmpfiles --create
+ExecStart=/usr/sbin/cloudstack-management start
--- End diff --

I see a similar change in 
4.5:packaging/centos63/rhel7/cloud-management.service

```
[Service]
Type=forking
ExecStartPre=/usr/bin/systemd-tmpfiles --create
ExecStart=/usr/sbin/cloudstack-management start
ExecStop=/usr/sbin/cloudstack-management stop
SuccessExitStatus=143
User=cloud
Group=cloud
```





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


> CentOS 7 - systemd-tmpfiles - Operation not permitted
> -
>
> Key: CLOUDSTACK-8812
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8812
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.2, 4.6.0
> Environment: KVM VM / CentOS Linux release 7.1.1503 (Core)
>Reporter: Sven Vogel
>Priority: Blocker
>
> installation of the shapeblue upstream 4.5.2 repository. setup of the 
> database works. when i start the  service with systemctl start 
> cloudstack-management.service i get the following error.
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd[1]: Starting CloudStack 
> Management Server...
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/netreport) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/net) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/mapper) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/vfio) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/snd) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock/subsys) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock/lockdev) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/setrans) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock/lvm) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lvm) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/console) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/faillock) failed: Operation not permitted
> Sep 04 17:14:34

[jira] [Commented] (CLOUDSTACK-8812) CentOS 7 - systemd-tmpfiles - Operation not permitted

2015-10-15 Thread Sven Vogel (JIRA)


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

Sven Vogel commented on CLOUDSTACK-8812:


But I think that's only management Service. What's with usage service. This 
service systemd file is not present in shapeblue. I don't know maybe a other 
person wrote that.



Mit freundlichen Grüßen

Sven Vogel

-

Sven Vogel
Systems Engineer / Consultant
Kupper Computer GmbH

Prager Straße 15
04103 Leipzig


Registergericht Leipzig: HRB 19970

Geschäftsführer: Dipl.-Ing. Andreas Kupper

Tel: +49 (0)341 305 36 0
Fax:+49 (0)341 305 36 63
 Web:http://www.kupper-computer.com
 http://www.kupper-websolutions.de
Mail:mailto:sven.vo...@kupper-computer.com
  Originalnachricht
Von: Remi Bergsma (JIRA)
Gesendet: Donnerstag, 15. Oktober 2015 13:28
An: Vogel, Sven
Betreff: [jira] [Commented] (CLOUDSTACK-8812) CentOS 7 - systemd-tmpfiles - 
Operation not permitted


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

Remi Bergsma commented on CLOUDSTACK-8812:
--

Does that even work? Because /usr/sbin/cloudstack-management is not in the 
package. At least not in 4.6.

# rpm -qpl cloudstack-management-4.6.0-SNAPSHOT.el7.centos.x86_64.rpm | grep -v 
share
/etc/cloudstack/management/Catalina
/etc/cloudstack/management/Catalina/localhost
/etc/cloudstack/management/Catalina/localhost/client
/etc/cloudstack/management/Catalina/localhost/client/context.xml
/etc/cloudstack/management/catalina.properties
/etc/cloudstack/management/commons-logging.properties
/etc/cloudstack/management/db.properties
/etc/cloudstack/management/environment.properties
/etc/cloudstack/management/java.security.ciphers
/etc/cloudstack/management/log4j-cloud.xml
/etc/cloudstack/management/server.xml
/etc/cloudstack/management/tomcat-users.xml
/etc/cloudstack/management/web.xml
/etc/rc.d/init.d/cloudstack-ipallocator
/etc/security/limits.d/cloud
/etc/sudoers.d/cloudstack-management
/etc/sysconfig/cloudstack-management
/usr/bin/cloudstack-external-ipallocator.py
/usr/bin/cloudstack-migrate-databases
/usr/bin/cloudstack-set-guest-password
/usr/bin/cloudstack-set-guest-sshkey
/usr/bin/cloudstack-setup-databases
/usr/bin/cloudstack-setup-encryption
/usr/bin/cloudstack-setup-management
/usr/bin/cloudstack-sysvmadm
/usr/bin/cloudstack-update-xenserver-licenses
/usr/lib/systemd/system/cloudstack-management.service
/var/cache/cloudstack/management
/var/cache/cloudstack/management/temp
/var/cache/cloudstack/management/work
/var/cloudstack/management
/var/cloudstack/mnt
/var/log/cloudstack/ipallocator
/var/log/cloudstack/management
/var/log/cloudstack/management/catalina.out
/var/run/cloudstack-management.pid





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


> CentOS 7 - systemd-tmpfiles - Operation not permitted
> -
>
> Key: CLOUDSTACK-8812
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8812
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.2, 4.6.0
> Environment: KVM VM / CentOS Linux release 7.1.1503 (Core)
>Reporter: Sven Vogel
>Priority: Blocker
>
> installation of the shapeblue upstream 4.5.2 repository. setup of the 
> database works. when i start the  service with systemctl start 
> cloudstack-management.service i get the following error.
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd[1]: Starting CloudStack 
> Management Server...
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/netreport) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/net) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/mapper) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/vfio) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/snd) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock/subsys) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock/lockdev) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
>

[jira] [Resolved] (CLOUDSTACK-8903) CentOS 7 - cloudstack-setup-agent (localhost)

2015-09-25 Thread Sven Vogel (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sven Vogel resolved CLOUDSTACK-8903.

   Resolution: Fixed
Fix Version/s: 4.5.2

My Problem. I found out that you need 100% DNS Resolution. A Host Entry in 
/etc/hosts seems not solve the problem.



> CentOS 7 - cloudstack-setup-agent (localhost)
> -
>
> Key: CLOUDSTACK-8903
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8903
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.2
>Reporter: Sven Vogel
> Fix For: 4.5.2
>
>
> Hi,
> my cloudstack management server runs fine, but when i want to add a host from 
> webui i get the following error.
>  tail -f /var/log/cloudstack/management/management-server.log
> 2015-09-23 16:31:18,965 DEBUG [c.c.u.s.SSHCmdHelper] 
> (catalina-exec-12:ctx-9b3db966 ctx-1940710f) Executing cmd: lsmod|grep kvm
> 2015-09-23 16:31:19,996 DEBUG [c.c.u.s.SSHCmdHelper] 
> (catalina-exec-12:ctx-9b3db966 ctx-1940710f) lsmod|grep kvm output:kvm_intel  
>148081  0
> kvm   461126  1 kvm_intel
> 2015-09-23 16:31:20,014 DEBUG [c.c.u.s.SSHCmdHelper] 
> (catalina-exec-12:ctx-9b3db966 ctx-1940710f) Executing cmd: 
> cloudstack-setup-agent  -m localhost -z 2 -p 2 -c 2 -g 
> a6e064f8-e740-3a29-a6e3-6972d74c74e9 -a --pubNic=cloudbr2 --prvNic=cloudbr0 
> --guestNic=cloudbr1 --hypervisor=kvm
> when i run on managment server hostname -f i get the correct hostname also 
> when i use nslookup i get the correct ip.
> anyone knows why is that so?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8903) CentOS 7 - cloudstack-setup-agent (localhost)

2015-09-23 Thread Sven Vogel (JIRA)

Sven Vogel created CLOUDSTACK-8903:
--

 Summary: CentOS 7 - cloudstack-setup-agent (localhost)
 Key: CLOUDSTACK-8903
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8903
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Install and Setup
Affects Versions: 4.5.2
Reporter: Sven Vogel


Hi,

my cloudstack management server runs fine, but when i want to add a host from 
webui i get the following error.

 tail -f /var/log/cloudstack/management/management-server.log

2015-09-23 16:31:18,965 DEBUG [c.c.u.s.SSHCmdHelper] 
(catalina-exec-12:ctx-9b3db966 ctx-1940710f) Executing cmd: lsmod|grep kvm
2015-09-23 16:31:19,996 DEBUG [c.c.u.s.SSHCmdHelper] 
(catalina-exec-12:ctx-9b3db966 ctx-1940710f) lsmod|grep kvm output:kvm_intel
 148081  0
kvm   461126  1 kvm_intel

2015-09-23 16:31:20,014 DEBUG [c.c.u.s.SSHCmdHelper] 
(catalina-exec-12:ctx-9b3db966 ctx-1940710f) Executing cmd: 
cloudstack-setup-agent  -m localhost -z 2 -p 2 -c 2 -g 
a6e064f8-e740-3a29-a6e3-6972d74c74e9 -a --pubNic=cloudbr2 --prvNic=cloudbr0 
--guestNic=cloudbr1 --hypervisor=kvm

when i run on managment server hostname -f i get the correct hostname also when 
i use nslookup i get the correct ip.

anyone knows why is that so?

thanks

Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8812) CentOS 7 - systemd-tmpfiles - Operation not permitted

2015-09-15 Thread Sven Vogel (JIRA)


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

Sven Vogel commented on CLOUDSTACK-8812:


i think it will also be relevant in 4.6 since we use systemd. i think there are 
no changes in this time :).

> CentOS 7 - systemd-tmpfiles - Operation not permitted
> -
>
> Key: CLOUDSTACK-8812
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8812
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.2
> Environment: KVM VM / CentOS Linux release 7.1.1503 (Core)
>Reporter: Sven Vogel
>
> installation of the shapeblue upstream 4.5.2 repository. setup of the 
> database works. when i start the  service with systemctl start 
> cloudstack-management.service i get the following error.
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd[1]: Starting CloudStack 
> Management Server...
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/netreport) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/net) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/mapper) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/vfio) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/snd) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock/subsys) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock/lockdev) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/setrans) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock/lvm) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lvm) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/console) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/faillock) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/sepermit) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/ppp) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/lock/ppp) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/user) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: Failed to 
> create file /var/log/wtmp: Permission denied
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: Failed to 
> create file /var/log/btmp: Permission denied
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/ask-password) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/seats) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/sessions) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/users) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/machines) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/shutdown) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/log/journal) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/log/journal/9b4671a20660436c8068d4f91eea0c1d) failed: Operation 
> not p
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/tmp) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/tmp) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: Failed to 
> create file

[jira] [Commented] (CLOUDSTACK-8812) CentOS 7 - systemd-tmpfiles - Operation not permitted

2015-09-15 Thread Sven Vogel (JIRA)


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

Sven Vogel commented on CLOUDSTACK-8812:


Yes. I think it's the fact that the cloud user is used. Every time you call a 
systemd-tmpfiles --create it looks in the folder for the service Config files 
and want to recreate the information of them e.g. /var/run/ Problem, only 
root have this rights for any folders to do that. So I added that 
"PermissionsStartOnly=true"

With these command we get for a moment the needed rights. 



> CentOS 7 - systemd-tmpfiles - Operation not permitted
> -
>
> Key: CLOUDSTACK-8812
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8812
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.2
> Environment: KVM VM / CentOS Linux release 7.1.1503 (Core)
>Reporter: Sven Vogel
>
> installation of the shapeblue upstream 4.5.2 repository. setup of the 
> database works. when i start the  service with systemctl start 
> cloudstack-management.service i get the following error.
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd[1]: Starting CloudStack 
> Management Server...
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/netreport) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/net) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/mapper) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/vfio) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/snd) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock/subsys) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock/lockdev) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/setrans) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock/lvm) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lvm) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/console) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/faillock) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/sepermit) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/ppp) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/lock/ppp) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/user) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: Failed to 
> create file /var/log/wtmp: Permission denied
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: Failed to 
> create file /var/log/btmp: Permission denied
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/ask-password) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/seats) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/sessions) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/users) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/machines) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/shutdown) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/log/journal) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/log/journal/9b4671a20660436c8068d4f91eea0c1d) failed: Operation 
> not p
> Sep 04 17:14:34 cloudstack01.oscloud.local

[jira] [Commented] (CLOUDSTACK-8812) CentOS 7 - systemd-tmpfiles - Operation not permitted

2015-09-07 Thread Sven Vogel (JIRA)


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

Sven Vogel commented on CLOUDSTACK-8812:


i think the problem is in the 
/etc/systemd/system/multi-user.target.wants/cloudstack-management.service file

we should add the PermissionsStartOnly=true to create the 
cloudstack-management.pid file correctly because i think it try the cloud user 
and dont have anough permissions.

[Service]
Type=forking
PermissionsStartOnly=true (added)
ExecStartPre=/usr/bin/systemd-tmpfiles --create
ExecStart=/usr/sbin/cloudstack-management start
ExecStop=/usr/sbin/cloudstack-management stop
SuccessExitStatus=143
User=cloud
Group=cloud


> CentOS 7 - systemd-tmpfiles - Operation not permitted
> -
>
> Key: CLOUDSTACK-8812
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8812
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.2
> Environment: KVM VM / CentOS Linux release 7.1.1503 (Core)
>Reporter: Sven Vogel
>
> installation of the shapeblue upstream 4.5.2 repository. setup of the 
> database works. when i start the  service with systemctl start 
> cloudstack-management.service i get the following error.
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd[1]: Starting CloudStack 
> Management Server...
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/netreport) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/net) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/mapper) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/vfio) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/dev/snd) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock/subsys) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock/lockdev) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/setrans) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lock/lvm) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/lvm) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/console) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/faillock) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/sepermit) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/run/ppp) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/var/lock/ppp) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/user) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: Failed to 
> create file /var/log/wtmp: Permission denied
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: Failed to 
> create file /var/log/btmp: Permission denied
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/ask-password) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/seats) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/sessions) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/users) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/machines) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/systemd/shutdown) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
> chmod(/run/log/journal) failed: Operation not permitted
> Sep 04 17:14:34 cloudstack01.oscloud.local systemd-tmpfiles[5519]: 
>

[jira] [Updated] (CLOUDSTACK-10127) 4.9 / 4.10 KVM + openvswitch + vpc + static nat / secondary ip on eth2?

[jira] [Updated] (CLOUDSTACK-10127) 4.9 / 4.10 KVM + openvswitch + vpc + static nat / secondary ip on eth2?

[jira] [Created] (CLOUDSTACK-10127) 4.9 / 4.10 KVM + openvswitch + vpc + static nat / secondary ip on eth2?

[jira] [Commented] (CLOUDSTACK-10112) Template registration errors out when the URL is https

[jira] [Resolved] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[jira] [Comment Edited] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[jira] [Updated] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[jira] [Updated] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[jira] [Updated] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[jira] [Created] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[jira] [Commented] (CLOUDSTACK-8812) CentOS 7 - systemd-tmpfiles - Operation not permitted

[jira] [Commented] (CLOUDSTACK-8812) CentOS 7 - systemd-tmpfiles - Operation not permitted

[jira] [Resolved] (CLOUDSTACK-8903) CentOS 7 - cloudstack-setup-agent (localhost)

[jira] [Created] (CLOUDSTACK-8903) CentOS 7 - cloudstack-setup-agent (localhost)

[jira] [Commented] (CLOUDSTACK-8812) CentOS 7 - systemd-tmpfiles - Operation not permitted

[jira] [Commented] (CLOUDSTACK-8812) CentOS 7 - systemd-tmpfiles - Operation not permitted

[jira] [Commented] (CLOUDSTACK-8812) CentOS 7 - systemd-tmpfiles - Operation not permitted

27 matches

Site Navigation

Mail list logo

Footer information