[jira] [Commented] (CLOUDSTACK-10038) listTemplates API call fails for public templates when id parameter passed

2017-08-08 Thread Nathan Johnson (JIRA) 

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

Nathan Johnson commented on CLOUDSTACK-10038:
-

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

> listTemplates API call fails for public templates when id parameter passed
> --
>
> Key: CLOUDSTACK-10038
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10038
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
> Environment: Cloudstack 4.10, KVM (will affect all hypervisors)
>Reporter: Nathan Johnson
>Assignee: Nathan Johnson
>Priority: Minor
>
> listTemplates api call fails when called by users with the Domain Admin role 
> and a template id is specified.  This was introduced with CLOUDSTACK-9679 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (CLOUDSTACK-10038) listTemplates API call fails for public templates when id parameter passed

2017-08-08 Thread Nathan Johnson (JIRA) 

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

Nathan Johnson updated CLOUDSTACK-10038:

Comment: was deleted

(was: https://github.com/apache/cloudstack)

> listTemplates API call fails for public templates when id parameter passed
> --
>
> Key: CLOUDSTACK-10038
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10038
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
> Environment: Cloudstack 4.10, KVM (will affect all hypervisors)
>Reporter: Nathan Johnson
>Assignee: Nathan Johnson
>Priority: Minor
>
> listTemplates api call fails when called by users with the Domain Admin role 
> and a template id is specified.  This was introduced with CLOUDSTACK-9679 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10038) listTemplates API call fails for public templates when id parameter passed

2017-08-08 Thread Nathan Johnson (JIRA) 

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

Nathan Johnson commented on CLOUDSTACK-10038:
-

https://github.com/apache/cloudstack

> listTemplates API call fails for public templates when id parameter passed
> --
>
> Key: CLOUDSTACK-10038
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10038
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
> Environment: Cloudstack 4.10, KVM (will affect all hypervisors)
>Reporter: Nathan Johnson
>Assignee: Nathan Johnson
>Priority: Minor
>
> listTemplates api call fails when called by users with the Domain Admin role 
> and a template id is specified.  This was introduced with CLOUDSTACK-9679 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CLOUDSTACK-10039) Adding IOPS/GB offering

2017-08-08 Thread Syed Ahmed (JIRA) 
Syed Ahmed created CLOUDSTACK-10039:
---

 Summary: Adding IOPS/GB offering
 Key: CLOUDSTACK-10039
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10039
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Storage Controller
Reporter: Syed Ahmed
 Fix For: Future


We want to add a disk offering where we can specify the Min/Max IOPS as a 
function of size. The idea is the larger volume you create, the greater your 
IOPS will be (this is similar to the way GCE handles IOPS). We also have added 
limits to the IOPS (min and max) so that once the volume goes beyond a certain 
size, the IOPS won't change and are capped to the given values.

The following parameters are added to the `createDiskOffering` API:

1. `miniopspergb' : Minimum IOPS/GB for the offering
2. `maxiopspergb`: Maximum IOPS/GB for the offering
3. `highestminiops`: The highest `miniops` value that is allowed for this 
offering
3. `highestmaxiops`: The highest `maxiops` value that is allowed for this 
offering





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CLOUDSTACK-10038) listTemplates API call fails for public templates when id parameter passed

2017-08-08 Thread Nathan Johnson (JIRA) 
Nathan Johnson created CLOUDSTACK-10038:
---

 Summary: listTemplates API call fails for public templates when id 
parameter passed
 Key: CLOUDSTACK-10038
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10038
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.10.0.0
 Environment: Cloudstack 4.10, KVM (will affect all hypervisors)
Reporter: Nathan Johnson
Assignee: Nathan Johnson
Priority: Minor


listTemplates api call fails when called by users with the Domain Admin role 
and a template id is specified.  This was introduced with CLOUDSTACK-9679 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CLOUDSTACK-10037) Virtual display support for VM

2017-08-08 Thread Tadas A (JIRA) 

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

Tadas A updated CLOUDSTACK-10037:
-
Description: 
Hello, 
  When using ESXi you have option to go to Video Card settings on VM, and set 
how much virtual displays you want to have for that VM. Would be nice to have 
this feature on CloudStack.

This is how we tried to get virtual displays working:
1. We modified VM settings to have 3 virtual displays on ESXi, which is 
controlled by ACS but VM didn't see that setting so we only had 1 display.
2. Another thing we tried to export VM to ova file which has 3 virtual displays 
on our stand alone ESXi server and imported that ova to CloudStack. To our 
surprise VM had two virtual monitors out of 3, but we was having issues 
controlling VM over ASC remote console window, so we had to install VMware 
tools of that ESXi which was behind ASC and after we did that number of 
displays went to 1. 

Both ESXi servers at the moment we tested was running 5.5

It would be nice to have monitor button next to Destroy, Attach button, which 
could let you to set how many display you want to have and set video memory. It 
could be automatically predefined by ASC system administrator so that user 
couldn't set more displays than administrator allows. 

ESXi-displays.png shows the settings i am talking about in ESXi.

Thanks, 
   Tadas 

  was:
Hello, 
  When using ESXi you have option to go to Video Card settings on VM, and set 
how much virtual displays you want to have for that VM. Would be nice to have 
this feature on CloudStack.

This is how we tried to get virtual displays working:
1. We modified VM settings to have 3 virtual displays on ESXi, which is 
controlled by ACS but VM didn't see that setting so we only had 1 display.
2. Another thing we tried to export VM to ova file which has 3 virtual displays 
on our stand alone ESXi server and imported that ova to CloudStack. To our 
surprise VM had two virtual monitors out of 3, but we was having issues 
controlling VM over ASC remote console window, so we had to install VMware 
tools of that ESXi which was behind ASC and after we did that number of 
displays went to 1. 

Both ESXi servers at the moment we tested was running 5.5

It would be nice to have monitor button next to Destroy, Attach button which 
would let you to set how many display you want to have and set video memory. It 
could be automatically predefined by ASC system administrator so that user 
couldn't set more displays than administrator allows. 

ESXi-displays.png shows the settings i am talking about in ESXi.

Thanks, 
   Tadas 


> Virtual display support for VM
> --
>
> Key: CLOUDSTACK-10037
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10037
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
> Environment: windows, linux
>Reporter: Tadas A
>Priority: Minor
>  Labels: feature
> Attachments: esxi-displaysPNG.PNG
>
>
> Hello, 
>   When using ESXi you have option to go to Video Card settings on VM, and set 
> how much virtual displays you want to have for that VM. Would be nice to have 
> this feature on CloudStack.
> This is how we tried to get virtual displays working:
> 1. We modified VM settings to have 3 virtual displays on ESXi, which is 
> controlled by ACS but VM didn't see that setting so we only had 1 display.
> 2. Another thing we tried to export VM to ova file which has 3 virtual 
> displays on our stand alone ESXi server and imported that ova to CloudStack. 
> To our surprise VM had two virtual monitors out of 3, but we was having 
> issues controlling VM over ASC remote console window, so we had to install 
> VMware tools of that ESXi which was behind ASC and after we did that number 
> of displays went to 1. 
> Both ESXi servers at the moment we tested was running 5.5
> It would be nice to have monitor button next to Destroy, Attach button, which 
> could let you to set how many display you want to have and set video memory. 
> It could be automatically predefined by ASC system administrator so that user 
> couldn't set more displays than administrator allows. 
> ESXi-displays.png shows the settings i am talking about in ESXi.
> Thanks, 
>Tadas 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CLOUDSTACK-10037) Virtual display support for VM

2017-08-08 Thread Tadas A (JIRA) 

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

Tadas A updated CLOUDSTACK-10037:
-
Description: 
Hello, 
  When using ESXi you have option to go to Video Card settings on VM, and set 
how much virtual displays you want to have for that VM. Would be nice to have 
this feature on CloudStack.

This is how we tried to get virtual displays working:
1. We modified VM settings to have 3 virtual displays on ESXi, which is 
controlled by ACS but VM didn't see that setting so we only had 1 display.
2. Another thing we tried to export VM to ova file which has 3 virtual displays 
on our stand alone ESXi server and imported that ova to CloudStack. To our 
surprise VM had two virtual monitors out of 3, but we was having issues 
controlling VM over ASC remote console window, so we had to install VMware 
tools of that ESXi which was behind ASC and after we did that number of 
displays went to 1. 

Both ESXi servers at the moment we tested was running 5.5

It would be nice to have monitor button next to Destroy, Attach button which 
would let you to set how many display you want to have and set video memory. It 
could be automatically predefined by ASC system administrator so that user 
couldn't set more displays than administrator allows. 

ESXi-displays.png shows the settings i am talking about in ESXi.

Thanks, 
   Tadas 

  was:
Hello, 
  When using ESXi you have option to go to Video Card settings on VM, and set 
how much virtual displays you want to have for that VM. Would be nice to have 
this feature on CloudStack.


If we change now VM settings on ESXi to have 2 virtual displays which is 
controller by CloudStack, VM only see 1 monitor, so this setting is not passed 
to VM. 
Another thing we tried to export VM to ova file which has 3 virtual displays on 
our stand alone ESXi server and imported that ova to CloudStack. To our 
surprise VM had two virtual monitors, but we



ESXi-displays.png shows the settings i am talking about in ESXi.

Thanks, 
   Tadas 


> Virtual display support for VM
> --
>
> Key: CLOUDSTACK-10037
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10037
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
> Environment: windows, linux
>Reporter: Tadas A
>Priority: Minor
>  Labels: feature
> Attachments: esxi-displaysPNG.PNG
>
>
> Hello, 
>   When using ESXi you have option to go to Video Card settings on VM, and set 
> how much virtual displays you want to have for that VM. Would be nice to have 
> this feature on CloudStack.
> This is how we tried to get virtual displays working:
> 1. We modified VM settings to have 3 virtual displays on ESXi, which is 
> controlled by ACS but VM didn't see that setting so we only had 1 display.
> 2. Another thing we tried to export VM to ova file which has 3 virtual 
> displays on our stand alone ESXi server and imported that ova to CloudStack. 
> To our surprise VM had two virtual monitors out of 3, but we was having 
> issues controlling VM over ASC remote console window, so we had to install 
> VMware tools of that ESXi which was behind ASC and after we did that number 
> of displays went to 1. 
> Both ESXi servers at the moment we tested was running 5.5
> It would be nice to have monitor button next to Destroy, Attach button which 
> would let you to set how many display you want to have and set video memory. 
> It could be automatically predefined by ASC system administrator so that user 
> couldn't set more displays than administrator allows. 
> ESXi-displays.png shows the settings i am talking about in ESXi.
> Thanks, 
>Tadas 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CLOUDSTACK-10037) Virtual display support for VM

2017-08-08 Thread Tadas A (JIRA) 

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

Tadas A updated CLOUDSTACK-10037:
-
Description: 
Hello, 
  When using ESXi you have option to go to Video Card settings on VM, and set 
how much virtual displays you want to have for that VM. Would be nice to have 
this feature on CloudStack.


If we change now VM settings on ESXi to have 2 virtual displays which is 
controller by CloudStack, VM only see 1 monitor, so this setting is not passed 
to VM. 
Another thing we tried to export VM to ova file which has 3 virtual displays on 
our stand alone ESXi server and imported that ova to CloudStack. To our 
surprise VM had two virtual monitors, but we



ESXi-displays.png shows the settings i am talking about in ESXi.

Thanks, 
   Tadas 

  was:
Hello, 
  When using ESXi you have option to go to Video Card settings on VM, and set 
how much virtual displays you want to have for that VM. Would be nice to have 
this feature on CloudStack.

ESXi-displays.png shows the settings i am talking about in ESXi.

Thanks, 
   Tadas 


> Virtual display support for VM
> --
>
> Key: CLOUDSTACK-10037
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10037
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
> Environment: windows, linux
>Reporter: Tadas A
>Priority: Minor
>  Labels: feature
> Attachments: esxi-displaysPNG.PNG
>
>
> Hello, 
>   When using ESXi you have option to go to Video Card settings on VM, and set 
> how much virtual displays you want to have for that VM. Would be nice to have 
> this feature on CloudStack.
> If we change now VM settings on ESXi to have 2 virtual displays which is 
> controller by CloudStack, VM only see 1 monitor, so this setting is not 
> passed to VM. 
> Another thing we tried to export VM to ova file which has 3 virtual displays 
> on our stand alone ESXi server and imported that ova to CloudStack. To our 
> surprise VM had two virtual monitors, but we
> ESXi-displays.png shows the settings i am talking about in ESXi.
> Thanks, 
>Tadas 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CLOUDSTACK-10037) Virtual display support for VM

2017-08-08 Thread Tadas A (JIRA) 

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

Tadas A updated CLOUDSTACK-10037:
-
Description: 
Hello, 
  When using ESXi you have option to go to Video Card settings on VM, and set 
how much virtual displays you want to have for that VM. Would be nice to have 
this feature on CloudStack.

ESXi-displays.png shows the settings i am talking about in ESXi.

Thanks, 
   Tadas 

  was:
Hello, 
  When using ESXi you have option to go to Video Card settings on VM, and set 
how much virtual displays you want to have for that VM. Would be nice to have 
this option on CloudStack.

ESXi-displays.png shows the settings i am talking about in ESXi.

Thanks, 
   Tadas 


> Virtual display support for VM
> --
>
> Key: CLOUDSTACK-10037
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10037
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
> Environment: windows, linux
>Reporter: Tadas A
>Priority: Minor
>  Labels: feature
> Attachments: esxi-displaysPNG.PNG
>
>
> Hello, 
>   When using ESXi you have option to go to Video Card settings on VM, and set 
> how much virtual displays you want to have for that VM. Would be nice to have 
> this feature on CloudStack.
> ESXi-displays.png shows the settings i am talking about in ESXi.
> Thanks, 
>Tadas 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CLOUDSTACK-10037) Virtual display support for VM

2017-08-08 Thread Tadas A (JIRA) 

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

Tadas A updated CLOUDSTACK-10037:
-
Description: 
Hello, 
  When using ESXi you have option to go to Video Card settings on VM, and set 
how much virtual displays you want to have for that VM. Would be nice to have 
this option on CloudStack.

ESXi-displays.png shows the settings i am talking about in ESXi.

Thanks, 
   Tadas 

  was:
Hello, 
  When using ESXi you have and options to go to Video Card settings on VM, and 
set how much virtual displays you want to have for that VM. Would be nice to 
have this option on CloudStack.

ESXi-displays.png shows the settings i am talking about in ESXi.

Thanks, 
   Tadas 


> Virtual display support for VM
> --
>
> Key: CLOUDSTACK-10037
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10037
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
> Environment: windows, linux
>Reporter: Tadas A
>Priority: Minor
>  Labels: feature
> Attachments: esxi-displaysPNG.PNG
>
>
> Hello, 
>   When using ESXi you have option to go to Video Card settings on VM, and set 
> how much virtual displays you want to have for that VM. Would be nice to have 
> this option on CloudStack.
> ESXi-displays.png shows the settings i am talking about in ESXi.
> Thanks, 
>Tadas 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CLOUDSTACK-10037) Virtual display support for VM

2017-08-08 Thread Tadas A (JIRA) 
Tadas A created CLOUDSTACK-10037:


 Summary: Virtual display support for VM
 Key: CLOUDSTACK-10037
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10037
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public (Anyone can view this level - this is the default.)
 Environment: windows, linux
Reporter: Tadas A
Priority: Minor
 Attachments: esxi-displaysPNG.PNG

Hello, 
  When using ESXi you have and options to go to Video Card settings on VM, and 
set how much virtual displays you want to have for that VM. Would be nice to 
have this option on CloudStack.

ESXi-displays.png shows the settings i am talking about in ESXi.

Thanks, 
   Tadas 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10013) Migrate to Debian9 systemvmtemplate

2017-08-08 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on CLOUDSTACK-10013:
--

Commit 6c8fbc994d3fd6c3fc97d2107bc06168268159ee in cloudstack's branch 
refs/heads/debian9-systemvmtemplate from [~rohit.ya...@shapeblue.com]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=6c8fbc9 ]

CLOUDSTACK-10013: Migrate systemvmtemplate to Debian9

  SystemVM changes to work on Debian 9
- Migrate away from chkconfig to systemctl
- Remove xenstore-utils override deb pkg
- Fix runlevel in sysv scripts for systemd

Signed-off-by: Rohit Yadav 


> Migrate to Debian9 systemvmtemplate
> ---
>
> Key: CLOUDSTACK-10013
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10013
> 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: Future, 4.11.0.0
>
>
> Migrate to debian9 based systemvmtemplate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10036) Decrease timeout of failing unit test HypervisorUtilsTest.java

2017-08-08 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on CLOUDSTACK-10036:
--

Commit 18ffd7b199fdca2011ea4f86f9de7b379156a961 in cloudstack's branch 
refs/heads/debian9-systemvmtemplate from [~bstoyanov]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=18ffd7b ]

CLOUDSTACK-10036: Decreasing timeout of failing unit test (#2228)

This test occasionally fails on CentOS6 environments by failing to meet the 
2000 milliseconds threshold. Usually it ends up executing the method for ~1100. 
So decreasing the timeout to 1000 would prevent it from failing.

> Decrease timeout of failing unit test HypervisorUtilsTest.java
> --
>
> Key: CLOUDSTACK-10036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10036
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Boris Stoyanov
>
> This test occasionally fails on CentOS6 environments by failing to meet the 
> 2000 milliseconds threshold. Usually it ends up executing the method for 
> ~1100. So decreasing the timeout to 1000 would prevent it from failing. 
> utils/src/test/java/org/apache/cloudstack/utils/hypervisor/HypervisorUtilsTest.java
> method: checkVolumeFileForActivityTest()



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9861) Expire VM snapshots after configured duration

2017-08-08 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on CLOUDSTACK-9861:
-

Commit d7f5b929b25d4b0c9af8736da68a43ce84b8dc47 in cloudstack's branch 
refs/heads/debian9-systemvmtemplate from [~abhi_shapeblue]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=d7f5b92 ]

CLOUDSTACK-9861: Expire VM snapshots after configured duration (#2026)

Default value of the account level global config vmsnapshot.expire.interval is 
-1 that conforms to legacy behaviour. A positive value will expire the VM 
snapshots for the respective account in that many hours.

> Expire VM snapshots after configured duration
> -
>
> Key: CLOUDSTACK-9861
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9861
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Abhinandan Prateek
>
> Currently, users can keep VM snapshots for an indefinite time period.  
> Long-lived snapshots can cause stability issues on the hypervisor.
> Requirement: Add a timeout for VM Snapshots, whereby snapshots get 
> automatically deleted after a given time period. This would be available at 
> account level, with a default value determined by a global setting. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

2017-08-08 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on CLOUDSTACK-9608:
-

Commit 3614f8aae29f3e084671b5269d2429fa7f355978 in cloudstack's branch 
refs/heads/debian9-systemvmtemplate from Mowgli
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=3614f8a ]

CLOUDSTACK-9608: Errored State and Abandoned state Templates are not displayed 
on UI. (#1774)

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. Refer - CLOUDSTACK-9608

> 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.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10034) rbd: Use libvirt to create new volumes and not rados-java

2017-08-08 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on CLOUDSTACK-10034:
--

Commit 28670809791d9853c21693fbbd80154c9f66824f in cloudstack's branch 
refs/heads/debian9-systemvmtemplate from [~widodh]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=2867080 ]

CLOUDSTACK-10034: Use libvirt to create new volumes and not rados-java (#2039)

Since libvirt 1.2.2 libvirt will properly create volumes
using RBD format 2.

We can use libvirt to creates the volumes which strips a bit of
code from the CloudStack Agent's responsbility.

RBD format 2 is already used by all volumes created by CloudStack.

This format is the most recent format of RBD and is still actively
being developed.

This removes the support for Ubuntu 12.04 as that does not have the
proper libvirt version available.

Signed-off-by: Wido den Hollander w...@widodh.nl

We can use libvirt to creates the volumes which strips a bit of
code from the CloudStack Agent's responsbility.

RBD format 2 is already used by all volumes created by CloudStack.

This format is the most recent format of RBD and is still actively
being developed.

This removes the support for Ubuntu 12.04 as that does not have the
proper libvirt version available.

Signed-off-by: Wido den Hollander 

> rbd: Use libvirt to create new volumes and not rados-java
> -
>
> Key: CLOUDSTACK-10034
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10034
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
> Fix For: 4.11.0.0
>
>
> rbd: Use libvirt to create new volumes and not rados-java #2039
> https://github.com/apache/cloudstack/pull/2039



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9955) Featured Templates/Iso's created by Root/admin user are not visible to Domain Admin users

2017-08-08 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on CLOUDSTACK-9955:
-

Commit 6203013ec6b9bf09bf94f48150a4f72aba598424 in cloudstack's branch 
refs/heads/debian9-systemvmtemplate from niteshsarda
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=6203013 ]

CLOUDSTACK-9955 : Featured Templates/Iso's created by Root/admin user are not 
visible to Domain Admin users (#2144)

ISSUE: Featured Templates/Iso's created by Root/admin user are not visible to 
Domain Admin users.

STEPS TO REPRODUCE

Mark a template as featured and try to view it from a domain admin user
The issue occurs for both templates and iso's registered before and after 
upgrade
Templates,ISO's whose owner is ROOT admin, public: Yes, featured: Yes
Log in to UI (as a domain admin, such as an admin of “TEST/TEST1” domain)
Choose “Templates”.
Error message will be shown on UI

> Featured Templates/Iso's created by Root/admin user are not visible to Domain 
> Admin users
> -
>
> Key: CLOUDSTACK-9955
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9955
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitesh Sarda
>Priority: Minor
>
> ISSUE
> 
> Featured Templates/Iso's created by Root/admin user are not visible to Domain 
> Admin users.
> STEPS TO REPRODUCE
> ==
> * Mark a template as featured and try to view it from a domain admin user
> * The issue occurs for both templates and iso's registered before and after 
> upgrade
> Templates,ISO's whose owner is ROOT admin, public: Yes, featured: Yes
> Log in to UI (as a domain admin, such as an admin of “TEST/TEST1” domain)
> Choose “Templates”.
> * Error message will be shown on UI



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

2017-08-08 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on CLOUDSTACK-9801:
-

Commit a5778139c2205971a0210f30ce537217ef0a2473 in cloudstack's branch 
refs/heads/debian9-systemvmtemplate from [~slair1]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=a577813 ]

CLOUDSTACK-9801: IPSec VPN does not work after vRouter reboot or recreate 
(#1966)

This makes sure IP address is active.

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")

> 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.4.14#64029)

[jira] [Commented] (CLOUDSTACK-8945) rp_filter=1 not set on VPC private gateway initially, but is set after restart of VPC router

2017-08-08 Thread Rohit Yadav (JIRA) 

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

Rohit Yadav commented on CLOUDSTACK-8945:
-

Disabling rp_filter would mean no source validation will be done on incoming 
packets on an interface, i.e. packets won't be dropped. This is used for all 
sorts of domR (VPC VRs, rVRs, normal VRs). On normal VRs, eth0 and eth1 are 
link-local and guest network nics, however eth2 is public network nic. For 
VPC/redundantVPC VRs, eth0 is link-local, eth1 is public, eth2 is guest network 
-- based on actual env tests on kvm, vmware, xenserver.

> rp_filter=1 not set on VPC private gateway initially, but is set after 
> restart of VPC router
> 
>
> Key: CLOUDSTACK-8945
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8945
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.4.4
>Reporter: Anton Opgenoort
>Assignee: Rohit Yadav
>
> (on ACS4.4.4 with XenServer as hypervisor)
> Steps to reproduce:
> -create VPC router
> -Create private gateway on VPC router
> -now log on to the rVM via the hypervisor's link-local address
> root@r-46771-VM:~# sysctl net.ipv4.conf.eth2.rp_filter
> net.ipv4.conf.eth2.rp_filter = 0
> Restart the rVM via CloudStack (NOT restart VPC but restart the underlying 
> router via CloudStack)
> -log on again:
> root@r-46771-VM:~# sysctl net.ipv4.conf.eth2.rp_filter
> net.ipv4.conf.eth2.rp_filter = 1
> The issue thus is that on initial creation it is not set, where it should be 
> set immediately 
> Note: when adding a regular network tier to the VPC config, that new 
> interface IS configured with rp_filter=1. So it is limited to the private 
> gateway NIC. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-10036) Decrease timeout of failing unit test HypervisorUtilsTest.java

2017-08-08 Thread Boris Stoyanov (JIRA) 

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

Boris Stoyanov resolved CLOUDSTACK-10036.
-
Resolution: Fixed

> Decrease timeout of failing unit test HypervisorUtilsTest.java
> --
>
> Key: CLOUDSTACK-10036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10036
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Boris Stoyanov
>
> This test occasionally fails on CentOS6 environments by failing to meet the 
> 2000 milliseconds threshold. Usually it ends up executing the method for 
> ~1100. So decreasing the timeout to 1000 would prevent it from failing. 
> utils/src/test/java/org/apache/cloudstack/utils/hypervisor/HypervisorUtilsTest.java
> method: checkVolumeFileForActivityTest()



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CLOUDSTACK-8945) rp_filter=1 not set on VPC private gateway initially, but is set after restart of VPC router

2017-08-08 Thread Rohit Yadav (JIRA) 

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

Rohit Yadav reassigned CLOUDSTACK-8945:
---

Assignee: Rohit Yadav

> rp_filter=1 not set on VPC private gateway initially, but is set after 
> restart of VPC router
> 
>
> Key: CLOUDSTACK-8945
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8945
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.4.4
>Reporter: Anton Opgenoort
>Assignee: Rohit Yadav
>
> (on ACS4.4.4 with XenServer as hypervisor)
> Steps to reproduce:
> -create VPC router
> -Create private gateway on VPC router
> -now log on to the rVM via the hypervisor's link-local address
> root@r-46771-VM:~# sysctl net.ipv4.conf.eth2.rp_filter
> net.ipv4.conf.eth2.rp_filter = 0
> Restart the rVM via CloudStack (NOT restart VPC but restart the underlying 
> router via CloudStack)
> -log on again:
> root@r-46771-VM:~# sysctl net.ipv4.conf.eth2.rp_filter
> net.ipv4.conf.eth2.rp_filter = 1
> The issue thus is that on initial creation it is not set, where it should be 
> set immediately 
> Note: when adding a regular network tier to the VPC config, that new 
> interface IS configured with rp_filter=1. So it is limited to the private 
> gateway NIC. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CLOUDSTACK-10028) Rebooting router fails

2017-08-08 Thread Rohit Yadav (JIRA) 

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

Rohit Yadav reassigned CLOUDSTACK-10028:


Assignee: Rohit Yadav

> Rebooting router fails
> --
>
> Key: CLOUDSTACK-10028
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10028
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.11.0.0
>Reporter: Boris Stoyanov
>Assignee: Rohit Yadav
>
> Few tests report errors on starting/restarting a router: 
> test_01_nic  Error  193.93  test_nic.py
> test_reboot_router  Error  238.47  test_network.py
> test_03_vpc_privategw_restart_vpc_cleanup
> Here's the log from management
> {code}
> 2017-08-03 08:39:21,485 INFO  [c.c.v.VirtualMachineManagerImpl] 
> (AgentManager-Handler-11:null) (logid:) There is pending job or HA tasks 
> working on the VM. vm id: 26, postpone power-change report by resetting 
> power-change counters
> 2017-08-03 08:39:21,494 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
> (AgentManager-Handler-11:null) (logid:) Done with process of VM state report. 
> host: 2
> 2017-08-03 08:39:22,989 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-25:ctx-9de4b3c2) (logid:9e34d539) ===START===  10.1.0.1 -- GET 
>  
> signature=GW5N4FsQQmEwb88LLMgUbiAJKVA%3D=LIN6rqXuaJwMPfGYFh13qDwYz5VNNz1J2J6qIOWcd3oLQOq0WtD4CwRundBL6rzXToa3lQOC_vKjI3nkHtiD8Q=queryAsyncJobResult=json=79f83157-5dbb-4d3e-afd0-90306550030d
> 2017-08-03 08:39:23,005 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-25:ctx-9de4b3c2 ctx-3955671b ctx-82b0f609) (logid:9e34d539) 
> ===END===  10.1.0.1 -- GET  
> signature=GW5N4FsQQmEwb88LLMgUbiAJKVA%3D=LIN6rqXuaJwMPfGYFh13qDwYz5VNNz1J2J6qIOWcd3oLQOq0WtD4CwRundBL6rzXToa3lQOC_vKjI3nkHtiD8Q=queryAsyncJobResult=json=79f83157-5dbb-4d3e-afd0-90306550030d
> 2017-08-03 08:39:23,518 DEBUG [c.c.a.t.Request] 
> (AgentManager-Handler-15:null) (logid:) Seq 2-2966746254530314637: 
> Processing:  { Ans: , MgmtId: 7589375051554, via: 2, Ver: v1, Flags: 110, 
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":26,"name":"r-26-VM","type":"DomainRouter","cpus":1,"minSpeed":250,"maxSpeed":500,"minRam":268435456,"maxRam":268435456,"arch":"x86_64","os":"Debian
>  GNU/Linux 5.0 (64-bit)","platformEmulator":"Debian GNU/Linux 5","bootArgs":" 
> vpccidr=10.0.1.0/24 domain=cs20cloud.internal dns1=8.8.8.8 dns2=8.8.4.4 
> privategateway=10.0.3.100 template=domP name=r-26-VM eth0ip=169.254.2.154 
> eth0mask=255.255.0.0 type=vpcrouter disable_rp_filter=true 
> baremetalnotificationsecuritykey=FiAIoemfwpWCOGXSL9LkNkpkHN3Tg0a2uFsd65sZR-3YbILIk5QvtBykdEAqjqIHFyv15jLtyl2XwNqMJwYuyA
>  
> baremetalnotificationapikey=7xDDCgrtLsx-yJXbsgF78xrImLPW7Pbit__g33ANzDPDdlpxtnMqamTk08teVDvvp-0m3rwIQSWait8Lc99y_g
>  host=10.2.2.42 
> port=8080","enableHA":true,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"GWzMbEzuzvbnc1RGLYFPwg","vncAddr":"10.2.2.45","params":{"cpuOvercommitRatio":"2.0","memoryOvercommitRatio":"1.0"},"uuid":"dde05785-343b-425e-b700-40320b71421f","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"df8ebe6a-bf69-4de8-ba70-f05b75b36309","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"81433667-8d42-39db-8e1b-e74d2167dcc0","id":1,"poolType":"NetworkFilesystem","host":"10.2.0.16","path":"/acs/primary/trl-796-k-cs411-bstoyanov/trl-796-k-cs411-bstoyanov-kvm-pri1","port":2049,"url":"NetworkFilesystem://10.2.0.16/acs/primary/trl-796-k-cs411-bstoyanov/trl-796-k-cs411-bstoyanov-kvm-pri1/?ROLE=Primary=81433667-8d42-39db-8e1b-e74d2167dcc0","isManaged":false}},"name":"ROOT-26","size":349752832,"path":"df8ebe6a-bf69-4de8-ba70-f05b75b36309","volumeId":28,"vmName":"r-26-VM","accountId":32,"format":"QCOW2","provisioningType":"THIN","id":28,"deviceId":0,"bytesReadRate":0,"bytesWriteRate":0,"iopsReadRate":0,"iopsWriteRate":0,"hypervisorType":"KVM"}},"diskSeq":0,"path":"df8ebe6a-bf69-4de8-ba70-f05b75b36309","type":"ROOT","_details":{"storageHost":"10.2.0.16","managed":"false","storagePort":"2049","volumeSize":"349752832"}}],"nics":[{"deviceId":0,"networkRateMbps":-1,"defaultNic":false,"pxeDisable":true,"nicUuid":"e240a815-7cb9-45f3-b4fb-684b54ac7682","uuid":"1b67c5d8-fa83-41ca-a20d-2ecb0c0db0d1","ip":"169.254.2.154","netmask":"255.255.0.0","gateway":"169.254.0.1","mac":"0e:00:a9:fe:02:9a","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false}],"guestOsDetails":{}},"result":true,"wait":0}},{"com.cloud.agent.api.check.CheckSshAnswer":{"result":true,"wait":0}},{"com.cloud.agent.api.GetDomRVersionAnswer":{"templateVersion":"Cloudstack
>  Release 4.10.0 Wed Jun 14 04:42:21 UTC 
> 2017","scriptsVersion":"d3e3b82cd825b0cb33c1d7f8db3f8a3a\n","result":true,"details":"Cloudstack
>  Release 4.10.0 Wed

[jira] [Created] (CLOUDSTACK-10036) Decrease timeout of failing unit test HypervisorUtilsTest.java

2017-08-08 Thread Boris Stoyanov (JIRA) 
Boris Stoyanov created CLOUDSTACK-10036:
---

 Summary: Decrease timeout of failing unit test 
HypervisorUtilsTest.java
 Key: CLOUDSTACK-10036
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10036
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Boris Stoyanov


This test occasionally fails on CentOS6 environments by failing to meet the 
2000 milliseconds threshold. Usually it ends up executing the method for ~1100. 
So decreasing the timeout to 1000 would prevent it from failing. 

utils/src/test/java/org/apache/cloudstack/utils/hypervisor/HypervisorUtilsTest.java
method: checkVolumeFileForActivityTest()



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CLOUDSTACK-9884) Duplicate of VR after disabling RvR

2017-08-08 Thread Patrick (JIRA) 

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

Patrick updated CLOUDSTACK-9884:

Description: 
Our environment is:
ACS: 4.9.2 (migrated from 4.5.2)
Management Server: CentOS 6.8
Hosts: XenServer 6.5 SP1
System VM: systemvm64template-4.6.0-xen.vhd.bz2
Network: Isolated Network
Network Offering: Offering for Isolated networks with Source Nat service enabled

Issue description:
After the migration to 4.9.2 and the multiple (known) issues with RvR, all 
networks had their offerings changed to disable HA and RvR and run networks 
with a single VR.
Since, the following actions initiate the creation of a "duplicate" second VR, 
ending in an UNKNOWN state, and triggering a lot of random network issues.
- New VM instances creation
- Start of VM instances on given network
- Clean restart of the network
Interestingly, when switching between offerings, it also recreates the VR, but 
it doesn't do any duplicate this time.

Analysis:
This only impacts networks that were initially set as HA network with RvR 
before the migration to 4.9.2. These networks keep the redundant flag to 1 in 
the networks table, even though the offering redundant_router_service flag is 
set to 0. I believe it should be changed to 0 when the network is using an 
non-HA offering.

  was:
Our environment is:
ACS: 4.9.2 (migrated from 4.5.2)
Management Server: CentOS 6.8
Hosts: XenServer 6.5 SP1
System VM: systemvm64template-4.6.0-xen.vhd.bz2
Network: Isolated Network
Network Offering: Offering for Isolated networks with Source Nat service enabled

Issue description:
After the migration to 4.9.2 and the multiple (known) issues with RvR, all 
networks had their offerings changed to disable HA and RvR and run networks 
with a single VR.
Since, the following actions initiate the creation of a "duplicate" second VR, 
ending in an UNKNOWN state, and triggering a lot of random network issues.
- New VM instances creation
- Clean restart of the network
Interestingly, when switching between offerings, it also recreates the VR, but 
it doesn't do any duplicate this time.

Analysis:
This only impacts networks that were initially set as HA network with RvR 
before the migration to 4.9.2. These networks keep the redundant flag to 1 in 
the networks table, even though the offering redundant_router_service flag is 
set to 0. I believe it should be changed to 0 when the network is using an 
non-HA offering.


> Duplicate of VR after disabling RvR
> ---
>
> Key: CLOUDSTACK-9884
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9884
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.2.0
> Environment: CentOS 6.8 + XenServer 6.5
>Reporter: Patrick
>Priority: Critical
>
> Our environment is:
> ACS: 4.9.2 (migrated from 4.5.2)
> Management Server: CentOS 6.8
> Hosts: XenServer 6.5 SP1
> System VM: systemvm64template-4.6.0-xen.vhd.bz2
> Network: Isolated Network
> Network Offering: Offering for Isolated networks with Source Nat service 
> enabled
> Issue description:
> After the migration to 4.9.2 and the multiple (known) issues with RvR, all 
> networks had their offerings changed to disable HA and RvR and run networks 
> with a single VR.
> Since, the following actions initiate the creation of a "duplicate" second 
> VR, ending in an UNKNOWN state, and triggering a lot of random network issues.
> - New VM instances creation
> - Start of VM instances on given network
> - Clean restart of the network
> Interestingly, when switching between offerings, it also recreates the VR, 
> but it doesn't do any duplicate this time.
> Analysis:
> This only impacts networks that were initially set as HA network with RvR 
> before the migration to 4.9.2. These networks keep the redundant flag to 1 in 
> the networks table, even though the offering redundant_router_service flag is 
> set to 0. I believe it should be changed to 0 when the network is using an 
> non-HA offering.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10002) Restart network with cleanup spawns Redundant Routers(In Default Network Offering)

2017-08-08 Thread Patrick (JIRA) 

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

Patrick commented on CLOUDSTACK-10002:
--

Part of this issue is described in this bug: 
https://issues.apache.org/jira/browse/CLOUDSTACK-9884

> Restart network with cleanup spawns Redundant Routers(In Default Network 
> Offering)
> --
>
> Key: CLOUDSTACK-10002
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10002
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.10.0.0
> Environment: Persistent VR
>Reporter: Nitin Kumar Maharana
> Fix For: 4.10.1.0
>
>
> Reproduction Steps:
> Create a network with redundant router capability.
> Create instances with the above network.
> Update the network to Default 
> Offering(DefaultIsolatedNetworkOfferingWithSourceNAT).
> After successful update, one router is created which is as expected.
> Try to restart the network with cleanup=true.
> Observation:
> Two routers are created with redundant state UNKNOWN.
> Note: - The similar behavior is seen when we update RVR to default.
> Expectation:
> After successful restart, only one router should be created
> FS: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Persistent+Configuration+for+Virtual+Routers



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CLOUDSTACK-9884) Duplicate of VR after disabling RvR

2017-08-08 Thread Patrick (JIRA) 

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

Patrick updated CLOUDSTACK-9884:

Description: 
Our environment is:
ACS: 4.9.2 (migrated from 4.5.2)
Management Server: CentOS 6.8
Hosts: XenServer 6.5 SP1
System VM: systemvm64template-4.6.0-xen.vhd.bz2
Network: Isolated Network
Network Offering: Offering for Isolated networks with Source Nat service enabled

Issue description:
After the migration to 4.9.2 and the multiple (known) issues with RvR, all 
networks had their offerings changed to disable HA and RvR and run networks 
with a single VR.
Since, the following actions initiate the creation of a "duplicate" second VR, 
ending in an UNKNOWN state, and triggering a lot of random network issues.
- New VM instances creation
- Clean restart of the network
Interestingly, when switching between offerings, it also recreates the VR, but 
it doesn't do any duplicate this time.

Analysis:
This only impacts networks that were initially set as HA network with RvR 
before the migration to 4.9.2. These networks keep the redundant flag to 1 in 
the networks table, even though the offering redundant_router_service flag is 
set to 0. I believe it should be changed to 0 when the network is using an 
non-HA offering.

  was:
Our environment is:
ACS: 4.9.2 (migrated from 4.5.2)
Management Server: CentOS 6.8
Hosts: XenServer 6.5 SP1
System VM: systemvm64template-4.6.0-xen.vhd.bz2
Network: Isolated Network
Network Offering: Offering for Isolated networks with Source Nat service enabled

Issue description:
After the migration to 4.9.2 and the multiple (known) issues with RvR, all 
networks had their offerings changed to disable HA and RvR and run networks 
with a single VR.
Since, the following actions initiate the creation of a "duplicate" second VR, 
ending in an UNKNOWN state, and triggering a lot of random network issues.
- New VM instances creation
- Clean restart of the network
Interestingly, when switching between offerings, it also recreates the VR, but 
it doesn't do any duplicate this time.

Analysis:
This only impacts networks that were initially set as HA network with RvR. 
These networks keep the redundant flag to 1 in the networks table, even though 
the offering redundant_router_service flag is set to 0. I believe it should be 
changed to 0 when the network is using an non-HA offering.


> Duplicate of VR after disabling RvR
> ---
>
> Key: CLOUDSTACK-9884
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9884
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.2.0
> Environment: CentOS 6.8 + XenServer 6.5
>Reporter: Patrick
>Priority: Critical
>
> Our environment is:
> ACS: 4.9.2 (migrated from 4.5.2)
> Management Server: CentOS 6.8
> Hosts: XenServer 6.5 SP1
> System VM: systemvm64template-4.6.0-xen.vhd.bz2
> Network: Isolated Network
> Network Offering: Offering for Isolated networks with Source Nat service 
> enabled
> Issue description:
> After the migration to 4.9.2 and the multiple (known) issues with RvR, all 
> networks had their offerings changed to disable HA and RvR and run networks 
> with a single VR.
> Since, the following actions initiate the creation of a "duplicate" second 
> VR, ending in an UNKNOWN state, and triggering a lot of random network issues.
> - New VM instances creation
> - Clean restart of the network
> Interestingly, when switching between offerings, it also recreates the VR, 
> but it doesn't do any duplicate this time.
> Analysis:
> This only impacts networks that were initially set as HA network with RvR 
> before the migration to 4.9.2. These networks keep the redundant flag to 1 in 
> the networks table, even though the offering redundant_router_service flag is 
> set to 0. I believe it should be changed to 0 when the network is using an 
> non-HA offering.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)