Hi Ozhan,
Thanks for sharing. I traced the change to the following PR that changes the delimiter character to ';' than ":" to support ipv6 addresses: https://github.com/apache/cloudstack/pull/2028/files Can you share with the workaround, if applicable send a pull request? Were you still using old 4.9.3 VRs post upgrade, does killing old 4.9 VRs help fix the issue? /cc Wido - Rohit <https://cloudstack.apache.org> ________________________________ From: Özhan Rüzgar Karaman <oruzgarkara...@gmail.com> Sent: Friday, January 19, 2018 3:38:19 PM To: dev@cloudstack.apache.org Subject: Re: [4.11] KVM Advanced Networking with SG Problem Hi; We solved the bug there and write a small workaround today, the problem is generally from the Java code which calls security_group.py. On 4.9.3 release it was using : character but from 4.11 release delimiter changed to ; character but security_group.py expects : as delimeter so security_group.py could not parse & send rules to the iptables. Afternoon i will create a JIRA ticket and if anyone could fix the delimiter character or code in the Java code for 4.11 release that would be great because without this code Security Groups are not operational for 4.11. Also @Rohit do we need to check test codes for Security Groups? Because i do not understand how this bug passed our testing scenarios. Thanks Özhan On Fri, Jan 19, 2018 at 12:00 PM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Can anyone help look into this issue, reproduce it and if it's a genuine > bug help fix it? > > Any takers - Wido, Wei, Mike and others who may be using KVM+SG? > > > - Rohit > > <https://cloudstack.apache.org> > > > > ________________________________ > From: Özhan Rüzgar Karaman <oruzgarkara...@gmail.com> > Sent: Tuesday, January 16, 2018 9:53:59 PM > To: dev@cloudstack.apache.org > Subject: [4.11] KVM Advanced Networking with SG Problem > > Hi; > We made a test with 4.11 rc over Ubuntu16.04 KVM hosts and we noticed that > there is a problem on setting & applying security group changes on KVM > host. > > All instances could ping vr and they could access internet but no one could > access to the instances. > > I checked iptables rules and i noticed that iptables rules for vm is in all > drop state for incoming packages while i gave access to all ingress and > egress tcp/udp traffic ports for that instances. Below are iptables output > for selected vm: > > Chain i-2-6-VM (1 references) > target prot opt source destination > DROP all -- anywhere anywhere > > Chain i-2-6-VM-eg (1 references) > target prot opt source destination > RETURN all -- anywhere anywhere > > Chain i-2-6-def (2 references) > target prot opt source destination > ACCEPT all -- anywhere anywhere state > RELATED,ESTABLISHED > ACCEPT udp -- anywhere anywhere PHYSDEV match > --physdev-in vnet9 --physdev-is-bridged udp spt:bootpc dpt:bootps > ACCEPT udp -- anywhere anywhere PHYSDEV match > --physdev-out vnet9 --physdev-is-bridged udp spt:bootps dpt:bootpc > DROP all -- anywhere anywhere PHYSDEV match > --physdev-in vnet9 --physdev-is-bridged ! match-set i-2-6-VM src > RETURN udp -- anywhere anywhere PHYSDEV match > --physdev-in vnet9 --physdev-is-bridged match-set i-2-6-VM src udp > dpt:domain > RETURN tcp -- anywhere anywhere PHYSDEV match > --physdev-in vnet9 --physdev-is-bridged match-set i-2-6-VM src tcp > dpt:domain > i-2-6-VM-eg all -- anywhere anywhere PHYSDEV > match --physdev-in vnet9 --physdev-is-bridged match-set i-2-6-VM src > i-2-6-VM all -- anywhere anywhere PHYSDEV match > --physdev-out vnet9 --physdev-is-bridged > > All management and agent logs could be accessed from: > http://51.15.199.7/4.11r1_Test_20190116.tgz > > Thanks > Özhan > > rohit.ya...@shapeblue.com > www.shapeblue.com<http://www.shapeblue.com> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > > rohit.ya...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
