secondaryStorageResource used for SSVM
Issue:
For deploying VMware VMs, cloud service on SSVM needs to be started with
PremiumSecondaryStorageResource, a bunch of VMware related commands rely
on it.
Changes:
1)include cloud-vmware.jar in systemvm.zip
2)start cloud service in SSVM with PremiumSecondaryStorageResource
RB: https://reviews.apache.org/r/6320/
Send-by: mice_xia@tcloudcomputing.com
1) When account/domainId or projectId are passed in:
* list all account specific networks of the account/project
* list all domain level networks from the domainId + subdomains if the targeted network has allowSubdomainAccess = true
In other words, we use all the networks that can be used for vm deployment by account/domainId.
If listAll is not specified in the request, account/domainId are being defaulted to the account/domainId of the caller
listAll is ignored if the call is being done by the regular user.
2) listAll is passed in by the Root admin, we list:
* all Account specific networks in the system
* all domain specific networks in the system
3) listAll is passed by the Domain admin, we list:
* All Account specific networks belonging to domain/subdomains of the domain admin.
* All domain specific networks belonging to domain/subdomains of the domain admin
* All domain specific networks allowing subdomain access belonging to the parent domain.
4) domainId - can be passed either with or without listAll. We list:
* all account specific networks belonging to the domain
* all domain specific networks of the domain
* all domain specific networks of the subdomains if isRecursive = true is passed in
Conflicts:
server/src/com/cloud/network/NetworkManagerImpl.java
If in a section with multiple subsections, show active subsection in
the breadcrumb.
For example, if in storage->snapshots, display 'Storage - Snapshots'
based on the 'title' attribute for the main section and subsetion.
-- Note: this disables the 'fixSize' functionality which resizes long
breadcrumb trails, due to incompatibility with this new feature. It
is going to be reimplemented anyway, as it is fairly glitchy in its
current incarnation.
Since we are using libvirt for handling our storage pools we should rely on that information as well.
Before fetching the capacity we refresh the pool so libvirt has the most up-to-date information.
This is not needed with newly created pools since libvirt does a refresh on creation.
