cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cs user <acldstk...@gmail.com>
Subject Re: Instance reboot issue - CS 4.5.1 - Xen 6.5
Date Wed, 02 Sep 2015 12:03:44 GMT
Hi Folks,

Looks like this is fixed in https://github.com/apache/cloudstack/pull/479 ?

Which cloudstack release contains this fix?

Many thanks!

On Wed, Sep 2, 2015 at 11:16 AM, cs user <acldstkusr@gmail.com> wrote:

> Forwarding to users channel in case anyone else has seen this...
>
>
>
> Hi All,
>
> We have seen this in 2 separate environments, both running the same
> versions of Cloudstack and Xenserver. When we reboot an instance, we lose
> access to it.
>
> Looking at the iptables config on the xen host, we can see that the vif is
> incremented for the bridged entries, but not updated for the rules.
>
> For example, this is how the iptables look before a reboot:
>
> [root@xen001 cloud]# iptables -L|grep 25075
> i-2-25075-def  all  --  anywhere             anywhere             PHYSDEV
> match --physdev-in vif108.0 --physdev-is-bridged
> i-2-25075-def  all  --  anywhere             anywhere             PHYSDEV
> match --physdev-out vif108.0 --physdev-is-bridged
> Chain i-2-25075-VM (1 references)
> Chain i-2-25075-VM-eg (1 references)
> Chain i-2-25075-def (2 references)
> RETURN     udp  --  anywhere             anywhere             PHYSDEV
> match --physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM src
> udp dpt:domain
> DROP       all  --  anywhere             anywhere             PHYSDEV
> match --physdev-in vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM
> src
> DROP       all  --  anywhere             anywhere             PHYSDEV
> match --physdev-out vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM
> dst
> i-2-25075-VM-eg  all  --  anywhere             anywhere
> PHYSDEV match --physdev-in vif108.0 --physdev-is-bridged match-set
> i-2-25075-VM src
> i-2-25075-VM  all  --  anywhere             anywhere             PHYSDEV
> match --physdev-out vif108.0 --physdev-is-bridged
>
> After a reboot, we can see the following:
>
> [root@xen001 cloud]# iptables -L|grep 25075
> i-2-25075-def  all  --  anywhere             anywhere             PHYSDEV
> match --physdev-in vif109.0 --physdev-is-bridged
> i-2-25075-def  all  --  anywhere             anywhere             PHYSDEV
> match --physdev-out vif109.0 --physdev-is-bridged
> Chain i-2-25075-VM (1 references)
> Chain i-2-25075-VM-eg (1 references)
> Chain i-2-25075-def (2 references)
> RETURN     udp  --  anywhere             anywhere             PHYSDEV
> match --physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM src
> udp dpt:domain
> DROP       all  --  anywhere             anywhere             PHYSDEV
> match --physdev-in vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM
> src
> DROP       all  --  anywhere             anywhere             PHYSDEV
> match --physdev-out vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM
> dst
> i-2-25075-VM-eg  all  --  anywhere             anywhere
> PHYSDEV match --physdev-in vif108.0 --physdev-is-bridged match-set
> i-2-25075-VM src
> i-2-25075-VM  all  --  anywhere             anywhere             PHYSDEV
> match --physdev-out vif108.0 --physdev-is-bridged
>
> You can see that the bridged entries have been incremented to vif109,
> where as the rules still reference vif108.
>
> Stopping the instance appears to clear out the rules, and then everything
> works fine again once the instance is started.
>
> Is this a known issue? Is anyone able to replicate this?
>
> Cheers!
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message