[jira] [Commented] (CLOUDSTACK-9732) Update L10N resource files with 4.9 strings from Transifex (20170106)

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880083#comment-15880083
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9732:


Github user milamberspace commented on the issue:

https://github.com/apache/cloudstack/pull/1896
  
@karuturi Since master (4.10) use now JSON files for the localization files 
(and too because on Transifex the localization's resources for each version of 
CS are different), so this PR will be merge only on 4.9.




> Update L10N resource files with 4.9 strings from Transifex (20170106)
> -
>
> Key: CLOUDSTACK-9732
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9732
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.9.0, 4.9.2.0, 4.9.1.0
>Reporter: Milamber
>Priority: Minor
> Fix For: Future
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9783) Improve metrics view performance

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880100#comment-15880100
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9783:


Github user rashmidixit commented on the issue:

https://github.com/apache/cloudstack/pull/1944
  
@rhtyd Will be trying this out today - will post my comments.


> Improve metrics view performance
> 
>
> Key: CLOUDSTACK-9783
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9783
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0, 4.9.3.0
>
>
> Metrics view is a pure frontend feature, where several API calls are made to 
> generate the metrics view tabular data. In very large environments, rendering 
> of these tables can take a lot of time, especially when there is high 
> latency. The improvement task is to reimplement this feature by moving the 
> logic to backend so metrics calculations happen at the backend and final 
> result can be served by a single API request.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9604) Root disk resize support for VMware and XenServer

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880137#comment-15880137
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9604:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/1813
  
@priyankparihar can you take a look on the test failures?


> Root disk resize support for VMware and XenServer
> -
>
> Key: CLOUDSTACK-9604
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9604
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Priyank Parihar
>Assignee: Priyank Parihar
> Attachments: 1.png, 2.png, 3.png
>
>
> Currently the root size of an instance is locked to that of the template. 
> This creates unnecessary template duplicates, prevents the creation of a 
> market place, wastes time and disk space and generally makes work more 
> complicated.
> Real life example - a small VPS provider might want to offer the following 
> sizes (in GB):
> 10,20,40,80,160,240,320,480,620
> That's 9 offerings.
> The template selection could look like this, including real disk space used:
> Windows 2008 ~10GB
> Windows 2008+Plesk ~15GB
> Windows 2008+MSSQL ~15GB
> Windows 2012 ~10GB
> Windows 2012+Plesk ~15GB
> Windows 2012+MSSQL ~15GB
> CentOS ~1GB
> CentOS+CPanel ~3GB
> CentOS+Virtualmin ~3GB
> CentOS+Zimbra ~3GB
> CentOS+Docker ~2GB
> Debian ~1GB
> Ubuntu LTS ~1GB
> In this case the total disk space used by templates will be 828 GB, that's 
> almost 1 TB. If your storage is expensive and limited SSD this can get 
> painful!
> If the root resize feature is enabled we can reduce this to under 100 GB.
> Specifications and Description 
> Administrators don't want to deploy duplicate OS templates of differing 
> sizes just to support different storage packages. Instead, the VM deployment 
> can accept a size for the root disk and adjust the template clone 
> accordingly. In addition, CloudStack already supports data disk resizing for 
> existing volumes, we can extend that functionality to resize existing root 
> disks. 
>   As mentioned, we can leverage the existing design for resizing an existing 
> volume. The difference with root volumes is that we can't resize via disk 
> offering, therefore we need to verify that no disk offering was passed, just 
> a size. The existing enforcements of new size > existing size will still 
> server their purpose.
>For deployment-based resize (ROOT volume size different from template 
> size), we pass the rootdisksize parameter when the existing code allocates 
> the root volume. In the process, we validate that the root disk size is > 
> existing template size, and non-zero. This will persist the root volume as 
> the desired size regardless of whether or not the VM is started on deploy. 
> Then hypervisor specific code needs to be made to pay attention to the 
> VolumeObjectTO's size attribute and use that when doing the work of cloning 
> from template, rather than inheriting the template's size. This can be 
> implemented one hypervisor at a time, and as such there needs to be a check 
> in UserVmManagerImpl to fail unsupported hypervisors with 
> InvalidParameterValueException when the rootdisksize is passed.
>
> Hypervisor specific changes
> XenServer
> Resize ROOT volume is only supported for stopped VMs
> Newly created ROOT volume will be resized after clone from template
> VMware  
> Resize ROOT volume is only supported for stopped VMs.
> New size should be large then the previous size.
> Newly created ROOT volume will be resized after clone from template iff
>  There is no root disk chaining.(means use Full clone)
> And Root Disk controller setting is not  IDE.
> Previously created Root Volume could be resized iif
> There is no root disk chaining.
> And Root Disk controller setting is not  IDE.
> Web Services APIs
> resizeVolume API call will not change, but it will accept volume UUIDs of 
> root volumes in id parameter for resizing.
> deployVirtualMachine API call will allow new rootdisksize parameter to be 
> passed. This parameter will be used as the disk size (in GB) when cloning 
> from template.
> UI
> 1) (refer attached image 1) shows UI that resize volume option is added for 
> ROOT disks.
> 2) (refer attached image 2) when user calls the resize volume on ROOT volume. 
> Here only size option is shown. For DATADISK disk offerings are shown.
> 3) (refer attached image 3) when user deploys VM. New option for Root disk 
> size is added.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8239) Add support for VirtIO-SCSI for KVM hypervisors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880153#comment-15880153
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8239:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/1955
  
@nathanejohnson Thanks, for this good enhancement. Can we have a marvin 
tests that covers the new functionality? 


> Add support for VirtIO-SCSI for KVM hypervisors
> ---
>
> Key: CLOUDSTACK-8239
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8239
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Storage Controller
>Affects Versions: 4.6.0
> Environment: KVM
>Reporter: Andrei Mikhailovsky
>Assignee: Wido den Hollander
>Priority: Critical
>  Labels: ceph, gsoc2017, kvm, libvirt, rbd, storage_drivers, 
> virtio
> Fix For: Future
>
>
> It would be nice to have support for virtio-scsi for KVM hypervisors.
> The reason for using virtio-scsi instead of virtio-blk would be increasing 
> the number of devices you can attach to a vm, have ability to use discard and 
> reclaim unused blocks from the backend storage like ceph rbd. There are also 
> talks about having a greater performance advantage as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9753) Update L10N resource files with 4.10 strings from Transifex (20170121)

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880159#comment-15880159
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9753:


Github user milamberspace commented on the issue:

https://github.com/apache/cloudstack/pull/1914
  
@karuturi This is the PR for update le localization files for CS 4.10. I've 
just updated the PR with the latest translation data from Transifex. Please 
consider to merge this PR before the RC.

cc @rhtyd 


> Update L10N resource files with 4.10 strings from Transifex (20170121)
> --
>
> Key: CLOUDSTACK-9753
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9753
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.10.0.0
>Reporter: Milamber
>Assignee: Milamber
>Priority: Minor
> Fix For: 4.10.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8841) Storage XenMotion from XS 6.2 to XS 6.5 fails.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880167#comment-15880167
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8841:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/815
  
@priyankparihar there are lots of failures on Xen62sp1, can you have a look.


> Storage XenMotion from XS 6.2 to XS 6.5 fails.
> --
>
> Key: CLOUDSTACK-8841
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8841
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Reporter: Priyank Parihar
>Assignee: Priyank Parihar
>
> Storage XenMotion from XS 6.2 to XS 6.5 fails with error.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8841) Storage XenMotion from XS 6.2 to XS 6.5 fails.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880172#comment-15880172
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8841:


Github user abhinandanprateek commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/815#discussion_r102671303
  
--- Diff: server/src/com/cloud/vm/UserVmManagerImpl.java ---
@@ -4717,8 +4717,8 @@ public VirtualMachine 
migrateVirtualMachineWithVolume(Long vmId, Host destinatio
 }
 
 // Check if the source and destination hosts are of the same type 
and support storage motion.
-if 
(!(srcHost.getHypervisorType().equals(destinationHost.getHypervisorType()) && 
srcHost.getHypervisorVersion().equals(destinationHost.getHypervisorVersion( 
{
-throw new CloudRuntimeException("The source and destination 
hosts are not of the same type and version. " + "Source hypervisor type and 
version: "
+if 
(!(srcHost.getHypervisorType().equals(destinationHost.getHypervisorType( {
+throw new CloudRuntimeException("The source and destination 
hosts are not of the same type. " + "Source hypervisor type and version: "
--- End diff --

The Xenserver version on the target host can be same or higher, please see 
if the version check can be further improved.



> Storage XenMotion from XS 6.2 to XS 6.5 fails.
> --
>
> Key: CLOUDSTACK-8841
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8841
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Reporter: Priyank Parihar
>Assignee: Priyank Parihar
>
> Storage XenMotion from XS 6.2 to XS 6.5 fails with error.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-5806) Storage types other than NFS/VMFS can't overprovision

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880171#comment-15880171
 ] 

ASF GitHub Bot commented on CLOUDSTACK-5806:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/1958
  
@abhinandanprateek I think we hit an issue with the test: 

```
  File "/marvin/tests/smoke/test_over_provisioning.py", line 83, in 
test_UpdateStorageOverProvisioningFactor

CloudstackAPIException: Execute cmd: updateconfiguration failed, due to: 
errorCode: 431, errorText:Unable to update  storage pool with id 2. 
Overprovision not supported for NetworkFilesystem
 >> begin captured stdout << -
=== TestName: test_UpdateStorageOverProvisioningFactor | Status : EXCEPTION 
===
```
Reading the code changes looks like over provisioning is not supported for 
NFS, if that's expected we should edit the test I think.


> Storage types other than NFS/VMFS can't overprovision
> -
>
> Key: CLOUDSTACK-5806
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5806
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.2.0, 4.3.0, Future
>Reporter: Marcus Sorensen
>Assignee: edison su
>Priority: Critical
> Fix For: 4.4.0
>
>
> Edison, Mike, or myself can probably fix this. Mgmt server hardcodes storage 
> types that can overprovision. Need to fix this.
> Edison suggests:
> We can move it to storage driver's capabilities method.
> Each storage driver can report its capabilities in DataStoreDriver-> 
> getCapabilities(), which returns a map[String, String], we can change the 
> signature to map[String, Object]
> In CloudStackPrimaryDataStoreDriverImpl(the default storage driver)-> 
> getCapabilities, which can return something like:
> Var comparator = new  storageOverProvision() {
> Public Boolean isOverProvisionSupported(DataStore store) {
>Var storagepool = (PrimaryDataStoreInfo)store;
>If (store.getPoolType() == NFS or VMFS) {
>Return true;
>   }
>  };
> };
> Var caps = new HashMap[String, Object]();
> Caps.put("storageOverProvision", comparator);
> Return caps;
> }
> Whenever, other places in mgt server want to check the capabilities of 
> overprovision, we can do the following:
> Var primaryStore = DataStoreManager. getPrimaryDataStore(primaryStoreId);
> var caps = primaryStore. getDriver().getCapabilities();
> var overprovision = caps.get("storageOverProvision");
> var result = overprovision. isOverProvisionSupported(primaryStore);



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9733) Concurrent volume snapshots of a VM are not allowed and are not limited per host as per the global configuration parameter "concurrent.snapshots.threshold.perhost"

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880173#comment-15880173
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9733:


Github user cloudmonger commented on the issue:

https://github.com/apache/cloudstack/pull/1897
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 381
 Hypervisor xenserver
 NetworkType Advanced
 Passed=104
 Failed=1
 Skipped=7

_Link to logs Folder (search by build_no):_ 
https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0


**Failed tests:**
* test_non_contigiousvlan.py

 * test_extendPhysicalNetworkVlan Failed


**Skipped tests:**
test_01_test_vm_volume_snapshot
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
test_11_ss_nfs_version_on_ssvm
test_nested_virtualization_vmware
test_3d_gpu_support
test_deploy_vgpu_enabled_vm

**Passed test suits:**
test_deploy_vm_with_userdata.py
test_affinity_groups_projects.py
test_portable_publicip.py
test_over_provisioning.py
test_global_settings.py
test_scale_vm.py
test_service_offerings.py
test_routers_iptables_default_policy.py
test_loadbalance.py
test_routers.py
test_reset_vm_on_reboot.py
test_deploy_vms_with_varied_deploymentplanners.py
test_network.py
test_router_dns.py
test_login.py
test_deploy_vm_iso.py
test_list_ids_parameter.py
test_public_ip_range.py
test_multipleips_per_nic.py
test_regions.py
test_affinity_groups.py
test_network_acl.py
test_pvlan.py
test_volumes.py
test_nic.py
test_deploy_vm_root_resize.py
test_resource_detail.py
test_secondary_storage.py
test_vm_life_cycle.py
test_routers_network_ops.py
test_disk_offerings.py


> Concurrent volume snapshots of a VM are not allowed and are not limited per 
> host as per the global configuration parameter 
> "concurrent.snapshots.threshold.perhost".
> 
>
> Key: CLOUDSTACK-9733
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9733
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot, Volumes
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
>
> Pre-CloudStack 4.4.0, before the VM job framework changes (CLOUDSTACK-669), 
> Concurrent volume (both root and data) snapshots were allowed per host based 
> on the value of global config "concurrent.snapshots.threshold.perhost". The 
> volumes could belong to the same VM or spread across multiple VMs on a given 
> host. The synchronisation was done based on the host (Id).
> As part of the VM job framework changes (CLOUDSTACK-669) in CloudStack 4.4.0, 
> a separate job queue was introduced for individual VMs with a concurrency 
> level of 1 (i.e. all operations to a given VM are serialized). Volume 
> snapshot was also considered as a VM operation as part of these changes  and 
> goes through the VM job queue. These changes made the config 
> "concurrent.snapshots.threshold.perhost" obsolete (it was also no longer 
> getting honoured, since there is no single point of enforcement).
> Only one volume snapshot of a VM is allowed at any given point of time as the 
> sync object is the VM (id). So concurrent volume snapshots of a VM are not 
> allowed and are not limited per host as per the global configuration 
> parameter "concurrent.snapshots.threshold.perhost".
> This functionality needs to be re-introduced to execute more than 1 snapshot 
> of a VM at a time (when the underlying hypervisor supports) and snapshots 
> should be limited per host based on the value of 
> "concurrent.snapshots.threshold.perhost" at the cluster level (for more 
> flexibility).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9782) Host HA

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880222#comment-15880222
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9782:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/1960
  
@rhtyd tests looks good, except this one: 
```
ERROR: Tests default ha providers list
--
Traceback (most recent call last):
  File "/marvin/tests/smoke/test_hostha_simulator.py", line 199, in 
test_ha_list_providers
response = self.apiclient.listHostHAProviders(cmd)[0]
TypeError: 'NoneType' object has no attribute '__getitem__'
```
Looks like when simulator is not deployed test would fail. 


> Host HA
> ---
>
> Key: CLOUDSTACK-9782
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9782
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.11.0.0
>
>
> CloudStack lacks a way to reliably fence a host, the idea of the host-ha 
> feature is to provide a general purpose HA framework and implementation 
> specific for hypervisor that can use additional mechanism such as OOBM (ipmi 
> based power management) to reliably investigate, recover and fencing a host. 
> This feature can handle scenarios associated with server crash issues and 
> reliable fencing of hosts and HA of VM.
> FS: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Host+HA



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CLOUDSTACK-9800) Enable inline mode for NetScaler device

[Kishan Kavala (JIRA)]

Kishan Kavala created CLOUDSTACK-9800:
-

 Summary: Enable inline mode for NetScaler device
 Key: CLOUDSTACK-9800
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9800
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Devices
Reporter: Kishan Kavala
Assignee: Kishan Kavala


Only side-by-side mode is enabled for NetScaler devices. NetScaler can work in 
inline mode also along with other Firewall devices



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8239) Add support for VirtIO-SCSI for KVM hypervisors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880253#comment-15880253
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8239:


Github user wido commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1955#discussion_r102687113
  
--- Diff: 
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
 ---
@@ -2158,6 +2166,7 @@ public int compare(final DiskTO arg0, final DiskTO 
arg1) {
 
 if (diskBusType == null) {
 diskBusType = 
getGuestDiskModel(vmSpec.getPlatformEmulator());
+s_logger.debug("disk bus type derived from 
getPlatformEmulator: " + vmSpec.getPlatformEmulator() + ", diskbustype is: 
"+diskBusType.toString());
--- End diff --

Same here, please add the name of the VM


> Add support for VirtIO-SCSI for KVM hypervisors
> ---
>
> Key: CLOUDSTACK-8239
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8239
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Storage Controller
>Affects Versions: 4.6.0
> Environment: KVM
>Reporter: Andrei Mikhailovsky
>Assignee: Wido den Hollander
>Priority: Critical
>  Labels: ceph, gsoc2017, kvm, libvirt, rbd, storage_drivers, 
> virtio
> Fix For: Future
>
>
> It would be nice to have support for virtio-scsi for KVM hypervisors.
> The reason for using virtio-scsi instead of virtio-blk would be increasing 
> the number of devices you can attach to a vm, have ability to use discard and 
> reclaim unused blocks from the backend storage like ceph rbd. There are also 
> talks about having a greater performance advantage as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8239) Add support for VirtIO-SCSI for KVM hypervisors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880251#comment-15880251
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8239:


Github user wido commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1955#discussion_r102687039
  
--- Diff: 
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
 ---
@@ -2059,6 +2060,13 @@ So if getMinSpeed() returns null we fall back to 
getSpeed().
 final InputDef input = new InputDef("tablet", "usb");
 devices.addDevice(input);
 
+// If we're using virtio scsi, then we need to add a virtual scsi 
controller
+if (getGuestDiskModel(vmTO.getPlatformEmulator()) == 
DiskDef.DiskBus.SCSI) {
+final SCSIDef sd = new SCSIDef((short)0, 0, 0, 9, 0);
+devices.addDevice(sd);
+s_logger.debug("Adding scsi definition:\n" + sd.toString());
--- End diff --

Might want to include the name of the VM here as well? And SCSI is written 
in upper-case.


> Add support for VirtIO-SCSI for KVM hypervisors
> ---
>
> Key: CLOUDSTACK-8239
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8239
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Storage Controller
>Affects Versions: 4.6.0
> Environment: KVM
>Reporter: Andrei Mikhailovsky
>Assignee: Wido den Hollander
>Priority: Critical
>  Labels: ceph, gsoc2017, kvm, libvirt, rbd, storage_drivers, 
> virtio
> Fix For: Future
>
>
> It would be nice to have support for virtio-scsi for KVM hypervisors.
> The reason for using virtio-scsi instead of virtio-blk would be increasing 
> the number of devices you can attach to a vm, have ability to use discard and 
> reclaim unused blocks from the backend storage like ceph rbd. There are also 
> talks about having a greater performance advantage as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8239) Add support for VirtIO-SCSI for KVM hypervisors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880252#comment-15880252
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8239:


Github user wido commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1955#discussion_r102687170
  
--- Diff: 
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
 ---
@@ -2216,6 +2225,8 @@ public int compare(final DiskTO arg0, final DiskTO 
arg1) {
 
disk.setCacheMode(DiskDef.DiskCacheMode.valueOf(volumeObjectTO.getCacheMode().toString().toUpperCase()));
 }
 }
+
+s_logger.debug("Adding disk: " + disk.toString());
--- End diff --

Same here, please include the name of the VM

Also, do we really need all these logging lines?


> Add support for VirtIO-SCSI for KVM hypervisors
> ---
>
> Key: CLOUDSTACK-8239
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8239
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Storage Controller
>Affects Versions: 4.6.0
> Environment: KVM
>Reporter: Andrei Mikhailovsky
>Assignee: Wido den Hollander
>Priority: Critical
>  Labels: ceph, gsoc2017, kvm, libvirt, rbd, storage_drivers, 
> virtio
> Fix For: Future
>
>
> It would be nice to have support for virtio-scsi for KVM hypervisors.
> The reason for using virtio-scsi instead of virtio-blk would be increasing 
> the number of devices you can attach to a vm, have ability to use discard and 
> reclaim unused blocks from the backend storage like ceph rbd. There are also 
> talks about having a greater performance advantage as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9800) Enable inline mode for NetScaler device

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880257#comment-15880257
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9800:


GitHub user kishankavala opened a pull request:

https://github.com/apache/cloudstack/pull/1964

Bug-Id: CLOUDSTACK-9800 Enabled netscaler inline mode. Added corresponding 
changes in UI

NetScaler can work in inline mode also along with other Firewall devices. 
Enabled netscaler inline mode capability

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kishankavala/cloudstack CLOUDSTACK-9800

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1964.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1964


commit a0f990a2f270e8af92ed03a624a84e14da0ba4c0
Author: Kishan Kavala 
Date:   2017-02-23T09:53:56Z

Bug-Id: CLOUDSTACK-9800 Enabled netscaler inline mode. Added corrsponding 
changes in UI




> Enable inline mode for NetScaler device
> ---
>
> Key: CLOUDSTACK-9800
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9800
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Reporter: Kishan Kavala
>Assignee: Kishan Kavala
>
> Only side-by-side mode is enabled for NetScaler devices. NetScaler can work 
> in inline mode also along with other Firewall devices



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880259#comment-15880259
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user wido commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1950#discussion_r102688184
  
--- Diff: .gitignore ---
@@ -51,7 +51,6 @@ tools/cli/build/
 *.jar
 *.war
 *.mar
-*.zip
--- End diff --

Why? Are we adding ZIP files to the repo?


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8663) Snapshot Improvements

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880318#comment-15880318
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8663:


Github user koushik-das commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1941#discussion_r102698293
  
--- Diff: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
 ---
@@ -1415,6 +1417,10 @@ public VM createWorkingVM(final Connection conn, 
final String vmName, final Stri
 vbdr.userdevice = "autodetect";
 vbdr.mode = Types.VbdMode.RW;
 vbdr.type = Types.VbdType.DISK;
+Long deviceId = volumeTO.getDeviceId();
+if (deviceId != null && (!isDeviceUsed(conn, vm, deviceId) || 
deviceId > 3)) {
--- End diff --

I remember seeing these changes in another PR, check if that is merged or 
not


> Snapshot Improvements
> -
>
> Key: CLOUDSTACK-8663
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8663
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
> Fix For: Future
>
>
> Split volume snapshot process
> Allow VM snapshot and volume snapshots to exist together



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8663) Snapshot Improvements

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880327#comment-15880327
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8663:


Github user anshul1886 commented on the issue:

https://github.com/apache/cloudstack/pull/1941
  
@koushik-das, That PR is still not merged. @karuturi @rhtyd This PR has 
LGTM now. Can we merge it? 


> Snapshot Improvements
> -
>
> Key: CLOUDSTACK-8663
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8663
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
> Fix For: Future
>
>
> Split volume snapshot process
> Allow VM snapshot and volume snapshots to exist together



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9727) Password reset discrepancy in RVR when one of the Router is not in Running state.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880371#comment-15880371
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9727:


GitHub user bvbharatk opened a pull request:

https://github.com/apache/cloudstack/pull/1965

CLOUDSTACK-9727 Password reset discrepancy in RVR when one of the Rou…

…ter is not in Running state.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bvbharatk/cloudstack CLOUDSTACK-9727

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1965.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1965


commit 7ac5a03bbbda3249700bdb67481fb08f815fe76d
Author: Bharat Kumar 
Date:   2015-12-17T10:49:30Z

CLOUDSTACK-9727 Password reset discrepancy in RVR when one of the Router is 
not in Running state.




> Password reset discrepancy in RVR when one of the Router is not in Running 
> state.
> -
>
> Key: CLOUDSTACK-9727
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9727
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
> Fix For: 4.9.2.0
>
>
> - Deploy an instance and place " cloud-set-guest-password " script in the 
> /etc/init.d location and provide the executable permission.
> - Create a template from the above VM.
> - Create a new network offering with RVR enabled.
> - Deploy a new VM from the above created template and select the above RVR 
> offering.
> - Ensure that the password script is sucessfuly running.
> - Put the backup router in stopped state and ensure only master is running.
> - Now stop the VM and and Reset the password.
> - DO not start the VM , Now Stop the current Master and start the Back up.
> - Now the Back Up would be the Master. Now start the VM.
> Observations:
> - The password is saved onto only Master which is in stopped state now or 
> either in backup if we start it.
> - The current Master which was back up earlier do not have the new password. 
> Hence user cannot now login with the new password.
> - In this scenario there is disperancy in the password stored on both the 
> RVR's.
> The only way to sync both the passwords now is , ensure both the RVR are 
> running and reset the password on VM. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8663) Snapshot Improvements

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880443#comment-15880443
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8663:


Github user GabrielBrascher commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1941#discussion_r102715520
  
--- Diff: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
 ---
@@ -1415,6 +1417,10 @@ public VM createWorkingVM(final Connection conn, 
final String vmName, final Stri
 vbdr.userdevice = "autodetect";
 vbdr.mode = Types.VbdMode.RW;
 vbdr.type = Types.VbdType.DISK;
+Long deviceId = volumeTO.getDeviceId();
+if (deviceId != null && (!isDeviceUsed(conn, vm, deviceId) || 
deviceId > 3)) {
--- End diff --

Is this PR https://github.com/apache/cloudstack/pull/1829 @koushik-das?


> Snapshot Improvements
> -
>
> Key: CLOUDSTACK-8663
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8663
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
> Fix For: Future
>
>
> Split volume snapshot process
> Allow VM snapshot and volume snapshots to exist together



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9727) Password reset discrepancy in RVR when one of the Router is not in Running state.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880447#comment-15880447
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9727:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1965
  
@bvbharatk can you format the code ?


> Password reset discrepancy in RVR when one of the Router is not in Running 
> state.
> -
>
> Key: CLOUDSTACK-9727
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9727
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
> Fix For: 4.9.2.0
>
>
> - Deploy an instance and place " cloud-set-guest-password " script in the 
> /etc/init.d location and provide the executable permission.
> - Create a template from the above VM.
> - Create a new network offering with RVR enabled.
> - Deploy a new VM from the above created template and select the above RVR 
> offering.
> - Ensure that the password script is sucessfuly running.
> - Put the backup router in stopped state and ensure only master is running.
> - Now stop the VM and and Reset the password.
> - DO not start the VM , Now Stop the current Master and start the Back up.
> - Now the Back Up would be the Master. Now start the VM.
> Observations:
> - The password is saved onto only Master which is in stopped state now or 
> either in backup if we start it.
> - The current Master which was back up earlier do not have the new password. 
> Hence user cannot now login with the new password.
> - In this scenario there is disperancy in the password stored on both the 
> RVR's.
> The only way to sync both the passwords now is , ensure both the RVR are 
> running and reset the password on VM. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880450#comment-15880450
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user ustcweizhou commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1950#discussion_r102716218
  
--- Diff: .gitignore ---
@@ -51,7 +51,6 @@ tools/cli/build/
 *.jar
 *.war
 *.mar
-*.zip
--- End diff --

@wido ,yes, ./core/test/resources/vhds/test.vhd.zip for testing.


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8663) Snapshot Improvements

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880480#comment-15880480
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8663:


Github user GabrielBrascher commented on the issue:

https://github.com/apache/cloudstack/pull/1941
  
Thanks @anshul1886. I see that you improved this PR considering the 
comments from the one closed. Some tests failed. Are they false positives? 
Otherwise LGTM. Just need to confirm those failures.


> Snapshot Improvements
> -
>
> Key: CLOUDSTACK-8663
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8663
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
> Fix For: Future
>
>
> Split volume snapshot process
> Allow VM snapshot and volume snapshots to exist together



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9757) VPC traffic from vm to additional public subnet is not working

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880540#comment-15880540
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9757:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1922
  
LGTM as it is same to commit edd839ab10226760749d4fc15703a41eddc1dfdd
not tested yet, as VPC with RVR is working fine, so I assume this fixes the 
issue in VPC with single VR.




> VPC traffic from vm to additional public subnet is not working
> --
>
> Key: CLOUDSTACK-9757
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9757
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> 1. Add additional Public IP to Physical Network (specify a VLAN ID to isolate 
> traffic),
> 2. Create PortForward rule in VPC
> i) Acquire New IP , which used additional Public IP
> ii) Map a VM instance to use this Public IP
> 3. Observe that when VM ping additional public subnet then it is  not working
> For additional public subnet ip SNAT rules are not configured when 
> PF/Staticnat is configured. Due to this PF/StaticNAT VM traffic from to 
> additional public subnet is not SNATed to public ip.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8663) Snapshot Improvements

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880584#comment-15880584
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8663:


Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1941
  
@borisstoyanov @rhtyd Can we re-test this with B.O. ?


> Snapshot Improvements
> -
>
> Key: CLOUDSTACK-8663
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8663
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
> Fix For: Future
>
>
> Split volume snapshot process
> Allow VM snapshot and volume snapshots to exist together



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8663) Snapshot Improvements

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880591#comment-15880591
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8663:


Github user GabrielBrascher commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1941#discussion_r102730127
  
--- Diff: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
 ---
@@ -1415,6 +1417,10 @@ public VM createWorkingVM(final Connection conn, 
final String vmName, final Stri
 vbdr.userdevice = "autodetect";
 vbdr.mode = Types.VbdMode.RW;
 vbdr.type = Types.VbdType.DISK;
+Long deviceId = volumeTO.getDeviceId();
+if (deviceId != null && (!isDeviceUsed(conn, vm, deviceId) || 
deviceId > 3)) {
--- End diff --

There is this one also https://github.com/apache/cloudstack/pull/1829.
However, after sorting out the tests failures and with the code approved I 
don't think that this would be a reason to not take the PR forward.


> Snapshot Improvements
> -
>
> Key: CLOUDSTACK-8663
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8663
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
> Fix For: Future
>
>
> Split volume snapshot process
> Allow VM snapshot and volume snapshots to exist together



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9717) [VMware] RVRs have mismatching MAC addresses for extra public NICs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880596#comment-15880596
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9717:


Github user remibergsma commented on the issue:

https://github.com/apache/cloudstack/pull/1878
  
@sureshanaparti Thanks for the info!


> [VMware] RVRs have mismatching MAC addresses for extra public NICs
> --
>
> Key: CLOUDSTACK-9717
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9717
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller, VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
>
> [CLOUDSTACK-985|https://issues.apache.org/jira/browse/CLOUDSTACK-985] doesn't 
> seem to be completely fixed.
> ISSUE
> ==
> If there are two public networks on two VLANs, and a pair redundant VRs 
> acquire IPs from both, the associated NICs on the redundant VRs will have 
> mismatching MAC addresses.  
> The example below shows the eth2 NICs for the first public network 
> (210.140.168.0/21) have matching MAC addresses (06:c4:b6:00:03:df) as 
> expected, but the eth3 NICs for the second one (210.140.160.0/21) have 
> mismatching MACs (02:00:50:e1:6c:cd versus 02:00:5a:e6:6c:d5).
> *r-43584-VM (Master)*
> 6: eth2:  mtu 1500 qdisc mq state UNKNOWN 
> qlen 1000 
> link/ether 06:c4:b6:00:03:df brd ff:ff:ff:ff:ff:ff 
> inet 210.140.168.42/21 brd 210.140.175.255 scope global eth2 
> inet 210.140.168.20/21 brd 210.140.175.255 scope global secondary eth2 
> 8: eth3:  mtu 1500 qdisc mq state UNKNOWN 
> qlen 1000 
> link/ether 02:00:50:e1:6c:cd brd ff:ff:ff:ff:ff:ff 
> inet 210.140.162.124/21 brd 210.140.167.255 scope global eth3 
> inet 210.140.163.36/21 brd 210.140.167.255 scope global secondary eth3 
> *r-43585-VM (Backup)*
> 6: eth2:  mtu 1500 qdisc noop state DOWN qlen 1000 
> link/ether 06:c4:b6:00:03:df brd ff:ff:ff:ff:ff:ff 
> inet 210.140.168.42/21 brd 210.140.175.255 scope global eth2 
> inet 210.140.168.20/21 brd 210.140.175.255 scope global secondary eth2 
> 8: eth3:  mtu 1500 qdisc noop state DOWN qlen 1000 
> link/ether 02:00:5a:e6:6c:d5 brd ff:ff:ff:ff:ff:ff 
> inet 210.140.162.124/21 brd 210.140.167.255 scope global eth3 
> inet 210.140.163.36/21 brd 210.140.167.255 scope global secondary eth3 
> CloudStack should ensure that the NICs for all public networks have matching 
> MACs.
> REPRO STEPS
> ==
> 1) Set up redundant VR.
> 2) Set up multiple public networks on different VLANs.
> 3) Acquire IPs in the RVR network until the VRs get IPs in the different 
> public networks.
> 4) Confirm the mismatching MAC addresses.
> EXPECTED BEHAVIOR
> ==
> Redundant VRs have matching MACs for all public networks.
> ACTUAL BEHAVIOR
> ==
> Redundant VRs have matching MACs only for the first public network.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9794) Unable to attach more than 14 devices to a VM

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880616#comment-15880616
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9794:


Github user remibergsma commented on the issue:

https://github.com/apache/cloudstack/pull/1953
  
Thanks @sureshanaparti will test it soon! 


> Unable to attach more than 14 devices to a VM
> -
>
> Key: CLOUDSTACK-9794
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9794
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10
>
>
> A limit of 13 disks is set in hypervisor_capabilities for VMware hypervisor. 
> Changed this limit to a higher value in the DB directly for the VMware and 
> tried attaching more than 14 disks. This was failing with the below exception:
> {noformat}
> 2016-08-12 18:42:53,694 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-40:ctx-56068c6b job-1015) (logid:b22938fd) Unexpected 
> exception while executing 
> org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin
> java.util.NoSuchElementException
>   at java.util.ArrayList$Itr.next(ArrayList.java:794)
>   at 
> com.cloud.storage.VolumeApiServiceImpl.getDeviceId(VolumeApiServiceImpl.java:2439)
>   at 
> com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1308)
>   at 
> com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1173)
>   at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>   at 
> org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
> {noformat}
> There was a hardcoded limit of 15 on the number of devices for a VM.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9748) VPN Users search functionality broken

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880636#comment-15880636
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9748:


Github user rafaelweingartner commented on the issue:

https://github.com/apache/cloudstack/pull/1957
  
Actually, my concerns are not regarding the response. Reading the name of 
the method one can for sure understand what it returns. My concern is that 
reading the parameter name `keyword` I really have no clue that this keyword is 
part of a username. The `keyword` could be used to list users of domains that 
may match it; the same can be applied for projects. Did you understand what I 
mean?
I was trying to discuss if we could find a better way to document it. As 
you also checked, there are other methods that this situation happens. However, 
I really do not believe this is a good standard to follow.
Would not something like the following work as well?
```
...
sb.and("id", sb.entity().getId(), SearchCriteria.Op.EQ);
sb.and("state", sb.entity().getState(), Op.IN);
sb.and().op("username", sb.entity().getUsername(), 
SearchCriteria.Op.EQ).or("username", "%" + sb.entity().getUsername() + "%" , 
SearchCriteria.Op.LIKE);
...
```



> VPN Users search functionality broken
> -
>
> Key: CLOUDSTACK-9748
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9748
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Ashadeepa Debnath
>
> VPN Users search functionality broken
> If you try to search VPN users with it’s user name, you will not be able to 
> search.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-5806) Storage types other than NFS/VMFS can't overprovision

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880778#comment-15880778
 ] 

ASF GitHub Bot commented on CLOUDSTACK-5806:


Github user serg38 commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1958#discussion_r102753237
  
--- Diff: server/src/com/cloud/configuration/ConfigurationManagerImpl.java 
---
@@ -508,7 +507,7 @@ public String updateConfiguration(final long userId, 
final String name, final St
 throw new InvalidParameterValueException("unable to 
find storage pool by id " + resourceId);
 }
 
if(name.equals(CapacityManager.StorageOverprovisioningFactor.key())) {
-if(pool.getPoolType() != 
StoragePoolType.NetworkFilesystem && pool.getPoolType() != 
StoragePoolType.VMFS) {
+if(pool.getPoolType().supportsOverProvisioning() ) {
--- End diff --

I believe it should be negated


> Storage types other than NFS/VMFS can't overprovision
> -
>
> Key: CLOUDSTACK-5806
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5806
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.2.0, 4.3.0, Future
>Reporter: Marcus Sorensen
>Assignee: edison su
>Priority: Critical
> Fix For: 4.4.0
>
>
> Edison, Mike, or myself can probably fix this. Mgmt server hardcodes storage 
> types that can overprovision. Need to fix this.
> Edison suggests:
> We can move it to storage driver's capabilities method.
> Each storage driver can report its capabilities in DataStoreDriver-> 
> getCapabilities(), which returns a map[String, String], we can change the 
> signature to map[String, Object]
> In CloudStackPrimaryDataStoreDriverImpl(the default storage driver)-> 
> getCapabilities, which can return something like:
> Var comparator = new  storageOverProvision() {
> Public Boolean isOverProvisionSupported(DataStore store) {
>Var storagepool = (PrimaryDataStoreInfo)store;
>If (store.getPoolType() == NFS or VMFS) {
>Return true;
>   }
>  };
> };
> Var caps = new HashMap[String, Object]();
> Caps.put("storageOverProvision", comparator);
> Return caps;
> }
> Whenever, other places in mgt server want to check the capabilities of 
> overprovision, we can do the following:
> Var primaryStore = DataStoreManager. getPrimaryDataStore(primaryStoreId);
> var caps = primaryStore. getDriver().getCapabilities();
> var overprovision = caps.get("storageOverProvision");
> var result = overprovision. isOverProvisionSupported(primaryStore);



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9764) Delete domain failure due to Account Cleanup task

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880924#comment-15880924
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9764:


Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1935
  
@rafaelweingartner Can you review latest updates from @nvazquez . Since 
tests are passing this PR will be ready for merging to 4.10


> Delete domain failure due to Account Cleanup task
> -
>
> Key: CLOUDSTACK-9764
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9764
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> It was noticed in production environments that {{deleteDomain}} task failed 
> for domains with multiple accounts and resources. Examining logs it was found 
> out that if Account Cleanup Task got executed after domain (and all of its 
> subchilds) got marked as Inactive; and before delete domain task finishes, it 
> produces a failure.
> {{AccountCleanupTask}} gets executed every {{account.cleanup.interval}} 
> seconds looking for:
> * Removed accounts
> * Disabled accounts
> * Inactive domains
> As {{deleteDomain}} marks domain to delete (and its subchilds) as Inactive 
> before deleting them, when {{AccountCleanupTask}} is executed, it removes 
> marked domains. When there are resources to cleanup on domain accounts, 
> domain is not found throwing exception: 
> {{com.cloud.exception.InvalidParameterValueException: Please specify a valid 
> domain ID}}
> h3. Example
> {{account.cleanup.interval}} = 100
> {noformat}
> 2017-01-26 06:07:03,621 DEBUG [cloud.api.ApiServlet] 
> (catalina-exec-8:ctx-50cfa3b6 ctx-92ad5b38) ===END===  10.39.251.17 -- GET  
> command=deleteDomain&id=1910a3dc-6fa6-457b-ab3a-602b0cfb6686&cleanup=true&response=json&_=1485439623475
> ...
> // Domain and its subchilds marked as Inactive
> 2017-01-26 06:07:03,640 DEBUG [cloud.user.DomainManagerImpl] 
> (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Marking domain id=27 
> as Inactive before actually deleting it
> 2017-01-26 06:07:03,646 DEBUG [cloud.user.DomainManagerImpl] 
> (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain 
> id=27
> 2017-01-26 06:07:03,670 DEBUG [cloud.user.DomainManagerImpl] 
> (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain 
> id=28
> 2017-01-26 06:07:03,685 DEBUG [cloud.user.DomainManagerImpl] 
> (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain 
> id=29
> ...
> // AccountCleanupTask removes Inactive domain id=29, no rollback for it
> 2017-01-26 06:07:44,285 INFO  [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Found 0 removed accounts to cleanup
> 2017-01-26 06:07:44,287 INFO  [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Found 0 disabled accounts to cleanup
> 2017-01-26 06:07:44,289 INFO  [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Found 3 inactive domains to cleanup
> 2017-01-26 06:07:44,292 DEBUG [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=27
> 2017-01-26 06:07:44,297 DEBUG [db.Transaction.Transaction] 
> (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = 
>  AccountChecker-1; called by 
> -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62
> 2017-01-26 06:07:44,301 DEBUG [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=28
> 2017-01-26 06:07:44,304 DEBUG [db.Transaction.Transaction] 
> (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = 
>  AccountChecker-1; called by 
> -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62
> 2017-01-26 06:07:44,307 DEBUG [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=29
> 2017-01-26 06:07:44,319 INFO  [cloud.user.AccountManagerImpl] 
> (A

[jira] [Commented] (CLOUDSTACK-9799) Unable to create volume from snapshots with "_" in solidfire

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880940#comment-15880940
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9799:


Github user syed commented on the issue:

https://github.com/apache/cloudstack/pull/1963
  
@mike-tutkowski If you already have this in your PR, I can close this. Let 
me know!


> Unable to create volume from snapshots with "_" in solidfire
> 
>
> Key: CLOUDSTACK-9799
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9799
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Syed Ahmed
>
> Steps to reproduce:
> 1. Create a volume using the SolidFire plugin
> 2. Take a snpshot of the volume
> 3. Create volume from snapshot with "_" in the name
> 4. Error



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9764) Delete domain failure due to Account Cleanup task

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881000#comment-15881000
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9764:


Github user rafaelweingartner commented on the issue:

https://github.com/apache/cloudstack/pull/1935
  
@serg38 I did, the code is great as always. However, I have a concern about 
that `rollBackState` variable being static there. Because the 
`DomainManagerImpl ` is a singleton, using that variable may create problems. 
Instead of using the variable to indicate when the rollback has to be executed, 
we could do the same using an exception (the exception is already thrown when 
the variable is set to `true`).


> Delete domain failure due to Account Cleanup task
> -
>
> Key: CLOUDSTACK-9764
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9764
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> It was noticed in production environments that {{deleteDomain}} task failed 
> for domains with multiple accounts and resources. Examining logs it was found 
> out that if Account Cleanup Task got executed after domain (and all of its 
> subchilds) got marked as Inactive; and before delete domain task finishes, it 
> produces a failure.
> {{AccountCleanupTask}} gets executed every {{account.cleanup.interval}} 
> seconds looking for:
> * Removed accounts
> * Disabled accounts
> * Inactive domains
> As {{deleteDomain}} marks domain to delete (and its subchilds) as Inactive 
> before deleting them, when {{AccountCleanupTask}} is executed, it removes 
> marked domains. When there are resources to cleanup on domain accounts, 
> domain is not found throwing exception: 
> {{com.cloud.exception.InvalidParameterValueException: Please specify a valid 
> domain ID}}
> h3. Example
> {{account.cleanup.interval}} = 100
> {noformat}
> 2017-01-26 06:07:03,621 DEBUG [cloud.api.ApiServlet] 
> (catalina-exec-8:ctx-50cfa3b6 ctx-92ad5b38) ===END===  10.39.251.17 -- GET  
> command=deleteDomain&id=1910a3dc-6fa6-457b-ab3a-602b0cfb6686&cleanup=true&response=json&_=1485439623475
> ...
> // Domain and its subchilds marked as Inactive
> 2017-01-26 06:07:03,640 DEBUG [cloud.user.DomainManagerImpl] 
> (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Marking domain id=27 
> as Inactive before actually deleting it
> 2017-01-26 06:07:03,646 DEBUG [cloud.user.DomainManagerImpl] 
> (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain 
> id=27
> 2017-01-26 06:07:03,670 DEBUG [cloud.user.DomainManagerImpl] 
> (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain 
> id=28
> 2017-01-26 06:07:03,685 DEBUG [cloud.user.DomainManagerImpl] 
> (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain 
> id=29
> ...
> // AccountCleanupTask removes Inactive domain id=29, no rollback for it
> 2017-01-26 06:07:44,285 INFO  [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Found 0 removed accounts to cleanup
> 2017-01-26 06:07:44,287 INFO  [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Found 0 disabled accounts to cleanup
> 2017-01-26 06:07:44,289 INFO  [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Found 3 inactive domains to cleanup
> 2017-01-26 06:07:44,292 DEBUG [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=27
> 2017-01-26 06:07:44,297 DEBUG [db.Transaction.Transaction] 
> (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = 
>  AccountChecker-1; called by 
> -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62
> 2017-01-26 06:07:44,301 DEBUG [cloud.user.AccountManagerImpl] 
> (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=28
> 2017-01-26 06:07:44,304 DEBUG [db.Transaction.Transaction] 
> (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = 
>  AccountChecker-1; called by 
> -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImp

[jira] [Commented] (CLOUDSTACK-9732) Update L10N resource files with 4.9 strings from Transifex (20170106)

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881015#comment-15881015
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9732:


Github user rafaelweingartner commented on the issue:

https://github.com/apache/cloudstack/pull/1896
  
@milamberspace @rhtyd do you know why the entry "label.host.alerts" was 
removed from some languages?


> Update L10N resource files with 4.9 strings from Transifex (20170106)
> -
>
> Key: CLOUDSTACK-9732
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9732
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.9.0, 4.9.2.0, 4.9.1.0
>Reporter: Milamber
>Priority: Minor
> Fix For: Future
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9799) Unable to create volume from snapshots with "_" in solidfire

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881019#comment-15881019
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9799:


Github user mike-tutkowski commented on the issue:

https://github.com/apache/cloudstack/pull/1963
  
Yes, but the PR is scheduled for 4.11.

On Feb 23, 2017, at 10:58 AM, Syed Mushtaq Ahmed 
mailto:notificati...@github.com>> wrote:


@mike-tutkowski If you already have this 
in your PR, I can close this. Let me know!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on 
GitHub, 
or mute the 
thread.



> Unable to create volume from snapshots with "_" in solidfire
> 
>
> Key: CLOUDSTACK-9799
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9799
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Syed Ahmed
>
> Steps to reproduce:
> 1. Create a volume using the SolidFire plugin
> 2. Take a snpshot of the volume
> 3. Create volume from snapshot with "_" in the name
> 4. Error



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9799) Unable to create volume from snapshots with "_" in solidfire

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881053#comment-15881053
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9799:


Github user mike-tutkowski commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1963#discussion_r102793622
  
--- Diff: 
engine/storage/datamotion/src/org/apache/cloudstack/storage/motion/StorageSystemDataMotionStrategy.java
 ---
@@ -711,6 +711,7 @@ private void 
handleCreateVolumeFromSnapshotBothOnStorageSystem(SnapshotInfo snap
 }
 catch (Exception ex) {
 errMsg = ex.getMessage() != null ? ex.getMessage() : "Copy 
operation failed in 
'StorageSystemDataMotionStrategy.handleCreateVolumeFromSnapshotBothOnStorageSystem'";
+copyCmdAnswer = new CopyCmdAnswer(errMsg);
--- End diff --

@syed What I don't have in my version of this fix is this line of code. I 
can add it to mine.


> Unable to create volume from snapshots with "_" in solidfire
> 
>
> Key: CLOUDSTACK-9799
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9799
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Syed Ahmed
>
> Steps to reproduce:
> 1. Create a volume using the SolidFire plugin
> 2. Take a snpshot of the volume
> 3. Create volume from snapshot with "_" in the name
> 4. Error



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9799) Unable to create volume from snapshots with "_" in solidfire

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881090#comment-15881090
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9799:


Github user syed closed the pull request at:

https://github.com/apache/cloudstack/pull/1963


> Unable to create volume from snapshots with "_" in solidfire
> 
>
> Key: CLOUDSTACK-9799
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9799
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Syed Ahmed
>
> Steps to reproduce:
> 1. Create a volume using the SolidFire plugin
> 2. Take a snpshot of the volume
> 3. Create volume from snapshot with "_" in the name
> 4. Error



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9799) Unable to create volume from snapshots with "_" in solidfire

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881089#comment-15881089
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9799:


Github user syed commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1963#discussion_r102798055
  
--- Diff: 
engine/storage/datamotion/src/org/apache/cloudstack/storage/motion/StorageSystemDataMotionStrategy.java
 ---
@@ -711,6 +711,7 @@ private void 
handleCreateVolumeFromSnapshotBothOnStorageSystem(SnapshotInfo snap
 }
 catch (Exception ex) {
 errMsg = ex.getMessage() != null ? ex.getMessage() : "Copy 
operation failed in 
'StorageSystemDataMotionStrategy.handleCreateVolumeFromSnapshotBothOnStorageSystem'";
+copyCmdAnswer = new CopyCmdAnswer(errMsg);
--- End diff --

That would be great @mike-tutkowski. That makes sure that the snapshot goes 
back to a good state if the storage driver operation fails. I will close this 
request then.




> Unable to create volume from snapshots with "_" in solidfire
> 
>
> Key: CLOUDSTACK-9799
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9799
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Syed Ahmed
>
> Steps to reproduce:
> 1. Create a volume using the SolidFire plugin
> 2. Take a snpshot of the volume
> 3. Create volume from snapshot with "_" in the name
> 4. Error



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9732) Update L10N resource files with 4.9 strings from Transifex (20170106)

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881116#comment-15881116
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9732:


Github user milamberspace commented on the issue:

https://github.com/apache/cloudstack/pull/1896
  
@rafaelweingartner It was because the source string (en) has been chenged 
by this PR 1803, so the translations have been deleted by Transifex to invite 
the translator to make the new translation.

https://github.com/apache/cloudstack/pull/1803/files


> Update L10N resource files with 4.9 strings from Transifex (20170106)
> -
>
> Key: CLOUDSTACK-9732
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9732
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.9.0, 4.9.2.0, 4.9.1.0
>Reporter: Milamber
>Priority: Minor
> Fix For: Future
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9732) Update L10N resource files with 4.9 strings from Transifex (20170106)

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881117#comment-15881117
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9732:


Github user rafaelweingartner commented on the issue:

https://github.com/apache/cloudstack/pull/1896
  
Got it, thanks for the explanation. I saw that, and I was wondering if it 
could have been a bug or something else.

LGTM then.



> Update L10N resource files with 4.9 strings from Transifex (20170106)
> -
>
> Key: CLOUDSTACK-9732
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9732
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.9.0, 4.9.2.0, 4.9.1.0
>Reporter: Milamber
>Priority: Minor
> Fix For: Future
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CLOUDSTACK-4164) "Data Disk Offering" should be changed to "Root Disk Offering" (or something) in VM-Creation Wizard when using an ISO

[Mike Tutkowski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Tutkowski resolved CLOUDSTACK-4164.

Resolution: Fixed

> "Data Disk Offering" should be changed to "Root Disk Offering" (or something) 
> in VM-Creation Wizard when using an ISO
> -
>
> Key: CLOUDSTACK-4164
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4164
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: pre-4.0.0, 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0, 
> Future
> Environment: Chrome on Mac OS X
>Reporter: Mike Tutkowski
>Priority: Minor
> Fix For: Future
>
>
> From an e-mail to the CS distribution list:
> Hi,
> I noticed while creating a VM from an ISO today that I am taken to a page in 
> the wizard that talks about a Data Disk Offering.
> It seems a bit confusing to me because I don't actually get a data disk once 
> the wizard has spun up the VM. This Data Disk Offering page is displayed to 
> collect data regarding the size of the root disk the VM will have.
> Any thoughts on this? Is this a known issue or should I log a bug?
> Thanks!
> Reply from Ryan Lei:
> I noticed this issue long ago, and I agree with you.
> In my understanding, while the tab in the VM wizard always says "Data Disk
> Offering," if you create a VM using ISO, this step actually means Root Disk
> Offering.
> If this is the case, the tab name should depend on whether the user chooses
> Select Template (Data Disk Offering) or Select ISO (Root Disk Offering).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (CLOUDSTACK-4164) "Data Disk Offering" should be changed to "Root Disk Offering" (or something) in VM-Creation Wizard when using an ISO

[Mike Tutkowski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Tutkowski closed CLOUDSTACK-4164.
--

> "Data Disk Offering" should be changed to "Root Disk Offering" (or something) 
> in VM-Creation Wizard when using an ISO
> -
>
> Key: CLOUDSTACK-4164
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4164
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: pre-4.0.0, 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0, 
> Future
> Environment: Chrome on Mac OS X
>Reporter: Mike Tutkowski
>Priority: Minor
> Fix For: Future
>
>
> From an e-mail to the CS distribution list:
> Hi,
> I noticed while creating a VM from an ISO today that I am taken to a page in 
> the wizard that talks about a Data Disk Offering.
> It seems a bit confusing to me because I don't actually get a data disk once 
> the wizard has spun up the VM. This Data Disk Offering page is displayed to 
> collect data regarding the size of the root disk the VM will have.
> Any thoughts on this? Is this a known issue or should I log a bug?
> Thanks!
> Reply from Ryan Lei:
> I noticed this issue long ago, and I agree with you.
> In my understanding, while the tab in the VM wizard always says "Data Disk
> Offering," if you create a VM using ISO, this step actually means Root Disk
> Offering.
> If this is the case, the tab name should depend on whether the user chooses
> Select Template (Data Disk Offering) or Select ISO (Root Disk Offering).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-4164) "Data Disk Offering" should be changed to "Root Disk Offering" (or something) in VM-Creation Wizard when using an ISO

[Mike Tutkowski (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881143#comment-15881143
 ] 

Mike Tutkowski commented on CLOUDSTACK-4164:


It's possible this has been fixed a while ago. Looking at 4.10 code, the text 
now reads "Disk Offering" (which solves the issue).

> "Data Disk Offering" should be changed to "Root Disk Offering" (or something) 
> in VM-Creation Wizard when using an ISO
> -
>
> Key: CLOUDSTACK-4164
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4164
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: pre-4.0.0, 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0, 
> Future
> Environment: Chrome on Mac OS X
>Reporter: Mike Tutkowski
>Priority: Minor
> Fix For: Future
>
>
> From an e-mail to the CS distribution list:
> Hi,
> I noticed while creating a VM from an ISO today that I am taken to a page in 
> the wizard that talks about a Data Disk Offering.
> It seems a bit confusing to me because I don't actually get a data disk once 
> the wizard has spun up the VM. This Data Disk Offering page is displayed to 
> collect data regarding the size of the root disk the VM will have.
> Any thoughts on this? Is this a known issue or should I log a bug?
> Thanks!
> Reply from Ryan Lei:
> I noticed this issue long ago, and I agree with you.
> In my understanding, while the tab in the VM wizard always says "Data Disk
> Offering," if you create a VM using ISO, this step actually means Root Disk
> Offering.
> If this is the case, the tab name should depend on whether the user chooses
> Select Template (Data Disk Offering) or Select ISO (Root Disk Offering).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9660) NPE while destroying volumes during 1000 VMs deploy and destroy tests

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881401#comment-15881401
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9660:


Github user cloudmonger commented on the issue:

https://github.com/apache/cloudstack/pull/1825
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 384
 Hypervisor xenserver
 NetworkType Advanced
 Passed=105
 Failed=0
 Skipped=7

_Link to logs Folder (search by build_no):_ 
https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0


**Failed tests:**

**Skipped tests:**
test_01_test_vm_volume_snapshot
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
test_11_ss_nfs_version_on_ssvm
test_nested_virtualization_vmware
test_3d_gpu_support
test_deploy_vgpu_enabled_vm

**Passed test suits:**
test_deploy_vm_with_userdata.py
test_affinity_groups_projects.py
test_portable_publicip.py
test_over_provisioning.py
test_global_settings.py
test_scale_vm.py
test_service_offerings.py
test_routers_iptables_default_policy.py
test_loadbalance.py
test_routers.py
test_reset_vm_on_reboot.py
test_deploy_vms_with_varied_deploymentplanners.py
test_network.py
test_router_dns.py
test_non_contigiousvlan.py
test_login.py
test_deploy_vm_iso.py
test_list_ids_parameter.py
test_public_ip_range.py
test_multipleips_per_nic.py
test_regions.py
test_affinity_groups.py
test_network_acl.py
test_pvlan.py
test_volumes.py
test_nic.py
test_deploy_vm_root_resize.py
test_resource_detail.py
test_secondary_storage.py
test_vm_life_cycle.py
test_routers_network_ops.py
test_disk_offerings.py


> NPE while destroying volumes during 1000 VMs deploy and destroy tests
> -
>
> Key: CLOUDSTACK-9660
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9660
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
>Reporter: Koushik Das
>Assignee: Koushik Das
> Fix For: 4.10.0.0
>
>
> Steps:
> 1. Install and configure a zone (advanced or basic).
> 2. Set config storage.cleanup.enabled = true and storage.cleanup.interval = 
> 10 seconds
> 3. Deploy 1000 VMs and then destroy over multiple iterations.
> NPE seen in MS logs while deleting volume:
> 2015-06-18 16:27:47,797 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (UserVm-Scavenger-1:ctx-5ecc886e) (logid:132e3ff8) Cleaning up hypervisor 
> data structures (ex. SRs in XenServer) for managed storage
> 2015-06-18 16:27:47,799 DEBUG [o.a.c.e.o.VolumeOrchestrator] 
> (UserVm-Scavenger-1:ctx-5ecc886e) (logid:132e3ff8) Cleaning storage for vm: 
> 2894
> 2015-06-18 16:27:47,823 INFO [o.a.c.s.v.VolumeServiceImpl] 
> (UserVm-Scavenger-1:ctx-5ecc886e) (logid:132e3ff8) Expunge volume with no 
> data store specified
> 2015-06-18 16:27:47,828 DEBUG [c.c.s.StorageManagerImpl] 
> (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb642325) Storage pool 
> garbage collector found 0 templates to clean up in storage pool: 
> XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0
> 2015-06-18 16:27:47,828 INFO [o.a.c.s.v.VolumeServiceImpl] 
> (UserVm-Scavenger-1:ctx-5ecc886e) (logid:132e3ff8) Volume 2894 is not 
> referred anywhere, remove it from volumes table
> 2015-06-18 16:27:47,829 DEBUG [c.c.s.StorageManagerImpl] 
> (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb642325) Storage pool 
> garbage collector found 0 templates to clean up in storage pool: 
> XenRT-Zone-0-Pod-0-Cluster-1-Primary-Store-0
> 2015-06-18 16:27:47,832 DEBUG [c.c.s.StorageManagerImpl] 
> (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb642325) Secondary storage 
> garbage collector found 0 templates to cleanup on template_store_ref for 
> store: nfs://10.81.56.7/xenrtnfs/1092931-dycPsK
> 2015-06-18 16:27:47,833 DEBUG [c.c.s.StorageManagerImpl] 
> (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb642325) Secondary storage 
> garbage collector found 0 snapshots to cleanup on snapshot_store_ref for 
> store: nfs://10.81.56.7/xenrtnfs/1092931-dycPsK
> 2015-06-18 16:27:47,834 DEBUG [c.c.s.StorageManagerImpl] 
> (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb642325) Secondary storage 
> garbage collector found 0 volumes to cleanup on volume_store_ref for store: 
> nfs://10.81.56.7/xenrtnfs/1092931-dycPsK
> 2015-06-18 16:27:47,842 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (UserVm-Scavenger-1:ctx-5ecc886e) (logid:132e3ff8) Expunged 
> VM[User|i-10-2894-VM]
> 2015-06-18 16:27:47,844 WARN [c.c.s.StorageManagerImpl] 
> (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb6

[jira] [Created] (CLOUDSTACK-9801) IPSec VPN does not work after vRouter reboot or recreate

[Sean Lair (JIRA)]

Sean Lair created CLOUDSTACK-9801:
-

 Summary: IPSec VPN does not work after vRouter reboot or recreate
 Key: CLOUDSTACK-9801
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9801
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Virtual Router
Affects Versions: 4.9.0.1, 4.9.0, 4.9.2.0
 Environment: Tested in XenServer as hypervisor.  With RemoteAccess VPN 
enabled.  Both Remote Access VPN and Site to Site VPN functionality won't work.
Reporter: Sean Lair
Priority: Critical


After a vRouter is recreated (which happens when a reboot via CloudStack UI for 
example) and Remote Access VPN enabled, VPN won't work anymore.  Here is the 
abbreviated output of "ipsec auto -status" while we were having the issue:

root@r-10-VM:~# ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 169.254.1.45
000 interface eth0/eth0 169.254.1.45
000 %myid = (none)

Notice that only eth0 is shown, not the public interface eth1.  Because of that 
ipsec is broken.

However, if we manually stopped and started ipsec, then issued a "ipsec auto 
-status", the abbreviated output would be:

root@r-10-VM:~# ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 169.254.1.45
000 interface eth0/eth0 169.254.1.45
000 interface eth1/eth1 xxx.xxx.xxx.172
000 interface eth1/eth1 xxx.xxx.xxx.172
000 interface eth2/eth2 192.168.1.1
000 interface eth2/eth2 192.168.1.1
000 %myid = (none)

eth1 interface IP is masked, but now ipsec sees all the interfaces and VPN 
works.  

Looks like this bug was introduced by Pull Request #1423

https://github.com/apache/cloudstack/pull/1423

It added code to start ipsec 
(cloudstack/systemvm/patches/debian/config/opt/cloud/bin/configure.py)

if vpnconfig['create']:
logging.debug("Enabling  remote access vpn  on "+ public_ip)
CsHelper.start_if_stopped("ipsec")
self.configure_l2tpIpsec(public_ip, self.dbag[public_ip])


The issue is that if a reboot is issued from the CloudStack UI (as opposed to 
manually by logging into the vRouter), the NICS (except eth0) are not added to 
the VM until the cloud service is running.

Since ipsec was started before the nics were added to the VM and before the 
public IP address is added to the nic, ipsec is not listening on the public IP 
address and all VPNs are broken.

This is not a problem with the Site2Site VPN section of configure.py, because 
that section does not start ipsec if the public IP is not on the system yet...  




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9798) Resizing root disk fails when using SolidFire

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881607#comment-15881607
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9798:


Github user mike-tutkowski commented on the issue:

https://github.com/apache/cloudstack/pull/1962
  
@syed Hey - I was also working on a feature like this, but related to both 
XenServer and VMware (adding in VMware-specific code on the resource side). Do 
you need these changes for 4.10 or can I incorporate what I need from them for 
4.11 into code that I'm building?


> Resizing root disk fails when using SolidFire 
> --
>
> Key: CLOUDSTACK-9798
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9798
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Syed Ahmed
>
> This one is easy to reproduce:
> 1. Create a VM with where the root disk goes to the managed solidfire
> 2. Stop the VM
> 3. Resize the ROOT disk
> 4. Error



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9801) IPSec VPN does not work after vRouter reboot or recreate

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881642#comment-15881642
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9801:


GitHub user Slair1 opened a pull request:

https://github.com/apache/cloudstack/pull/1966

CLOUDSTACK-9801: IPSec VPN does not work after vRouter reboot or recreate

After a vRouter is recreated  (e.g. reboot via CloudStack UI) and Remote 
Access VPN enabled, VPN won't work anymore. Here is the abbreviated output of 
"ipsec auto -status" while we were having the issue:

```
root@r-10-VM:~# ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 169.254.1.45
000 interface eth0/eth0 169.254.1.45
000 %myid = (none)
```

After this commit, the following occurs and VPNs work:
```

root@r-10-VM:~# ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 169.254.1.45
000 interface eth0/eth0 169.254.1.45
000 interface eth1/eth1 xxx.xxx.xxx.172
000 interface eth1/eth1 xxx.xxx.xxx.172
000 interface eth2/eth2 192.168.1.1
000 interface eth2/eth2 192.168.1.1
000 %myid = (none)

```
eth1 interface IP is masked, but now ipsec sees all the interfaces and VPN 
works.

Looks like this bug was introduced by Pull Request #1423

It added code to start ipsec 
(cloudstack/systemvm/patches/debian/config/opt/cloud/bin/configure.py)

```
if vpnconfig['create']:
logging.debug("Enabling remote access vpn on "+ public_ip)
CsHelper.start_if_stopped("ipsec")
```

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Slair1/cloudstack 
CLOUDSTACK-9801--IPSec-VPN-does-not-work-after-vRouter-reboot-or-recreate

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1966.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1966






> IPSec VPN does not work after vRouter reboot or recreate
> 
>
> Key: CLOUDSTACK-9801
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9801
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.0, 4.9.2.0, 4.9.0.1
> Environment: Tested in XenServer as hypervisor.  With RemoteAccess 
> VPN enabled.  Both Remote Access VPN and Site to Site VPN functionality won't 
> work.
>Reporter: Sean Lair
>Priority: Critical
>  Labels: ipsec, virtual-router, vpc, vpn
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> After a vRouter is recreated (which happens when a reboot via CloudStack UI 
> for example) and Remote Access VPN enabled, VPN won't work anymore.  Here is 
> the abbreviated output of "ipsec auto -status" while we were having the issue:
> root@r-10-VM:~# ipsec auto --status
> 000 using kernel interface: netkey
> 000 interface lo/lo 127.0.0.1
> 000 interface lo/lo 127.0.0.1
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth0/eth0 169.254.1.45
> 000 %myid = (none)
> Notice that only eth0 is shown, not the public interface eth1.  Because of 
> that ipsec is broken.
> However, if we manually stopped and started ipsec, then issued a "ipsec auto 
> -status", the abbreviated output would be:
> root@r-10-VM:~# ipsec auto --status
> 000 using kernel interface: netkey
> 000 interface lo/lo 127.0.0.1
> 000 interface lo/lo 127.0.0.1
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth1/eth1 xxx.xxx.xxx.172
> 000 interface eth1/eth1 xxx.xxx.xxx.172
> 000 interface eth2/eth2 192.168.1.1
> 000 interface eth2/eth2 192.168.1.1
> 000 %myid = (none)
> eth1 interface IP is masked, but now ipsec sees all the interfaces and VPN 
> works.  
> Looks like this bug was introduced by Pull Request #1423
> https://github.com/apache/cloudstack/pull/1423
> It added code to start ipsec 
> (cloudstack/systemvm/patches/debian/config/opt/cloud/bin/configure.py)
> if vpnconfig['create']:
> logging.debug("Enabling  remote access vpn  on "+ public_ip)
> CsHelper.start_if_stopped("ipsec")
> self.configure_l2tpIpsec(public_ip, self.dbag[public_ip])
> The issue is that if a reboot is issued from the CloudStack UI (as opposed to 
> manually by logging into the vRouter), the NICS (except eth0) are not added 
> to the VM until the cloud service is ru

[jira] [Commented] (CLOUDSTACK-9801) IPSec VPN does not work after vRouter reboot or recreate

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881766#comment-15881766
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9801:


Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1966
  
I can't see what branch this is opened against on my phone. What version of 
ACS is this opened against and which version do you have a problem in. The 
reason I ask is because #1741 was added in master to upgrade from openswan to 
strongswan. . Thx... 


> IPSec VPN does not work after vRouter reboot or recreate
> 
>
> Key: CLOUDSTACK-9801
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9801
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.0, 4.9.2.0, 4.9.0.1
> Environment: Tested in XenServer as hypervisor.  With RemoteAccess 
> VPN enabled.  Both Remote Access VPN and Site to Site VPN functionality won't 
> work.
>Reporter: Sean Lair
>Priority: Critical
>  Labels: ipsec, virtual-router, vpc, vpn
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> After a vRouter is recreated (which happens when a reboot via CloudStack UI 
> for example) and Remote Access VPN enabled, VPN won't work anymore.  Here is 
> the abbreviated output of "ipsec auto -status" while we were having the issue:
> root@r-10-VM:~# ipsec auto --status
> 000 using kernel interface: netkey
> 000 interface lo/lo 127.0.0.1
> 000 interface lo/lo 127.0.0.1
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth0/eth0 169.254.1.45
> 000 %myid = (none)
> Notice that only eth0 is shown, not the public interface eth1.  Because of 
> that ipsec is broken.
> However, if we manually stopped and started ipsec, then issued a "ipsec auto 
> -status", the abbreviated output would be:
> root@r-10-VM:~# ipsec auto --status
> 000 using kernel interface: netkey
> 000 interface lo/lo 127.0.0.1
> 000 interface lo/lo 127.0.0.1
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth1/eth1 xxx.xxx.xxx.172
> 000 interface eth1/eth1 xxx.xxx.xxx.172
> 000 interface eth2/eth2 192.168.1.1
> 000 interface eth2/eth2 192.168.1.1
> 000 %myid = (none)
> eth1 interface IP is masked, but now ipsec sees all the interfaces and VPN 
> works.  
> Looks like this bug was introduced by Pull Request #1423
> https://github.com/apache/cloudstack/pull/1423
> It added code to start ipsec 
> (cloudstack/systemvm/patches/debian/config/opt/cloud/bin/configure.py)
> if vpnconfig['create']:
> logging.debug("Enabling  remote access vpn  on "+ public_ip)
> CsHelper.start_if_stopped("ipsec")
> self.configure_l2tpIpsec(public_ip, self.dbag[public_ip])
> The issue is that if a reboot is issued from the CloudStack UI (as opposed to 
> manually by logging into the vRouter), the NICS (except eth0) are not added 
> to the VM until the cloud service is running.
> Since ipsec was started before the nics were added to the VM and before the 
> public IP address is added to the nic, ipsec is not listening on the public 
> IP address and all VPNs are broken.
> This is not a problem with the Site2Site VPN section of configure.py, because 
> that section does not start ipsec if the public IP is not on the system 
> yet...  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8239) Add support for VirtIO-SCSI for KVM hypervisors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881772#comment-15881772
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8239:


Github user nathanejohnson commented on the issue:

https://github.com/apache/cloudstack/pull/1955
  
As an update, I'm working on a Marvin test, and I'm also planning to 
address wido's concerns.  Today had many distractions unfortunately.


> Add support for VirtIO-SCSI for KVM hypervisors
> ---
>
> Key: CLOUDSTACK-8239
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8239
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Storage Controller
>Affects Versions: 4.6.0
> Environment: KVM
>Reporter: Andrei Mikhailovsky
>Assignee: Wido den Hollander
>Priority: Critical
>  Labels: ceph, gsoc2017, kvm, libvirt, rbd, storage_drivers, 
> virtio
> Fix For: Future
>
>
> It would be nice to have support for virtio-scsi for KVM hypervisors.
> The reason for using virtio-scsi instead of virtio-blk would be increasing 
> the number of devices you can attach to a vm, have ability to use discard and 
> reclaim unused blocks from the backend storage like ceph rbd. There are also 
> talks about having a greater performance advantage as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CLOUDSTACK-9801) IPSec VPN does not work after vRouter reboot or recreate

[Sean Lair (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean Lair updated CLOUDSTACK-9801:
--

We are running 4.9.2.0, looks like it affects all 4.9.x.x

We haven't tested against 4.10 (strongswan) yet.  But it could be a problem and 
will be worth testing.  If strongswan starts before cloudstack adds the nics to 
the VM it could have same issue.
 
 



> IPSec VPN does not work after vRouter reboot or recreate
> 
>
> Key: CLOUDSTACK-9801
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9801
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.0, 4.9.2.0, 4.9.0.1
> Environment: Tested in XenServer as hypervisor.  With RemoteAccess 
> VPN enabled.  Both Remote Access VPN and Site to Site VPN functionality won't 
> work.
>Reporter: Sean Lair
>Priority: Critical
>  Labels: ipsec, virtual-router, vpc, vpn
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> After a vRouter is recreated (which happens when a reboot via CloudStack UI 
> for example) and Remote Access VPN enabled, VPN won't work anymore.  Here is 
> the abbreviated output of "ipsec auto -status" while we were having the issue:
> root@r-10-VM:~# ipsec auto --status
> 000 using kernel interface: netkey
> 000 interface lo/lo 127.0.0.1
> 000 interface lo/lo 127.0.0.1
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth0/eth0 169.254.1.45
> 000 %myid = (none)
> Notice that only eth0 is shown, not the public interface eth1.  Because of 
> that ipsec is broken.
> However, if we manually stopped and started ipsec, then issued a "ipsec auto 
> -status", the abbreviated output would be:
> root@r-10-VM:~# ipsec auto --status
> 000 using kernel interface: netkey
> 000 interface lo/lo 127.0.0.1
> 000 interface lo/lo 127.0.0.1
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth1/eth1 xxx.xxx.xxx.172
> 000 interface eth1/eth1 xxx.xxx.xxx.172
> 000 interface eth2/eth2 192.168.1.1
> 000 interface eth2/eth2 192.168.1.1
> 000 %myid = (none)
> eth1 interface IP is masked, but now ipsec sees all the interfaces and VPN 
> works.  
> Looks like this bug was introduced by Pull Request #1423
> https://github.com/apache/cloudstack/pull/1423
> It added code to start ipsec 
> (cloudstack/systemvm/patches/debian/config/opt/cloud/bin/configure.py)
> if vpnconfig['create']:
> logging.debug("Enabling  remote access vpn  on "+ public_ip)
> CsHelper.start_if_stopped("ipsec")
> self.configure_l2tpIpsec(public_ip, self.dbag[public_ip])
> The issue is that if a reboot is issued from the CloudStack UI (as opposed to 
> manually by logging into the vRouter), the NICS (except eth0) are not added 
> to the VM until the cloud service is running.
> Since ipsec was started before the nics were added to the VM and before the 
> public IP address is added to the nic, ipsec is not listening on the public 
> IP address and all VPNs are broken.
> This is not a problem with the Site2Site VPN section of configure.py, because 
> that section does not start ipsec if the public IP is not on the system 
> yet...  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8663) Snapshot Improvements

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881885#comment-15881885
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8663:


Github user anshul1886 commented on the issue:

https://github.com/apache/cloudstack/pull/1941
  
@GabrielBrascher, Those tests failure are not related to this PR and seems 
to be failing most of the time and reported as intermittent failures. @rhtyd 
@karuturi  @serg38, We have already run tests twice, Do we still need to re 
run? 


> Snapshot Improvements
> -
>
> Key: CLOUDSTACK-8663
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8663
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
> Fix For: Future
>
>
> Split volume snapshot process
> Allow VM snapshot and volume snapshots to exist together



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9685) [Xen]Delete snapshot on primary when associated volume is deleted

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881921#comment-15881921
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9685:


Github user cloudmonger commented on the issue:

https://github.com/apache/cloudstack/pull/1840
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 385
 Hypervisor xenserver
 NetworkType Advanced
 Passed=105
 Failed=0
 Skipped=7

_Link to logs Folder (search by build_no):_ 
https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0


**Failed tests:**

**Skipped tests:**
test_01_test_vm_volume_snapshot
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
test_11_ss_nfs_version_on_ssvm
test_nested_virtualization_vmware
test_3d_gpu_support
test_deploy_vgpu_enabled_vm

**Passed test suits:**
test_deploy_vm_with_userdata.py
test_affinity_groups_projects.py
test_portable_publicip.py
test_over_provisioning.py
test_global_settings.py
test_scale_vm.py
test_service_offerings.py
test_routers_iptables_default_policy.py
test_loadbalance.py
test_routers.py
test_reset_vm_on_reboot.py
test_deploy_vms_with_varied_deploymentplanners.py
test_network.py
test_router_dns.py
test_non_contigiousvlan.py
test_login.py
test_deploy_vm_iso.py
test_list_ids_parameter.py
test_public_ip_range.py
test_multipleips_per_nic.py
test_regions.py
test_affinity_groups.py
test_network_acl.py
test_pvlan.py
test_volumes.py
test_nic.py
test_deploy_vm_root_resize.py
test_resource_detail.py
test_secondary_storage.py
test_vm_life_cycle.py
test_routers_network_ops.py
test_disk_offerings.py


> [Xen]Delete snapshot on primary when associated volume is deleted
> -
>
> Key: CLOUDSTACK-9685
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9685
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> When we delete volume, we don't delete snapshots associated with it on 
> primary. These snapshot then are never deleted and fill up storage pool.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9608) Errored State and Abandoned state Templates are not displayed on UI

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881943#comment-15881943
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9608:


Github user ramkatru commented on the issue:

https://github.com/apache/cloudstack/pull/1774
  
@priyankparihar please check the test failures.


> Errored State and Abandoned state Templates are not displayed on UI
> ---
>
> Key: CLOUDSTACK-9608
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9608
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Priyank Parihar
>Assignee: Priyank Parihar
>
> Errored and Abandoned Templates should also be displayed on UI so that user 
> has the accessibility to delete the template even before the clean up thread 
> is run.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9733) Concurrent volume snapshots of a VM are not allowed and are not limited per host as per the global configuration parameter "concurrent.snapshots.threshold.perhost"

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881954#comment-15881954
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9733:


Github user sureshanaparti commented on the issue:

https://github.com/apache/cloudstack/pull/1897
  
The failed test cases above are not related to this PR changes.


> Concurrent volume snapshots of a VM are not allowed and are not limited per 
> host as per the global configuration parameter 
> "concurrent.snapshots.threshold.perhost".
> 
>
> Key: CLOUDSTACK-9733
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9733
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot, Volumes
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
>
> Pre-CloudStack 4.4.0, before the VM job framework changes (CLOUDSTACK-669), 
> Concurrent volume (both root and data) snapshots were allowed per host based 
> on the value of global config "concurrent.snapshots.threshold.perhost". The 
> volumes could belong to the same VM or spread across multiple VMs on a given 
> host. The synchronisation was done based on the host (Id).
> As part of the VM job framework changes (CLOUDSTACK-669) in CloudStack 4.4.0, 
> a separate job queue was introduced for individual VMs with a concurrency 
> level of 1 (i.e. all operations to a given VM are serialized). Volume 
> snapshot was also considered as a VM operation as part of these changes  and 
> goes through the VM job queue. These changes made the config 
> "concurrent.snapshots.threshold.perhost" obsolete (it was also no longer 
> getting honoured, since there is no single point of enforcement).
> Only one volume snapshot of a VM is allowed at any given point of time as the 
> sync object is the VM (id). So concurrent volume snapshots of a VM are not 
> allowed and are not limited per host as per the global configuration 
> parameter "concurrent.snapshots.threshold.perhost".
> This functionality needs to be re-introduced to execute more than 1 snapshot 
> of a VM at a time (when the underlying hypervisor supports) and snapshots 
> should be limited per host based on the value of 
> "concurrent.snapshots.threshold.perhost" at the cluster level (for more 
> flexibility).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9720) [VMware] template_spool_ref table is not getting updated with correct template physical size in template_size column.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881969#comment-15881969
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9720:


Github user sureshanaparti commented on the issue:

https://github.com/apache/cloudstack/pull/1880
  
@rhtyd Can you please kick off the tests again.


> [VMware] template_spool_ref table is not getting updated with correct 
> template physical size in template_size column.
> -
>
> Key: CLOUDSTACK-9720
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9720
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Template, VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
>
> CloudStack is not updating template_spool_ref table with correct template 
> physical_size in template_size column which leads to incorrect calculation of 
> allocated primary storage.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9638) Problems caused when inputting double-byte numbers for custom compute offerings

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882008#comment-15882008
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9638:


GitHub user bvbharatk opened a pull request:

https://github.com/apache/cloudstack/pull/1967

CLOUDSTACK-9638 Problems caused when inputting double-byte numbers fo…

…r custom compute offerings

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bvbharatk/cloudstack CLOUDSTACK-9638

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1967.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1967


commit 59312dd976a6fb5e4d5d3a5b701fc1cccac9a3d2
Author: Bharat Kumar 
Date:   2017-01-03T12:25:08Z

CLOUDSTACK-9638 Problems caused when inputting double-byte numbers for 
custom compute offerings




>  Problems caused when inputting double-byte numbers for custom compute 
> offerings
> 
>
> Key: CLOUDSTACK-9638
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9638
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
> Fix For: 4.9.1.0
>
>
> When creating a VM with a custom compute offering, CloudPlatform allows the 
> input of double-byte numbers. The VM will be created but listVirtualMachines 
> will subsequently fail with an exception. The problem seems to be with the 
> value of detail_value for the associated entry in the user_vm_view table. If 
> you manually change it to a regular number the issue is resolved. Double-byte 
> numbers should either be considered invalid for custom offerings and 
> rejected, or listVMs should work when they are used for a VM.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9666) Add configuration validation for the config drive global settings

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882022#comment-15882022
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9666:


GitHub user bvbharatk opened a pull request:

https://github.com/apache/cloudstack/pull/1968

CLOUDSTACK-9666 Added basic configuration validation for the config d…

…rive global settings

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bvbharatk/cloudstack CLOUDSTACK-9666

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1968.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1968


commit 366175b9a5dd3994b2807fcc5aaeed7a22052cae
Author: Bharat Kumar 
Date:   2015-10-06T11:02:58Z

CLOUDSTACK-9666 Added basic configuration validation for the config drive 
global settings




> Add configuration validation for the config drive global settings
> -
>
> Key: CLOUDSTACK-9666
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9666
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
> Fix For: 4.9.2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9667) Enable resourcecount.check.interval by default

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882023#comment-15882023
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9667:


GitHub user bvbharatk opened a pull request:

https://github.com/apache/cloudstack/pull/1969

CLOUDSTACK-9667 Enable resourcecount.check.interval by default



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bvbharatk/cloudstack CLOUDSTACK-9667

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1969.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1969


commit 0ef668b3d2f62bb94ce8ac95b8e315214b506c62
Author: Bharat Kumar 
Date:   2015-10-06T11:00:58Z

CLOUDSTACK-9667 Enable resourcecount.check.interval by default




> Enable resourcecount.check.interval by default
> --
>
> Key: CLOUDSTACK-9667
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9667
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
> Fix For: 4.9.2.0
>
>
> Issue. In cloud stack there is a thread with runs at regular interval and 
> updates the resource count. The interval at with this runs is specified by 
> resourcecount.check.interval global config. This is set to zero by default, 
> which means it will never run and so the count of public Ips is not updated.
> Fix: Made the default value 300 seconds. This will run the resource count 
> update thread thread every 300 seconds by default.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9725) Failed to update VPC Network during N/w offering Upgrade which doesnt have ACL service Enabled. check if acl service provider is configured when network is ass

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882024#comment-15882024
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9725:


GitHub user bvbharatk opened a pull request:

https://github.com/apache/cloudstack/pull/1970

CLOUDSTACK-9725 Failed to update VPC Network during N/w offering Upgr…

…ade which doesnt have ACL service Enabled.

check if acl service provider is configured when network is associated with 
a acl.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bvbharatk/cloudstack CLOUDSTACK-9725

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1970.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1970


commit bbff9f15754c06dc8a7a74fdd34ab7968b052c3f
Author: Bharat Kumar 
Date:   2016-01-05T05:53:49Z

CLOUDSTACK-9725 Failed to update VPC Network during N/w offering Upgrade 
which doesnt have ACL service Enabled.
check if acl service provider is configured when network is associated with 
a acl.




> Failed to update VPC Network during N/w offering Upgrade which doesnt have 
> ACL service Enabled. check if acl service provider is configured when 
> network is associated with a acl.
> --
>
> Key: CLOUDSTACK-9725
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9725
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
> Fix For: 4.9.0
>
>
> - Create a VPC set up with default Offering : " Default VPC offering ".
> - Create a tier T1 with default offering : " Offering for Isolated Vpc 
> networks with Source Nat service enabled".
> - Perform few operation such as Deploy instance , configure Public IP etc.
> - CReate a new VPC network offering (vpc1) which doesnt have ' Network ACL' 
> service enabled.
> - Now try to Update the offering ID of T1 with the new offering (vpc1).
> Observations : 
> - Since this is a network offering degrade ( i.e it doesnt have Network ACL 
> service as compared to the existing default offering ) it throws a status 
> message saying [ "  The new offering:vpc1 will remove the following services 
> [NetworkACL, PortForwarding, StaticNat, UserData, Vpn]along with all the 
> related configuration currently in use. will not proceed with the network 
> update.set forced parameter to true for forcing an update.]
> - after issuing an API with forced parameter set to true following is the 
> exception observed : 
> -  When a tier is created with a VPC network offering which doesnt have ACL 
> service enabled : following error message is observed " Cannot apply 
> NetworkACL. Network Offering does not support NetworkACL service "
> 2016-01-04 16:42:01,140 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-244:ctx-056cc899) (logid:877ad8b1) Seq 6-5478347471719527904: 
> Response Received:
> 2016-01-04 16:42:01,143 DEBUG [c.c.a.t.Request] 
> (DirectAgent-244:ctx-056cc899) (logid:877ad8b1) Seq 6-5478347471719527904: 
> Processing:  { Ans: , MgmtId: 7203499016310, via: 6(10.147.28.36), Ver: v1, 
> Flags: 10, [{"com.cloud.agent.api.Answer":{"result":true,"details":"Command 
> aggregation started","wait":0}}] }
> 2016-01-04 16:42:01,143 DEBUG [c.c.a.t.Request] 
> (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) Seq 
> 6-5478347471719527904: Received:  { Ans: , MgmtId: 7203499016310, via: 
> 6(10.147.28.36), Ver: v1, Flags: 10, { Answer } }
> 2016-01-04 16:42:01,144 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) 
> Reprogramming network Ntwk[222|Guest|20] as a part of network implement
> 2016-01-04 16:42:01,197 DEBUG [c.c.n.f.FirewallManagerImpl] 
> (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) 
> There are no firewall rules to apply
> 2016-01-04 16:42:01,267 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) 
> There are no static nat to apply for network id=222
> 2016-01-04 16:42:01,274 DEBUG [c.c.n.f.FirewallManagerImpl] 
> (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) 
> There are no firewall rules to apply
> 2016-01-04 16:42:01,304 DEBUG [c.c.n.r.RulesManagerImpl] 
> (API-Job-Executor-92:ctx-69f77f83 job-527 ctx-8ba1c852) (logid:877ad8b1) 
> There are no por

[jira] [Commented] (CLOUDSTACK-9726) state of the rvr dose not change to update failed when updating rvrs in sequence to a new offering fails.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882025#comment-15882025
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9726:


GitHub user bvbharatk opened a pull request:

https://github.com/apache/cloudstack/pull/1971

CLOUDSTACK-9726 Update state is not changed to UPDATE_FAILED in case …

…when Host is put in Maintenance Mode.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bvbharatk/cloudstack CLOUDSTACK-9726

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1971.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1971


commit 670f24ec5dc067ab1e7a29f12c8cd4a709545c24
Author: Bharat Kumar 
Date:   2016-01-04T13:06:28Z

CLOUDSTACK-9726 Update state is not changed to UPDATE_FAILED in case when 
Host is put in Maintenance Mode.




> state of the rvr dose not change to update failed when updating rvrs in 
> sequence to a new offering fails.
> -
>
> Key: CLOUDSTACK-9726
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9726
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
> Fix For: 4.9.0
>
>
> state of the rvr dose not change to update failed when updating rvrs in 
> sequence to a new offering fails.
> Create two Network offerings - RVR1 , RVR2 with RVR enabled.
> Deploy an instance by selecting RVR1 offering for the new Network and 
> ensure virtual routers are deployed and are in Running State.
> Update the network by setting the parameter Updateinsequence to true with 
> offering ID RVR2.
> While the Network update is in progress , put the Primary Storage in 
> Maintenance Mode.
> Observations:
> Pre-Network Update states :
> VR 1 - UPdate Complete , VR 2 - Update in Progress
> States after Host in maintenance mode :
> Routers moved to stopped state.
> VR 1 - Update needed , VR 2 , VR3 : Update in Progress .
> States after cancelling maintenance mode:
> VR 1 - Update needed , VR 2 , VR 3 : Update in Progress .
> Events shows Network update to new offering failed and following exceptions 
> are seen in logs .
> Execpetion during host in maintenance mode : 
> 2016-01-01 08:44:44,453 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (Work-Job-Executor-21:ctx-96b2541b job-49/job-56) (logid:b50e7b75) Remove 
> job-56 from job monitoring
> 2016-01-01 08:44:44,458 DEBUG [c.c.n.NetworkModelImpl] 
> (API-Job-Executor-23:ctx-febc4ccc job-49 ctx-82bfdcbd) (logid:b50e7b75) 
> Service SecurityGroup is not supported in the network id=205
> 2016-01-01 08:44:44,470 WARN  [c.c.n.NetworkServiceImpl] 
> (API-Job-Executor-23:ctx-febc4ccc job-49 ctx-82bfdcbd) (logid:b50e7b75) 
> Failed to implement network Ntwk[205|Guest|17] elements and resources as a 
> part of network update due to
> com.cloud.exception.AgentUnavailableException: Resource [Host:1] is 
> unreachable: Host 1: Unable to send class 
> com.cloud.agent.api.routing.AggregationControlCommand because agent perf04 is 
> in maintenance mode
> at 
> com.cloud.agent.manager.AgentAttache.checkAvailability(AgentAttache.java:165)
> at 
> com.cloud.agent.manager.ClusteredAgentAttache.checkAvailability(ClusteredAgentAttache.java:82)
> at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:346)
> at 
> com.cloud.agent.manager.ClusteredAgentAttache.send(ClusteredAgentAttache.java:141)
> at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:395)
> at 
> com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:457)
> at 
> com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:974)
> at 
> com.cloud.network.router.NetworkHelperImpl.sendCommandsToRouter(NetworkHelperImpl.java:180)
> at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.aggregationExecution(VirtualNetworkApplianceManagerImpl.java:2765)
> at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.prepareAggregatedExecution(VirtualNetworkApplianceManagerImpl.java:2778)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:6

[jira] [Commented] (CLOUDSTACK-9660) NPE while destroying volumes during 1000 VMs deploy and destroy tests

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882052#comment-15882052
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9660:


Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1825
  
@karuturi This can be merged


> NPE while destroying volumes during 1000 VMs deploy and destroy tests
> -
>
> Key: CLOUDSTACK-9660
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9660
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
>Reporter: Koushik Das
>Assignee: Koushik Das
> Fix For: 4.10.0.0
>
>
> Steps:
> 1. Install and configure a zone (advanced or basic).
> 2. Set config storage.cleanup.enabled = true and storage.cleanup.interval = 
> 10 seconds
> 3. Deploy 1000 VMs and then destroy over multiple iterations.
> NPE seen in MS logs while deleting volume:
> 2015-06-18 16:27:47,797 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (UserVm-Scavenger-1:ctx-5ecc886e) (logid:132e3ff8) Cleaning up hypervisor 
> data structures (ex. SRs in XenServer) for managed storage
> 2015-06-18 16:27:47,799 DEBUG [o.a.c.e.o.VolumeOrchestrator] 
> (UserVm-Scavenger-1:ctx-5ecc886e) (logid:132e3ff8) Cleaning storage for vm: 
> 2894
> 2015-06-18 16:27:47,823 INFO [o.a.c.s.v.VolumeServiceImpl] 
> (UserVm-Scavenger-1:ctx-5ecc886e) (logid:132e3ff8) Expunge volume with no 
> data store specified
> 2015-06-18 16:27:47,828 DEBUG [c.c.s.StorageManagerImpl] 
> (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb642325) Storage pool 
> garbage collector found 0 templates to clean up in storage pool: 
> XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0
> 2015-06-18 16:27:47,828 INFO [o.a.c.s.v.VolumeServiceImpl] 
> (UserVm-Scavenger-1:ctx-5ecc886e) (logid:132e3ff8) Volume 2894 is not 
> referred anywhere, remove it from volumes table
> 2015-06-18 16:27:47,829 DEBUG [c.c.s.StorageManagerImpl] 
> (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb642325) Storage pool 
> garbage collector found 0 templates to clean up in storage pool: 
> XenRT-Zone-0-Pod-0-Cluster-1-Primary-Store-0
> 2015-06-18 16:27:47,832 DEBUG [c.c.s.StorageManagerImpl] 
> (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb642325) Secondary storage 
> garbage collector found 0 templates to cleanup on template_store_ref for 
> store: nfs://10.81.56.7/xenrtnfs/1092931-dycPsK
> 2015-06-18 16:27:47,833 DEBUG [c.c.s.StorageManagerImpl] 
> (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb642325) Secondary storage 
> garbage collector found 0 snapshots to cleanup on snapshot_store_ref for 
> store: nfs://10.81.56.7/xenrtnfs/1092931-dycPsK
> 2015-06-18 16:27:47,834 DEBUG [c.c.s.StorageManagerImpl] 
> (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb642325) Secondary storage 
> garbage collector found 0 volumes to cleanup on volume_store_ref for store: 
> nfs://10.81.56.7/xenrtnfs/1092931-dycPsK
> 2015-06-18 16:27:47,842 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (UserVm-Scavenger-1:ctx-5ecc886e) (logid:132e3ff8) Expunged 
> VM[User|i-10-2894-VM]
> 2015-06-18 16:27:47,844 WARN [c.c.s.StorageManagerImpl] 
> (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb642325) Unable to destroy 
> volume 0b22f54b-3242-49ef-b16d-1c7801d5c2bd
> java.lang.NullPointerException
> at 
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.expungeVolumeAsync(VolumeServiceImpl.java:276)
> at 
> com.cloud.storage.StorageManagerImpl.cleanupStorage(StorageManagerImpl.java:1121)
> at 
> com.cloud.storage.StorageManagerImpl$StorageGarbageCollector.runInContext(StorageManagerImpl.java:1481)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at 
> java.util.concu

[jira] [Commented] (CLOUDSTACK-9727) Password reset discrepancy in RVR when one of the Router is not in Running state.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882067#comment-15882067
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9727:


Github user bvbharatk commented on the issue:

https://github.com/apache/cloudstack/pull/1965
  
@ustcweizhou 
Reformatted the code.
thanks.


> Password reset discrepancy in RVR when one of the Router is not in Running 
> state.
> -
>
> Key: CLOUDSTACK-9727
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9727
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
> Fix For: 4.9.2.0
>
>
> - Deploy an instance and place " cloud-set-guest-password " script in the 
> /etc/init.d location and provide the executable permission.
> - Create a template from the above VM.
> - Create a new network offering with RVR enabled.
> - Deploy a new VM from the above created template and select the above RVR 
> offering.
> - Ensure that the password script is sucessfuly running.
> - Put the backup router in stopped state and ensure only master is running.
> - Now stop the VM and and Reset the password.
> - DO not start the VM , Now Stop the current Master and start the Back up.
> - Now the Back Up would be the Master. Now start the VM.
> Observations:
> - The password is saved onto only Master which is in stopped state now or 
> either in backup if we start it.
> - The current Master which was back up earlier do not have the new password. 
> Hence user cannot now login with the new password.
> - In this scenario there is disperancy in the password stored on both the 
> RVR's.
> The only way to sync both the passwords now is , ensure both the RVR are 
> running and reset the password on VM. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9723) Enable unique mac address across different deployments and networks

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882092#comment-15882092
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9723:


Github user jayapalu commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1883#discussion_r102888327
  
--- Diff: engine/schema/src/com/cloud/network/dao/NetworkDaoImpl.java ---
@@ -377,11 +377,16 @@ protected void addAccountToNetwork(final long 
networkId, final long accountId, f
 }
 
 @Override
-public String getNextAvailableMacAddress(final long networkConfigId) {
+public String getNextAvailableMacAddress(final long networkConfigId, 
Integer zoneMacIdentifier) {
--- End diff --

I tried writing unit test cases for it. I have difficulty in call static 
method. I tried with the PowerMockito.mockStatic but still I face NPE in 
fetch.getNextSequence. 


> Enable unique mac address across different deployments and networks
> ---
>
> Key: CLOUDSTACK-9723
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9723
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.10.0.0
>
>
> Specify the MAC address range for VMs created in ACS
> If there are Multiple CCP environments, There is  difficulty in identifying 
> VMs based on their MAC addresses since the addresses are duplicated across 
> environments.
> Specifying the MAC address range in zone will avoid the conflict.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9800) Enable inline mode for NetScaler device

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882097#comment-15882097
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9800:


Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1964
  
Code changes LGTM


> Enable inline mode for NetScaler device
> ---
>
> Key: CLOUDSTACK-9800
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9800
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Reporter: Kishan Kavala
>Assignee: Kishan Kavala
>
> Only side-by-side mode is enabled for NetScaler devices. NetScaler can work 
> in inline mode also along with other Firewall devices



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9638) Problems caused when inputting double-byte numbers for custom compute offerings

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882101#comment-15882101
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9638:


Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1967
  
Code change LGTM


>  Problems caused when inputting double-byte numbers for custom compute 
> offerings
> 
>
> Key: CLOUDSTACK-9638
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9638
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
> Fix For: 4.9.1.0
>
>
> When creating a VM with a custom compute offering, CloudPlatform allows the 
> input of double-byte numbers. The VM will be created but listVirtualMachines 
> will subsequently fail with an exception. The problem seems to be with the 
> value of detail_value for the associated entry in the user_vm_view table. If 
> you manually change it to a regular number the issue is resolved. Double-byte 
> numbers should either be considered invalid for custom offerings and 
> rejected, or listVMs should work when they are used for a VM.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9666) Add configuration validation for the config drive global settings

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882102#comment-15882102
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9666:


Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1968
  
Code changes LGTM


> Add configuration validation for the config drive global settings
> -
>
> Key: CLOUDSTACK-9666
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9666
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
> Fix For: 4.9.2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9726) state of the rvr dose not change to update failed when updating rvrs in sequence to a new offering fails.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882103#comment-15882103
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9726:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/1971
  
@bvbharatk is there unit tests for this change?
@blueorangutan package


> state of the rvr dose not change to update failed when updating rvrs in 
> sequence to a new offering fails.
> -
>
> Key: CLOUDSTACK-9726
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9726
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
> Fix For: 4.9.0
>
>
> state of the rvr dose not change to update failed when updating rvrs in 
> sequence to a new offering fails.
> Create two Network offerings - RVR1 , RVR2 with RVR enabled.
> Deploy an instance by selecting RVR1 offering for the new Network and 
> ensure virtual routers are deployed and are in Running State.
> Update the network by setting the parameter Updateinsequence to true with 
> offering ID RVR2.
> While the Network update is in progress , put the Primary Storage in 
> Maintenance Mode.
> Observations:
> Pre-Network Update states :
> VR 1 - UPdate Complete , VR 2 - Update in Progress
> States after Host in maintenance mode :
> Routers moved to stopped state.
> VR 1 - Update needed , VR 2 , VR3 : Update in Progress .
> States after cancelling maintenance mode:
> VR 1 - Update needed , VR 2 , VR 3 : Update in Progress .
> Events shows Network update to new offering failed and following exceptions 
> are seen in logs .
> Execpetion during host in maintenance mode : 
> 2016-01-01 08:44:44,453 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (Work-Job-Executor-21:ctx-96b2541b job-49/job-56) (logid:b50e7b75) Remove 
> job-56 from job monitoring
> 2016-01-01 08:44:44,458 DEBUG [c.c.n.NetworkModelImpl] 
> (API-Job-Executor-23:ctx-febc4ccc job-49 ctx-82bfdcbd) (logid:b50e7b75) 
> Service SecurityGroup is not supported in the network id=205
> 2016-01-01 08:44:44,470 WARN  [c.c.n.NetworkServiceImpl] 
> (API-Job-Executor-23:ctx-febc4ccc job-49 ctx-82bfdcbd) (logid:b50e7b75) 
> Failed to implement network Ntwk[205|Guest|17] elements and resources as a 
> part of network update due to
> com.cloud.exception.AgentUnavailableException: Resource [Host:1] is 
> unreachable: Host 1: Unable to send class 
> com.cloud.agent.api.routing.AggregationControlCommand because agent perf04 is 
> in maintenance mode
> at 
> com.cloud.agent.manager.AgentAttache.checkAvailability(AgentAttache.java:165)
> at 
> com.cloud.agent.manager.ClusteredAgentAttache.checkAvailability(ClusteredAgentAttache.java:82)
> at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:346)
> at 
> com.cloud.agent.manager.ClusteredAgentAttache.send(ClusteredAgentAttache.java:141)
> at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:395)
> at 
> com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:457)
> at 
> com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:974)
> at 
> com.cloud.network.router.NetworkHelperImpl.sendCommandsToRouter(NetworkHelperImpl.java:180)
> at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.aggregationExecution(VirtualNetworkApplianceManagerImpl.java:2765)
> at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.prepareAggregatedExecution(VirtualNetworkApplianceManagerImpl.java:2778)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProx

[jira] [Commented] (CLOUDSTACK-9657) Ipset command fails for VM's with long internal name

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882107#comment-15882107
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9657:


Github user kishankavala commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1824#discussion_r101981147
  
--- Diff: scripts/vm/hypervisor/xenserver/vmops ---
@@ -232,28 +233,50 @@ def deleteFile(session, args):
 
 return txt
 
+#using all the iptables chain names length to 24 because cleanup_rules 
groups the vm chain excluding -def,-eg
+#to avoid multiple iptables chains for single vm there using length 24
 def chain_name(vm_name):
 if vm_name.startswith('i-') or vm_name.startswith('r-'):
 if vm_name.endswith('untagged'):
 return '-'.join(vm_name.split('-')[:-1])
 if len(vm_name) > 28:
-vm_name = vm_name[0:27]
+vm_name = vm_name[0:24]
 return vm_name
 
 def chain_name_def(vm_name):
+#iptables chain length max is 29 chars
+if len(vm_name) > 28:
--- End diff --

Check should be > 25, "-def" is suffixed


> Ipset command fails for VM's with long internal name
> 
>
> Key: CLOUDSTACK-9657
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9657
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.9.1.0
>
>
> ipset rules configuration in security groups is failing for the VM with 
> longer name 
> ipset -N 12345677 nethash
> ipset v6.11: Syntax error: setname '12345677' is 
> longer than 31 characters



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)