Hi Adam,

As per Nicolas’ comments probably a good idea to increase the verbosity of your 
agent logs and see if anything pops up – also check your normal 
/var/log/messages.

My twopence worth apart from this:
- Your config looks OK.
- Have you made sure LACP is actually up and running on your switch stack? If 
LACP on KVM can’t handshake correctly with the switches I could see you having 
problems.
- What does a “cat /proc/net/bonding/bond0” tell you when the bridge is down?
- Overall I suspect this could also be down to NIC drivers – it may be an idea 
to make sure these are fully up to date.
- If all else fails and you cannot find a resolution you could bodge a 
workaround with libvirt hooks – by putting a script to up all bridges into 
/etc/libvirt/hooks/network – see https://libvirt.org/hooks.html for more info. 
I would use this as your last option though.

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 30/04/2018, 14:13, "Nicolas Bouige" <n.bou...@dimsi.fr> wrote:

    Adam,
    
    
    Yes ;)
    
    Sorry for my misunderstanding, i saw that when i check on my own KVM 
configuration.
    
    
    Do you have any log from KVM agent cloudstack or MGMT ?
    
    Nicolas Bouige
    DIMSI
    cloud.dimsi.fr<http://www.cloud.dimsi.fr>
    4, avenue Laurent Cely
    Tour d’Asnière – 92600 Asnière sur Seine
    T/ +33 (0)6 28 98 53 40
    
    
    
    ________________________________
    De : Adam Witwicki <awitwi...@oakfordis.com>
    Envoyé : lundi 30 avril 2018 14:36
    À : users@cloudstack.apache.org
    Objet : New to Cloudstack - Issues going in to production - Public and 
Guest bridges not up KVM
    
    Hello
    
    I have managed to test Cloudstack in the Lab with very little issues, but 
now going into production (adding Loadbalanced Cloudstack management servers 
and LACP nic bonding) I am having a few issues.
    
    When starting my first instance the network bridges stay down
    
    13: brbond0-999: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 
1000
    
    If I bring this up using ip link set dev brbond0-999 up the bridge comes up 
fine and the systemVMs work.
    
    Any ideas?
    
    Kind Regards
    
    Adam Witwicki
    
    
    Centos 7
    Cloudstack 4.9.3.1
    KVM 3.2.0
    
    /etc/sysconfig/network-scripts/ifcfg-enp4s0f0
    TYPE="Ethernet"
    USERCTL=no
    MASTER=bond0
    SLAVE=yes
    NAME="enp4s0f0"
    UUID="abe1d2f9-253c-4246-a7d6-b7e7e396ce8f"
    DEVICE="enp4s0f0"
    ONBOOT="yes"
    NM_CONTROLLED=no
    BOOTPROTO=none
    
    
    /etc/sysconfig/network-scripts/ifcfg-enp4s0f0
    TYPE=Ethernet
    BOOTPROTO=none
    USERCTL=no
    MASTER=bond0
    SLAVE=yes
    NAME=enp4s0f1
    UUID=f6cec93b-e271-44d4-818b-c94393133d23
    DEVICE=enp4s0f1
    ONBOOT=yes
    NM_CONTROLLED=no
    
    
    /etc/sysconfig/network-scripts/ifcfg-bond0
    DEVICE=bond0
    ONBOOT=yes
    BONDING_OPTS='mode=4 miimon=100'
    BRIDGE=cloudbr0
    NM_CONTROLLED=no
    
    
    /etc/sysconfig/network-scripts/ifcfg-cloudbr0
    DEVICE=cloudbr0
    TYPE=Bridge
    ONBOOT=yes
    BOOTPROTO=static
    IPV6INIT=no
    IPV6_AUTOCONF=no
    DELAY=5
    STP=yes
    IPADDR= x.x.x.x
    GATEWAY= x.x.x.x
    PREFIX=xx
    DNS1= x.x.x.x
    DNS2= x.x.x.x
    
    bridge name     bridge id               STP enabled     interfaces
    brbond0-999             8000.a0369f20953c       no              bond0.999
                                                            vnet4
                                                            vnet5
    cloud0          8000.fe00a9fe0006       no              vnet0
                                                            vnet1
    cloudbr0                8000.a0369f20953c       yes             bond0
                                                            vnet2
                                                            vnet3
    virbr0          8000.525400a48eba       yes             virbr0-nic
    
    
    
    
    
    
    Disclaimer Notice:
    This email has been sent by Oakford Technology Limited, while we have 
checked this e-mail and any attachments for viruses, we can not guarantee that 
they are virus-free. You must therefore take full responsibility for virus 
checking.
    This message and any attachments are confidential and should only be read 
by those to whom they are addressed. If you are not the intended recipient, 
please contact us, delete the message from your computer and destroy any 
copies. Any distribution or copying without our prior permission is prohibited.
    Internet communications are not always secure and therefore Oakford 
Technology Limited does not accept legal responsibility for this message. The 
recipient is responsible for verifying its authenticity before acting on the 
contents. Any views or opinions presented are solely those of the author and do 
not necessarily represent those of Oakford Technology Limited.
    Registered address: Oakford Technology Limited, 10 Prince Maurice Court, 
Devizes, Wiltshire. SN10 2RT.
    Registered in England and Wales No. 5971519
    
    


dag.sonst...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Reply via email to