Detail: Accounts can fail in cleanup/gc process due to inconsistent op_networks
table and null pointer in looking up account for event publishing.
BUG-ID: CLOUDSTACK-3957
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1375204815 -0600
sourceNAT service on it
if a portable ip is first IP associated with a non-VPC network, then its
being considered as source nat IP. This fix adds exemption for portable
IP not to be considred for source nat.
Add simultor to the seemingly strict filter which should happen within
the hypervisor resource and not the virtualmachine :/
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
Implement the download url expiration functionality for templates. Also persist the template download urls after their creation
Signed off by : nitin mehta<nitin.mehta@citrix.com>
Marked the system template new system template as dynamicallyScalable
- handled upgrade case
- moved "dynamicallyScalable" flag to vm_instance table from user_vm_details to support dynamic scaling of system vm
Signed off by : Nitin Mehta<nitin.mehta@citrix.com>
CLOUDSTACK-3437 In case of multiple physical network setup we see log message "can't get physical network"
CloudStack's control network is management network in case of VMware.
Processing management VLAN id provided in zone traffic label for management traffic.`
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
Changes:
- ListCapacity API was searching the capacities per zone, pod and cluster causing duplicates to end up in th result.
- Instead we should group by zone if zone and pod both are null. Group by pod if zone is provided but no pod. Or group by cluster when zone and pod both are provided.
This issue is reporducible if user adds a primary storage and quickly fires
listStoragePool API command without waiting for the responce of previous
createStoragePool API command. So during this period
(before receiving createStoragePool API resonce), the primary srorage is in
initialized status and the "scope" of storage is not set.
Some existing scenarios for root and data volume combination was not working. These are
a. Local root + Shared data
b. Shared root + Local data
Enabled these scenarios as part of this fix
Conflicts:
server/src/com/cloud/storage/VolumeManagerImpl.java
Removing memoryovercommitratio and cpuovercommitratio parameters from addCluster and updateCluster APIs,
since these can be configurable using updateConfiguration API at cluster level.
By default while creating cluster these values are taken from global configuration parameters.
Conflicts:
server/src/com/cloud/resource/ResourceManagerImpl.java