incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rohit Yadav (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CLOUDSTACK-591) Wrong vnet in iptables on KVM hypervisors after VM reboot
Date Thu, 13 Dec 2012 23:38:12 GMT

     [ 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 <bill.rich@gmail.com>
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 <bhaisaab@apache.org>
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 <bhaisaab@apache.org>
                
> 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

Mime
View raw message