Removing this, it will be revisited with the move from nova-network to
quantum.
** Changed in: nova
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/903282
Title:
Instances spawned on XenServer cannot communicate
Status in OpenStack Compute (Nova):
Won't Fix
Bug description:
I'm not sure whether this is actually a bug in the code or a
misconfiguration in my setup, however I noticed that instances spawned
on XenServer are unable to communicate, even if their VIFs are puggled
into the appropriate XenServer's networks.
In my setup I'm running XenServer 6 with Open vSwitch as the networking
stack.
The nova-network node is running with the Flat network manager.
Instances are being created with a single VIF on a network labelled 'private'
with CIDR 10.0.0.0/24, associated with the xenbr0 bridge.
The output from ovs-ofctl for xenbr0 is reported here:
http://paste.openstack.org/show/3755/
The basic 'drop' action, and the 'normal' action for the traffic on the
physical interface port are correctly configured.
However, there is no trace of the rules for allowing traffic onto VIF ports,
which should be entered by the ovs_confiurre_vif_flows.py script.
From a closer look at this script it seems that there are several issues:
A) Parent bridge is not resolved for VLAN networks (vlans are fake bridges,
and flows should be added to the corresponding 'real' OVS instance). This mean
per-VIF rules cannot be enforced on VLAN bridges.
B) It seems that the script attempts to read the MAC from a xenstore location
different from the one where the MAC is actually storead
C) It seems the script attempts to apply the rules to the first VIF only if
the network is labelled 'public', otherwise it attempts to apply the rules to
the second VIF
D) Among IPv4 rules, a rule for allowing IP broadcasts as well as ARP
broadcasts is currently missing; this will prevent Flat DHCP and VLAN modes to
work properly when these isolation rules are applied.
After trying to fix the above issues in the script, I managed to get the
following entries in the flow table for xenbr0:
http://paste.openstack.org/show/3756/
The VIFs on the instances where deactivated and re-activated to trigger the
modified script. With this modified script the instances were able to
communicate.
I honestly don't know whether there's actually a bug in this script or is
just me negleting something about network configuration.
I'm however attaching a patch file hoping to get some feedback from the
community.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/903282/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
