I've submitted https://review.openstack.org/642 and https://review.openstack.org/643. The second one of these means that you will need to change /etc/sysconfig/openstack-nova from DEVICE_BRIDGES="eth0:xenbr0 eth1:xenbr1" to INTERFACES="eth0 eth1". Other than that, the intention is that this changes nothing for your use case - I'd appreciate a review just to check that that's the case.
Cheers, Ewan. From: Ewan Mellor Sent: 23 September 2011 14:54 To: 'Antony Messerli' Cc: openstack-xenapi@lists.launchpad.net Subject: RE: [Openstack-xenapi] Multitenancy networking rules Thanks Ant, very useful. So the fact that you use separate NICs for VM traffic and dom0 traffic explains why you don't need the extra rule for dom0. That's obviously not the general case, so I'll submit a patch that allows either. I've also got a couple of cleanups coming. The current scripts assume that VM VIF X corresponds to bridge xenbrX, which is obviously not true in the general case either. There's no need to assume that, it turns out - there's a command to map the VIF back to the bridge that I found out about recently: ovs-vsctl iface-to-br. Using that removes the need to declare the bridges in /etc/sysconfig/openvswitch-nova too. Cheers, Ewan. From: Antony Messerli [mailto:amess...@rackspace.com] Sent: 22 September 2011 21:54 To: Ewan Mellor Cc: openstack-xenapi@lists.launchpad.net Subject: Re: [Openstack-xenapi] Multitenancy networking rules Ewan, We don't utilize eth0 for our dom0 network but instead dedicate eth0 and eth1 for VM networks. We use another interface for Management/dom0. By default they are fully locked down and run networking restrictions as needed. We originally used the vif script but we decided to go down the route of using a udev rule instead to make things cleaner and not have to worry about changes from version to version as we've ran into in the past. The one issue we ran into was how udev/rules.d doesnt have numerical tags on the beginning of the filenames instead running through the scripts alphabetically so we had to ensure the udev rule was at the end of the other xen rules. We try and avoid changing existing files in the XenServer release as much as possible. We've been running these scripts in production so far without any issues. Ant On Sep 22, 2011, at 9:18 PM, Ewan Mellor wrote: Hi, I'd like to get a better understanding of Rackspace's use of the multitenancy network rules in nova's plugins/xenserver/networking directory. At the moment, as far as I can tell, the vSwitch version of the rules are set up to allow no traffic to leave domain 0 at all. This seems pretty extreme. Also, the vSwitch version of rules are hooked off udev at the moment. There's nothing wrong with that per se, but it wouldn't have been my choice. We're already hooking inside /etc/xensource/scripts/vif for the ebtables version of the rules, so I'd have used the same hook point for the vSwitch rules too. It would be a good idea to make sure that there's a guaranteed ordering between the rest of the code in scripts/vif and these rules, and I'm not sure that hooking off udev gives you that guarantee. So my questions are: * Are you using the vSwitch rules in the form that they are upstream in nova? * Is there a reason to hook off udev, or can I move that? * Is the blocking of traffic from dom0 deliberate? If so, I will create a patch that allows you to configure that as an option. Otherwise, I'll relax the rules unconditionally. Thanks, Ewan. _______________________________________________ Mailing list: https://launchpad.net/~openstack-xenapi Post to : openstack-xenapi@lists.launchpad.net<mailto:openstack-xenapi@lists.launchpad.net> Unsubscribe : https://launchpad.net/~openstack-xenapi More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it.
_______________________________________________ Mailing list: https://launchpad.net/~openstack-xenapi Post to : openstack-xenapi@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-xenapi More help : https://help.launchpad.net/ListHelp
