[jira] [Commented] (CLOUDSTACK-8746) VM Snapshotting implementation for KVM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


Github user Tosta-Mixta commented on the issue:

https://github.com/apache/cloudstack/pull/977
  
Many thanks for the work, very nice feature.


> VM Snapshotting implementation for KVM
> --
>
> Key: CLOUDSTACK-8746
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8746
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> Currently it is not supported.
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-9684) Invalid zone id error while listing vmware zones

[Sateesh Chodapuneedi (JIRA)]

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

Sateesh Chodapuneedi reassigned CLOUDSTACK-9684:


Assignee: Sateesh Chodapuneedi

> Invalid zone id error while listing vmware zones
> 
>
> Key: CLOUDSTACK-9684
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9684
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
> Fix For: 4.10.0.0
>
>
> When we select a VMware zone in the UI, listvmwaredcs API gets called and for 
> a legacy zone it throws a 'Invalid zone id error while listing VMware zones'.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9684) Invalid zone id error while listing vmware zones

[Sateesh Chodapuneedi (JIRA)]

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

Sateesh Chodapuneedi updated CLOUDSTACK-9684:
-
Fix Version/s: 4.10.0.0

> Invalid zone id error while listing vmware zones
> 
>
> Key: CLOUDSTACK-9684
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9684
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
> Fix For: 4.10.0.0
>
>
> When we select a VMware zone in the UI, listvmwaredcs API gets called and for 
> a legacy zone it throws a 'Invalid zone id error while listing VMware zones'.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9684) Invalid zone id error while listing vmware zones

[Sateesh Chodapuneedi (JIRA)]

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

Sateesh Chodapuneedi updated CLOUDSTACK-9684:
-
Affects Version/s: 4.9.0.1

> Invalid zone id error while listing vmware zones
> 
>
> Key: CLOUDSTACK-9684
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9684
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
> Fix For: 4.10.0.0
>
>
> When we select a VMware zone in the UI, listvmwaredcs API gets called and for 
> a legacy zone it throws a 'Invalid zone id error while listing VMware zones'.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9683:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1839
  
Trillian test result (tid-691)
Environment: kvm-centos6 (x2), Advanced Networking with Mgmt server 6
Total time taken: 27285 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1839-t691-kvm-centos6.zip
Test completed. 45 look ok, 3 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_04_rvpc_privategw_static_routes | `Failure` | 371.36 | 
test_privategw_acl.py
ContextSuite context=TestTemplates>:setup | `Error` | 339.95 | 
test_templates.py
test_oobm_zchange_password | `Error` | 15.34 | test_outofbandmanagement.py
ContextSuite context=TestListIdsParams>:setup | `Error` | 0.00 | 
test_list_ids_parameter.py
test_01_vpc_site2site_vpn | Success | 170.53 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 66.34 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 266.50 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 327.58 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 639.88 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 528.36 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1342.17 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 554.44 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 766.04 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1313.50 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 15.49 | test_volumes.py
test_08_resize_volume | Success | 15.44 | test_volumes.py
test_07_resize_fail | Success | 20.54 | test_volumes.py
test_06_download_detached_volume | Success | 15.37 | test_volumes.py
test_05_detach_volume | Success | 100.24 | test_volumes.py
test_04_delete_attached_volume | Success | 10.26 | test_volumes.py
test_03_download_attached_volume | Success | 15.35 | test_volumes.py
test_02_attach_volume | Success | 74.86 | test_volumes.py
test_01_create_volume | Success | 861.76 | test_volumes.py
test_deploy_vm_multiple | Success | 293.08 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.71 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.30 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 41.00 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.13 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 125.95 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 125.93 | test_vm_life_cycle.py
test_02_start_vm | Success | 10.20 | test_vm_life_cycle.py
test_01_stop_vm | Success | 40.37 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 70.71 | test_templates.py
test_01_create_template | Success | 60.66 | test_templates.py
test_10_destroy_cpvm | Success | 161.97 | test_ssvm.py
test_09_destroy_ssvm | Success | 164.04 | test_ssvm.py
test_08_reboot_cpvm | Success | 101.72 | test_ssvm.py
test_07_reboot_ssvm | Success | 133.90 | test_ssvm.py
test_06_stop_cpvm | Success | 131.95 | test_ssvm.py
test_05_stop_ssvm | Success | 163.91 | test_ssvm.py
test_04_cpvm_internals | Success | 1.62 | test_ssvm.py
test_03_ssvm_internals | Success | 3.72 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.12 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.12 | test_ssvm.py
test_04_change_offering_small | Success | 267.72 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.06 | test_service_offerings.py
test_01_create_service_offering | Success | 0.12 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.12 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.18 | test_secondary_storage.py
test_09_reboot_router | Success | 40.40 | test_routers.py
test_08_start_router | Success | 35.36 | test_routers.py
test_07_stop_router | Success | 10.18 | test_routers.py
test_06_router_advanced | Success | 0.06 | test_routers.py
test_05_router_basic | Success | 0.05 | test_routers.py
test_04_restart_network_wo_cleanup | Success | 5.76 | test_routers.py
test_03_restart_network_cleanup | Success | 65.61 | test_routers.py
test_02_router_internal_adv | Success | 1.12 | test_routers.py

[jira] [Commented] (CLOUDSTACK-8746) VM Snapshotting implementation for KVM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


Github user asaivan commented on the issue:

https://github.com/apache/cloudstack/pull/977
  
Would be great to get this integrated, thanks for working on this, guys.  
Our organization really needs it right now.


> VM Snapshotting implementation for KVM
> --
>
> Key: CLOUDSTACK-8746
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8746
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> Currently it is not supported.
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8746) VM Snapshotting implementation for KVM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


Github user ozhanrk commented on the issue:

https://github.com/apache/cloudstack/pull/977
  
great news   thanks @ustcweizhou @kiwiflyer 


> VM Snapshotting implementation for KVM
> --
>
> Key: CLOUDSTACK-8746
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8746
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> Currently it is not supported.
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8746) VM Snapshotting implementation for KVM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/977
  
@kiwiflyer that's very good. I will rebase it , and add the restriction.


> VM Snapshotting implementation for KVM
> --
>
> Key: CLOUDSTACK-8746
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8746
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> Currently it is not supported.
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8746) VM Snapshotting implementation for KVM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


Github user kiwiflyer commented on the issue:

https://github.com/apache/cloudstack/pull/977
  
@ustcweizhou If you rebase it, I'll get it tested. The last time I tested 
this PR, it was looking really good. The only thing it needed was some 
restriction so that it returned an error if the primary storage wasn't NFS.


> VM Snapshotting implementation for KVM
> --
>
> Key: CLOUDSTACK-8746
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8746
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> Currently it is not supported.
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8746) VM Snapshotting implementation for KVM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/977
  
@luhaijiao @rhtyd @ozhanrk sorry I have no testing env running with 
4.9/4.10 or master. Although I can rebase the PR against latest master, I 
cannot test it . It is irresponsible to push a PR without enough testing.


> VM Snapshotting implementation for KVM
> --
>
> Key: CLOUDSTACK-8746
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8746
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> Currently it is not supported.
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8746) VM Snapshotting implementation for KVM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


Github user ozhanrk commented on the issue:

https://github.com/apache/cloudstack/pull/977
  
Hi, any news on this pr? 


> VM Snapshotting implementation for KVM
> --
>
> Key: CLOUDSTACK-8746
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8746
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> Currently it is not supported.
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9683:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1839
  
@abhinandanprateek a Trillian-Jenkins test job (centos6 mgmt + kvm-centos6) 
has been kicked to run smoke tests


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9652) Job framework - Cancelling async jobs

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9652:
---

## Todo texto digitado acima será adicionado no ticket [[[83]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#83 - [jira] [Commented] (CLOUDSTACK-9652) Job framework - Cancelling async 
jobs

Criado por Anshul Gangwar (JIRA) em 19/12/2016 09:53:10




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/83
[2] https://brascloud.acelerato.com/tickets/83
[3] http://www.acelerato.com


> Job framework - Cancelling async jobs
> -
>
> Key: CLOUDSTACK-9652
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9652
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>
> enable cancellation of long running or subsequent queued up async jobs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9652) Job framework - Cancelling async jobs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9652:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1832
  
@marcaurele out for the next three days. will get back
@rhtyd marvin test is in progress. I will take it up in a separate PR. 
Regarding squashing, a humongous commit would be difficult. I already 
grouped them into individual logical units.


> Job framework - Cancelling async jobs
> -
>
> Key: CLOUDSTACK-9652
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9652
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>
> enable cancellation of long running or subsequent queued up async jobs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9683:
---

## Todo texto digitado acima será adicionado no ticket [[[80]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#80 - [jira] [Created] (CLOUDSTACK-9683) system.vm.default.hypervisor Does 
Not Pin Hypervisor Type of Virtual Routers

Criado por Anshul Gangwar (JIRA) em 19/12/2016 09:44:07




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/80
[2] https://brascloud.acelerato.com/tickets/80
[3] http://www.acelerato.com


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9683:
---

## Todo texto digitado acima será adicionado no ticket [[[78]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#78 - [jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does 
Not Pin Hypervisor Type of Virtual Routers

Criado por Anshul Gangwar (JIRA) em 19/12/2016 09:43:04




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/78
[2] https://brascloud.acelerato.com/tickets/78
[3] http://www.acelerato.com


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9683:
---

## Todo texto digitado acima será adicionado no ticket [[[77]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#77 - [jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does 
Not Pin Hypervisor Type of Virtual Routers

Criado por Anshul Gangwar (JIRA) em 19/12/2016 09:42:18




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/77
[2] https://brascloud.acelerato.com/tickets/77
[3] http://www.acelerato.com


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9363) Can't start a Xen HVM vm when more than 2 volumes attached

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9363:
---

## Todo texto digitado acima será adicionado no ticket [[[76]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#76 - [jira] [Commented] (CLOUDSTACK-9363) Can't start a Xen HVM vm when 
more than 2 volumes attached

Criado por Anshul Gangwar (JIRA) em 19/12/2016 09:38:34




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/76
[2] https://brascloud.acelerato.com/tickets/76
[3] http://www.acelerato.com


> Can't start a Xen HVM vm when more than 2 volumes attached
> --
>
> Key: CLOUDSTACK-9363
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9363
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.7.1
> Environment: XenServer 6.5
> HVM template
>Reporter: Simon Godard
>Priority: Critical
>
> Starting a HVM VM fails on XenServer fails when more than 2 volumes are 
> attached to the vm. Attaching the volumes while the vm is running is fine.
> PV vms are not affected by this problem. The bug seems to have been 
> introduced in this bug fix: 
> https://issues.apache.org/jira/browse/CLOUDSTACK-8826
> Mailing list discussion: http://markmail.org/thread/4nmyra6aofxtu3o2



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9683:
---

## Todo texto digitado acima será adicionado no ticket [[[75]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#75 - [jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does 
Not Pin Hypervisor Type of Virtual Routers

Criado por Anshul Gangwar (JIRA) em 19/12/2016 09:35:55




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/75
[2] https://brascloud.acelerato.com/tickets/75
[3] http://www.acelerato.com


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9363) Can't start a Xen HVM vm when more than 2 volumes attached

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9363:
---

## Todo texto digitado acima será adicionado no ticket [[[67]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#67 - [jira] [Commented] (CLOUDSTACK-9363) Can't start a Xen HVM vm when 
more than 2 volumes attached

Criado por Anshul Gangwar (JIRA) em 19/12/2016 09:10:05




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/67
[2] https://brascloud.acelerato.com/tickets/67
[3] http://www.acelerato.com


> Can't start a Xen HVM vm when more than 2 volumes attached
> --
>
> Key: CLOUDSTACK-9363
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9363
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.7.1
> Environment: XenServer 6.5
> HVM template
>Reporter: Simon Godard
>Priority: Critical
>
> Starting a HVM VM fails on XenServer fails when more than 2 volumes are 
> attached to the vm. Attaching the volumes while the vm is running is fine.
> PV vms are not affected by this problem. The bug seems to have been 
> introduced in this bug fix: 
> https://issues.apache.org/jira/browse/CLOUDSTACK-8826
> Mailing list discussion: http://markmail.org/thread/4nmyra6aofxtu3o2



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9363) Can't start a Xen HVM vm when more than 2 volumes attached

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9363:


Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1829
  
Changes LGTM. As @syed mentioned there is a workaround, so won't qualify as 
a blocker. 


> Can't start a Xen HVM vm when more than 2 volumes attached
> --
>
> Key: CLOUDSTACK-9363
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9363
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.7.1
> Environment: XenServer 6.5
> HVM template
>Reporter: Simon Godard
>Priority: Critical
>
> Starting a HVM VM fails on XenServer fails when more than 2 volumes are 
> attached to the vm. Attaching the volumes while the vm is running is fine.
> PV vms are not affected by this problem. The bug seems to have been 
> introduced in this bug fix: 
> https://issues.apache.org/jira/browse/CLOUDSTACK-8826
> Mailing list discussion: http://markmail.org/thread/4nmyra6aofxtu3o2



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9683:
---

## Todo texto digitado acima será adicionado no ticket [[[65]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#65 - [jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does 
Not Pin Hypervisor Type of Virtual Routers

Criado por Anshul Gangwar (JIRA) em 19/12/2016 08:31:04




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/65
[2] https://brascloud.acelerato.com/tickets/65
[3] http://www.acelerato.com


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9683:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1839
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-403


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9683:
---

## Todo texto digitado acima será adicionado no ticket [[[59]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#59 - [jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does 
Not Pin Hypervisor Type of Virtual Routers

Criado por Anshul Gangwar (JIRA) em 19/12/2016 07:56:04




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/59
[2] https://brascloud.acelerato.com/tickets/59
[3] http://www.acelerato.com


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9683:
---

## Todo texto digitado acima será adicionado no ticket [[[58]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#58 - [jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does 
Not Pin Hypervisor Type of Virtual Routers

Criado por Anshul Gangwar (JIRA) em 19/12/2016 07:55:06




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/58
[2] https://brascloud.acelerato.com/tickets/58
[3] http://www.acelerato.com


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9683:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1839
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9683:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1839
  
@blueorangutan package


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9683:
---

## Todo texto digitado acima será adicionado no ticket [[[56]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#56 - [jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does 
Not Pin Hypervisor Type of Virtual Routers

Criado por Anshul Gangwar (JIRA) em 19/12/2016 07:52:00




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/56
[2] https://brascloud.acelerato.com/tickets/56
[3] http://www.acelerato.com


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9683:
---

## Todo texto digitado acima será adicionado no ticket [[[55]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#55 - [jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does 
Not Pin Hypervisor Type of Virtual Routers

Criado por Anshul Gangwar (JIRA) em 19/12/2016 07:50:57




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/55
[2] https://brascloud.acelerato.com/tickets/55
[3] http://www.acelerato.com


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9683:
---

## Todo texto digitado acima será adicionado no ticket [[[54]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#54 - [jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does 
Not Pin Hypervisor Type of Virtual Routers

Criado por Anshul Gangwar (JIRA) em 19/12/2016 07:48:10




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/54
[2] https://brascloud.acelerato.com/tickets/54
[3] http://www.acelerato.com


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9683:
---

## Todo texto digitado acima será adicionado no ticket [[[52]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#52 - [jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does 
Not Pin Hypervisor Type of Virtual Routers

Criado por Anshul Gangwar (JIRA) em 19/12/2016 07:47:03




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/52
[2] https://brascloud.acelerato.com/tickets/52
[3] http://www.acelerato.com


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9683:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1839
  
@abhinandanprateek a Trillian-Jenkins test job (centos6 mgmt + kvm-centos6) 
has been kicked to run smoke tests


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9683:


Github user abhinandanprateek commented on the issue:

https://github.com/apache/cloudstack/pull/1839
  
@blueorangutan test centos6 kvm-centos6


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9683:
---

## Todo texto digitado acima será adicionado no ticket [[[51]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#51 - [jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does 
Not Pin Hypervisor Type of Virtual Routers

Criado por Anshul Gangwar (JIRA) em 19/12/2016 07:45:03




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/51
[2] https://brascloud.acelerato.com/tickets/51
[3] http://www.acelerato.com


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9683) system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9683:


Github user abhinandanprateek commented on the issue:

https://github.com/apache/cloudstack/pull/1839
  
@blueorangutan help


> system.vm.default.hypervisor Does Not Pin Hypervisor Type of Virtual Routers
> 
>
> Key: CLOUDSTACK-9683
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9683
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.2.0
>
>
> The system.vm.default.hypervisor global setting should pin the type of 
> hypervisor on which VRs are created. Therefore, if a user VM is created in a 
> VMware cluster with a new isolated network, the associated VR should be 
> created on a KVM host. However, the VR is being created on the same 
> hypervisor as the user VM instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9620) KVM Improvements for Managed Storage

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9620:
---

## Todo texto digitado acima será adicionado no ticket [[[47]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#47 - [jira] [Commented] (CLOUDSTACK-9620) KVM Improvements for Managed 
Storage

Criado por Anshul Gangwar (JIRA) em 19/12/2016 07:19:12




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/47
[2] https://brascloud.acelerato.com/tickets/47
[3] http://www.acelerato.com


> KVM Improvements for Managed Storage
> 
>
> Key: CLOUDSTACK-9620
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9620
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Management Server
>Affects Versions: Future
> Environment: KVM
>Reporter: Mike Tutkowski
> Fix For: Future
>
>
> Allow zone-wide primary storage based on a custom plug-in to be added via the 
> GUI in a KVM-only environment.
> Support for root disks on managed storage with KVM
> Template caching with managed storage and KVM
> Support for volume snapshots with managed storage on KVM
> Added the ability to revert a volume to a snapshot on KVM
> Updated some integration tests
> Enforce that a SolidFire volume’s Min IOPS cannot exceed 15,000 and its Max 
> and Burst IOPS cannot exceed 100,000.
> A SolidFire volume must be at least one GB.
> The storage driver should not remove the row from the 
> cloud.template_spool_ref table.
> Enable cluster-scoped managed storage
> Only volumes from zone-wide managed storage can be storage motioned from a 
> host in one cluster to a host in another cluster (cannot do so at the time 
> being with volumes from cluster-scoped managed storage).
> Updates for SAN-assisted snapshots



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9456) Migrate master to use Java8 and Spring4

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9456:
---

## Todo texto digitado acima será adicionado no ticket [[[43]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#43 - [jira] [Commented] (CLOUDSTACK-9456) Migrate master to use Java8 and 
Spring4

Criado por Anshul Gangwar (JIRA) em 19/12/2016 06:20:01




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/43
[2] https://brascloud.acelerato.com/tickets/43
[3] http://www.acelerato.com


> Migrate master to use Java8 and Spring4
> ---
>
> Key: CLOUDSTACK-9456
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9456
> 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.10.0.0
>
>
> We need to move master to use Java8 and Spring4.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9619:
---

## Todo texto digitado acima será adicionado no ticket [[[42]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#42 - [jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600

Criado por Anshul Gangwar (JIRA) em 19/12/2016 06:19:09




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/42
[2] https://brascloud.acelerato.com/tickets/42
[3] http://www.acelerato.com


> Fixes for PR 1600
> -
>
> Key: CLOUDSTACK-9619
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619
> 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
> Environment: All
>Reporter: Mike Tutkowski
> Fix For: 4.10.0.0
>
>
> In StorageSystemDataMotionStrategy.performCopyOfVdi we call 
> getSnapshotDetails. In one such scenario, the source snapshot in question is 
> coming from secondary storage (when we are creating a new volume on managed 
> storage from a snapshot of ours that’s on secondary storage).
> This usually “worked” in the regression tests due to a bit of "luck": We 
> retrieve the ID of the snapshot (which is on secondary storage) and then try 
> to pull out its StorageVO object (which is for primary storage). If you 
> happen to have a primary storage that matches the ID (which is the ID of a 
> secondary storage), then getSnapshotDetails populates its Map 
> with inapplicable data (that is later ignored) and you don’t easily see a 
> problem. However, if you don’t have a primary storage that matches that ID 
> (which I didn’t today because I had removed that primary storage), then a 
> NullPointerException is thrown.
> I have fixed that issue by skipping getSnapshotDetails if the source is 
> coming from secondary storage.
> While fixing that, I noticed a couple more problems:
>   We can invoke grantAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
>   We can invoke revokeAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
> I have corrected those issues, as well.
> I then came across one more problem:
> · When using a SAN snapshot and copying it to secondary storage or creating a 
> new managed-storage volume from a snapshot of ours on secondary storage, we 
> attach to the SR in the XenServer code, but detach from it in the 
> StorageSystemDataMotionStrategy code (by sending a message to the XenServer 
> code to perform an SR detach). Since we know to detach from the SR after the 
> copy is done, we should detach from the SR in the XenServer code (without 
> that code having to be explicitly called from outside of the XenServer logic).
> I went ahead and changed that, as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9456) Migrate master to use Java8 and Spring4

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9456:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1638
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-398


> Migrate master to use Java8 and Spring4
> ---
>
> Key: CLOUDSTACK-9456
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9456
> 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.10.0.0
>
>
> We need to move master to use Java8 and Spring4.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9619:
---

## Todo texto digitado acima será adicionado no ticket [[[40]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#40 - [jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600

Criado por Anshul Gangwar (JIRA) em 19/12/2016 06:19:02




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/40
[2] https://brascloud.acelerato.com/tickets/40
[3] http://www.acelerato.com


> Fixes for PR 1600
> -
>
> Key: CLOUDSTACK-9619
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619
> 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
> Environment: All
>Reporter: Mike Tutkowski
> Fix For: 4.10.0.0
>
>
> In StorageSystemDataMotionStrategy.performCopyOfVdi we call 
> getSnapshotDetails. In one such scenario, the source snapshot in question is 
> coming from secondary storage (when we are creating a new volume on managed 
> storage from a snapshot of ours that’s on secondary storage).
> This usually “worked” in the regression tests due to a bit of "luck": We 
> retrieve the ID of the snapshot (which is on secondary storage) and then try 
> to pull out its StorageVO object (which is for primary storage). If you 
> happen to have a primary storage that matches the ID (which is the ID of a 
> secondary storage), then getSnapshotDetails populates its Map 
> with inapplicable data (that is later ignored) and you don’t easily see a 
> problem. However, if you don’t have a primary storage that matches that ID 
> (which I didn’t today because I had removed that primary storage), then a 
> NullPointerException is thrown.
> I have fixed that issue by skipping getSnapshotDetails if the source is 
> coming from secondary storage.
> While fixing that, I noticed a couple more problems:
>   We can invoke grantAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
>   We can invoke revokeAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
> I have corrected those issues, as well.
> I then came across one more problem:
> · When using a SAN snapshot and copying it to secondary storage or creating a 
> new managed-storage volume from a snapshot of ours on secondary storage, we 
> attach to the SR in the XenServer code, but detach from it in the 
> StorageSystemDataMotionStrategy code (by sending a message to the XenServer 
> code to perform an SR detach). Since we know to detach from the SR after the 
> copy is done, we should detach from the SR in the XenServer code (without 
> that code having to be explicitly called from outside of the XenServer logic).
> I went ahead and changed that, as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9619:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1749
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-396


> Fixes for PR 1600
> -
>
> Key: CLOUDSTACK-9619
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619
> 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
> Environment: All
>Reporter: Mike Tutkowski
> Fix For: 4.10.0.0
>
>
> In StorageSystemDataMotionStrategy.performCopyOfVdi we call 
> getSnapshotDetails. In one such scenario, the source snapshot in question is 
> coming from secondary storage (when we are creating a new volume on managed 
> storage from a snapshot of ours that’s on secondary storage).
> This usually “worked” in the regression tests due to a bit of "luck": We 
> retrieve the ID of the snapshot (which is on secondary storage) and then try 
> to pull out its StorageVO object (which is for primary storage). If you 
> happen to have a primary storage that matches the ID (which is the ID of a 
> secondary storage), then getSnapshotDetails populates its Map 
> with inapplicable data (that is later ignored) and you don’t easily see a 
> problem. However, if you don’t have a primary storage that matches that ID 
> (which I didn’t today because I had removed that primary storage), then a 
> NullPointerException is thrown.
> I have fixed that issue by skipping getSnapshotDetails if the source is 
> coming from secondary storage.
> While fixing that, I noticed a couple more problems:
>   We can invoke grantAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
>   We can invoke revokeAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
> I have corrected those issues, as well.
> I then came across one more problem:
> · When using a SAN snapshot and copying it to secondary storage or creating a 
> new managed-storage volume from a snapshot of ours on secondary storage, we 
> attach to the SR in the XenServer code, but detach from it in the 
> StorageSystemDataMotionStrategy code (by sending a message to the XenServer 
> code to perform an SR detach). Since we know to detach from the SR after the 
> copy is done, we should detach from the SR in the XenServer code (without 
> that code having to be explicitly called from outside of the XenServer logic).
> I went ahead and changed that, as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9682) Block VM migration to a storage which is in maintainence mode

[BRASCLOUD (JIRA)]

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

BRASCLOUD commented on CLOUDSTACK-9682:
---

## Todo texto digitado acima será adicionado no ticket [[[38]]] ##



Olá, Anshul Gangwar (JIRA).



O seu ticket foi aberto com sucesso em nosso Suporte.


[1]#38 - [jira] [Commented] (CLOUDSTACK-9682) Block VM migration to a storage 
which is in maintainence mode

Criado por Anshul Gangwar (JIRA) em 19/12/2016 06:09:52




Para visualizar o ticket completo, [2]clique aqui








[3]Acelerato

[1] https://brascloud.acelerato.com/tickets/38
[2] https://brascloud.acelerato.com/tickets/38
[3] http://www.acelerato.com


> Block VM migration to a storage which is in maintainence mode
> -
>
> Key: CLOUDSTACK-9682
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9682
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> Description
> Put vmfs storage pool (cluster wide/zone wide) in maintenance mode and try to 
> migrate a VM through api call to that storage pool
> Steps
> 1. Put one of the storage pool in a cluster in maintenance mode
> 2. From api call, migrate VM from one cluster to another to the above storage 
> pool
> 3. Even though the storage pool is in maintenance mode, the migration task is 
> initiated and completed without any error
> Expectation
> CloudStack should block these kind of migration



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)