You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by "Vladimir Ostrovsky (JIRA)" <ji...@apache.org> on 2012/09/11 16:51:08 UTC
[jira] [Created] (CLOUDSTACK-79) CloudStack 3.0.4: firewall rules
not restored on KVM host
Vladimir Ostrovsky created CLOUDSTACK-79:
--------------------------------------------
Summary: CloudStack 3.0.4: firewall rules not restored on KVM host
Key: CLOUDSTACK-79
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-79
Project: CloudStack
Issue Type: Bug
Components: KVM, Network Controller
Affects Versions: pre-4.0.0
Reporter: Vladimir Ostrovsky
I have CloudStack 3.0.4 with a Basic Zone defined. The Zone includes several KVM hosts and uses Security Groups (in other words, IPtables on the hosts) to isolate traffic between VMs.
The problem: if, for some reason, IPtables on the host are flushed or the iptables service is restarted, the cloud-agent doesn't pull the correct rules from the management server and doesn't synchronize the host with Security Groups definitions in CloudStack. Restart of the cloud-agent service doesn't help as well.
Shouldn't the agent do it?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-79) CloudStack 3.0.4: firewall rules
not restored on KVM host
Posted by "Alex Huang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alex Huang updated CLOUDSTACK-79:
---------------------------------
Fix Version/s: 4.1.0
> CloudStack 3.0.4: firewall rules not restored on KVM host
> ---------------------------------------------------------
>
> Key: CLOUDSTACK-79
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-79
> Project: CloudStack
> Issue Type: Bug
> Components: KVM, Network Controller
> Affects Versions: pre-4.0.0
> Reporter: Vladimir Ostrovsky
> Fix For: 4.1.0
>
>
> I have CloudStack 3.0.4 with a Basic Zone defined. The Zone includes several KVM hosts and uses Security Groups (in other words, IPtables on the hosts) to isolate traffic between VMs.
> The problem: if, for some reason, IPtables on the host are flushed or the iptables service is restarted, the cloud-agent doesn't pull the correct rules from the management server and doesn't synchronize the host with Security Groups definitions in CloudStack. Restart of the cloud-agent service doesn't help as well.
> Shouldn't the agent do it?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-79) CloudStack 3.0.4: firewall rules
not restored on KVM host
Posted by "Vladimir Ostrovsky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453379#comment-13453379 ]
Vladimir Ostrovsky commented on CLOUDSTACK-79:
----------------------------------------------
Thanks, Wido!
Can you please tell me, how to force the cloud-agent to apply rules again? I haven't found such call in API documentation (http://docs.cloudstack.org/CloudStack_Documentation/API_Reference%3A_CloudStack).
> CloudStack 3.0.4: firewall rules not restored on KVM host
> ---------------------------------------------------------
>
> Key: CLOUDSTACK-79
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-79
> Project: CloudStack
> Issue Type: Bug
> Components: KVM, Network Controller
> Affects Versions: pre-4.0.0
> Reporter: Vladimir Ostrovsky
> Fix For: 4.1.0
>
>
> I have CloudStack 3.0.4 with a Basic Zone defined. The Zone includes several KVM hosts and uses Security Groups (in other words, IPtables on the hosts) to isolate traffic between VMs.
> The problem: if, for some reason, IPtables on the host are flushed or the iptables service is restarted, the cloud-agent doesn't pull the correct rules from the management server and doesn't synchronize the host with Security Groups definitions in CloudStack. Restart of the cloud-agent service doesn't help as well.
> Shouldn't the agent do it?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-79) CloudStack 3.0.4: firewall rules
not restored on KVM host
Posted by "David Nalley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453740#comment-13453740 ]
David Nalley commented on CLOUDSTACK-79:
----------------------------------------
So I personally like the idea of:
compare rules against definition - if found to be out of spec, reapply the rules.
But as part of this we'd need to make sure that application of the rules is idempotent, and ideally as minimally disruptive as possible, if we didn't do the above, #1 is the next best IMO (assuming we could mitigate disruption.)
> CloudStack 3.0.4: firewall rules not restored on KVM host
> ---------------------------------------------------------
>
> Key: CLOUDSTACK-79
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-79
> Project: CloudStack
> Issue Type: Bug
> Components: KVM, Network Controller
> Affects Versions: pre-4.0.0
> Reporter: Vladimir Ostrovsky
> Fix For: 4.1.0
>
>
> I have CloudStack 3.0.4 with a Basic Zone defined. The Zone includes several KVM hosts and uses Security Groups (in other words, IPtables on the hosts) to isolate traffic between VMs.
> The problem: if, for some reason, IPtables on the host are flushed or the iptables service is restarted, the cloud-agent doesn't pull the correct rules from the management server and doesn't synchronize the host with Security Groups definitions in CloudStack. Restart of the cloud-agent service doesn't help as well.
> Shouldn't the agent do it?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-79) CloudStack 3.0.4: firewall rules
not restored on KVM host
Posted by "Wido den Hollander (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453429#comment-13453429 ]
Wido den Hollander commented on CLOUDSTACK-79:
----------------------------------------------
Oh, sorry, I didn't make this really clear.
In CS 3.0.2 and the upcoming 4.0 release this isn't possible yet. What you could do is run the security_group.py script by hand with the same parameters as the agent did. You can find this in the agent.log if the loglevel is high enough.
The three options I proposed where actually development options which could be implemented.
> CloudStack 3.0.4: firewall rules not restored on KVM host
> ---------------------------------------------------------
>
> Key: CLOUDSTACK-79
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-79
> Project: CloudStack
> Issue Type: Bug
> Components: KVM, Network Controller
> Affects Versions: pre-4.0.0
> Reporter: Vladimir Ostrovsky
> Fix For: 4.1.0
>
>
> I have CloudStack 3.0.4 with a Basic Zone defined. The Zone includes several KVM hosts and uses Security Groups (in other words, IPtables on the hosts) to isolate traffic between VMs.
> The problem: if, for some reason, IPtables on the host are flushed or the iptables service is restarted, the cloud-agent doesn't pull the correct rules from the management server and doesn't synchronize the host with Security Groups definitions in CloudStack. Restart of the cloud-agent service doesn't help as well.
> Shouldn't the agent do it?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-79) CloudStack 3.0.4: firewall rules
not restored on KVM host
Posted by "Wido den Hollander (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453272#comment-13453272 ]
Wido den Hollander commented on CLOUDSTACK-79:
----------------------------------------------
This is known, the security rules are only applied when a instance is started, but are not checked afterwards.
A couple of approaches can be taken here:
* Have the agent flush all the rules every X minutes/seconds/hours and apply all the rules again.
* Have the agent parse the iptable rules and have it find out which are not applied anymore
* Have a button/API call: "Re-apply rules"
The first one could disrupt traffic for a short moment, probably not desirable.
The second one is however not that easy to implement and could potentially hurt stuff when parsing goes wrong.
I think option 3 is more doable.
> CloudStack 3.0.4: firewall rules not restored on KVM host
> ---------------------------------------------------------
>
> Key: CLOUDSTACK-79
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-79
> Project: CloudStack
> Issue Type: Bug
> Components: KVM, Network Controller
> Affects Versions: pre-4.0.0
> Reporter: Vladimir Ostrovsky
>
> I have CloudStack 3.0.4 with a Basic Zone defined. The Zone includes several KVM hosts and uses Security Groups (in other words, IPtables on the hosts) to isolate traffic between VMs.
> The problem: if, for some reason, IPtables on the host are flushed or the iptables service is restarted, the cloud-agent doesn't pull the correct rules from the management server and doesn't synchronize the host with Security Groups definitions in CloudStack. Restart of the cloud-agent service doesn't help as well.
> Shouldn't the agent do it?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira