CLOUDSTACK-8956: NSX/Nicira Plugin does not support NSX v4.2.1JIRA Ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-8956
### Description of the problem:
Prior to version 4.2. Nicira/VmWare NSX used a variation of Open vSwitch as means of integrating SDN into hypervisor layer. Cloudstack NiciraNVP plugin was written to support OVS as a bridge to NSX.
In version 4.2 VMware introduced NSX vSwitch as a replacement for OVS in ESX hypervisors. It is a fork of distributed vSwitch leveraging one of the recent features of ESX called opaque networks. Because of that change the current version of NiciraNVP plugin doesnt support versions of NSX-MH above 4.2 specifically in Vsphere environment. Proposed fix will analyze a version of NVP/NSX API and use proper support for ESX hypervisors.
vSphere hypervisor mode operations when NV is deployed onto NSX managed network changes:
* Current mode. A portgroup = UUID of CS VM NIC is created on a local standard switch of the Hypervisor where VM is starting. VM nic is attached to that port group.
* New mode. No additional port group is created on a HW. No port group cleanup is needed after VM/NIC is destroyed. VM is attached to 1st port group having the following attributes:
** opaqueNetworkId string "br-int
** opaqueNetworkType string "nsx.network"
If portgroup with such attributes is not found a deployment should fail with exception.
### VMware vSphere API version from 5.1 to 5.5:
Since vSphere API version 5.5, [OpaqueNetworks](https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.OpaqueNetwork.html) are introduced.
Its description says:
> This interface defines an opaque network, in the sense that the detail and configuration of the network is unknown to vShpere and is managed by a management plane outside of vSphere. However, the identifier and name of these networks is made available to vSphere so that host and virtual machine virtual ethernet device can connect to them.
In order to connect a vm's virtual ethernet device to the proper opaque network when deploying a vm into a NSX managed network, we first need to look for a particular opaque network on hosts. This opaque network's id has to be **"br-int"** and its type **"nsx.network"**.
Since vSphere API version 5.5 [HostNetworkInfo](https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.host.NetworkInfo.html#opaqueNetwork) introduces a list of available opaque networks for each host.
If NSX API version >= 4.2 we look for a [OpaqueNetworkInfo](https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.host.OpaqueNetworkInfo.html) which satisfies:
* opaqueNetworkId = "br-int"
* opaqueNetworkType = "nsx.netork"
If that opaque network is found, then we need to attach vm's NIC to a virtual ethernet device which support this, so we use [VirtualEthernetCardOpaqueNetworkBackingInfo](https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.vm.device.VirtualEthernetCard.OpaqueNetworkBackingInfo.html) setting:
* opaqueNetworkId = "br-int"
* opaqueNetworkType = "nsx.netork"
* pr/935:
CLOUDSTACK-8956: Remove assert(false) on opaque network and ping method on NiciraNvpApiVersion
CLOUDSTACK-8956: Deploy VM on NSX managed network changes if NSX Api Version >= 4.2: has to connect to "br-int" of "nsx.network" type
CLOUDSTACK-8956: Log NSX Api Version
CLOUDSTACK-8956: Add VMware Api v5.5 and change pom.xml to use VMware Api v5.5
Signed-off-by: Remi Bergsma <github@remi.nl>
CLOUDSTACK-9058 - Respond with "saved_password" if no password is to be issued.The password server on the virtual router should respond with "saved_password" if no password is to be issued. This allows for backwards compatibility with Windows Guest VMs which require the "saved_password" response.
* pr/1079:
CLOUDSTACK-9058
Signed-off-by: Remi Bergsma <github@remi.nl>
Before change:
cloudmonkey> list vlanipranges keyword=118
: Caught: com.mysql.jdbc.JDBC4PreparedStatement@18f36b6e: SELECT vlan.id, vlan.vlan_id, vlan.vlan_gateway, vlan.vlan_netmask, vlan.ip6_gateway, vlan.ip6_cidr, vlan.data_center_id, vlan.description, vlan.ip6_range, vlan.network_id, vlan.physical_network_id, vlan.vlan_type, vlan.uuid, vlan.removed, vlan.created FROM vlan WHERE ( OR vlan.description LIKE ** NOT SPECIFIED ** ) AND vlan.removed IS NULL ORDER BY vlan.id ASC LIMIT 0, 500
After change:
cloudmonkey> list vlanipranges keyword='118'
count = 1
vlaniprange:
id = 0d80fd9c-cd6b-4f99-96c6-261420e75f58
account = system
domain = ROOT
domainid = 2044762d-c4a5-11e3-8379-005056ac4490
......
For setting the width of each data item for each row of Port Forwarding rules, it was processing all rules.
Basically for each data item, it was searching in all rules, which is un-necessary.
If there are N-Rules, It was processing N-times.
Now, it only processes one time by taking all N-rules at a time.
The previous solution was of O(NxN). Now its changed to O(N).
generateRandomPassword() is supposed to create root user passwords.
Right now it is only used on the guest VMs. The format of the passwords
it creates are of the form "random 3-character string with a lowercase
character, uppercase character, and a digit" + random n-character string
with only lowercase characters".
For whatever reason it was that we use generateRandomPassword() for
guest VM root user passwords(maybe more secure?) we should use the same
function for system VM root user passwords.
When rabbitmq connections are blocked(for example when rabbitmq is
server is out of space), all the cloudstack threads which does any
action and publishes to rabbitmq(for example login, launch vm etc.) are
all blocked.
Added a blocked connection listener to handle this and unblock the
parent thread.
throwing error for value < 8 and value > 256
right now, 8, 256 are hardcoded in the code. They should be moved to a
constant and has to be reused everywhere.
* 4.6:
more poms didn't get updated with script
implemented upgrade path from 4.6.0 to 4.6.1
checkstyle pom didn't get updated with script
debian: add 4.6.1-snapshot to changelog
Updating pom.xml version numbers for release 4.6.1-SNAPSHOT
Updating pom.xml version numbers for release 4.6.0
Make master 4.7.0-SNAPSHOT and implement upgrade paths towards itThis bumps all pom.xml versions to 4.7.0-SNAPSHOT. It also implements upgrade paths from 4.6.0 and the upcoming 4.6.1 (branch 4.6 is now on 4.6.1-SNAPSHOT) towards 4.7.0.
I will be doing some upgrade tests, will post back results soon.
* pr/1068:
Add 4.7.0-SNAPSHOT to Debian changelog
implement upgrade paths from 4.6.0/4.6.1 to 4.7.0
Updating pom.xml version numbers for release 4.7.0-SNAPSHOT
Signed-off-by: Remi Bergsma <github@remi.nl>
implement upgrade path from 4.6.0 to 4.6.1The 4.6 branch needs an upgrade path to 4.6.1. I looked at how this was done before and think this will do. Can you give it a second pair of eyes please @DaanHoogland ?
When this is indeed OK, I'll do the same for master for the 4.6.0 -> 4.7.0 path.
I've tried a build and that works: `mvn clean install`
```
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 07:33 min
[INFO] Finished at: 2015-11-15T13:45:58+01:00
[INFO] Final Memory: 120M/1591M
[INFO] ------------------------------------------------------------------------
```
Once this is a PR, I'll try an actual upgrade from 4.6.0 to 4.6.1-SNAPSHOT.
* pr/1067:
implemented upgrade path from 4.6.0 to 4.6.1
Signed-off-by: Remi Bergsma <github@remi.nl>
Wilder Rodrigues
Remi Bergsma
Wei Zhou
Nitin Kumar Maharana
Priti Sarap
Rajani Karuturi
Daan Hoogland
nvazquez
David Amorim Faria
Daan Hoogland