cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sateesh Chodapuneedi (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CLOUDSTACK-7151) vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks
Date Tue, 22 Jul 2014 06:19:38 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14069886#comment-14069886
] 

Sateesh Chodapuneedi edited comment on CLOUDSTACK-7151 at 7/22/14 6:17 AM:
---------------------------------------------------------------------------

Commit 7c4831df9292115466fb9e01fcba952a5dad31c changes logic to pick vswitch type from zone
level physical traffic label ignoring the vmware traffic label information persisted per cluster.
This breaks existing functionality to support a choice of vswitch type on cluster basis, which
was introduced in 4.2.
In 4.2, CloudStack allows admins to,
1) Choose zone level vswitch name/type through physical network traffic label.
2) Choose specific cluster level vswitch name/type through optional parameters to addCluster
API and through add cluster wizard UI where user is given a list box to choose type of vSwitch
and name of vSwitch. These details would be persisted to database for further reference while
implementing virtual networks in any of the hosts in that cluster. This option of specific
cluster level choice would help users who have a zone where some legacy clusters were based
on vSwitch and they want to move to advance switch options for their guest/public traffic
like vmware dvSwitch or Cisco Nexus 1000v for their remaining clusters. This option also protects
existing virtual network implemented on a particular type of vswitch from modification of
physical network traffic label to accommodate/flip to other type of vswitch if user want to
move to another type of vswitch in this zone.

Due to changes done in 4.3 (7c4831df9292115466fb9e01fcba952a5dad31c ) existing customers who
have chosen option (2) above in 4.2 deployment and upgraded to 4.3 will see this bug. Because
in 4.2 CloudStack honours the cluster level vswitch type/name settings but in 4.3 we defaulted
only to zone level physical network traffic label unless the zone level traffic label itself
is defined.




was (Author: sateeshc):
Commit 7c4831df9292115466fb9e01fcba952a5dad31c changes logic to pick vswitch type from zone
level physical traffic label ignoring the vmware traffic label information persisted per cluster.
This breaks existing functionality to support a choice of vswitch type on cluster basis, which
was introduced in 4.2.
In 4.2, CloudStack allows admins to,
1) Choose zone level vswitch name/type through physical network traffic label.
2) Choose specific cluster level vswitch name/type through optional parameters to addCluster
API and through add cluster wizard UI where user is given a list box to choose type of vSwitch
and name of vSwitch. These details would be persisted to database for further reference while
implementing virtual networks in any of the hosts in that cluster. This option of specific
cluster level choice would help users who have a zone where some legacy clusters were based
on vSwitch and they want to move to advance switch options for their guest/public traffic
like vmware dvSwitch or Cisco Nexus 1000v for their remaining clusters. This option also protects
existing virtual network implemented on a particular type of vswitch from modification of
physical network traffic label to accommodate/flip to other type of vswitch if user want to
move to another type of vswitch in this zone.

Due to changes done in 4.3 () existing customers who have chosen option (2) above will see
this bug. Because in 4.2 CloudStack honours the cluster level vswitch type/name settings but
in 4.3 we defaulted only to zone level physical network traffic label unless the zone level
traffic label itself is defined.



> vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual
networks
> ------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-7151
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7151
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: VMware
>    Affects Versions: 4.3.0, 4.3.1
>         Environment: VMware ESXi 5.0
> ACS 4.3.0
>            Reporter: Sateesh Chodapuneedi
>            Assignee: Sateesh Chodapuneedi
>            Priority: Blocker
>             Fix For: 4.5.0
>
>
> After upgrade to 4.3.0 from 4.2.0 system vms are not able to start.
> 2014-07-18 07:14:16,732 INFO [c.c.h.v.r.VmwareResource] (DirectAgent-348:ctx-7cf2f084
brvmc01-host01-vmw.vcore.host.net) Prepare network on vmwaresvs Public_Guest_Net with name
prefix: cloud.public
>  2014-07-18 07:14:16,778 ERROR [c.c.h.v.m.HypervisorHostHelper] (DirectAgent-348:ctx-7cf2f084
brvmc01-host01-vmw.vcore.host.net) Unable to find vSwitchPublic_Guest_Net
>  2014-07-18 07:14:16,778 WARN [c.c.h.v.r.VmwareResource] (DirectAgent-348:ctx-7cf2f084
brvmc01-host01-vmw.vcore.host.net) StartCommand failed due to Exception: java.lang.Exception
>  Message: Unable to find vSwitchPublic_Guest_Net



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message