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
357 22182 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
662 38835 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
> > 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 <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?
> > >
> >
>
