cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CLOUDSTACK-9884) Duplicate of VR after disabling RvR
Date Tue, 08 Aug 2017 06:54:00 GMT

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-9884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Patrick updated CLOUDSTACK-9884:
--------------------------------
    Description: 
Our environment is:
ACS: 4.9.2 (migrated from 4.5.2)
Management Server: CentOS 6.8
Hosts: XenServer 6.5 SP1
System VM: systemvm64template-4.6.0-xen.vhd.bz2
Network: Isolated Network
Network Offering: Offering for Isolated networks with Source Nat service enabled

Issue description:
After the migration to 4.9.2 and the multiple (known) issues with RvR, all networks had their
offerings changed to disable HA and RvR and run networks with a single VR.
Since, the following actions initiate the creation of a "duplicate" second VR, ending in an
UNKNOWN state, and triggering a lot of random network issues.
- New VM instances creation
- Clean restart of the network
Interestingly, when switching between offerings, it also recreates the VR, but it doesn't
do any duplicate this time.

Analysis:
This only impacts networks that were initially set as HA network with RvR before the migration
to 4.9.2. These networks keep the redundant flag to 1 in the networks table, even though the
offering redundant_router_service flag is set to 0. I believe it should be changed to 0 when
the network is using an non-HA offering.

  was:
Our environment is:
ACS: 4.9.2 (migrated from 4.5.2)
Management Server: CentOS 6.8
Hosts: XenServer 6.5 SP1
System VM: systemvm64template-4.6.0-xen.vhd.bz2
Network: Isolated Network
Network Offering: Offering for Isolated networks with Source Nat service enabled

Issue description:
After the migration to 4.9.2 and the multiple (known) issues with RvR, all networks had their
offerings changed to disable HA and RvR and run networks with a single VR.
Since, the following actions initiate the creation of a "duplicate" second VR, ending in an
UNKNOWN state, and triggering a lot of random network issues.
- New VM instances creation
- Clean restart of the network
Interestingly, when switching between offerings, it also recreates the VR, but it doesn't
do any duplicate this time.

Analysis:
This only impacts networks that were initially set as HA network with RvR. These networks
keep the redundant flag to 1 in the networks table, even though the offering redundant_router_service
flag is set to 0. I believe it should be changed to 0 when the network is using an non-HA
offering.


> Duplicate of VR after disabling RvR
> -----------------------------------
>
>                 Key: CLOUDSTACK-9884
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9884
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Virtual Router
>    Affects Versions: 4.9.2.0
>         Environment: CentOS 6.8 + XenServer 6.5
>            Reporter: Patrick
>            Priority: Critical
>
> Our environment is:
> ACS: 4.9.2 (migrated from 4.5.2)
> Management Server: CentOS 6.8
> Hosts: XenServer 6.5 SP1
> System VM: systemvm64template-4.6.0-xen.vhd.bz2
> Network: Isolated Network
> Network Offering: Offering for Isolated networks with Source Nat service enabled
> Issue description:
> After the migration to 4.9.2 and the multiple (known) issues with RvR, all networks had
their offerings changed to disable HA and RvR and run networks with a single VR.
> Since, the following actions initiate the creation of a "duplicate" second VR, ending
in an UNKNOWN state, and triggering a lot of random network issues.
> - New VM instances creation
> - Clean restart of the network
> Interestingly, when switching between offerings, it also recreates the VR, but it doesn't
do any duplicate this time.
> Analysis:
> This only impacts networks that were initially set as HA network with RvR before the
migration to 4.9.2. These networks keep the redundant flag to 1 in the networks table, even
though the offering redundant_router_service flag is set to 0. I believe it should be changed
to 0 when the network is using an non-HA offering.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message