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.
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.
Support for up to 16 VDIs per VM on XS 6.0 and above (16 VDIs => root + cd + 14 data volumes). Currently in CS number of data disk that can be attached to VM is hard-coded to 6. Made this setting configurable by moving it to hypervisor capabilities. Although XS 6.0 and above supports upto 16 VDIs but while testing on XS 6.0.2 found that only 13 data volumes can be attached to a VM. So for XS 6.0 and 6.0.2 max_data_volumes_limit is set to 13 currently.
Signed-off-by: Koushik Das <Koushik.Das@citrix.com>
