[
https://issues.apache.org/jira/browse/CLOUDSTACK-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rohit Yadav resolved CLOUDSTACK-591.
------------------------------------
Resolution: Fixed
commit 1ae2d720a3ca3bde2baacb0d06610e7466f95bfe
Author: Bill Rich <[email protected]>
Date: Fri Dec 7 08:39:13 2012 -0800
CLOUDSTACK-591: Changed bridge name parsing in security_group.py to support
bridges named with dashes
commit 6f29317a8492008d37c7eb0770f0cee650c14c40
Author: Rohit Yadav <[email protected]>
Date: Thu Dec 13 15:26:05 2012 -0800
CLOUDSTACK-591: Fix execute and string processing logic for reboot_vm in
security_group
- Since we're always getting the first from the list, use head -1 to get
the first
of the results instead of processing again
- Remove unecessay pop (why was it even there)
Signed-off-by: Rohit Yadav <[email protected]>
> 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
