[jira] [Comment Edited] (CLOUDSTACK-7151) vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks

["Sateesh Chodapuneedi (JIRA)" <ji...@apache.org>]

    [ 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 8/19/15 5:45 AM:
---------------------------------------------------------------------------

Commit 7c4831df9292115466fb9e01fcba952a5dad31c (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7c4831d) 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 - https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7c4831d) 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 (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.



> 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
>             Fix For: 4.6.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.3.4#6332)