cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Weller <swel...@ena.com>
Subject Re: Incorrect details for private Nic
Date Wed, 07 Sep 2016 13:50:25 GMT
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 <msmart@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: msmart@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 [jcenile1983@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 <sweller@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 [jcenile1983@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]
>> (main:null) (logid:) Retrieving network interface: cloudbr0
>> 2016-08-30 00:07:30,029 DEBUG [cloud.resource.ServerResourceBase]
>> (main:null) (logid:) Retrieving network interface: null
>> 2016-08-30 00:07:30,029 DEBUG [cloud.resource.ServerResourceBase]
>> (main:null) (logid:) Retrieving network interface: null
>> 2016-08-30 00:07:30,031 WARN  [cloud.resource.ServerResourceBase]
>> (main:null) (logid:) Incorrect details for private Nic during
>> initialization of ServerResourceBase
>> 2016-08-30 00:07:30,032 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
>> Unable to start agent: Unable to configure LibvirtComputingResource
>>
>>
>>
>>
>>
>> On 29 August 2016 at 22:47, Simon Weller <sweller@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 [jcenile1983@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 <sweller@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?
>>>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message