Hi, I am a colleague of Bram working with him on these same systems. We are now experiencing other issues related to networking on our nodes:
- we gave openstack eth0 as the vlan interface - eth0 en eth1 are still slaves in a bond0 (mode 6) ==> we are seeing a big number of dropped packets on the eth1 interface, this under heavy load causing an unstable network on our VMs My guess would be because we are directly using eth0 as vlan interface while it is a slave in a bond is creating these issues. Or should this not create issues? If so while we managed to avoid inter VM communication issues by using eth0 as vlin int. instead of our bond0 (= eth0+eth1) this still leaves the issue of why a bond interface would function as the openstack vlan interface? Regards, Tom Op vrijdag 1 juni 2012, om 15:28 heeft Bram De Wilde het volgende geschreven: > The bond was the culprit! > > As we have been breaking our heads over this for close to 2 days it seems > important enough to report here: > > On our ubuntu 12.04 systems we had 2 bonded interfaces configured with an ip > of 10.0.0.0/24 in an adaptive load balancing mode. We used this mode = 6 type > bonding a bonding is not supported by the switch administrator. This appears > not to be compatible with vlan tagged multi-host networking. @Vish: thanx for > the suggestion, any idea where we would have to post this issue as a bug? I > guess not openstack but rather the ifenslave people? > I would suspect this not to occur with other, switch based bonding modes but > as we have no support for this I am unable to test... > This explained the inter vm communication to be really unreliable an drop out > after a while. Using the eth0 interface instead of the bond0 as the vlan > interface the network now is stable as ever. > > Happy openstack users we will now be configuring our private cloud for stable > operation in our department, thanx all! > > We will be working on a solution for the name resolution in vlan tagged > multi-host configurations, I will keep you posted as we progress. > > Kind regards, > > Bram > > On 1-jun-2012, at 10:02, Vishvananda Ishaya wrote: > > > > > On Jun 1, 2012, at 12:46 AM, Bram De Wilde wrote: > > > > > Thanx Vish, > > > > > > On the name resolution: would you consider this a bug (I can file one if > > > you would like) or a feature? > > > > Bug if it is an easy fix :) > > > > > Could this be fixed by changing the /usr/bin/nova-dhcpbridge script to > > > load all mac, hostname, ip combinations for the database instead of just > > > the physical hosts one? Or would this create other issues? > > > > We would have to do some investigation into special settings. We want to > > make sure that the host doesn't respond to dhcp requests from other hosts. > > If it is possible to set up dnsmasq to do name resolution for the other > > hosts without handing ip addresses then we could do it this way. Someone > > will have to look into it. It might have to be something a little more > > complicated like writing out a hosts file in addition to the dhcp file and > > telling dnsmasq to use it. If you want to investigate the easiest way to > > configure dnsmasq to do this, that would be a big help. > > > > Vish > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] (mailto:[email protected]) > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
