Code review comment for lp:~soren/nova/ec2-security-groups

Revision history for this message
Soren Hansen (soren) wrote :

On 25-09-2010 11:34, vishvananda wrote:
> Still not quite there on the security groups. Using your aa-complain fix i still get the following error in lucid:
> libvir: Network Filtererror : internal error Could not get access to ACL tech driver 'ebiptables'
> ERROR:root:instance i-1: Failed to spawn
> Traceback (most recent call last):
> File "/srv/cloud/nova/nova/compute/manager.py", line 91, in run_instance
> yield self.driver.spawn(instance_ref)
> File "/usr/local/lib/python2.6/dist-packages/twisted/internet/defer.py", line 823, in _inlineCallbacks
> result = g.send(result)
> File "/srv/cloud/nova/nova/virt/libvirt_conn.py", line 220, in spawn
> yield self._conn.createXML(xml, 0)
> File "/usr/lib/python2.6/dist-packages/libvirt.py", line 1289, in createXML
> if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
> libvirtError: internal error Could not get access to ACL tech driver 'ebiptables'

Do you have ebtables installed? This corner of libvirt has horrendous
error reporting, unfortunately. You need gawk, ebtables, and iptables
installed. Well, and bash and grep, but I can't imagine you'd be missing
those.

> I tried downloading and installing the maverick dpkg from the nova-repo
> I grabbed libnl, libvirt0 and libvirt-bin and they install and run fine. Now I can actually run machines again, but every time it tries to update the rules on the compute host, I get the following:
> libvir: Network Filtererror : internal error cannot create rule since iptables tool is missing.

Glancing at libvirt's code, that error code means it either failed to
locate iptables in your $PATH, or running "iptables -L FORWARD" failed.
Do you have iptables installed and in the $PATH of the libvirtd process?
(if you're using debian or ubuntu packages, you should be fine). Same

> So apparently, I'm missing the 'iptables tool'. Do i need to upgrade another package to a maverick version that wasn't listed as a depend properly in the dpkg?

Any reasonably recent version of iptables should be fine. Lucid is
definitely reasonably recent.

> Also DHCPackets are not coming through at all.

Yeah. That was the embarassing thing I was talking about on IRC
yesterday :) When I was attempting to get the networking stuff working
and couldn't get DHCP to work I was actually using this branch, and it
turns out it filters dhcp by default. To get DHCP to work, we can either
add a reference to the allow-dhcp or (preferably) allow-dhcp-server
filter for the instance. If the latter, we need to know the IP of the
DHCP server. If we have that, we can just add
<filterref filter="allow-dhcp-server">
  <parameter name="DHCPSERVER" value="<ip of DHCP server>" />
</filterref>

> I'm thinking that it is due to not being able to set up the rules properly, but I'm a bit surprised the dhcpdiscover isn't getting out, since it is udp.

That's an artefact of the no-ip-spoofing filter (part of the
clean-traffic which is included by nova-base-filter), I think. It
refuses traffic from an IP other than the one designated in the libvirt
XML (including DHCP requests that have a NULL IP, IIRC). Adding the
above mentioned allow-dhcp(-server) filter should fix this.

> Any suggestions are most welcome, since we really need to get the security groups tested ASAP.

Luckily, all the things you've identified seem to have rational
explanations. I'll try to address them before you turn up on Monday.
Thanks for your testing! I've only used the FlatManager with injected
network config, so I hadn't spotted the dhcp failure.

--
Soren Hansen
Ubuntu Developer http://www.ubuntu.com/
OpenStack Developer http://www.openstack.org/

« Back to merge proposal