yahoo-eng-team team mailing list archive

[John Garbutt <john@xxxxxxxxxxxxxxx>]

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