Re: Incorrect details for private Nic

[Yuriy Karpel]

nk/ether 90:e2:ba:aa:3e:e4 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::92e2:baff:feaa:3ee4/64 scope link
>valid_lft forever preferred_lft forever
> 6: team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue master
> cloudbr0 state UP
> link/ether 90:e2:ba:aa:3e:e4 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::92e2:baff:feaa:3ee4/64 scope link
>valid_lft forever preferred_lft forever
> 7: cloudbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue
> state UP
> link/ether 90:e2:ba:aa:3e:e4 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::92e2:baff:feaa:3ee4/64 scope link
>valid_lft forever preferred_lft forever
> 8: team0.1804@team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc
> noqueue master mgm0 state UP
> link/ether 90:e2:ba:aa:3e:e4 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::92e2:baff:feaa:3ee4/64 scope link
>valid_lft forever preferred_lft forever
> 9: mgm0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP
> link/ether 90:e2:ba:aa:3e:e4 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::92e2:baff:feaa:3ee4/64 scope link
>valid_lft forever preferred_lft forever
> 10: team0.1806@team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc
> noqueue master stor0 state UP
> link/ether 90:e2:ba:aa:3e:e4 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::92e2:baff:feaa:3ee4/64 scope link
>valid_lft forever preferred_lft forever
> 11: stor0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state
> UP
> link/ether 90:e2:ba:aa:3e:e4 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::92e2:baff:feaa:3ee4/64 scope link
>valid_lft forever preferred_lft forever
> 12: team0.1807@team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc
> noqueue state UP
> link/ether 90:e2:ba:aa:3e:e4 brd ff:ff:ff:ff:ff:ff
> inet 10.30.16.13/24 brd 10.30.16.255 scope global team0.1807
>valid_lft forever preferred_lft forever
> inet6 fe80::92e2:baff:feaa:3ee4/64 scope link
>valid_lft forever preferred_lft forever
> 13: cloud0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UNKNOWN
> link/ether 9a:e0:be:79:eb:e4 brd ff:ff:ff:ff:ff:ff
> inet 169.254.0.1/16 scope global cloud0
>valid_lft forever preferred_lft forever
> inet6 fe80::98e0:beff:fe79:ebe4/64 scope link
>valid_lft forever preferred_lft forever
>
>
> cat /etc/cloudstack/agent/agent.properties
> #Storage
> #Thu Sep 08 09:13:16 MSK 2016
>
> guest.network.device=cloudbr0
> workers=5
> private.network.device=mgm0
> port=8250
> resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource
> guest.cpu.mode=IvyBridge
> pod=4
> zone=4
> hypervisor.type=kvm
> guid=ae21201a-3e0a-345d-8fc8-84d16076309c
> vm.memballoon.disable=true
> public.network.device=cloudbr0
> cluster=4
> local.storage.uuid=a651f29f-1a0b-452f-9eea-98febdbf9080
> domr.scripts.dir=scripts/network/domr/kvm
> LibvirtComputingResource.id=172
> host=10.30.10.42
>
> After downgrade agent started. No errors.
>
>
> 2016-09-08 0:49 GMT+03:00 Matthew Smart <msm...@smartsoftwareinc.com>:
>
>> I found the problem that was causing the issue. I access the cloudstack
>> servers via a network that I want to be completely separate and unknown to
>> the cloudstack deployment. I am using one server as both management and
>> agent in this test. So my nic setup looks like this:
>>
>>  * bond0 : an untagged bonded interface tied to cloudbr0
>>  * bond0.3 : tagged interface for vlan 3 with static ip 192.168.1.108
>>  * cloudbr0 : ethernet bridge to the untagged bond0
>>
>> When I try to add the host it fails giving an error:
>> Unable to configure LibvirtComputingResource
>> and complaining about the private nic being incorrect
>>
>> When I look in agent.properties I noticed that the host value
>> automatically gets set to 192.168.1.108 which is not routable on cloudbr0.
>> If I manually set it to the proper host ip and then run
>> cloudstack-setup-agent from a terminal the host is added properly and works.
>>
>>
>> Matthew Smart
>> President
>> Smart Software Solutions Inc.
>> 108 S Pierre St.
>> Pierre, SD 57501
>>
>> Phone: (605) 280-0383
>> Skype: msmart13
>> Email: msm...@smartsoftwareinc.com
>>
>> On 09/06/2016 07:42 PM, Matthew Smart wrote:
>>
>>> Did this error end up in a bug report in Jira? I have just ran into the
>>> exact same issue testing an advanced network where public, private, and
>>> guest networks are assigned the same bridge. I am going to reload my test
>>> nodes tomorrow to make

Re: Incorrect details for private Nic

[Yuriy Karpel]

eployment. I am using one server as both management and
> agent in this test. So my nic setup looks like this:
>
>  * bond0 : an untagged bonded interface tied to cloudbr0
>  * bond0.3 : tagged interface for vlan 3 with static ip 192.168.1.108
>  * cloudbr0 : ethernet bridge to the untagged bond0
>
> When I try to add the host it fails giving an error:
> Unable to configure LibvirtComputingResource
> and complaining about the private nic being incorrect
>
> When I look in agent.properties I noticed that the host value
> automatically gets set to 192.168.1.108 which is not routable on cloudbr0.
> If I manually set it to the proper host ip and then run
> cloudstack-setup-agent from a terminal the host is added properly and works.
>
>
> Matthew Smart
> President
> Smart Software Solutions Inc.
> 108 S Pierre St.
> Pierre, SD 57501
>
> Phone: (605) 280-0383
> Skype: msmart13
> Email: msm...@smartsoftwareinc.com
>
> On 09/06/2016 07:42 PM, Matthew Smart wrote:
>
>> Did this error end up in a bug report in Jira? I have just ran into the
>> exact same issue testing an advanced network where public, private, and
>> guest networks are assigned the same bridge. I am going to reload my test
>> nodes tomorrow to make sure it is not the result of something left over
>> from previous tests but the fact that the exact errors are being logged by
>> another user is not encouraging.
>>
>> Matthew Smart
>> President
>> Smart Software Solutions Inc.
>> 108 S Pierre St.
>> Pierre, SD 57501
>>
>> Phone: (605) 280-0383
>> Skype: msmart13
>> Email: msm...@smartsoftwareinc.com
>>
>> On 08/29/2016 10:39 PM, Simon Weller wrote:
>>
>>> Sorry, I wasn't clear...I meant change your interfaces by removing the
>>> vlans so the bridges show just the interface name.
>>>
>>> Simon Weller/ENA
>>> (615) 312-6068
>>>
>>> -Original Message-
>>> From: John Cenile [jcenile1...@gmail.com]
>>> Received: Monday, 29 Aug 2016, 8:32PM
>>> To: users@cloudstack.apache.org [users@cloudstack.apache.org]
>>> Subject: Re: Incorrect details for private Nic
>>>
>>> Unfortunately that didn't fix it either, it looks like they just change
>>> straight back to "cloudbr0":
>>>
>>> [root@node1 ~]# tail -n 3 /etc/cloudstack/agent/agent.properties
>>> private.network.device=eth0
>>> public.network.device=eth0
>>> guest.network.device=eth0
>>>
>>>
>>>
>>> 2016-08-30 12:28:50,924 INFO  [cloud.agent.Agent] (main:null) (logid:)
>>> id is
>>> 2016-08-30 12:28:50,924 DEBUG [cloud.resource.ServerResourceBase]
>>> (main:null) (logid:) Retrieving network interface: cloudbr0
>>> 2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
>>> (main:null) (logid:) Retrieving network interface: cloudbr0
>>> 2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
>>> (main:null) (logid:) Retrieving network interface: null
>>> 2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
>>> (main:null) (logid:) Retrieving network interface: null
>>> 2016-08-30 12:28:50,935 WARN [cloud.resource.ServerResourceBase]
>>> (main:null) (logid:) Incorrect details for private Nic during
>>> initialization of ServerResourceBase
>>> 2016-08-30 12:28:50,935 ERROR [cloud.agent.AgentShell] (main:null)
>>> (logid:)
>>> Unable to start agent: Unable to configure LibvirtComputingResource
>>>
>>> [root@node1 ~]# service cloudstack-agent status
>>> cloudstack-agent dead but subsys locked
>>>
>>>
>>> Thanks for your help so far, do you have any other suggestions? The next
>>> thing I was going to try was downgrading to 4.8 and trying that version.
>>>
>>> On 30 August 2016 at 00:40, Simon Weller <swel...@ena.com> wrote:
>>>
>>> I'd suspect changing the sub ints to native ports will fix this as well.
>>>> That might be a better approach so you don't have to mess with the
>>>> traffic
>>>> labels
>>>>
>>>> Traveling today, so if my responses are a bit slow, it's because I'm on
>>>> a
>>>> plane.
>>>>
>>>> Simon Weller/ENA
>>>> (615) 312-6068
>>>>
>>>> -Original Message-
>>>> From: John Cenile [jcenile1...@gmail.com]
>>>> Received: Monday, 29 Aug 2016, 10:08AM
>>>> To: users@cloudstack.apache.org [users@cloudstack.apache.org]
>>>> Subject: Re: Incorrec

Re: Incorrect details for private Nic

[Simon Weller]

Matthew,


I don't believe a bug has been opened on this. Can you provide info on how your 
physical interfaces are setup (in ACS management), what traffic labels (and 
tags) you are using, as well as the interface and agent.properties config?


- Si



From: Matthew Smart <msm...@smartsoftwareinc.com>
Sent: Tuesday, September 6, 2016 7:42 PM
To: users@cloudstack.apache.org
Subject: Re: Incorrect details for private Nic

Did this error end up in a bug report in Jira? I have just ran into the
exact same issue testing an advanced network where public, private, and
guest networks are assigned the same bridge. I am going to reload my
test nodes tomorrow to make sure it is not the result of something left
over from previous tests but the fact that the exact errors are being
logged by another user is not encouraging.

Matthew Smart
President
Smart Software Solutions Inc.
108 S Pierre St.
Pierre, SD 57501

Phone: (605) 280-0383
Skype: msmart13
Email: msm...@smartsoftwareinc.com

On 08/29/2016 10:39 PM, Simon Weller wrote:
> Sorry, I wasn't clear...I meant change your interfaces by removing the vlans 
> so the bridges show just the interface name.
>
> Simon Weller/ENA
> (615) 312-6068
>
> -Original Message-
> From: John Cenile [jcenile1...@gmail.com]
> Received: Monday, 29 Aug 2016, 8:32PM
> To: users@cloudstack.apache.org [users@cloudstack.apache.org]
> Subject: Re: Incorrect details for private Nic
>
> Unfortunately that didn't fix it either, it looks like they just change
> straight back to "cloudbr0":
>
> [root@node1 ~]# tail -n 3 /etc/cloudstack/agent/agent.properties
> private.network.device=eth0
> public.network.device=eth0
> guest.network.device=eth0
>
>
>
> 2016-08-30 12:28:50,924 INFO  [cloud.agent.Agent] (main:null) (logid:) id is
> 2016-08-30 12:28:50,924 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: cloudbr0
> 2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: cloudbr0
> 2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-30 12:28:50,935 WARN  [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Incorrect details for private Nic during
> initialization of ServerResourceBase
> 2016-08-30 12:28:50,935 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
> Unable to start agent: Unable to configure LibvirtComputingResource
>
> [root@node1 ~]# service cloudstack-agent status
> cloudstack-agent dead but subsys locked
>
>
> Thanks for your help so far, do you have any other suggestions? The next
> thing I was going to try was downgrading to 4.8 and trying that version.
>
> On 30 August 2016 at 00:40, Simon Weller <swel...@ena.com> wrote:
>
>> I'd suspect changing the sub ints to native ports will fix this as well.
>> That might be a better approach so you don't have to mess with the traffic
>> labels
>>
>> Traveling today, so if my responses are a bit slow, it's because I'm on a
>> plane.
>>
>> Simon Weller/ENA
>> (615) 312-6068
>>
>> -----Original Message-
>> From: John Cenile [jcenile1...@gmail.com]
>> Received: Monday, 29 Aug 2016, 10:08AM
>> To: users@cloudstack.apache.org [users@cloudstack.apache.org]
>> Subject: Re: Incorrect details for private Nic
>>
>> I just tried this, unfortunately that didn't solve it. I was under the
>> impression that the master replaced the interface names in that file with
>> cloudbr0 / cloudbr1? When I check the file again, those interface names are
>> back.
>>
>> Here are the logs (notice on the second attempt, the interface names
>> changed back):
>>
>>
>> [root@node1 ~]# tail -f /var/log/cloudstack/agent/agent.log
>> 2016-08-30 00:06:34,789 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
>> Checking to see if agent.pid exists.
>> 2016-08-30 00:06:34,798 DEBUG [cloud.utils.ProcessUtil] (main:null)
>> (logid:) Executing: bash -c echo $PPID
>> 2016-08-30 00:06:34,803 DEBUG [cloud.utils.ProcessUtil] (main:null)
>> (logid:) Execution is successful.
>> 2016-08-30 00:06:34,853 INFO  [cloud.agent.Agent] (main:null) (logid:) id
>> is
>> 2016-08-30 00:06:34,853 DEBUG [cloud.resource.ServerResourceBase]
>> (main:null) (logid:) Retrieving network interface: eth0.200
>> 2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
>> (main:null) (logid:) Retrieving network interface: eth0.200
>> 2016-08-30

Re: Incorrect details for private Nic

[Matthew Smart]

Did this error end up in a bug report in Jira? I have just ran into the 
exact same issue testing an advanced network where public, private, and 
guest networks are assigned the same bridge. I am going to reload my 
test nodes tomorrow to make sure it is not the result of something left 
over from previous tests but the fact that the exact errors are being 
logged by another user is not encouraging.


Matthew Smart
President
Smart Software Solutions Inc.
108 S Pierre St.
Pierre, SD 57501

Phone: (605) 280-0383
Skype: msmart13
Email: msm...@smartsoftwareinc.com

On 08/29/2016 10:39 PM, Simon Weller wrote:

Sorry, I wasn't clear...I meant change your interfaces by removing the vlans so 
the bridges show just the interface name.

Simon Weller/ENA
(615) 312-6068

-Original Message-
From: John Cenile [jcenile1...@gmail.com]
Received: Monday, 29 Aug 2016, 8:32PM
To: users@cloudstack.apache.org [users@cloudstack.apache.org]
Subject: Re: Incorrect details for private Nic

Unfortunately that didn't fix it either, it looks like they just change
straight back to "cloudbr0":

[root@node1 ~]# tail -n 3 /etc/cloudstack/agent/agent.properties
private.network.device=eth0
public.network.device=eth0
guest.network.device=eth0



2016-08-30 12:28:50,924 INFO  [cloud.agent.Agent] (main:null) (logid:) id is
2016-08-30 12:28:50,924 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 12:28:50,935 WARN  [cloud.resource.ServerResourceBase]
(main:null) (logid:) Incorrect details for private Nic during
initialization of ServerResourceBase
2016-08-30 12:28:50,935 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
Unable to start agent: Unable to configure LibvirtComputingResource

[root@node1 ~]# service cloudstack-agent status
cloudstack-agent dead but subsys locked


Thanks for your help so far, do you have any other suggestions? The next
thing I was going to try was downgrading to 4.8 and trying that version.

On 30 August 2016 at 00:40, Simon Weller <swel...@ena.com> wrote:


I'd suspect changing the sub ints to native ports will fix this as well.
That might be a better approach so you don't have to mess with the traffic
labels

Traveling today, so if my responses are a bit slow, it's because I'm on a
plane.

Simon Weller/ENA
(615) 312-6068

-Original Message-
From: John Cenile [jcenile1...@gmail.com]
Received: Monday, 29 Aug 2016, 10:08AM
To: users@cloudstack.apache.org [users@cloudstack.apache.org]
Subject: Re: Incorrect details for private Nic

I just tried this, unfortunately that didn't solve it. I was under the
impression that the master replaced the interface names in that file with
cloudbr0 / cloudbr1? When I check the file again, those interface names are
back.

Here are the logs (notice on the second attempt, the interface names
changed back):


[root@node1 ~]# tail -f /var/log/cloudstack/agent/agent.log
2016-08-30 00:06:34,789 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Checking to see if agent.pid exists.
2016-08-30 00:06:34,798 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Executing: bash -c echo $PPID
2016-08-30 00:06:34,803 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Execution is successful.
2016-08-30 00:06:34,853 INFO  [cloud.agent.Agent] (main:null) (logid:) id
is
2016-08-30 00:06:34,853 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: eth0.200
2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: eth0.200
2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 00:06:34,859 WARN  [cloud.resource.ServerResourceBase]
(main:null) (logid:) Incorrect details for private Nic during
initialization of ServerResourceBase
2016-08-30 00:06:34,859 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
Unable to start agent: Unable to configure LibvirtComputingResource



2016-08-30 00:07:29,905 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Agent started
2016-08-30 00:07:29,907 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Implementation Version is 4.9.0
2016-08-30 00:07:29,909 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
agent.properties found at /etc/cloudstack/agent/agent.properties
2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: guest.network.device
2016-08-30 00

Re: Incorrect details for private Nic

[John Cenile]

I ended up downgrading to 4.8, without changing *anything* it worked
perfectly. I'll try upgrading to 4.9 soon and seeing if the problem returns
though.

I'm now facing a different problem which you may be able to help with, it
seems like I can't reach my Console Proxy VM at all? I can't ping it, I can
*only* access it via the link local address.

When I'm SSH'd in (via link local), I can ping / connect outbound, so I
have a feeling it's firewall related on the KVM host itself:

Running iptables -xvn -L returns:

Chain r-4-VM (2 references)
pkts  bytes target prot opt in out source
destination
  82 6603 RETURN all  --  *  *   0.0.0.0/0
0.0.0.0/0   PHYSDEV match --physdev-in vnet6 --physdev-is-bridged
 35722182 ACCEPT all  --  *  *   0.0.0.0/0
0.0.0.0/0

Chain s-2-VM (4 references)
pkts  bytes target prot opt in out source
destination
  14  888 RETURN all  --  *  *   0.0.0.0/0
0.0.0.0/0   PHYSDEV match --physdev-in vnet1 --physdev-is-bridged
  39 2772 RETURN all  --  *  *   0.0.0.0/0
0.0.0.0/0   PHYSDEV match --physdev-in vnet2 --physdev-is-bridged
 66238835 ACCEPT all  --  *  *   0.0.0.0/0
0.0.0.0/0

Chain v-1-VM (0 references)
pkts  bytes target prot opt in out source
destination
[root@node1 ~]#

Should there be any rules under the "v-1-VM" chain?

On 30 August 2016 at 13:39, Simon Weller <swel...@ena.com> wrote:

> Sorry, I wasn't clear...I meant change your interfaces by removing the
> vlans so the bridges show just the interface name.
>
> Simon Weller/ENA
> (615) 312-6068
>
> -Original Message-
> From: John Cenile [jcenile1...@gmail.com]
> Received: Monday, 29 Aug 2016, 8:32PM
> To: users@cloudstack.apache.org [users@cloudstack.apache.org]
> Subject: Re: Incorrect details for private Nic
>
> Unfortunately that didn't fix it either, it looks like they just change
> straight back to "cloudbr0":
>
> [root@node1 ~]# tail -n 3 /etc/cloudstack/agent/agent.properties
> private.network.device=eth0
> public.network.device=eth0
> guest.network.device=eth0
>
>
>
> 2016-08-30 12:28:50,924 INFO  [cloud.agent.Agent] (main:null) (logid:) id
> is
> 2016-08-30 12:28:50,924 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: cloudbr0
> 2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: cloudbr0
> 2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-30 12:28:50,935 WARN  [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Incorrect details for private Nic during
> initialization of ServerResourceBase
> 2016-08-30 12:28:50,935 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
> Unable to start agent: Unable to configure LibvirtComputingResource
>
> [root@node1 ~]# service cloudstack-agent status
> cloudstack-agent dead but subsys locked
>
>
> Thanks for your help so far, do you have any other suggestions? The next
> thing I was going to try was downgrading to 4.8 and trying that version.
>
> On 30 August 2016 at 00:40, Simon Weller <swel...@ena.com> wrote:
>
> > I'd suspect changing the sub ints to native ports will fix this as well.
> > That might be a better approach so you don't have to mess with the
> traffic
> > labels
> >
> > Traveling today, so if my responses are a bit slow, it's because I'm on a
> > plane.
> >
> > Simon Weller/ENA
> > (615) 312-6068
> >
> > -Original Message-
> > From: John Cenile [jcenile1...@gmail.com]
> > Received: Monday, 29 Aug 2016, 10:08AM
> > To: users@cloudstack.apache.org [users@cloudstack.apache.org]
> > Subject: Re: Incorrect details for private Nic
> >
> > I just tried this, unfortunately that didn't solve it. I was under the
> > impression that the master replaced the interface names in that file with
> > cloudbr0 / cloudbr1? When I check the file again, those interface names
> are
> > back.
> >
> > Here are the logs (notice on the second attempt, the interface names
> > changed back):
> >
> >
> > [root@node1 ~]# tail -f /var/log/cloudstack/agent/agent.log
> > 2016-08-30 00:06:34,789 DEBUG [cloud.agent.AgentShell] (main:null)
> (logid:)
> > Checking to see if agent.pid exists.
> > 2016-08-30 00:06:34,798 DEBUG [cloud.utils.ProcessUtil] (main:null)
> > (logid:) Executing: bash -c echo $PPID

RE: Incorrect details for private Nic

[Simon Weller]

Sorry, I wasn't clear...I meant change your interfaces by removing the vlans so 
the bridges show just the interface name.

Simon Weller/ENA
(615) 312-6068

-Original Message-
From: John Cenile [jcenile1...@gmail.com]
Received: Monday, 29 Aug 2016, 8:32PM
To: users@cloudstack.apache.org [users@cloudstack.apache.org]
Subject: Re: Incorrect details for private Nic

Unfortunately that didn't fix it either, it looks like they just change
straight back to "cloudbr0":

[root@node1 ~]# tail -n 3 /etc/cloudstack/agent/agent.properties
private.network.device=eth0
public.network.device=eth0
guest.network.device=eth0



2016-08-30 12:28:50,924 INFO  [cloud.agent.Agent] (main:null) (logid:) id is
2016-08-30 12:28:50,924 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 12:28:50,935 WARN  [cloud.resource.ServerResourceBase]
(main:null) (logid:) Incorrect details for private Nic during
initialization of ServerResourceBase
2016-08-30 12:28:50,935 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
Unable to start agent: Unable to configure LibvirtComputingResource

[root@node1 ~]# service cloudstack-agent status
cloudstack-agent dead but subsys locked


Thanks for your help so far, do you have any other suggestions? The next
thing I was going to try was downgrading to 4.8 and trying that version.

On 30 August 2016 at 00:40, Simon Weller <swel...@ena.com> wrote:

> I'd suspect changing the sub ints to native ports will fix this as well.
> That might be a better approach so you don't have to mess with the traffic
> labels
>
> Traveling today, so if my responses are a bit slow, it's because I'm on a
> plane.
>
> Simon Weller/ENA
> (615) 312-6068
>
> -Original Message-
> From: John Cenile [jcenile1...@gmail.com]
> Received: Monday, 29 Aug 2016, 10:08AM
> To: users@cloudstack.apache.org [users@cloudstack.apache.org]
> Subject: Re: Incorrect details for private Nic
>
> I just tried this, unfortunately that didn't solve it. I was under the
> impression that the master replaced the interface names in that file with
> cloudbr0 / cloudbr1? When I check the file again, those interface names are
> back.
>
> Here are the logs (notice on the second attempt, the interface names
> changed back):
>
>
> [root@node1 ~]# tail -f /var/log/cloudstack/agent/agent.log
> 2016-08-30 00:06:34,789 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Checking to see if agent.pid exists.
> 2016-08-30 00:06:34,798 DEBUG [cloud.utils.ProcessUtil] (main:null)
> (logid:) Executing: bash -c echo $PPID
> 2016-08-30 00:06:34,803 DEBUG [cloud.utils.ProcessUtil] (main:null)
> (logid:) Execution is successful.
> 2016-08-30 00:06:34,853 INFO  [cloud.agent.Agent] (main:null) (logid:) id
> is
> 2016-08-30 00:06:34,853 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: eth0.200
> 2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: eth0.200
> 2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-30 00:06:34,859 WARN  [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Incorrect details for private Nic during
> initialization of ServerResourceBase
> 2016-08-30 00:06:34,859 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
> Unable to start agent: Unable to configure LibvirtComputingResource
>
>
>
> 2016-08-30 00:07:29,905 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Agent started
> 2016-08-30 00:07:29,907 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Implementation Version is 4.9.0
> 2016-08-30 00:07:29,909 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> agent.properties found at /etc/cloudstack/agent/agent.properties
> 2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: guest.network.device
> 2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: workers
> 2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: private.network.device
> 2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: port
> 2016-08-30 00:07:

Re: Incorrect details for private Nic

[John Cenile]

Unfortunately that didn't fix it either, it looks like they just change
straight back to "cloudbr0":

[root@node1 ~]# tail -n 3 /etc/cloudstack/agent/agent.properties
private.network.device=eth0
public.network.device=eth0
guest.network.device=eth0



2016-08-30 12:28:50,924 INFO  [cloud.agent.Agent] (main:null) (logid:) id is
2016-08-30 12:28:50,924 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 12:28:50,935 WARN  [cloud.resource.ServerResourceBase]
(main:null) (logid:) Incorrect details for private Nic during
initialization of ServerResourceBase
2016-08-30 12:28:50,935 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
Unable to start agent: Unable to configure LibvirtComputingResource

[root@node1 ~]# service cloudstack-agent status
cloudstack-agent dead but subsys locked


Thanks for your help so far, do you have any other suggestions? The next
thing I was going to try was downgrading to 4.8 and trying that version.

On 30 August 2016 at 00:40, Simon Weller <swel...@ena.com> wrote:

> I'd suspect changing the sub ints to native ports will fix this as well.
> That might be a better approach so you don't have to mess with the traffic
> labels
>
> Traveling today, so if my responses are a bit slow, it's because I'm on a
> plane.
>
> Simon Weller/ENA
> (615) 312-6068
>
> -Original Message-
> From: John Cenile [jcenile1...@gmail.com]
> Received: Monday, 29 Aug 2016, 10:08AM
> To: users@cloudstack.apache.org [users@cloudstack.apache.org]
> Subject: Re: Incorrect details for private Nic
>
> I just tried this, unfortunately that didn't solve it. I was under the
> impression that the master replaced the interface names in that file with
> cloudbr0 / cloudbr1? When I check the file again, those interface names are
> back.
>
> Here are the logs (notice on the second attempt, the interface names
> changed back):
>
>
> [root@node1 ~]# tail -f /var/log/cloudstack/agent/agent.log
> 2016-08-30 00:06:34,789 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Checking to see if agent.pid exists.
> 2016-08-30 00:06:34,798 DEBUG [cloud.utils.ProcessUtil] (main:null)
> (logid:) Executing: bash -c echo $PPID
> 2016-08-30 00:06:34,803 DEBUG [cloud.utils.ProcessUtil] (main:null)
> (logid:) Execution is successful.
> 2016-08-30 00:06:34,853 INFO  [cloud.agent.Agent] (main:null) (logid:) id
> is
> 2016-08-30 00:06:34,853 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: eth0.200
> 2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: eth0.200
> 2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-30 00:06:34,859 WARN  [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Incorrect details for private Nic during
> initialization of ServerResourceBase
> 2016-08-30 00:06:34,859 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
> Unable to start agent: Unable to configure LibvirtComputingResource
>
>
>
> 2016-08-30 00:07:29,905 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Agent started
> 2016-08-30 00:07:29,907 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Implementation Version is 4.9.0
> 2016-08-30 00:07:29,909 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> agent.properties found at /etc/cloudstack/agent/agent.properties
> 2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: guest.network.device
> 2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: workers
> 2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: private.network.device
> 2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: port
> 2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: resource
> 2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: pod
> 2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: zone
> 2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) 

RE: Incorrect details for private Nic

[Simon Weller]

I'd suspect changing the sub ints to native ports will fix this as well. That 
might be a better approach so you don't have to mess with the traffic labels

Traveling today, so if my responses are a bit slow, it's because I'm on a plane.

Simon Weller/ENA
(615) 312-6068

-Original Message-
From: John Cenile [jcenile1...@gmail.com]
Received: Monday, 29 Aug 2016, 10:08AM
To: users@cloudstack.apache.org [users@cloudstack.apache.org]
Subject: Re: Incorrect details for private Nic

I just tried this, unfortunately that didn't solve it. I was under the
impression that the master replaced the interface names in that file with
cloudbr0 / cloudbr1? When I check the file again, those interface names are
back.

Here are the logs (notice on the second attempt, the interface names
changed back):


[root@node1 ~]# tail -f /var/log/cloudstack/agent/agent.log
2016-08-30 00:06:34,789 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Checking to see if agent.pid exists.
2016-08-30 00:06:34,798 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Executing: bash -c echo $PPID
2016-08-30 00:06:34,803 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Execution is successful.
2016-08-30 00:06:34,853 INFO  [cloud.agent.Agent] (main:null) (logid:) id is
2016-08-30 00:06:34,853 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: eth0.200
2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: eth0.200
2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 00:06:34,859 WARN  [cloud.resource.ServerResourceBase]
(main:null) (logid:) Incorrect details for private Nic during
initialization of ServerResourceBase
2016-08-30 00:06:34,859 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
Unable to start agent: Unable to configure LibvirtComputingResource



2016-08-30 00:07:29,905 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Agent started
2016-08-30 00:07:29,907 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Implementation Version is 4.9.0
2016-08-30 00:07:29,909 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
agent.properties found at /etc/cloudstack/agent/agent.properties
2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: guest.network.device
2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: workers
2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: private.network.device
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: port
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: resource
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: pod
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: zone
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: guid
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: hypervisor.type
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: cluster
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: public.network.device
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: local.storage.uuid
2016-08-30 00:07:29,916 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: domr.scripts.dir
2016-08-30 00:07:29,916 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: host
2016-08-30 00:07:29,916 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Defaulting to using properties file for storage
2016-08-30 00:07:29,918 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Defaulting to the constant time backoff algorithm
2016-08-30 00:07:29,935 INFO  [cloud.utils.LogUtils] (main:null) (logid:)
log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml
2016-08-30 00:07:29,951 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Using default Java settings for IPv6 preference for agent connection
2016-08-30 00:07:29,951 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Checking to see if agent.pid exists.
2016-08-30 00:07:29,959 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Executing: bash -c echo $PPID
2016-08-30 00:07:29,964 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Execution is successful.
2016-08-30 00:07:30,020 INFO  [cloud.agent.Agent] (main:null) (logid:) id is
2016-08-30 00:07:30,021 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-30 00:07:30,028 DEBUG [cloud.resource.ServerResourceBase

Re: Incorrect details for private Nic

[John Cenile]

 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
Unable to start agent: Unable to configure LibvirtComputingResource





On 29 August 2016 at 22:47, Simon Weller <swel...@ena.com> wrote:

> Can you edit /etc/cloudstack/agent.properties and try changing the
> interfaces from cloudbr0 to your sub int, e.g. eth0.200
>
>
> Simon Weller/ENA
> (615) 312-6068
>
> -Original Message-
> From: John Cenile [jcenile1...@gmail.com]
> Received: Monday, 29 Aug 2016, 7:28AM
> To: users@cloudstack.apache.org [users@cloudstack.apache.org]
> Subject: Re: Incorrect details for private Nic
>
> On 29 August 2016 at 22:16, Simon Weller <swel...@ena.com> wrote:
>
> > So, my guess here is that the agent doesn't like the fact you have a sub
> > interface plugged into the bridge. This is an advanced network zone,
> > correct?
>
>
> I haven't actually got that far, but I'm aiming for the Basic network zone.
> The guide on CloudStack's website actually recommends this set up (having a
> VLAN interface plugged into the bridge).
>
> For a testing setup, that will never have production servers on it, how
> would you recommend setting up the interfaces? Just an eth0 -> cloudbr0 and
> eth1 -> cloudbr1?
>

RE: Incorrect details for private Nic

[Simon Weller]

Can you edit /etc/cloudstack/agent.properties and try changing the interfaces 
from cloudbr0 to your sub int, e.g. eth0.200


Simon Weller/ENA
(615) 312-6068

-Original Message-
From: John Cenile [jcenile1...@gmail.com]
Received: Monday, 29 Aug 2016, 7:28AM
To: users@cloudstack.apache.org [users@cloudstack.apache.org]
Subject: Re: Incorrect details for private Nic

On 29 August 2016 at 22:16, Simon Weller <swel...@ena.com> wrote:

> So, my guess here is that the agent doesn't like the fact you have a sub
> interface plugged into the bridge. This is an advanced network zone,
> correct?


I haven't actually got that far, but I'm aiming for the Basic network zone.
The guide on CloudStack's website actually recommends this set up (having a
VLAN interface plugged into the bridge).

For a testing setup, that will never have production servers on it, how
would you recommend setting up the interfaces? Just an eth0 -> cloudbr0 and
eth1 -> cloudbr1?

Re: Incorrect details for private Nic

[John Cenile]

On 29 August 2016 at 22:16, Simon Weller  wrote:

> So, my guess here is that the agent doesn't like the fact you have a sub
> interface plugged into the bridge. This is an advanced network zone,
> correct?


I haven't actually got that far, but I'm aiming for the Basic network zone.
The guide on CloudStack's website actually recommends this set up (having a
VLAN interface plugged into the bridge).

For a testing setup, that will never have production servers on it, how
would you recommend setting up the interfaces? Just an eth0 -> cloudbr0 and
eth1 -> cloudbr1?

RE: Incorrect details for private Nic

[Simon Weller]

So, my guess here is that the agent doesn't like the fact you have a sub 
interface plugged into the bridge. This is an advanced network zone, correct?

Simon Weller/ENA
(615) 312-6068

-Original Message-
From: John Cenile [jcenile1...@gmail.com]
Received: Monday, 29 Aug 2016, 7:08AM
To: users@cloudstack.apache.org [users@cloudstack.apache.org]
Subject: Re: Incorrect details for private Nic

On 29 August 2016 at 21:57, Simon Weller <swel...@ena.com> wrote:

> Can you post the output of brctl show?


bridge name bridge id   STP enabled interfaces
cloud0  8000.   no
cloudbr08000.bcaec529ec9a   yes eth0.200
cloudbr18000.bcaec529ec9a   yes eth0.300
virbr0  8000.5254001fbe67   yes virbr0-nic



On 29 August 2016 at 21:57, Simon Weller <swel...@ena.com> wrote:

> Also, what are your kvm traffic labels set to? Do you have multiple
> physical networks configured in mgmt?


I haven't actually changed these, so I *assume* these are the default of
cloudbr0 and cloudbr1? No, I only have one physical network configured on
the management server.

Re: Incorrect details for private Nic

[John Cenile]

On 29 August 2016 at 21:06, Pierre-Luc Dion  wrote:

>
> Does the management server can ssh on the kvm server?


Yes it can.

[root@master ~]# ssh 10.1.1.2
root@10.1.1.2's password:
Last login: Mon Aug 29 21:44:20 2016 from master
[root@node1 ~]#

On 29 August 2016 at 21:06, Pierre-Luc Dion  wrote:

> Does the kvm server can tcp connect on the mgt server port 8250?


Yes it can:

[root@node1 ~]# nc -z 10.1.1.1 8250
Connection to 10.1.1.1 8250 port [tcp/*] succeeded!





On 29 August 2016 at 21:33, Simon Weller  wrote:

> Can you place the agent in debug mode and post the output?


Sure, here's the log output:

2016-08-29 21:50:18,650 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Agent started
2016-08-29 21:50:18,653 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Implementation Version is 4.9.0
2016-08-29 21:50:18,654 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
agent.properties found at /etc/cloudstack/agent/agent.properties
2016-08-29 21:50:18,660 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: guest.network.device
2016-08-29 21:50:18,660 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: workers
2016-08-29 21:50:18,660 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: private.network.device
2016-08-29 21:50:18,660 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: port
2016-08-29 21:50:18,660 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: resource
2016-08-29 21:50:18,661 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: pod
2016-08-29 21:50:18,661 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: zone
2016-08-29 21:50:18,661 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: guid
2016-08-29 21:50:18,661 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: hypervisor.type
2016-08-29 21:50:18,661 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: cluster
2016-08-29 21:50:18,661 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: public.network.device
2016-08-29 21:50:18,661 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: local.storage.uuid
2016-08-29 21:50:18,661 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: domr.scripts.dir
2016-08-29 21:50:18,662 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: host
2016-08-29 21:50:18,662 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Defaulting to using properties file for storage
2016-08-29 21:50:18,664 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Defaulting to the constant time backoff algorithm
2016-08-29 21:50:18,681 INFO  [cloud.utils.LogUtils] (main:null) (logid:)
log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml
2016-08-29 21:50:18,697 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Using default Java settings for IPv6 preference for agent connection
2016-08-29 21:50:18,697 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Checking to see if agent.pid exists.
2016-08-29 21:50:18,706 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Executing: bash -c echo $PPID
2016-08-29 21:50:18,712 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Execution is successful.
2016-08-29 21:50:18,768 INFO  [cloud.agent.Agent] (main:null) (logid:) id is
2016-08-29 21:50:18,769 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-29 21:50:18,776 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-29 21:50:18,777 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-29 21:50:18,777 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-29 21:50:18,780 WARN  [cloud.resource.ServerResourceBase]
(main:null) (logid:) Incorrect details for private Nic during
initialization of ServerResourceBase
2016-08-29 21:50:18,780 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
Unable to start agent: Unable to configure LibvirtComputingResource

RE: Incorrect details for private Nic

[Simon Weller]

In my experience, the error your reporting normally indicates that the agent 
can't figure out the interface names for some reason. Can you place the agent 
in debug mode and post the output?

You can enable agent debugging by running the following command: sed -i 
's/INFO/DEBUG/g' /etc/cloudstack/agent/log4j-cloud.xml

- Si

Simon Weller/ENA
(615) 312-6068

-Original Message-
From: Pierre-Luc Dion [pd...@cloudops.com]
Received: Monday, 29 Aug 2016, 6:06AM
To: users@cloudstack.apache.org [users@cloudstack.apache.org]
Subject: Re: Incorrect details for private Nic

I presume the kvm node is a different one than the management server, has a
basic tests:

Does the management server can ssh on the kvm server?

Does the kvm server can tcp connect on the mgt server port 8250?

On Aug 29, 2016 03:52, "John Cenile" <jcenile1...@gmail.com> wrote:

> Hi all,
>
> I'm trying to set up a test CloudStack installation, using two very basic
> CentOS 6.8 servers (I previously tried with CentOS 7, but ran into the same
> issue, so now I'm trying CentOS 6).
>
> Basically I can get (almost) everything working, except for the *Add
> host* stage,
> where I get the error "Incorrect details for private Nic during
> initialization of ServerResourceBase" in the agent.log.
>
> I haven't edited the agent.properties file manually at all, I have followed
> the KVM agent configuration guide
> <http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/4.
> 9/hypervisor/kvm.html>
> perfectly as far as I can tell, as well as the Management Node
> configuration guide
> <http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/4.
> 9/management-server/index.html>
> .
>
> I have cloudbr0 and cloudbr1 bridge interfaces set up, as well as eth0
> which is the actual IP I'm connecting to.
>
> The only other thread I can find where someone had this issue, they ended
> up downgrading the agent, does that mean this is a known issue with 4.9? (
> https://www.mail-archive.com/users@cloudstack.apache.org/msg20717.html)
>
> Does anyone have any idea why I'm getting these errors? If there's any
> other logs / config files you need, please let me know.
>
> Thanks in advance.
>
> *Cloudstack Management: *4.9.0.1.el6
>
> *Cloudstack Agent:* 4.9.0.1.el6
>
> *Agent logs*
>
> [root@node1 ~]# tail -n 15 /var/log/cloudstack/agent/agent.log
> 2016-08-29 17:18:08,572 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: host
> 2016-08-29 17:18:08,572 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Defaulting to using properties file for storage
> 2016-08-29 17:18:08,574 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Defaulting to the constant time backoff algorithm
> 2016-08-29 17:18:08,591 INFO  [cloud.utils.LogUtils] (main:null) (logid:)
> log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml
> 2016-08-29 17:18:08,606 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Using default Java settings for IPv6 preference for agent connection
> 2016-08-29 17:18:08,607 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Checking to see if agent.pid exists.
> 2016-08-29 17:18:08,615 DEBUG [cloud.utils.ProcessUtil] (main:null)
> (logid:) Executing: bash -c echo $PPID
> 2016-08-29 17:18:08,620 DEBUG [cloud.utils.ProcessUtil] (main:null)
> (logid:) Execution is successful.
> 2016-08-29 17:18:08,670 INFO  [cloud.agent.Agent] (main:null) (logid:) id
> is
> 2016-08-29 17:18:08,670 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: cloudbr0
> 2016-08-29 17:18:08,673 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: cloudbr0
> 2016-08-29 17:18:08,674 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-29 17:18:08,674 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-29 17:18:08,676 WARN  [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Incorrect details for private Nic during
> initialization of ServerResourceBase
> 2016-08-29 17:18:08,677 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
> Unable to start agent: Unable to configure LibvirtComputingResource
>
>
> Agent properties
>
> [root@node1 ~]# cat /etc/cloudstack/agent/agent.properties | sed -e
> '/^#/d'
> | sed -e '/^$/d'
> guid=b02788c7-20fc-30cd-a391-f2abaf002019
> resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource
> workers=5
> host=10.1.1.1
> port=8250
> cluster=1
> pod=1
> zone=1
> local.storage.uuid=525850bd-64fa-4eba-89e1-c0af4fb49621
> domr.scripts.dir=scripts/network/domr/kvm
> hypervisor.type=kvm
> 

Re: Incorrect details for private Nic

[Pierre-Luc Dion]

I presume the kvm node is a different one than the management server, has a
basic tests:

Does the management server can ssh on the kvm server?

Does the kvm server can tcp connect on the mgt server port 8250?

On Aug 29, 2016 03:52, "John Cenile"  wrote:

> Hi all,
>
> I'm trying to set up a test CloudStack installation, using two very basic
> CentOS 6.8 servers (I previously tried with CentOS 7, but ran into the same
> issue, so now I'm trying CentOS 6).
>
> Basically I can get (almost) everything working, except for the *Add
> host* stage,
> where I get the error "Incorrect details for private Nic during
> initialization of ServerResourceBase" in the agent.log.
>
> I haven't edited the agent.properties file manually at all, I have followed
> the KVM agent configuration guide
>  9/hypervisor/kvm.html>
> perfectly as far as I can tell, as well as the Management Node
> configuration guide
>  9/management-server/index.html>
> .
>
> I have cloudbr0 and cloudbr1 bridge interfaces set up, as well as eth0
> which is the actual IP I'm connecting to.
>
> The only other thread I can find where someone had this issue, they ended
> up downgrading the agent, does that mean this is a known issue with 4.9? (
> https://www.mail-archive.com/users@cloudstack.apache.org/msg20717.html)
>
> Does anyone have any idea why I'm getting these errors? If there's any
> other logs / config files you need, please let me know.
>
> Thanks in advance.
>
> *Cloudstack Management: *4.9.0.1.el6
>
> *Cloudstack Agent:* 4.9.0.1.el6
>
> *Agent logs*
>
> [root@node1 ~]# tail -n 15 /var/log/cloudstack/agent/agent.log
> 2016-08-29 17:18:08,572 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: host
> 2016-08-29 17:18:08,572 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Defaulting to using properties file for storage
> 2016-08-29 17:18:08,574 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Defaulting to the constant time backoff algorithm
> 2016-08-29 17:18:08,591 INFO  [cloud.utils.LogUtils] (main:null) (logid:)
> log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml
> 2016-08-29 17:18:08,606 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Using default Java settings for IPv6 preference for agent connection
> 2016-08-29 17:18:08,607 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Checking to see if agent.pid exists.
> 2016-08-29 17:18:08,615 DEBUG [cloud.utils.ProcessUtil] (main:null)
> (logid:) Executing: bash -c echo $PPID
> 2016-08-29 17:18:08,620 DEBUG [cloud.utils.ProcessUtil] (main:null)
> (logid:) Execution is successful.
> 2016-08-29 17:18:08,670 INFO  [cloud.agent.Agent] (main:null) (logid:) id
> is
> 2016-08-29 17:18:08,670 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: cloudbr0
> 2016-08-29 17:18:08,673 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: cloudbr0
> 2016-08-29 17:18:08,674 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-29 17:18:08,674 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-29 17:18:08,676 WARN  [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Incorrect details for private Nic during
> initialization of ServerResourceBase
> 2016-08-29 17:18:08,677 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
> Unable to start agent: Unable to configure LibvirtComputingResource
>
>
> Agent properties
>
> [root@node1 ~]# cat /etc/cloudstack/agent/agent.properties | sed -e
> '/^#/d'
> | sed -e '/^$/d'
> guid=b02788c7-20fc-30cd-a391-f2abaf002019
> resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource
> workers=5
> host=10.1.1.1
> port=8250
> cluster=1
> pod=1
> zone=1
> local.storage.uuid=525850bd-64fa-4eba-89e1-c0af4fb49621
> domr.scripts.dir=scripts/network/domr/kvm
> hypervisor.type=kvm
> private.network.device=cloudbr0
> public.network.device=cloudbr0
> guest.network.device=cloudbr0
>
>
> *Master ifconfig output*
>
> [root@master ~]# ifconfig
> eth0  Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
>   inet addr:10.1.1.1  Bcast:10.1.1.255 Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:350162 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:135250 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:342643150 (326.7 MiB)  TX bytes:12230569 (11.6 MiB)
>   Interrupt:18 Memory:fbce-fbd0
>
>
> *Agent ifconfig output*
>
> [root@node1 ~]# ifconfig
> cloud0Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
>   inet addr:169.254.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500