[
https://issues.apache.org/jira/browse/CLOUDSTACK-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526054#comment-13526054
]
Bill Rich edited comment on CLOUDSTACK-591 at 12/7/12 5:23 PM:
---------------------------------------------------------------
Review Request #8406 has been submitted to address this issue.
was (Author: bill.rich):
I found the solution. My bridge names were being parsed wrong. As soon as
git is back up I will submit the patch.
> Wrong vnet in iptables on KVM hypervisors after VM reboot
> ---------------------------------------------------------
>
> Key: CLOUDSTACK-591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-591
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Hypervisor Controller, KVM
> Affects Versions: pre-4.0.0, 4.0.1, 4.1.0
> Environment: Cloudstack 3.0.5 with KVM hypervisor using basic
> networking with security groups
> libvirt v 0.9.10
> iptables v1.4.7
> Reporter: Bill Rich
> Priority: Minor
>
> Sometimes when a VM is rebooted on KVM, the wrong vnet is listed in the
> iptables rules on the hypervisor.
> For example, iptables and ebtables show that i-3-956 is on vnet3, but it is
> actually using vnet0. Modifying the rules to use the correct interface
> restores network connectivity. This behavior is inconsistent, but triggered
> by issuing a reboot from the OS.
> iptables -L
> Chain BF-br-public-IN (1 references)
> ...
> i-3-956-def all -- anywhere anywhere PHYSDEV match
> --physdev-in vnet3 --physdev-is-bridged
> Chain BF-br-public-OUT (1 references)
> i-3-956-def all -- anywhere anywhere PHYSDEV match
> --physdev-out vnet3 --physdev-is-bridged
> ebtables -t nat -L
> Bridge chain: PREROUTING, entries: 11, policy: ACCEPT
> ...
> -i vnet3 -j i-3-956-VM-in
> Bridge chain: POSTROUTING, entries: 11, policy: ACCEPT
> ...
> -o vnet3 -j i-3-956-VM-out
--
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
