Well, I've just found a problem with our modifications, if you migrate an instance, then destroy_rules is called without the vif and our cleanup fails, leaving rules behind.
i.e. VM destroy issues this command and all's good: Executing: /usr/share/cloudstack-common/scripts/vm/network/security_group.py destroy_network_rules_for_vm --vmname i-2-40-VM --vif vnet3 but live migration issues this command: Executing: /usr/share/cloudstack-common/scripts/vm/network/security_group.py destroy_network_rules_for_vm --vmname i-2-40-VM No --vif.. Anyone with python skills can advise on how to get out of this elegantly? -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ----- Original Message ----- > From: "Nux!" <n...@li.nux.ro> > To: dev@cloudstack.apache.org > Sent: Tuesday, 5 April, 2016 08:29:30 > Subject: Re: Hooking into the SecurityGroups > Thanks Jayapal! > > I won't propose this change as a pull request since this is a pretty custom > job. > > Myipset (with a different name) will include all our data centre (AS) subnets, > the end result being that with a simple "iptables-save -c" I can now know what > traffic was done against our data centre as well as global traffic; then with > simple arithmetic I can calculate exactly the amount of traffic done outside > our networks. e.g. > > iptables-save -c |grep -i vnet0 > [542306:28257982] -A BF-breth0-109-IN -m physdev --physdev-in vnet0 > --physdev-is-bridged -m set --match-set myipset dst > [719558:37497155] -A BF-breth0-109-IN -m physdev --physdev-in vnet0 > --physdev-is-bridged -j i-2-38-def > [562386:3982131066] -A BF-breth0-109-OUT -m physdev --physdev-out vnet0 > --physdev-is-bridged -m set --match-set myipset src > [765296:5230761832] -A BF-breth0-109-OUT -m physdev --physdev-out vnet0 > --physdev-is-bridged -j i-2-38-def > ... > > Logging and graphing this is another adventure, but I'm glad I got the > Cloudstack bit done, unless anyone else wants to point to some horrible > mistake. :) > > -- > Sent from the Delta quadrant using Borg technology! > > Nux! > www.nux.ro > > ----- Original Message ----- >> From: "Jayapal Uradi" <jayapal.ur...@accelerite.com> >> To: dev@cloudstack.apache.org >> Sent: Tuesday, 5 April, 2016 06:00:19 >> Subject: Re: Hooking into the SecurityGroups > >> Hi Nux, >> >> I think ipset ‘myipset’ changes might be there in other commits. If you do >> not >> have special requirement then you can use the existing ipset which is with >> the >> vmname ex: i-2-3-VM. Except this it looks good to me. >> >> >> Thanks, >> Jayapal >> >> >>> On 04-Apr-2016, at 10:17 pm, Nux! <n...@li.nux.ro> wrote: >>> >>> Well, this is what we got working in the end. If someone has any >>> suggestions on >>> how to improve it, that'd be great. >>> >>> https://github.com/NuxRo/cloudstack/commit/de6f97367fc2dc02378f367c462eaaec8f92e234 >>> >>> -- >>> Sent from the Delta quadrant using Borg technology! >>> >>> Nux! >>> www.nux.ro >>> >>> ----- Original Message ----- >>>> From: "Nux!" <n...@li.nux.ro> >>>> To: "dev" <dev@cloudstack.apache.org> >>>> Sent: Friday, 1 April, 2016 11:42:10 >>>> Subject: Hooking into the SecurityGroups >>> >>>> Hi, >>>> >>>> I want to hook into the SGs and add a few iptables rules every time a VM is >>>> spawned and delete them when the VM is moved/deleted. >>>> Has anyone done this before? Any pointers before I go and butcher it? :-) >>>> >>>> Lucian >>>> >>>> -- >>>> Sent from the Delta quadrant using Borg technology! >>>> >>>> Nux! >>>> www.nux.ro >> >> >> >> >> DISCLAIMER >> ========== >> This e-mail may contain privileged and confidential information which is the >> property of Accelerite, a Persistent Systems business. It is intended only >> for >> the use of the individual or entity to which it is addressed. If you are not >> the intended recipient, you are not authorized to read, retain, copy, print, >> distribute or use this message. If you have received this communication in >> error, please notify the sender and delete all copies of this message. >> Accelerite, a Persistent Systems business does not accept any liability for > > virus infected mails.
