[jira] [Commented] (CLOUDSTACK-9111) cloudstack-management start failed (CloudStack 4.6.1 + CentOS7)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043751#comment-15043751 ] satoru nakaya commented on CLOUDSTACK-9111: --- It worked fine. [root@acs ~]# cloudstack-setup-management --tomcat7 Starting to configure CloudStack Management Server: Configure Firewall ...[OK] Configure CloudStack Management Server ...[OK] CloudStack Management Server setup is Done! [root@acs ~]# [root@acs ~]# ls -la /etc/cloudstack/management total 136 drwxr-xr-x. 3 root root 4096 Dec 6 16:54 . drwxr-xr-x. 4 root root 4096 Dec 5 19:36 .. drwxrwx---. 3 root cloud 4096 Dec 5 18:52 Catalina -rw-r--r--. 1 root root 8945 Dec 1 20:22 catalina.policy -rw-r--r--. 1 root root 3794 Dec 1 20:22 catalina.properties -rw-r--r--. 1 root root 1653 Dec 1 20:22 classpath.conf -rw-r--r--. 1 root root 2211 Dec 6 10:13 cloudmanagementserver.keystore -rw-r--r--. 1 root root 1357 Dec 1 20:22 commons-logging.properties -rw-r-. 1 root cloud 3137 Dec 5 18:56 db.properties -rw-r--r--. 1 root root979 Dec 1 20:22 environment.properties -rw-r--r--. 1 root root927 Dec 1 20:22 java.security.ciphers -rw-r--r--. 1 root root 8 Dec 5 18:54 key -rw-r--r--. 1 root root 7020 Dec 1 20:22 log4j-cloud.xml -rw-r--r--. 1 root root 6722 Dec 1 20:22 server7-nonssl.xml -rw-r--r--. 1 root root 7251 Dec 1 20:22 server7-ssl.xml lrwxrwxrwx. 1 root root 45 Dec 6 16:54 server.xml -> /etc/cloudstack/management/server7-nonssl.xml -rw-r--r--. 1 root root 1383 Dec 1 20:22 tomcat-users.xml -rw-r--r--. 1 root root 50475 Dec 1 20:22 web.xml [root@acs ~]# [root@acs ~]# systemctl status cloudstack-management.service cloudstack-management.service - CloudStack Management Server Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service; enabled) Active: inactive (dead) since Sun 2015-12-06 16:51:51 JST; 3min 6s ago Main PID: 3164 (code=exited, status=143) CGroup: /system.slice/cloudstack-management.service Dec 06 16:51:51 acs.dom.local server[3164]: Dec 06, 2015 4:51:51 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads Dec 06 16:51:51 acs.dom.local server[3164]: SEVERE: The web application [/client] appears to have started a thread named [FileWatchdog] but has failed...ory leak. Dec 06 16:51:51 acs.dom.local server[3164]: Dec 06, 2015 4:51:51 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads Dec 06 16:51:51 acs.dom.local server[3164]: SEVERE: The web application [/client] appears to have started a thread named [AgentManager-Handler-1] but ...ory leak. Dec 06 16:51:51 acs.dom.local systemd[1]: Stopped CloudStack Management Server. Dec 06 16:53:00 acs.dom.local systemd[1]: Stopped CloudStack Management Server. Dec 06 16:53:14 acs.dom.local systemd[1]: Stopped CloudStack Management Server. Dec 06 16:53:36 acs.dom.local systemd[1]: Stopped CloudStack Management Server. Dec 06 16:54:13 acs.dom.local systemd[1]: Stopped CloudStack Management Server. Dec 06 16:54:35 acs.dom.local systemd[1]: Stopped CloudStack Management Server. Hint: Some lines were ellipsized, use -l to show in full. [root@acs ~]# [root@acs ~]# systemctl start cloudstack-management.service [root@acs ~]# [root@acs ~]# systemctl status cloudstack-management.service cloudstack-management.service - CloudStack Management Server Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service; enabled) Active: active (running) since Sun 2015-12-06 16:55:42 JST; 2s ago Main PID: 11377 (java) CGroup: /system.slice/cloudstack-management.service mq11377 java -Djava.awt.headless=true -Dcom.sun.management.jmxremote=false -Xmx2g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/cloudsta... Dec 06 16:55:43 acs.dom.local server[11377]: Dec 06, 2015 4:55:43 PM org.apache.coyote.AbstractProtocol init Dec 06 16:55:43 acs.dom.local server[11377]: INFO: Initializing ProtocolHandler ["ajp-bio-20400"] Dec 06 16:55:43 acs.dom.local server[11377]: Dec 06, 2015 4:55:43 PM org.apache.catalina.startup.Catalina load Dec 06 16:55:43 acs.dom.local server[11377]: INFO: Initialization processed in 1092 ms Dec 06 16:55:43 acs.dom.local server[11377]: Dec 06, 2015 4:55:43 PM org.apache.catalina.core.StandardService startInternal Dec 06 16:55:43 acs.dom.local server[11377]: INFO: Starting service Catalina Dec 06 16:55:43 acs.dom.local server[11377]: Dec 06, 2015 4:55:43 PM org.apache.catalina.core.StandardEngine startInternal Dec 06 16:55:43 acs.dom.local server[11377]: INFO: Starting Servlet Engine: Apache Tomcat/7.0.54 Dec 06 16:55:43 acs.dom.local server[11377]: Dec 06, 2015 4:55:43 PM org.apache.catalina.startup.HostConfig deployDirectory Dec 06 16:55:43 acs.dom.local server[11377]: INFO: Deploying web application directory /usr/share/cloudstack-management/webapps/client [root@acs ~]# > cloudstack-management start failed (C
[jira] [Closed] (CLOUDSTACK-9111) cloudstack-management start failed (CloudStack 4.6.1 + CentOS7)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] satoru nakaya closed CLOUDSTACK-9111. - Resolution: Not A Problem In the case of centos7: cloudstack-setup-management --tomcat7 > cloudstack-management start failed (CloudStack 4.6.1 + CentOS7) > --- > > Key: CLOUDSTACK-9111 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9111 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.1 > Environment: CloudStack 4.6.1 , CentOS7 > http://packages.shapeblue.com/cloudstack/upstream/centos7/4.6/ >Reporter: satoru nakaya > > Steps to reproduce: > 1)clean install CloudStack 4.6.1 on CentOS7 > use http://packages.shapeblue.com/cloudstack/upstream/centos7/4.6/ > [root@acs ~]# cat /etc/redhat-release > CentOS Linux release 7.1.1503 (Core) > [root@acs ~]# > [root@acs ~]# rpm -qa | grep cloudstack > cloudstack-management-4.6.1-shapeblue0.el7.centos.x86_64 > cloudstack-common-4.6.1-shapeblue0.el7.centos.x86_64 > [root@acs ~]# > 2)cloudstack-setup-databases...(snip) > 3)cloudstack-setup-management (Failed) > [root@acs ~]# cloudstack-setup-management > Starting to configure CloudStack Management Server: > Configure Firewall ...[OK] > Configure CloudStack Management Server ...[Failed] > Cannot find /etc/cloudstack/management/server-nonssl.xml or > /etc/cloudstack/management/tomcat6-nonssl.conf, https enable failed > Try to restore your system: > Restore Firewall ... [OK] > Restore CloudStack Management Server ...[OK] > [root@acs ~]# > 4)check log (/var/log/messages) > Dec 6 10:08:51 acs server: WARNING: Unable to load server configuration from > [/usr/share/cloudstack-management/conf/server.xml] > 5)check service status (failed) > [root@acs ~]# systemctl status cloudstack-management.service > cloudstack-management.service - CloudStack Management Server >Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service; > enabled) >Active: failed (Result: exit-code) since Sun 2015-12-06 10:08:52 JST; 11s > ago > Process: 3061 ExecStop=/usr/libexec/tomcat/server stop (code=exited, > status=1/FAILURE) > Process: 3026 ExecStart=/usr/libexec/tomcat/server start (code=exited, > status=0/SUCCESS) > Main PID: 3026 (code=exited, status=0/SUCCESS) > Dec 06 10:08:52 acs.dom.local server[3061]: at > java.io.FileInputStream.(FileInputStream.java:146) > Dec 06 10:08:52 acs.dom.local server[3061]: at > org.apache.catalina.startup.Catalina.stopServer(Catalina.java:466) > Dec 06 10:08:52 acs.dom.local server[3061]: at > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > Dec 06 10:08:52 acs.dom.local server[3061]: at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > Dec 06 10:08:52 acs.dom.local server[3061]: at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI...va:43) > Dec 06 10:08:52 acs.dom.local server[3061]: at > java.lang.reflect.Method.invoke(Method.java:606) > Dec 06 10:08:52 acs.dom.local server[3061]: at > org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:370) > Dec 06 10:08:52 acs.dom.local server[3061]: at > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:457) > Dec 06 10:08:52 acs.dom.local systemd[1]: cloudstack-management.service: > control process exited, code=exited status=1 > Dec 06 10:08:52 acs.dom.local systemd[1]: Unit cloudstack-management.service > entered failed state. > Hint: Some lines were ellipsized, use -l to show in full. > [root@acs ~]# > workaround: > The correct do not know whether or not , but it worked. > 6)check file > [root@acs ~]# ls -la /etc/cloudstack/management > total 132 > drwxr-xr-x. 3 root root 4096 Dec 5 17:59 . > drwxr-xr-x. 3 root root 4096 Dec 5 17:53 .. > drwxrwx---. 3 root cloud 4096 Dec 5 17:53 Catalina > -rw-r--r--. 1 root root 8945 Dec 1 20:22 catalina.policy > -rw-r--r--. 1 root root 3794 Dec 1 20:22 catalina.properties > -rw-r--r--. 1 root root 1653 Dec 1 20:22 classpath.conf > -rw-r--r--. 1 root root 1357 Dec 1 20:22 commons-logging.properties > -rw-r-. 1 root cloud 3137 Dec 5 17:59 db.properties > -rw-r--r--. 1 root root979 Dec 1 20:22 environment.properties > -rw-r--r--. 1 root root927 Dec 1 20:22 java.security.ciphers > -rw-r--r--. 1 root root 8 Dec 5 17:55 key > -rw-r--r--. 1 root root 7020 Dec 1 20:22 log4j-cloud.xml > -rw-r--r--. 1 root root 6722 Dec 1 20:22 server7-nonssl.xml > -rw-r--r--. 1 root root 7251 Dec 1 20:22 server7-ssl.xml > -rw-r--r--. 1 root root 1383 Dec 1 20:22 tomcat-users.xml > -rw-r--r--. 1 root root 50475 Dec 1 20:22 web.xml > [root@acs ~] > 7)copy file > [root@ac
[jira] [Commented] (CLOUDSTACK-9106) As a Developer I want the Redundant VPC private gateway feature fixed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043757#comment-15043757 ] ASF GitHub Bot commented on CLOUDSTACK-9106: Github user DaanHoogland commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1179#discussion_r46767881 --- Diff: plugins/network-elements/ovs/src/com/cloud/network/element/OvsElement.java --- @@ -488,50 +494,54 @@ public boolean applyPFRules(final Network network, final List As a Developer I want the Redundant VPC private gateway feature fixed > - > > Key: CLOUDSTACK-9106 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9106 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues > Fix For: 4.7.0 > > > Bug in BasicNetworkTopology.applyRules() method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8964) Can't create template or volume from snapshot - "Are you sure you got the right type of server?"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043762#comment-15043762
]
ASF GitHub Bot commented on CLOUDSTACK-8964:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1177#issuecomment-162286584
LGTM based on these tests:
```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
tags=advanced,required_hardware=true \
component/test_vpc_redundant.py \
component/test_routers_iptables_default_policy.py \
component/test_routers_network_ops.py \
component/test_vpc_router_nics.py \
smoke/test_loadbalance.py \
smoke/test_internal_lb.py \
smoke/test_ssvm.py \
smoke/test_network.py
```
Result:
```
Create a redundant VPC with two networks with two VMs in each network ...
=== TestName: test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Status :
SUCCESS ===
ok
Create a redundant VPC with two networks with two VMs in each network and
check default routes ... === TestName: test_02_redundant_VPC_default_routes |
Status : SUCCESS ===
ok
Create a redundant VPC with two networks with two VMs in each network ...
=== TestName:
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Status :
SUCCESS ===
ok
Test iptables default INPUT/FORWARD policy on RouterVM ... === TestName:
test_02_routervm_iptables_policies | Status : SUCCESS ===
ok
Test iptables default INPUT/FORWARD policies on VPC router ... ===
TestName: test_01_single_VPC_iptables_policies | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_01_isolate_network_FW_PF_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_02_isolate_network_FW_PF_default_routes_egress_false | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test nics
after destroy ... === TestName: test_01_VPC_nics_after_destroy | Status :
SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test default
routes ... === TestName: test_02_VPC_default_routes | Status : SUCCESS ===
ok
Check the password file in the Router VM ... === TestName:
test_isolate_network_password_server | Status : SUCCESS ===
ok
Check that the /etc/dhcphosts.txt doesn't contain duplicate IPs ... ===
TestName: test_router_dhcphosts | Status : SUCCESS ===
ok
Test to create Load balancing rule with source NAT ... === TestName:
test_01_create_lb_rule_src_nat | Status : SUCCESS ===
ok
Test to create Load balancing rule with non source NAT ... === TestName:
test_02_create_lb_rule_non_nat | Status : SUCCESS ===
ok
Test for assign & removing load balancing rule ... === TestName:
test_assign_and_removal_lb | Status : SUCCESS ===
ok
Test to verify access to loadbalancer haproxy admin stats page ... ===
TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS
===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic
to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80
| Status : SUCCESS ===
ok
Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status :
SUCCESS ===
ok
Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status :
SUCCESS ===
ok
Test stop SSVM ... === TestName: test_05_stop_ssvm | Status : SUCCESS ===
ok
Test stop CPVM ... === TestName: test_06_stop_cpvm | Status : SUCCESS ===
ok
Test reboot SSVM ... === TestName: test_07_reboot_ssvm | Status : SUCCESS
===
ok
Test reboot CPVM ... === TestName: test_08_reboot_cpvm | Status : SUCCESS
===
ok
Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : SUCCESS
===
ok
Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : SUCCESS
===
ok
Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn
| Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS
===
ok
Test for port forwarding on source NAT ... === TestName:
test_01_port_fwd_on_src_nat | Status : SUCCESS ===
ok
Test for port forwarding on non source NAT ... === TestName:
test_02_port_fwd_on_non_src_nat | Status : SUCCESS ===
ok
Test for reboot router ... === TestName: test_reboot_router | Status :
SUCCESS ===
ok
Test for Router rules for network rules on acquired pub
[jira] [Commented] (CLOUDSTACK-9106) As a Developer I want the Redundant VPC private gateway feature fixed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043767#comment-15043767
]
ASF GitHub Bot commented on CLOUDSTACK-9106:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1179#issuecomment-162287415
LGTM based on these tests:
```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
tags=advanced,required_hardware=true \
component/test_vpc_redundant.py \
component/test_routers_iptables_default_policy.py \
component/test_routers_network_ops.py \
component/test_vpc_router_nics.py \
smoke/test_loadbalance.py \
smoke/test_internal_lb.py \
smoke/test_ssvm.py \
smoke/test_network.py
```
Result:
```
Create a redundant VPC with two networks with two VMs in each network ...
=== TestName: test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Status :
SUCCESS ===
ok
Create a redundant VPC with two networks with two VMs in each network and
check default routes ... === TestName: test_02_redundant_VPC_default_routes |
Status : SUCCESS ===
ok
Create a redundant VPC with two networks with two VMs in each network ...
=== TestName:
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Status :
SUCCESS ===
ok
Test iptables default INPUT/FORWARD policy on RouterVM ... === TestName:
test_02_routervm_iptables_policies | Status : SUCCESS ===
ok
Test iptables default INPUT/FORWARD policies on VPC router ... ===
TestName: test_01_single_VPC_iptables_policies | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_01_isolate_network_FW_PF_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_02_isolate_network_FW_PF_default_routes_egress_false | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test nics
after destroy ... === TestName: test_01_VPC_nics_after_destroy | Status :
SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test default
routes ... === TestName: test_02_VPC_default_routes | Status : SUCCESS ===
ok
Check the password file in the Router VM ... === TestName:
test_isolate_network_password_server | Status : SUCCESS ===
ok
Check that the /etc/dhcphosts.txt doesn't contain duplicate IPs ... ===
TestName: test_router_dhcphosts | Status : SUCCESS ===
ok
Test to create Load balancing rule with source NAT ... === TestName:
test_01_create_lb_rule_src_nat | Status : SUCCESS ===
ok
Test to create Load balancing rule with non source NAT ... === TestName:
test_02_create_lb_rule_non_nat | Status : SUCCESS ===
ok
Test for assign & removing load balancing rule ... === TestName:
test_assign_and_removal_lb | Status : SUCCESS ===
ok
Test to verify access to loadbalancer haproxy admin stats page ... ===
TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS
===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic
to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80
| Status : SUCCESS ===
ok
Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status :
SUCCESS ===
ok
Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status :
SUCCESS ===
ok
Test stop SSVM ... === TestName: test_05_stop_ssvm | Status : SUCCESS ===
ok
Test stop CPVM ... === TestName: test_06_stop_cpvm | Status : SUCCESS ===
ok
Test reboot SSVM ... === TestName: test_07_reboot_ssvm | Status : SUCCESS
===
ok
Test reboot CPVM ... === TestName: test_08_reboot_cpvm | Status : SUCCESS
===
ok
Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : SUCCESS
===
ok
Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : SUCCESS
===
ok
Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn
| Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS
===
ok
Test for port forwarding on source NAT ... === TestName:
test_01_port_fwd_on_src_nat | Status : SUCCESS ===
ok
Test for port forwarding on non source NAT ... === TestName:
test_02_port_fwd_on_non_src_nat | Status : SUCCESS ===
ok
Test for reboot router ... === TestName: test_reboot_router | Status :
SUCCESS ===
ok
Test for Router rules for network rules on acquired pub
[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043819#comment-15043819 ] ASF GitHub Bot commented on CLOUDSTACK-9074: Github user miguelaferreira commented on the pull request: https://github.com/apache/cloudstack/pull/1094#issuecomment-162302939 @nvazquez I've been able to verify that the existing tests did not break with your PR, however I can't seem to get an NSX configuration for running the two additional test you added. Here's my network config: ``` start IP = 192.168.23.2 end IP = 192.168.23.20 netmask = 255.255.255.0 gateway = 192.168.23.1 ``` The VLAN config ``` VLAN= 50 VLAN_UUID = 2eea1553-837e-4a3e-bfbb-872c4cb2a49a ``` The VLAN_UUID is the UUID of a LRouter I've created in NSX. That LRouter is connected to an LSwitch. The pictures bellow show the LRouter and LSwitch. https://cloud.githubusercontent.com/assets/4670993/11612955/a094b276-9c0f-11e5-9774-657ae8b21f9f.png";> https://cloud.githubusercontent.com/assets/4670993/11612956/a64278ca-9c0f-11e5-8206-a8ab3afd0d96.png";> https://cloud.githubusercontent.com/assets/4670993/11612958/abe15d32-9c0f-11e5-8fd8-60f0d2f9bc59.png";> https://cloud.githubusercontent.com/assets/4670993/11612959/afd87a24-9c0f-11e5-92f6-08dfe0491c5a.png";> If you could help me fix my config, I'll test your PR today. > Support shared networking in NiciraNVP Plugin > - > > Key: CLOUDSTACK-9074 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9074 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Nicolas Vazquez > Fix For: 4.7.0 > > > h3. Introduction > Currently NiciraNVP plugin supports only Isolated networking. In this mode of > operations networks are assigned to individual Cloudstack accounts and on NSX > side are completely isolated on the L3 level. Many use cases especially in > corporate environment call for shared networking mode support. In some > circumstances there also may be a need to translate shared NSX network over > to a physical VLAN via L2 NSX gateway. > Features that will be introduced to support Cloudstack shared networks in two > modes of NiciraNVP plugin: > * Shared networks mapped to a physical VLAN with L2 NSX gateway > * Shared networks within the same L3 NSX domain. Multiple L3 NSX domains will > be supported. > h3. Features > h4. 1) Shared networking model support > # Support native Cloudstack shared network in NiciraNVP plugin. > # Current code that implements isolated networking mode support will stay > intact. > # Designate network service offering by configuring VirtualNetworking > provider with NiciraNVP. > # Static/Source NAT is not used and ignored if defined in the network > offering. > # Nicira_vvp_router_map table will support non-unique logical routers to > implement L3 NSX routing domains where multiple Cloudstack networks are > attached to the same logical router. > # Shared network with NSX based Virtual networking will go through the > following states: > ## Allocated > ## Implementing > ## Implemented > ## Destroy > h4. 2) Support NSX L2 gateways for L2 based VLANs mapped to a physical network > # Optional L2gatewayserviceuuid parameter for NiciraNVP controller > # VLAN ID of a Shared network represents VLAN to pass through L2 gateway > similar to native Cloudstack shared networking > # NSX workflow for network allocation > ## Check if l2gatewayservice defined > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_doamin > ### Vlan://vlan_id as broadcast_uri > ## Create record in VLAN table > # NSX workflow for network implementation > ## Check if l2gatewayservice defined and valid > ## Create logical switch > ## Map logical switch to L2gateway service assigning shared network VLAN ID > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 3) Support NSX L3 multiple routing domains > # VLAN ID of a Shared network represents an UUID of a NSX virtual router of a > particular routing domain. We will support UUID style notation for VLAN ID. > l3gatewayservice option is not used in shared networking > # It is assumed that if connectivity to the physical networking is required > then logical router is configured and connected to the physical network in > advance. NiciraNVP plugin will not perform any task beyond basic connectivity > to the logical router > # Support NSX L3 multiple routing domains > # NSX workflow for network allocation > ## Create record in networks ta
[jira] [Commented] (CLOUDSTACK-9111) cloudstack-management start failed (CloudStack 4.6.1 + CentOS7)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043822#comment-15043822 ] Rohit Yadav commented on CLOUDSTACK-9111: - This needs to be in docs, to use cloudstack-setup-management --tomcat7 on CentOS7 (if it's not in docs already). cc [~remibergsma] > cloudstack-management start failed (CloudStack 4.6.1 + CentOS7) > --- > > Key: CLOUDSTACK-9111 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9111 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.1 > Environment: CloudStack 4.6.1 , CentOS7 > http://packages.shapeblue.com/cloudstack/upstream/centos7/4.6/ >Reporter: satoru nakaya > > Steps to reproduce: > 1)clean install CloudStack 4.6.1 on CentOS7 > use http://packages.shapeblue.com/cloudstack/upstream/centos7/4.6/ > [root@acs ~]# cat /etc/redhat-release > CentOS Linux release 7.1.1503 (Core) > [root@acs ~]# > [root@acs ~]# rpm -qa | grep cloudstack > cloudstack-management-4.6.1-shapeblue0.el7.centos.x86_64 > cloudstack-common-4.6.1-shapeblue0.el7.centos.x86_64 > [root@acs ~]# > 2)cloudstack-setup-databases...(snip) > 3)cloudstack-setup-management (Failed) > [root@acs ~]# cloudstack-setup-management > Starting to configure CloudStack Management Server: > Configure Firewall ...[OK] > Configure CloudStack Management Server ...[Failed] > Cannot find /etc/cloudstack/management/server-nonssl.xml or > /etc/cloudstack/management/tomcat6-nonssl.conf, https enable failed > Try to restore your system: > Restore Firewall ... [OK] > Restore CloudStack Management Server ...[OK] > [root@acs ~]# > 4)check log (/var/log/messages) > Dec 6 10:08:51 acs server: WARNING: Unable to load server configuration from > [/usr/share/cloudstack-management/conf/server.xml] > 5)check service status (failed) > [root@acs ~]# systemctl status cloudstack-management.service > cloudstack-management.service - CloudStack Management Server >Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service; > enabled) >Active: failed (Result: exit-code) since Sun 2015-12-06 10:08:52 JST; 11s > ago > Process: 3061 ExecStop=/usr/libexec/tomcat/server stop (code=exited, > status=1/FAILURE) > Process: 3026 ExecStart=/usr/libexec/tomcat/server start (code=exited, > status=0/SUCCESS) > Main PID: 3026 (code=exited, status=0/SUCCESS) > Dec 06 10:08:52 acs.dom.local server[3061]: at > java.io.FileInputStream.(FileInputStream.java:146) > Dec 06 10:08:52 acs.dom.local server[3061]: at > org.apache.catalina.startup.Catalina.stopServer(Catalina.java:466) > Dec 06 10:08:52 acs.dom.local server[3061]: at > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > Dec 06 10:08:52 acs.dom.local server[3061]: at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > Dec 06 10:08:52 acs.dom.local server[3061]: at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI...va:43) > Dec 06 10:08:52 acs.dom.local server[3061]: at > java.lang.reflect.Method.invoke(Method.java:606) > Dec 06 10:08:52 acs.dom.local server[3061]: at > org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:370) > Dec 06 10:08:52 acs.dom.local server[3061]: at > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:457) > Dec 06 10:08:52 acs.dom.local systemd[1]: cloudstack-management.service: > control process exited, code=exited status=1 > Dec 06 10:08:52 acs.dom.local systemd[1]: Unit cloudstack-management.service > entered failed state. > Hint: Some lines were ellipsized, use -l to show in full. > [root@acs ~]# > workaround: > The correct do not know whether or not , but it worked. > 6)check file > [root@acs ~]# ls -la /etc/cloudstack/management > total 132 > drwxr-xr-x. 3 root root 4096 Dec 5 17:59 . > drwxr-xr-x. 3 root root 4096 Dec 5 17:53 .. > drwxrwx---. 3 root cloud 4096 Dec 5 17:53 Catalina > -rw-r--r--. 1 root root 8945 Dec 1 20:22 catalina.policy > -rw-r--r--. 1 root root 3794 Dec 1 20:22 catalina.properties > -rw-r--r--. 1 root root 1653 Dec 1 20:22 classpath.conf > -rw-r--r--. 1 root root 1357 Dec 1 20:22 commons-logging.properties > -rw-r-. 1 root cloud 3137 Dec 5 17:59 db.properties > -rw-r--r--. 1 root root979 Dec 1 20:22 environment.properties > -rw-r--r--. 1 root root927 Dec 1 20:22 java.security.ciphers > -rw-r--r--. 1 root root 8 Dec 5 17:55 key > -rw-r--r--. 1 root root 7020 Dec 1 20:22 log4j-cloud.xml > -rw-r--r--. 1 root root 6722 Dec 1 20:22 server7-nonssl.xml > -rw-r--r--. 1 root root 7251 Dec 1 20:22 server7-ssl.xml > -rw-r--r--. 1 root root 1383 Dec 1 20:22 tomcat-users.xml
[jira] [Commented] (CLOUDSTACK-9111) cloudstack-management start failed (CloudStack 4.6.1 + CentOS7)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043824#comment-15043824 ] Remi Bergsma commented on CLOUDSTACK-9111: -- It is in the admin guide already. > cloudstack-management start failed (CloudStack 4.6.1 + CentOS7) > --- > > Key: CLOUDSTACK-9111 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9111 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.1 > Environment: CloudStack 4.6.1 , CentOS7 > http://packages.shapeblue.com/cloudstack/upstream/centos7/4.6/ >Reporter: satoru nakaya > > Steps to reproduce: > 1)clean install CloudStack 4.6.1 on CentOS7 > use http://packages.shapeblue.com/cloudstack/upstream/centos7/4.6/ > [root@acs ~]# cat /etc/redhat-release > CentOS Linux release 7.1.1503 (Core) > [root@acs ~]# > [root@acs ~]# rpm -qa | grep cloudstack > cloudstack-management-4.6.1-shapeblue0.el7.centos.x86_64 > cloudstack-common-4.6.1-shapeblue0.el7.centos.x86_64 > [root@acs ~]# > 2)cloudstack-setup-databases...(snip) > 3)cloudstack-setup-management (Failed) > [root@acs ~]# cloudstack-setup-management > Starting to configure CloudStack Management Server: > Configure Firewall ...[OK] > Configure CloudStack Management Server ...[Failed] > Cannot find /etc/cloudstack/management/server-nonssl.xml or > /etc/cloudstack/management/tomcat6-nonssl.conf, https enable failed > Try to restore your system: > Restore Firewall ... [OK] > Restore CloudStack Management Server ...[OK] > [root@acs ~]# > 4)check log (/var/log/messages) > Dec 6 10:08:51 acs server: WARNING: Unable to load server configuration from > [/usr/share/cloudstack-management/conf/server.xml] > 5)check service status (failed) > [root@acs ~]# systemctl status cloudstack-management.service > cloudstack-management.service - CloudStack Management Server >Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service; > enabled) >Active: failed (Result: exit-code) since Sun 2015-12-06 10:08:52 JST; 11s > ago > Process: 3061 ExecStop=/usr/libexec/tomcat/server stop (code=exited, > status=1/FAILURE) > Process: 3026 ExecStart=/usr/libexec/tomcat/server start (code=exited, > status=0/SUCCESS) > Main PID: 3026 (code=exited, status=0/SUCCESS) > Dec 06 10:08:52 acs.dom.local server[3061]: at > java.io.FileInputStream.(FileInputStream.java:146) > Dec 06 10:08:52 acs.dom.local server[3061]: at > org.apache.catalina.startup.Catalina.stopServer(Catalina.java:466) > Dec 06 10:08:52 acs.dom.local server[3061]: at > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > Dec 06 10:08:52 acs.dom.local server[3061]: at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > Dec 06 10:08:52 acs.dom.local server[3061]: at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI...va:43) > Dec 06 10:08:52 acs.dom.local server[3061]: at > java.lang.reflect.Method.invoke(Method.java:606) > Dec 06 10:08:52 acs.dom.local server[3061]: at > org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:370) > Dec 06 10:08:52 acs.dom.local server[3061]: at > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:457) > Dec 06 10:08:52 acs.dom.local systemd[1]: cloudstack-management.service: > control process exited, code=exited status=1 > Dec 06 10:08:52 acs.dom.local systemd[1]: Unit cloudstack-management.service > entered failed state. > Hint: Some lines were ellipsized, use -l to show in full. > [root@acs ~]# > workaround: > The correct do not know whether or not , but it worked. > 6)check file > [root@acs ~]# ls -la /etc/cloudstack/management > total 132 > drwxr-xr-x. 3 root root 4096 Dec 5 17:59 . > drwxr-xr-x. 3 root root 4096 Dec 5 17:53 .. > drwxrwx---. 3 root cloud 4096 Dec 5 17:53 Catalina > -rw-r--r--. 1 root root 8945 Dec 1 20:22 catalina.policy > -rw-r--r--. 1 root root 3794 Dec 1 20:22 catalina.properties > -rw-r--r--. 1 root root 1653 Dec 1 20:22 classpath.conf > -rw-r--r--. 1 root root 1357 Dec 1 20:22 commons-logging.properties > -rw-r-. 1 root cloud 3137 Dec 5 17:59 db.properties > -rw-r--r--. 1 root root979 Dec 1 20:22 environment.properties > -rw-r--r--. 1 root root927 Dec 1 20:22 java.security.ciphers > -rw-r--r--. 1 root root 8 Dec 5 17:55 key > -rw-r--r--. 1 root root 7020 Dec 1 20:22 log4j-cloud.xml > -rw-r--r--. 1 root root 6722 Dec 1 20:22 server7-nonssl.xml > -rw-r--r--. 1 root root 7251 Dec 1 20:22 server7-ssl.xml > -rw-r--r--. 1 root root 1383 Dec 1 20:22 tomcat-users.xml > -rw-r--r--. 1 root root 50475 Dec 1 20:22 web.xml > [root@acs ~] > 7)copy file > [root@ac
[jira] [Commented] (CLOUDSTACK-9025) Unable to deploy VM instance from template if template spin from linked clone snapshot
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043825#comment-15043825
]
ASF GitHub Bot commented on CLOUDSTACK-9025:
Github user DaanHoogland commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1176#discussion_r46769041
--- Diff:
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/XenServerGuru.java ---
@@ -185,7 +185,8 @@ public boolean trackVmHostChange() {
DataTO srcData = cpyCommand.getSrcTO();
DataTO destData = cpyCommand.getDestTO();
-if (srcData.getObjectType() == DataObjectType.SNAPSHOT &&
destData.getObjectType() == DataObjectType.TEMPLATE) {
+if (srcData.getHypervisorType() == HypervisorType.XenServer &&
srcData.getObjectType() == DataObjectType.SNAPSHOT &&
--- End diff --
@anshul1886 What you show is implementation dependent. Unless the
specification confirms this behaviour, I think .equals is better.
> Unable to deploy VM instance from template if template spin from linked clone
> snapshot
> --
>
> Key: CLOUDSTACK-9025
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9025
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: XenServer
>Affects Versions: 4.5.2
> Environment: XenServer 6.5
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>Priority: Critical
>
> As default, CloudStack create linked clone snapshot for VM instance . When we
> take a snapshot for the VM, and create a template based on such snapshot,
> CloudStack only download incremental VHD as template file, as a result, the
> VM instance fail to deploy as it is incomplete.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9106) As a Developer I want the Redundant VPC private gateway feature fixed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043853#comment-15043853 ] ASF GitHub Bot commented on CLOUDSTACK-9106: Github user wilderrodrigues commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1179#discussion_r46769789 --- Diff: plugins/network-elements/ovs/src/com/cloud/network/element/OvsElement.java --- @@ -488,50 +494,54 @@ public boolean applyPFRules(final Network network, final List As a Developer I want the Redundant VPC private gateway feature fixed > - > > Key: CLOUDSTACK-9106 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9106 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues > Fix For: 4.7.0 > > > Bug in BasicNetworkTopology.applyRules() method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9106) As a Developer I want the Redundant VPC private gateway feature fixed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043856#comment-15043856
]
ASF GitHub Bot commented on CLOUDSTACK-9106:
Github user wilderrodrigues commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1179#discussion_r46769848
--- Diff: server/src/com/cloud/network/element/VirtualRouterElement.java ---
@@ -841,24 +857,26 @@ public VirtualRouterProvider addElement(final Long
nspId, final Type providerTyp
@Override
public boolean applyPFRules(final Network network, final
List rules) throws ResourceUnavailableException {
+boolean result = false;
if (canHandle(network, Service.PortForwarding)) {
final List routers =
_routerDao.listByNetworkAndRole(network.getId(), Role.VIRTUAL_ROUTER);
if (routers == null || routers.isEmpty()) {
s_logger.debug("Virtual router elemnt doesn't need to
apply firewall rules on the backend; virtual " + "router doesn't exist in the
network " + network.getId());
-return true;
+result = true;
--- End diff --
Yes, it would. But I won't change because I don't agree with the approach
of returning true/false in several places.
1. A method that returns something should have only one point where it
actually returns. So those several returns is a bad practice. A way to make it
not so bad is to assign the return to a variable, so people looking at the code
in the future won't miss a hidden "return true" somewhere. I did not change all
of it because in some places it requires a better refactor.
2. If a method execution cannot proceed due to some condition, it should
fail - exception. A return false should be used when one wants to check is
something is valid/exists or not.
> As a Developer I want the Redundant VPC private gateway feature fixed
> -
>
> Key: CLOUDSTACK-9106
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9106
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> Bug in BasicNetworkTopology.applyRules() method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043901#comment-15043901 ] ASF GitHub Bot commented on CLOUDSTACK-9074: Github user serg38 commented on the pull request: https://github.com/apache/cloudstack/pull/1094#issuecomment-162319994 Since you are testing L3 connectivity existing switch patch to router shouldn't overlap an ip range used by the new subnet. Cidr #1 should work fine . You might also try disconnect existing switch from router to see if test passes. For test #4 we tested we lrouter patched over to l3 gateway without existing switch . For test# 3 you need to have l2 gateway to match the one specified for nvp device. The issue we observed was if any of the test fail for any reason the cleanup on nsx side doesn't work so a manual cleanup might require to remove existing router port left over from previous tests that has overlapping cidr > Support shared networking in NiciraNVP Plugin > - > > Key: CLOUDSTACK-9074 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9074 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Nicolas Vazquez > Fix For: 4.7.0 > > > h3. Introduction > Currently NiciraNVP plugin supports only Isolated networking. In this mode of > operations networks are assigned to individual Cloudstack accounts and on NSX > side are completely isolated on the L3 level. Many use cases especially in > corporate environment call for shared networking mode support. In some > circumstances there also may be a need to translate shared NSX network over > to a physical VLAN via L2 NSX gateway. > Features that will be introduced to support Cloudstack shared networks in two > modes of NiciraNVP plugin: > * Shared networks mapped to a physical VLAN with L2 NSX gateway > * Shared networks within the same L3 NSX domain. Multiple L3 NSX domains will > be supported. > h3. Features > h4. 1) Shared networking model support > # Support native Cloudstack shared network in NiciraNVP plugin. > # Current code that implements isolated networking mode support will stay > intact. > # Designate network service offering by configuring VirtualNetworking > provider with NiciraNVP. > # Static/Source NAT is not used and ignored if defined in the network > offering. > # Nicira_vvp_router_map table will support non-unique logical routers to > implement L3 NSX routing domains where multiple Cloudstack networks are > attached to the same logical router. > # Shared network with NSX based Virtual networking will go through the > following states: > ## Allocated > ## Implementing > ## Implemented > ## Destroy > h4. 2) Support NSX L2 gateways for L2 based VLANs mapped to a physical network > # Optional L2gatewayserviceuuid parameter for NiciraNVP controller > # VLAN ID of a Shared network represents VLAN to pass through L2 gateway > similar to native Cloudstack shared networking > # NSX workflow for network allocation > ## Check if l2gatewayservice defined > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_doamin > ### Vlan://vlan_id as broadcast_uri > ## Create record in VLAN table > # NSX workflow for network implementation > ## Check if l2gatewayservice defined and valid > ## Create logical switch > ## Map logical switch to L2gateway service assigning shared network VLAN ID > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 3) Support NSX L3 multiple routing domains > # VLAN ID of a Shared network represents an UUID of a NSX virtual router of a > particular routing domain. We will support UUID style notation for VLAN ID. > l3gatewayservice option is not used in shared networking > # It is assumed that if connectivity to the physical networking is required > then logical router is configured and connected to the physical network in > advance. NiciraNVP plugin will not perform any task beyond basic connectivity > to the logical router > # Support NSX L3 multiple routing domains > # NSX workflow for network allocation > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_domain > ### NULL as broadcast_uri > ## Create record in VLAN table > ## Create record in nicira_nvp_router_map table > # NSX workflow for network implementation > ## Check if logical router exists on NSX side which UUID matches the one > defined during shared network creation. This mode is activated if VLAN ID > supplied in UUID style notation > ## Create logical switch > ## Attach logical switch to the logical router > ## Assign shared network defaul
[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043910#comment-15043910 ] ASF GitHub Bot commented on CLOUDSTACK-9074: Github user miguelaferreira commented on the pull request: https://github.com/apache/cloudstack/pull/1094#issuecomment-162321883 @serg38 I will use CIDR 1 and disconnect the switch from the router, to se if that works. I haven't' seen any think left behind after testing. That is, the clean up seems to be working fine for me. > Support shared networking in NiciraNVP Plugin > - > > Key: CLOUDSTACK-9074 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9074 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Nicolas Vazquez > Fix For: 4.7.0 > > > h3. Introduction > Currently NiciraNVP plugin supports only Isolated networking. In this mode of > operations networks are assigned to individual Cloudstack accounts and on NSX > side are completely isolated on the L3 level. Many use cases especially in > corporate environment call for shared networking mode support. In some > circumstances there also may be a need to translate shared NSX network over > to a physical VLAN via L2 NSX gateway. > Features that will be introduced to support Cloudstack shared networks in two > modes of NiciraNVP plugin: > * Shared networks mapped to a physical VLAN with L2 NSX gateway > * Shared networks within the same L3 NSX domain. Multiple L3 NSX domains will > be supported. > h3. Features > h4. 1) Shared networking model support > # Support native Cloudstack shared network in NiciraNVP plugin. > # Current code that implements isolated networking mode support will stay > intact. > # Designate network service offering by configuring VirtualNetworking > provider with NiciraNVP. > # Static/Source NAT is not used and ignored if defined in the network > offering. > # Nicira_vvp_router_map table will support non-unique logical routers to > implement L3 NSX routing domains where multiple Cloudstack networks are > attached to the same logical router. > # Shared network with NSX based Virtual networking will go through the > following states: > ## Allocated > ## Implementing > ## Implemented > ## Destroy > h4. 2) Support NSX L2 gateways for L2 based VLANs mapped to a physical network > # Optional L2gatewayserviceuuid parameter for NiciraNVP controller > # VLAN ID of a Shared network represents VLAN to pass through L2 gateway > similar to native Cloudstack shared networking > # NSX workflow for network allocation > ## Check if l2gatewayservice defined > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_doamin > ### Vlan://vlan_id as broadcast_uri > ## Create record in VLAN table > # NSX workflow for network implementation > ## Check if l2gatewayservice defined and valid > ## Create logical switch > ## Map logical switch to L2gateway service assigning shared network VLAN ID > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 3) Support NSX L3 multiple routing domains > # VLAN ID of a Shared network represents an UUID of a NSX virtual router of a > particular routing domain. We will support UUID style notation for VLAN ID. > l3gatewayservice option is not used in shared networking > # It is assumed that if connectivity to the physical networking is required > then logical router is configured and connected to the physical network in > advance. NiciraNVP plugin will not perform any task beyond basic connectivity > to the logical router > # Support NSX L3 multiple routing domains > # NSX workflow for network allocation > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_domain > ### NULL as broadcast_uri > ## Create record in VLAN table > ## Create record in nicira_nvp_router_map table > # NSX workflow for network implementation > ## Check if logical router exists on NSX side which UUID matches the one > defined during shared network creation. This mode is activated if VLAN ID > supplied in UUID style notation > ## Create logical switch > ## Attach logical switch to the logical router > ## Assign shared network default gateway to the inside port of the logical > router > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 4) API Changes > # Existing API addNiciraNvpDevices will be updated > ## Adding 1 new optional parameter – l2gatewayserviceuuid > ## Adding 1 new response tag – l2gatewayserviceuuid > # Existing API listNiciraNvpDevices will be updated > ## Adding 1 new res
[jira] [Commented] (CLOUDSTACK-9106) As a Developer I want the Redundant VPC private gateway feature fixed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043929#comment-15043929
]
ASF GitHub Bot commented on CLOUDSTACK-9106:
Github user DaanHoogland commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1179#discussion_r46771839
--- Diff: server/src/com/cloud/network/element/VirtualRouterElement.java ---
@@ -841,24 +857,26 @@ public VirtualRouterProvider addElement(final Long
nspId, final Type providerTyp
@Override
public boolean applyPFRules(final Network network, final
List rules) throws ResourceUnavailableException {
+boolean result = false;
if (canHandle(network, Service.PortForwarding)) {
final List routers =
_routerDao.listByNetworkAndRole(network.getId(), Role.VIRTUAL_ROUTER);
if (routers == null || routers.isEmpty()) {
s_logger.debug("Virtual router elemnt doesn't need to
apply firewall rules on the backend; virtual " + "router doesn't exist in the
network " + network.getId());
-return true;
+result = true;
--- End diff --
I agree with your consideration and I am not forcing you to change to win
my lgtm. I just want to make sure we discuss the consideration here for
posterity and change only if a simple good alternative comes up.
I noticed line 874 and wondered about this and the &= thingy upstairs. I
would use a combination of first trying all of them and then throw the
exception if any of them failed
> As a Developer I want the Redundant VPC private gateway feature fixed
> -
>
> Key: CLOUDSTACK-9106
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9106
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> Bug in BasicNetworkTopology.applyRules() method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9106) As a Developer I want the Redundant VPC private gateway feature fixed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043930#comment-15043930 ] ASF GitHub Bot commented on CLOUDSTACK-9106: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1179#issuecomment-162324443 @remibergsma I think I am being captain obvious (as my new colleagues like to call each other) but let's add them to the standard run. > As a Developer I want the Redundant VPC private gateway feature fixed > - > > Key: CLOUDSTACK-9106 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9106 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues > Fix For: 4.7.0 > > > Bug in BasicNetworkTopology.applyRules() method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8964) Can't create template or volume from snapshot - "Are you sure you got the right type of server?"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043975#comment-15043975
]
ASF GitHub Bot commented on CLOUDSTACK-8964:
Github user DaanHoogland commented on the pull request:
https://github.com/apache/cloudstack/pull/1177#issuecomment-162331595
lgtm, but can you squash these commits to no longer include a revert,
@ustcweizhou ? thanks
> Can't create template or volume from snapshot - "Are you sure you got the
> right type of server?"
>
>
> Key: CLOUDSTACK-8964
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8964
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs & mgmt
>Reporter: Nux
>Assignee: Wei Zhou
>Priority: Blocker
> Fix For: 4.6.0
>
>
> I have a couple of snapshots left-over from by now deleted instances. Trying
> to turn them into volumes fails with (UI/cloudmonkey shows this):
> "Failed to create templateUnsupported command issued:
> org.apache.cloudstack.storage.command.CopyCommand. Are you sure you got the
> right type of server?"
> mgmt server logs for when trying to create template:
> "2015-10-18 09:15:58,437 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be) ===START=== 192.168.192.198 -- GET
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,459 DEBUG [c.c.t.TemplateManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) This template is getting created
> from other template, setting source template Id to: 201
> 2015-10-18 09:15:58,500 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-33:ctx-f566f6af job-135) Add job-135 into job monitoring
> 2015-10-18 09:15:58,506 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) submit async job-135, details:
> AsyncJobVO {id:135, userId: 2, accountId: 2, instanceType: Template,
> instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-10-18 09:15:58,506 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) ===END=== 192.168.192.198 -- GET
>
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,507 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-33:ctx-f566f6af job-135) Executing AsyncJobVO {id:135,
> userId: 2, accountId: 2, instanceType: Template, instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS
[jira] [Commented] (CLOUDSTACK-8964) Can't create template or volume from snapshot - "Are you sure you got the right type of server?"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043976#comment-15043976
]
ASF GitHub Bot commented on CLOUDSTACK-8964:
Github user DaanHoogland commented on the pull request:
https://github.com/apache/cloudstack/pull/1177#issuecomment-162331667
@snuf are you, as the author of the ovm3 hypervisor plugin, alright with
this?
> Can't create template or volume from snapshot - "Are you sure you got the
> right type of server?"
>
>
> Key: CLOUDSTACK-8964
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8964
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs & mgmt
>Reporter: Nux
>Assignee: Wei Zhou
>Priority: Blocker
> Fix For: 4.6.0
>
>
> I have a couple of snapshots left-over from by now deleted instances. Trying
> to turn them into volumes fails with (UI/cloudmonkey shows this):
> "Failed to create templateUnsupported command issued:
> org.apache.cloudstack.storage.command.CopyCommand. Are you sure you got the
> right type of server?"
> mgmt server logs for when trying to create template:
> "2015-10-18 09:15:58,437 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be) ===START=== 192.168.192.198 -- GET
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,459 DEBUG [c.c.t.TemplateManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) This template is getting created
> from other template, setting source template Id to: 201
> 2015-10-18 09:15:58,500 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-33:ctx-f566f6af job-135) Add job-135 into job monitoring
> 2015-10-18 09:15:58,506 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) submit async job-135, details:
> AsyncJobVO {id:135, userId: 2, accountId: 2, instanceType: Template,
> instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-10-18 09:15:58,506 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) ===END=== 192.168.192.198 -- GET
>
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,507 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-33:ctx-f566f6af job-135) Executing AsyncJobVO {id:135,
> userId: 2, accountId: 2, instanceType: Template, instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStat
[jira] [Commented] (CLOUDSTACK-9025) Unable to deploy VM instance from template if template spin from linked clone snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043988#comment-15043988 ] ASF GitHub Bot commented on CLOUDSTACK-9025: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1176#issuecomment-162332724 LGTM > Unable to deploy VM instance from template if template spin from linked clone > snapshot > -- > > Key: CLOUDSTACK-9025 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9025 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.5.2 > Environment: XenServer 6.5 >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar >Priority: Critical > > As default, CloudStack create linked clone snapshot for VM instance . When we > take a snapshot for the VM, and create a template based on such snapshot, > CloudStack only download incremental VHD as template file, as a result, the > VM instance fail to deploy as it is incomplete. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9025) Unable to deploy VM instance from template if template spin from linked clone snapshot
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043987#comment-15043987
]
ASF GitHub Bot commented on CLOUDSTACK-9025:
Github user DaanHoogland commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1176#discussion_r46773579
--- Diff:
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/XenServerGuru.java ---
@@ -185,7 +185,8 @@ public boolean trackVmHostChange() {
DataTO srcData = cpyCommand.getSrcTO();
DataTO destData = cpyCommand.getDestTO();
-if (srcData.getObjectType() == DataObjectType.SNAPSHOT &&
destData.getObjectType() == DataObjectType.TEMPLATE) {
+if (srcData.getHypervisorType() == HypervisorType.XenServer &&
srcData.getObjectType() == DataObjectType.SNAPSHOT &&
--- End diff --
@anshul1886 I looked it up. @bhaisaab @ustcweizhou Anshul is right about
the equals versus ==, for readability it makes sense to leave this as is. from
8.9 in the language specs:
Because there is only one instance of each enum constant, it is permitted
to use the == operator in place of the equals method when comparing two object
references if it is known that at least one of them refers to an enum constant.
> Unable to deploy VM instance from template if template spin from linked clone
> snapshot
> --
>
> Key: CLOUDSTACK-9025
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9025
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: XenServer
>Affects Versions: 4.5.2
> Environment: XenServer 6.5
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>Priority: Critical
>
> As default, CloudStack create linked clone snapshot for VM instance . When we
> take a snapshot for the VM, and create a template based on such snapshot,
> CloudStack only download incremental VHD as template file, as a result, the
> VM instance fail to deploy as it is incomplete.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8746) VM Snapshotting implementation for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044001#comment-15044001 ] ASF GitHub Bot commented on CLOUDSTACK-8746: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/977#issuecomment-162334352 @wido any reason we shouldn't merge this in before 4.7? > 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-9051) Update Ip address of NIC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044009#comment-15044009 ] ASF GitHub Bot commented on CLOUDSTACK-9051: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1086#issuecomment-162335446 two lgtm, no response to the the answers on reviews so merging > Update Ip address of NIC > > > Key: CLOUDSTACK-9051 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9051 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > Sometimes we want to change the ipaddress of a NIC to a specified ip. > we need to add an API to replace the manual database change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9051) Update Ip address of NIC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044012#comment-15044012 ] ASF subversion and git services commented on CLOUDSTACK-9051: - Commit ccf770636c93ab0e8d66faeef8cbc5d5b14b8450 in cloudstack's branch refs/heads/master from Wei Zhou [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ccf7706 ] CLOUDSTACK-9051: reprogram network as a part of vm nic ip update > Update Ip address of NIC > > > Key: CLOUDSTACK-9051 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9051 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > Sometimes we want to change the ipaddress of a NIC to a specified ip. > we need to add an API to replace the manual database change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9051) Update Ip address of NIC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044014#comment-15044014 ] ASF subversion and git services commented on CLOUDSTACK-9051: - Commit bbe891bfc30feadc3b900b73728a9d04f8b98c72 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bbe891b ] Merge pull request #1086 from ustcweizhou/update-nic-ipaddr CLOUDSTACK-9051: update nic IP address of stopped vmThis provides the feature to change ip address of NIC on a stopped vm by API and UI. * pr/1086: CLOUDSTACK-9051: reprogram network as a part of vm nic ip update CLOUDSTACK-9051: add unit tests for UpdateVmNicIp CLOUDSTACK-9051: update nic IP address of stopped vm Signed-off-by: Daan Hoogland > Update Ip address of NIC > > > Key: CLOUDSTACK-9051 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9051 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > Sometimes we want to change the ipaddress of a NIC to a specified ip. > we need to add an API to replace the manual database change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9051) Update Ip address of NIC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044015#comment-15044015 ] ASF subversion and git services commented on CLOUDSTACK-9051: - Commit bbe891bfc30feadc3b900b73728a9d04f8b98c72 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bbe891b ] Merge pull request #1086 from ustcweizhou/update-nic-ipaddr CLOUDSTACK-9051: update nic IP address of stopped vmThis provides the feature to change ip address of NIC on a stopped vm by API and UI. * pr/1086: CLOUDSTACK-9051: reprogram network as a part of vm nic ip update CLOUDSTACK-9051: add unit tests for UpdateVmNicIp CLOUDSTACK-9051: update nic IP address of stopped vm Signed-off-by: Daan Hoogland > Update Ip address of NIC > > > Key: CLOUDSTACK-9051 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9051 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > Sometimes we want to change the ipaddress of a NIC to a specified ip. > we need to add an API to replace the manual database change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9051) Update Ip address of NIC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044010#comment-15044010 ] ASF subversion and git services commented on CLOUDSTACK-9051: - Commit b79d338f29c2b4e7387944c3a25ed0b4d0541e82 in cloudstack's branch refs/heads/master from Wei Zhou [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b79d338 ] CLOUDSTACK-9051: update nic IP address of stopped vm > Update Ip address of NIC > > > Key: CLOUDSTACK-9051 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9051 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > Sometimes we want to change the ipaddress of a NIC to a specified ip. > we need to add an API to replace the manual database change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9051) Update Ip address of NIC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044013#comment-15044013 ] ASF subversion and git services commented on CLOUDSTACK-9051: - Commit bbe891bfc30feadc3b900b73728a9d04f8b98c72 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bbe891b ] Merge pull request #1086 from ustcweizhou/update-nic-ipaddr CLOUDSTACK-9051: update nic IP address of stopped vmThis provides the feature to change ip address of NIC on a stopped vm by API and UI. * pr/1086: CLOUDSTACK-9051: reprogram network as a part of vm nic ip update CLOUDSTACK-9051: add unit tests for UpdateVmNicIp CLOUDSTACK-9051: update nic IP address of stopped vm Signed-off-by: Daan Hoogland > Update Ip address of NIC > > > Key: CLOUDSTACK-9051 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9051 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > Sometimes we want to change the ipaddress of a NIC to a specified ip. > we need to add an API to replace the manual database change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9051) Update Ip address of NIC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044016#comment-15044016 ] ASF subversion and git services commented on CLOUDSTACK-9051: - Commit bbe891bfc30feadc3b900b73728a9d04f8b98c72 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bbe891b ] Merge pull request #1086 from ustcweizhou/update-nic-ipaddr CLOUDSTACK-9051: update nic IP address of stopped vmThis provides the feature to change ip address of NIC on a stopped vm by API and UI. * pr/1086: CLOUDSTACK-9051: reprogram network as a part of vm nic ip update CLOUDSTACK-9051: add unit tests for UpdateVmNicIp CLOUDSTACK-9051: update nic IP address of stopped vm Signed-off-by: Daan Hoogland > Update Ip address of NIC > > > Key: CLOUDSTACK-9051 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9051 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > Sometimes we want to change the ipaddress of a NIC to a specified ip. > we need to add an API to replace the manual database change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9051) Update Ip address of NIC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044011#comment-15044011 ] ASF subversion and git services commented on CLOUDSTACK-9051: - Commit c01c73e44dd98db317b4e2ec5f5ece4fbfc8c26d in cloudstack's branch refs/heads/master from Wei Zhou [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c01c73e ] CLOUDSTACK-9051: add unit tests for UpdateVmNicIp > Update Ip address of NIC > > > Key: CLOUDSTACK-9051 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9051 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > Sometimes we want to change the ipaddress of a NIC to a specified ip. > we need to add an API to replace the manual database change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9051) Update Ip address of NIC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044017#comment-15044017 ] ASF GitHub Bot commented on CLOUDSTACK-9051: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1086 > Update Ip address of NIC > > > Key: CLOUDSTACK-9051 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9051 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > Sometimes we want to change the ipaddress of a NIC to a specified ip. > we need to add an API to replace the manual database change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9101) some issues in resize volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044022#comment-15044022 ] ASF GitHub Bot commented on CLOUDSTACK-9101: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1161#issuecomment-162336211 lgtm, merging > some issues in resize volume > > > Key: CLOUDSTACK-9101 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9101 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > I found some issues in the testing of resizeVolume > (1) it is not implemented on UI > (2) volume size is not updated even if the operation succeed > mysql> select volumes.id,volumes.size,disk_offering.disk_size from volumes > left join disk_offering on volumes.disk_offering_id=disk_offering.id where > volumes.uuid='999b8ad2-3664-44b9-8cf6-985e60a98cc8'; > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 45 | 85899345920 | 85899345920 | > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 7530 | 5368709120 | 21474836480 | > +--+-+-+ > 1 row in set (0.00 sec) > (3) on KVM, the resize on running vm is good > root@KVM015:~# qemu-img info > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > image: > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > file format: qcow2 > virtual size: 41G (44023414784 bytes) > but root volume on stopped vm is not correct > root@KVM015:~# qemu-img info > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > image: > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > file format: qcow2 > virtual size: 40G (42949672960 bytes) > (4) resource count of primary_storage is not updated after restorevm, if the > root volume has been resized before. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9101) some issues in resize volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044024#comment-15044024 ] ASF subversion and git services commented on CLOUDSTACK-9101: - Commit d6e21f74163212b198731ddf23dd48bc4c787b84 in cloudstack's branch refs/heads/4.6 from Wei Zhou [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d6e21f7 ] CLOUDSTACK-9101: add UI support for root volume resize > some issues in resize volume > > > Key: CLOUDSTACK-9101 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9101 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > I found some issues in the testing of resizeVolume > (1) it is not implemented on UI > (2) volume size is not updated even if the operation succeed > mysql> select volumes.id,volumes.size,disk_offering.disk_size from volumes > left join disk_offering on volumes.disk_offering_id=disk_offering.id where > volumes.uuid='999b8ad2-3664-44b9-8cf6-985e60a98cc8'; > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 45 | 85899345920 | 85899345920 | > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 7530 | 5368709120 | 21474836480 | > +--+-+-+ > 1 row in set (0.00 sec) > (3) on KVM, the resize on running vm is good > root@KVM015:~# qemu-img info > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > image: > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > file format: qcow2 > virtual size: 41G (44023414784 bytes) > but root volume on stopped vm is not correct > root@KVM015:~# qemu-img info > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > image: > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > file format: qcow2 > virtual size: 40G (42949672960 bytes) > (4) resource count of primary_storage is not updated after restorevm, if the > root volume has been resized before. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9101) some issues in resize volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044031#comment-15044031 ] ASF subversion and git services commented on CLOUDSTACK-9101: - Commit 998b1ba629bfdf3ea26fd515ad62f26260dee060 in cloudstack's branch refs/heads/4.6 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=998b1ba ] Merge pull request #1161 from ustcweizhou/resize-volume-issues CLOUDSTACK-9101: fix some issues in resize volume(1) fix issue: volume size is not updated even if the operation succeed (2) Add ui support for root volume resize (3) resize on qcow2 type ROOT volume of stopped vm does not really work see https://issues.apache.org/jira/browse/CLOUDSTACK-9101 * pr/1161: CLOUDSTACK-9101: resize root volume of stopped vm on KVM CLOUDSTACK-9101: add UI support for root volume resize CLOUDSTACK-9101: update volume size after resizevolume Signed-off-by: Daan Hoogland > some issues in resize volume > > > Key: CLOUDSTACK-9101 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9101 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > I found some issues in the testing of resizeVolume > (1) it is not implemented on UI > (2) volume size is not updated even if the operation succeed > mysql> select volumes.id,volumes.size,disk_offering.disk_size from volumes > left join disk_offering on volumes.disk_offering_id=disk_offering.id where > volumes.uuid='999b8ad2-3664-44b9-8cf6-985e60a98cc8'; > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 45 | 85899345920 | 85899345920 | > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 7530 | 5368709120 | 21474836480 | > +--+-+-+ > 1 row in set (0.00 sec) > (3) on KVM, the resize on running vm is good > root@KVM015:~# qemu-img info > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > image: > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > file format: qcow2 > virtual size: 41G (44023414784 bytes) > but root volume on stopped vm is not correct > root@KVM015:~# qemu-img info > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > image: > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > file format: qcow2 > virtual size: 40G (42949672960 bytes) > (4) resource count of primary_storage is not updated after restorevm, if the > root volume has been resized before. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9101) some issues in resize volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044026#comment-15044026 ] ASF subversion and git services commented on CLOUDSTACK-9101: - Commit 998b1ba629bfdf3ea26fd515ad62f26260dee060 in cloudstack's branch refs/heads/4.6 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=998b1ba ] Merge pull request #1161 from ustcweizhou/resize-volume-issues CLOUDSTACK-9101: fix some issues in resize volume(1) fix issue: volume size is not updated even if the operation succeed (2) Add ui support for root volume resize (3) resize on qcow2 type ROOT volume of stopped vm does not really work see https://issues.apache.org/jira/browse/CLOUDSTACK-9101 * pr/1161: CLOUDSTACK-9101: resize root volume of stopped vm on KVM CLOUDSTACK-9101: add UI support for root volume resize CLOUDSTACK-9101: update volume size after resizevolume Signed-off-by: Daan Hoogland > some issues in resize volume > > > Key: CLOUDSTACK-9101 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9101 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > I found some issues in the testing of resizeVolume > (1) it is not implemented on UI > (2) volume size is not updated even if the operation succeed > mysql> select volumes.id,volumes.size,disk_offering.disk_size from volumes > left join disk_offering on volumes.disk_offering_id=disk_offering.id where > volumes.uuid='999b8ad2-3664-44b9-8cf6-985e60a98cc8'; > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 45 | 85899345920 | 85899345920 | > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 7530 | 5368709120 | 21474836480 | > +--+-+-+ > 1 row in set (0.00 sec) > (3) on KVM, the resize on running vm is good > root@KVM015:~# qemu-img info > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > image: > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > file format: qcow2 > virtual size: 41G (44023414784 bytes) > but root volume on stopped vm is not correct > root@KVM015:~# qemu-img info > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > image: > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > file format: qcow2 > virtual size: 40G (42949672960 bytes) > (4) resource count of primary_storage is not updated after restorevm, if the > root volume has been resized before. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9101) some issues in resize volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044023#comment-15044023 ] ASF subversion and git services commented on CLOUDSTACK-9101: - Commit 119b27b2c6c366949b574fbca1574f15d67a3af3 in cloudstack's branch refs/heads/4.6 from Wei Zhou [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=119b27b ] CLOUDSTACK-9101: update volume size after resizevolume > some issues in resize volume > > > Key: CLOUDSTACK-9101 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9101 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > I found some issues in the testing of resizeVolume > (1) it is not implemented on UI > (2) volume size is not updated even if the operation succeed > mysql> select volumes.id,volumes.size,disk_offering.disk_size from volumes > left join disk_offering on volumes.disk_offering_id=disk_offering.id where > volumes.uuid='999b8ad2-3664-44b9-8cf6-985e60a98cc8'; > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 45 | 85899345920 | 85899345920 | > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 7530 | 5368709120 | 21474836480 | > +--+-+-+ > 1 row in set (0.00 sec) > (3) on KVM, the resize on running vm is good > root@KVM015:~# qemu-img info > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > image: > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > file format: qcow2 > virtual size: 41G (44023414784 bytes) > but root volume on stopped vm is not correct > root@KVM015:~# qemu-img info > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > image: > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > file format: qcow2 > virtual size: 40G (42949672960 bytes) > (4) resource count of primary_storage is not updated after restorevm, if the > root volume has been resized before. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9101) some issues in resize volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044030#comment-15044030 ] ASF subversion and git services commented on CLOUDSTACK-9101: - Commit 998b1ba629bfdf3ea26fd515ad62f26260dee060 in cloudstack's branch refs/heads/4.6 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=998b1ba ] Merge pull request #1161 from ustcweizhou/resize-volume-issues CLOUDSTACK-9101: fix some issues in resize volume(1) fix issue: volume size is not updated even if the operation succeed (2) Add ui support for root volume resize (3) resize on qcow2 type ROOT volume of stopped vm does not really work see https://issues.apache.org/jira/browse/CLOUDSTACK-9101 * pr/1161: CLOUDSTACK-9101: resize root volume of stopped vm on KVM CLOUDSTACK-9101: add UI support for root volume resize CLOUDSTACK-9101: update volume size after resizevolume Signed-off-by: Daan Hoogland > some issues in resize volume > > > Key: CLOUDSTACK-9101 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9101 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > I found some issues in the testing of resizeVolume > (1) it is not implemented on UI > (2) volume size is not updated even if the operation succeed > mysql> select volumes.id,volumes.size,disk_offering.disk_size from volumes > left join disk_offering on volumes.disk_offering_id=disk_offering.id where > volumes.uuid='999b8ad2-3664-44b9-8cf6-985e60a98cc8'; > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 45 | 85899345920 | 85899345920 | > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 7530 | 5368709120 | 21474836480 | > +--+-+-+ > 1 row in set (0.00 sec) > (3) on KVM, the resize on running vm is good > root@KVM015:~# qemu-img info > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > image: > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > file format: qcow2 > virtual size: 41G (44023414784 bytes) > but root volume on stopped vm is not correct > root@KVM015:~# qemu-img info > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > image: > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > file format: qcow2 > virtual size: 40G (42949672960 bytes) > (4) resource count of primary_storage is not updated after restorevm, if the > root volume has been resized before. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9101) some issues in resize volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044029#comment-15044029 ] ASF GitHub Bot commented on CLOUDSTACK-9101: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1161 > some issues in resize volume > > > Key: CLOUDSTACK-9101 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9101 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > I found some issues in the testing of resizeVolume > (1) it is not implemented on UI > (2) volume size is not updated even if the operation succeed > mysql> select volumes.id,volumes.size,disk_offering.disk_size from volumes > left join disk_offering on volumes.disk_offering_id=disk_offering.id where > volumes.uuid='999b8ad2-3664-44b9-8cf6-985e60a98cc8'; > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 45 | 85899345920 | 85899345920 | > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 7530 | 5368709120 | 21474836480 | > +--+-+-+ > 1 row in set (0.00 sec) > (3) on KVM, the resize on running vm is good > root@KVM015:~# qemu-img info > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > image: > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > file format: qcow2 > virtual size: 41G (44023414784 bytes) > but root volume on stopped vm is not correct > root@KVM015:~# qemu-img info > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > image: > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > file format: qcow2 > virtual size: 40G (42949672960 bytes) > (4) resource count of primary_storage is not updated after restorevm, if the > root volume has been resized before. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9101) some issues in resize volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044028#comment-15044028 ] ASF subversion and git services commented on CLOUDSTACK-9101: - Commit 998b1ba629bfdf3ea26fd515ad62f26260dee060 in cloudstack's branch refs/heads/4.6 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=998b1ba ] Merge pull request #1161 from ustcweizhou/resize-volume-issues CLOUDSTACK-9101: fix some issues in resize volume(1) fix issue: volume size is not updated even if the operation succeed (2) Add ui support for root volume resize (3) resize on qcow2 type ROOT volume of stopped vm does not really work see https://issues.apache.org/jira/browse/CLOUDSTACK-9101 * pr/1161: CLOUDSTACK-9101: resize root volume of stopped vm on KVM CLOUDSTACK-9101: add UI support for root volume resize CLOUDSTACK-9101: update volume size after resizevolume Signed-off-by: Daan Hoogland > some issues in resize volume > > > Key: CLOUDSTACK-9101 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9101 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > I found some issues in the testing of resizeVolume > (1) it is not implemented on UI > (2) volume size is not updated even if the operation succeed > mysql> select volumes.id,volumes.size,disk_offering.disk_size from volumes > left join disk_offering on volumes.disk_offering_id=disk_offering.id where > volumes.uuid='999b8ad2-3664-44b9-8cf6-985e60a98cc8'; > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 45 | 85899345920 | 85899345920 | > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 7530 | 5368709120 | 21474836480 | > +--+-+-+ > 1 row in set (0.00 sec) > (3) on KVM, the resize on running vm is good > root@KVM015:~# qemu-img info > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > image: > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > file format: qcow2 > virtual size: 41G (44023414784 bytes) > but root volume on stopped vm is not correct > root@KVM015:~# qemu-img info > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > image: > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > file format: qcow2 > virtual size: 40G (42949672960 bytes) > (4) resource count of primary_storage is not updated after restorevm, if the > root volume has been resized before. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9101) some issues in resize volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044027#comment-15044027 ] ASF subversion and git services commented on CLOUDSTACK-9101: - Commit 998b1ba629bfdf3ea26fd515ad62f26260dee060 in cloudstack's branch refs/heads/4.6 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=998b1ba ] Merge pull request #1161 from ustcweizhou/resize-volume-issues CLOUDSTACK-9101: fix some issues in resize volume(1) fix issue: volume size is not updated even if the operation succeed (2) Add ui support for root volume resize (3) resize on qcow2 type ROOT volume of stopped vm does not really work see https://issues.apache.org/jira/browse/CLOUDSTACK-9101 * pr/1161: CLOUDSTACK-9101: resize root volume of stopped vm on KVM CLOUDSTACK-9101: add UI support for root volume resize CLOUDSTACK-9101: update volume size after resizevolume Signed-off-by: Daan Hoogland > some issues in resize volume > > > Key: CLOUDSTACK-9101 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9101 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > I found some issues in the testing of resizeVolume > (1) it is not implemented on UI > (2) volume size is not updated even if the operation succeed > mysql> select volumes.id,volumes.size,disk_offering.disk_size from volumes > left join disk_offering on volumes.disk_offering_id=disk_offering.id where > volumes.uuid='999b8ad2-3664-44b9-8cf6-985e60a98cc8'; > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 45 | 85899345920 | 85899345920 | > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 7530 | 5368709120 | 21474836480 | > +--+-+-+ > 1 row in set (0.00 sec) > (3) on KVM, the resize on running vm is good > root@KVM015:~# qemu-img info > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > image: > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > file format: qcow2 > virtual size: 41G (44023414784 bytes) > but root volume on stopped vm is not correct > root@KVM015:~# qemu-img info > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > image: > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > file format: qcow2 > virtual size: 40G (42949672960 bytes) > (4) resource count of primary_storage is not updated after restorevm, if the > root volume has been resized before. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9101) some issues in resize volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044025#comment-15044025 ] ASF subversion and git services commented on CLOUDSTACK-9101: - Commit 9221cb3e0d0e5a0ea374f10e889f7e32c2a3eda1 in cloudstack's branch refs/heads/4.6 from Wei Zhou [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9221cb3 ] CLOUDSTACK-9101: resize root volume of stopped vm on KVM > some issues in resize volume > > > Key: CLOUDSTACK-9101 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9101 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > I found some issues in the testing of resizeVolume > (1) it is not implemented on UI > (2) volume size is not updated even if the operation succeed > mysql> select volumes.id,volumes.size,disk_offering.disk_size from volumes > left join disk_offering on volumes.disk_offering_id=disk_offering.id where > volumes.uuid='999b8ad2-3664-44b9-8cf6-985e60a98cc8'; > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 45 | 85899345920 | 85899345920 | > +--+-+-+ > | id | size| disk_size | > +--+-+-+ > | 7530 | 5368709120 | 21474836480 | > +--+-+-+ > 1 row in set (0.00 sec) > (3) on KVM, the resize on running vm is good > root@KVM015:~# qemu-img info > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > image: > /mnt/f773b66d-fd8c-3576-aa37-e3f0e685b183/e9ddd9b1-57c4-4ad7-b950-7b7f5c5cf2dc > file format: qcow2 > virtual size: 41G (44023414784 bytes) > but root volume on stopped vm is not correct > root@KVM015:~# qemu-img info > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > image: > /mnt/1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e/2412a4c0-8271-4e21-a3d1-61b041d209d6 > file format: qcow2 > virtual size: 40G (42949672960 bytes) > (4) resource count of primary_storage is not updated after restorevm, if the > root volume has been resized before. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8845) list snapshot without id is failing with Unable to determine the storage pool of the snapshot
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044034#comment-15044034
]
ASF GitHub Bot commented on CLOUDSTACK-8845:
Github user DaanHoogland commented on the pull request:
https://github.com/apache/cloudstack/pull/1168#issuecomment-162336441
code lgtm and since @ustcweizhou and @anshul1886 agree on how to solve this
and @remibergsma did the tests, i am merging this
> list snapshot without id is failing with Unable to determine the storage pool
> of the snapshot
> -
>
> Key: CLOUDSTACK-8845
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8845
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.6.0
>Reporter: prashant kumar mishra
>Assignee: Anshul Gangwar
> Labels: snapshot
> Attachments: cloud.dmp, management-server.log
>
>
> steps
>
> Try to list snapshot using api/UI without passing id
> http://10.*.*.*:8080/client/api?command=listSnapshots&response=json&_=1442227513154
> {"listsnapshotsresponse":{"uuidList":[],"errorcode":530,"cserrorcode":4250,"errortext":"Unable
> to determine the storage pool of the snapshot"}}
> logs
> -
> 2015-09-14 10:23:10,579 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-4:ctx-600cffa2) ===START=== 10.252.193.23 -- GET
> command=listSnapshots&response=json&_=1442227513154
> 2015-09-14 10:23:10,635 ERROR [c.c.a.ApiServer] (catalina-exec-4:ctx-600cffa2
> ctx-92e1cd5e) unhandled exception executing api command:
> [Ljava.lang.String;@10e4744f
> com.cloud.utils.exception.CloudRuntimeException: Unable to determine the
> storage pool of the snapshot
> at
> org.apache.cloudstack.storage.snapshot.StorageSystemSnapshotStrategy.canHandle(StorageSystemSnapshotStrategy.java:455)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl$3.canHandle(StorageStrategyFactoryImpl.java:72)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl$3.canHandle(StorageStrategyFactoryImpl.java:69)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl.bestMatch(StorageStrategyFactoryImpl.java:95)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl.getSnapshotStrategy(StorageStrategyFactoryImpl.java:69)
> at
> org.apache.cloudstack.storage.snapshot.SnapshotObject.isRevertable(SnapshotObject.java:133)
> at
> com.cloud.api.ApiResponseHelper.createSnapshotResponse(ApiResponseHelper.java:499)
> at
> org.apache.cloudstack.api.command.user.snapshot.ListSnapshotsCmd.execute(ListSnapshotsCmd.java:114)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:704)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:529)
> at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:296)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:127)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:124)
> at com.cloud.api.ApiServlet.doGet(ApiServlet.java:86)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
> at
> org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
> at
> org.apache.coyote.http11.Http11NioProtocol$Http11Conne
[jira] [Commented] (CLOUDSTACK-8964) Can't create template or volume from snapshot - "Are you sure you got the right type of server?"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044039#comment-15044039
]
ASF GitHub Bot commented on CLOUDSTACK-8964:
Github user DaanHoogland commented on the pull request:
https://github.com/apache/cloudstack/pull/1177#issuecomment-162337123
lgtm, merging
> Can't create template or volume from snapshot - "Are you sure you got the
> right type of server?"
>
>
> Key: CLOUDSTACK-8964
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8964
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs & mgmt
>Reporter: Nux
>Assignee: Wei Zhou
>Priority: Blocker
> Fix For: 4.6.0
>
>
> I have a couple of snapshots left-over from by now deleted instances. Trying
> to turn them into volumes fails with (UI/cloudmonkey shows this):
> "Failed to create templateUnsupported command issued:
> org.apache.cloudstack.storage.command.CopyCommand. Are you sure you got the
> right type of server?"
> mgmt server logs for when trying to create template:
> "2015-10-18 09:15:58,437 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be) ===START=== 192.168.192.198 -- GET
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,459 DEBUG [c.c.t.TemplateManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) This template is getting created
> from other template, setting source template Id to: 201
> 2015-10-18 09:15:58,500 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-33:ctx-f566f6af job-135) Add job-135 into job monitoring
> 2015-10-18 09:15:58,506 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) submit async job-135, details:
> AsyncJobVO {id:135, userId: 2, accountId: 2, instanceType: Template,
> instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-10-18 09:15:58,506 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) ===END=== 192.168.192.198 -- GET
>
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,507 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-33:ctx-f566f6af job-135) Executing AsyncJobVO {id:135,
> userId: 2, accountId: 2, instanceType: Template, instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693,
[jira] [Commented] (CLOUDSTACK-8845) list snapshot without id is failing with Unable to determine the storage pool of the snapshot
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044043#comment-15044043
]
ASF subversion and git services commented on CLOUDSTACK-8845:
-
Commit 24113e425e6cd213ffac568abc9fb7a55ae8d7e8 in cloudstack's branch
refs/heads/4.6 from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=24113e4 ]
Merge pull request #1168 from ustcweizhou/listSnapshots-Exception
CLOUDSTACK-8845: set isRevertable of snapshot to false if the volume is
removedSome users encounter an exception when listSnapshots.
We should set the isRevertable of snapshot to false if the original volume is
removed, without checking if the snapshot is stored in primary store (the
exception was thowned during the checking).
* pr/1168:
CLOUDSTACK-8845: set isRevertable of snapshot to false if the volume is
removed
Signed-off-by: Daan Hoogland
> list snapshot without id is failing with Unable to determine the storage pool
> of the snapshot
> -
>
> Key: CLOUDSTACK-8845
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8845
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.6.0
>Reporter: prashant kumar mishra
>Assignee: Anshul Gangwar
> Labels: snapshot
> Attachments: cloud.dmp, management-server.log
>
>
> steps
>
> Try to list snapshot using api/UI without passing id
> http://10.*.*.*:8080/client/api?command=listSnapshots&response=json&_=1442227513154
> {"listsnapshotsresponse":{"uuidList":[],"errorcode":530,"cserrorcode":4250,"errortext":"Unable
> to determine the storage pool of the snapshot"}}
> logs
> -
> 2015-09-14 10:23:10,579 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-4:ctx-600cffa2) ===START=== 10.252.193.23 -- GET
> command=listSnapshots&response=json&_=1442227513154
> 2015-09-14 10:23:10,635 ERROR [c.c.a.ApiServer] (catalina-exec-4:ctx-600cffa2
> ctx-92e1cd5e) unhandled exception executing api command:
> [Ljava.lang.String;@10e4744f
> com.cloud.utils.exception.CloudRuntimeException: Unable to determine the
> storage pool of the snapshot
> at
> org.apache.cloudstack.storage.snapshot.StorageSystemSnapshotStrategy.canHandle(StorageSystemSnapshotStrategy.java:455)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl$3.canHandle(StorageStrategyFactoryImpl.java:72)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl$3.canHandle(StorageStrategyFactoryImpl.java:69)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl.bestMatch(StorageStrategyFactoryImpl.java:95)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl.getSnapshotStrategy(StorageStrategyFactoryImpl.java:69)
> at
> org.apache.cloudstack.storage.snapshot.SnapshotObject.isRevertable(SnapshotObject.java:133)
> at
> com.cloud.api.ApiResponseHelper.createSnapshotResponse(ApiResponseHelper.java:499)
> at
> org.apache.cloudstack.api.command.user.snapshot.ListSnapshotsCmd.execute(ListSnapshotsCmd.java:114)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:704)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:529)
> at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:296)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:127)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:124)
> at com.cloud.api.ApiServlet.doGet(ApiServlet.java:86)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at
> org.apache.catalina.valves.ErrorReportValve.invok
[jira] [Commented] (CLOUDSTACK-8964) Can't create template or volume from snapshot - "Are you sure you got the right type of server?"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044040#comment-15044040
]
ASF subversion and git services commented on CLOUDSTACK-8964:
-
Commit e0501be87ea3a171afba03086139355bb3dc6051 in cloudstack's branch
refs/heads/4.6 from Wei Zhou
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e0501be ]
Revert "CLOUDSTACK-8964 side effect isolation"
This reverts commit fc18d1e8b11c82a18854234b0c8c827896a5b78d.
> Can't create template or volume from snapshot - "Are you sure you got the
> right type of server?"
>
>
> Key: CLOUDSTACK-8964
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8964
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs & mgmt
>Reporter: Nux
>Assignee: Wei Zhou
>Priority: Blocker
> Fix For: 4.6.0
>
>
> I have a couple of snapshots left-over from by now deleted instances. Trying
> to turn them into volumes fails with (UI/cloudmonkey shows this):
> "Failed to create templateUnsupported command issued:
> org.apache.cloudstack.storage.command.CopyCommand. Are you sure you got the
> right type of server?"
> mgmt server logs for when trying to create template:
> "2015-10-18 09:15:58,437 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be) ===START=== 192.168.192.198 -- GET
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,459 DEBUG [c.c.t.TemplateManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) This template is getting created
> from other template, setting source template Id to: 201
> 2015-10-18 09:15:58,500 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-33:ctx-f566f6af job-135) Add job-135 into job monitoring
> 2015-10-18 09:15:58,506 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) submit async job-135, details:
> AsyncJobVO {id:135, userId: 2, accountId: 2, instanceType: Template,
> instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-10-18 09:15:58,506 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) ===END=== 192.168.192.198 -- GET
>
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,507 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-33:ctx-f566f6af job-135) Executing AsyncJobVO {id:135,
> userId: 2, accountId: 2, instanceType: Template, instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0
[jira] [Commented] (CLOUDSTACK-8964) Can't create template or volume from snapshot - "Are you sure you got the right type of server?"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044045#comment-15044045
]
ASF subversion and git services commented on CLOUDSTACK-8964:
-
Commit f66e78279571dcc339bf18e37b5b7f22c4711b9b in cloudstack's branch
refs/heads/4.6 from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f66e782 ]
Merge pull request #1177 from ustcweizhou/Ovm3-CopyCommand
CLOUDSTACK-8964: Ovm3HypervisorGuru handle only srcData with HypervisorType is
Ovm3This PR can only be applied after PR #1176
The CopyCommand on Ovm3 should be handled by Ovm3StorageProcessor, not SSVM.
Hence, I revert two commits on Ovm3HypervisorGuru, and add the hypervisorType
check so that only the this guru will only handle Ovm3 (not KVM)
* pr/1177:
CLOUDSTACK-8964: Ovm3HypervisorGuru handle only srcData with HypervisorType
is Ovm3
Revert "simple change to prevent failure and keep OVM3 snapshots working"
Revert "CLOUDSTACK-8964 side effect isolation"
Signed-off-by: Daan Hoogland
> Can't create template or volume from snapshot - "Are you sure you got the
> right type of server?"
>
>
> Key: CLOUDSTACK-8964
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8964
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs & mgmt
>Reporter: Nux
>Assignee: Wei Zhou
>Priority: Blocker
> Fix For: 4.6.0
>
>
> I have a couple of snapshots left-over from by now deleted instances. Trying
> to turn them into volumes fails with (UI/cloudmonkey shows this):
> "Failed to create templateUnsupported command issued:
> org.apache.cloudstack.storage.command.CopyCommand. Are you sure you got the
> right type of server?"
> mgmt server logs for when trying to create template:
> "2015-10-18 09:15:58,437 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be) ===START=== 192.168.192.198 -- GET
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,459 DEBUG [c.c.t.TemplateManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) This template is getting created
> from other template, setting source template Id to: 201
> 2015-10-18 09:15:58,500 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-33:ctx-f566f6af job-135) Add job-135 into job monitoring
> 2015-10-18 09:15:58,506 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) submit async job-135, details:
> AsyncJobVO {id:135, userId: 2, accountId: 2, instanceType: Template,
> instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-10-18 09:15:58,506 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) ===END=== 192.168.192.198 -- GET
>
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,507 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-33:ctx-f566f6af job-135) Executing AsyncJobVO {id:135,
> userId: 2, accountId: 2, instanceType: Template, instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPubl
[jira] [Commented] (CLOUDSTACK-8964) Can't create template or volume from snapshot - "Are you sure you got the right type of server?"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044041#comment-15044041
]
ASF subversion and git services commented on CLOUDSTACK-8964:
-
Commit a90b953dbcb80cba09e03f34f96a7a52c0521d4f in cloudstack's branch
refs/heads/4.6 from Wei Zhou
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a90b953 ]
CLOUDSTACK-8964: Ovm3HypervisorGuru handle only srcData with HypervisorType is
Ovm3
> Can't create template or volume from snapshot - "Are you sure you got the
> right type of server?"
>
>
> Key: CLOUDSTACK-8964
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8964
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs & mgmt
>Reporter: Nux
>Assignee: Wei Zhou
>Priority: Blocker
> Fix For: 4.6.0
>
>
> I have a couple of snapshots left-over from by now deleted instances. Trying
> to turn them into volumes fails with (UI/cloudmonkey shows this):
> "Failed to create templateUnsupported command issued:
> org.apache.cloudstack.storage.command.CopyCommand. Are you sure you got the
> right type of server?"
> mgmt server logs for when trying to create template:
> "2015-10-18 09:15:58,437 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be) ===START=== 192.168.192.198 -- GET
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,459 DEBUG [c.c.t.TemplateManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) This template is getting created
> from other template, setting source template Id to: 201
> 2015-10-18 09:15:58,500 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-33:ctx-f566f6af job-135) Add job-135 into job monitoring
> 2015-10-18 09:15:58,506 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) submit async job-135, details:
> AsyncJobVO {id:135, userId: 2, accountId: 2, instanceType: Template,
> instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-10-18 09:15:58,506 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) ===END=== 192.168.192.198 -- GET
>
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,507 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-33:ctx-f566f6af job-135) Executing AsyncJobVO {id:135,
> userId: 2, accountId: 2, instanceType: Template, instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","c
[jira] [Commented] (CLOUDSTACK-8845) list snapshot without id is failing with Unable to determine the storage pool of the snapshot
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044042#comment-15044042
]
ASF subversion and git services commented on CLOUDSTACK-8845:
-
Commit 24113e425e6cd213ffac568abc9fb7a55ae8d7e8 in cloudstack's branch
refs/heads/4.6 from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=24113e4 ]
Merge pull request #1168 from ustcweizhou/listSnapshots-Exception
CLOUDSTACK-8845: set isRevertable of snapshot to false if the volume is
removedSome users encounter an exception when listSnapshots.
We should set the isRevertable of snapshot to false if the original volume is
removed, without checking if the snapshot is stored in primary store (the
exception was thowned during the checking).
* pr/1168:
CLOUDSTACK-8845: set isRevertable of snapshot to false if the volume is
removed
Signed-off-by: Daan Hoogland
> list snapshot without id is failing with Unable to determine the storage pool
> of the snapshot
> -
>
> Key: CLOUDSTACK-8845
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8845
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.6.0
>Reporter: prashant kumar mishra
>Assignee: Anshul Gangwar
> Labels: snapshot
> Attachments: cloud.dmp, management-server.log
>
>
> steps
>
> Try to list snapshot using api/UI without passing id
> http://10.*.*.*:8080/client/api?command=listSnapshots&response=json&_=1442227513154
> {"listsnapshotsresponse":{"uuidList":[],"errorcode":530,"cserrorcode":4250,"errortext":"Unable
> to determine the storage pool of the snapshot"}}
> logs
> -
> 2015-09-14 10:23:10,579 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-4:ctx-600cffa2) ===START=== 10.252.193.23 -- GET
> command=listSnapshots&response=json&_=1442227513154
> 2015-09-14 10:23:10,635 ERROR [c.c.a.ApiServer] (catalina-exec-4:ctx-600cffa2
> ctx-92e1cd5e) unhandled exception executing api command:
> [Ljava.lang.String;@10e4744f
> com.cloud.utils.exception.CloudRuntimeException: Unable to determine the
> storage pool of the snapshot
> at
> org.apache.cloudstack.storage.snapshot.StorageSystemSnapshotStrategy.canHandle(StorageSystemSnapshotStrategy.java:455)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl$3.canHandle(StorageStrategyFactoryImpl.java:72)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl$3.canHandle(StorageStrategyFactoryImpl.java:69)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl.bestMatch(StorageStrategyFactoryImpl.java:95)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl.getSnapshotStrategy(StorageStrategyFactoryImpl.java:69)
> at
> org.apache.cloudstack.storage.snapshot.SnapshotObject.isRevertable(SnapshotObject.java:133)
> at
> com.cloud.api.ApiResponseHelper.createSnapshotResponse(ApiResponseHelper.java:499)
> at
> org.apache.cloudstack.api.command.user.snapshot.ListSnapshotsCmd.execute(ListSnapshotsCmd.java:114)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:704)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:529)
> at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:296)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:127)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:124)
> at com.cloud.api.ApiServlet.doGet(ApiServlet.java:86)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at
> org.apache.catalina.valves.ErrorReportValve.invok
[jira] [Commented] (CLOUDSTACK-8964) Can't create template or volume from snapshot - "Are you sure you got the right type of server?"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044044#comment-15044044
]
ASF subversion and git services commented on CLOUDSTACK-8964:
-
Commit f66e78279571dcc339bf18e37b5b7f22c4711b9b in cloudstack's branch
refs/heads/4.6 from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f66e782 ]
Merge pull request #1177 from ustcweizhou/Ovm3-CopyCommand
CLOUDSTACK-8964: Ovm3HypervisorGuru handle only srcData with HypervisorType is
Ovm3This PR can only be applied after PR #1176
The CopyCommand on Ovm3 should be handled by Ovm3StorageProcessor, not SSVM.
Hence, I revert two commits on Ovm3HypervisorGuru, and add the hypervisorType
check so that only the this guru will only handle Ovm3 (not KVM)
* pr/1177:
CLOUDSTACK-8964: Ovm3HypervisorGuru handle only srcData with HypervisorType
is Ovm3
Revert "simple change to prevent failure and keep OVM3 snapshots working"
Revert "CLOUDSTACK-8964 side effect isolation"
Signed-off-by: Daan Hoogland
> Can't create template or volume from snapshot - "Are you sure you got the
> right type of server?"
>
>
> Key: CLOUDSTACK-8964
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8964
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs & mgmt
>Reporter: Nux
>Assignee: Wei Zhou
>Priority: Blocker
> Fix For: 4.6.0
>
>
> I have a couple of snapshots left-over from by now deleted instances. Trying
> to turn them into volumes fails with (UI/cloudmonkey shows this):
> "Failed to create templateUnsupported command issued:
> org.apache.cloudstack.storage.command.CopyCommand. Are you sure you got the
> right type of server?"
> mgmt server logs for when trying to create template:
> "2015-10-18 09:15:58,437 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be) ===START=== 192.168.192.198 -- GET
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,459 DEBUG [c.c.t.TemplateManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) This template is getting created
> from other template, setting source template Id to: 201
> 2015-10-18 09:15:58,500 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-33:ctx-f566f6af job-135) Add job-135 into job monitoring
> 2015-10-18 09:15:58,506 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) submit async job-135, details:
> AsyncJobVO {id:135, userId: 2, accountId: 2, instanceType: Template,
> instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-10-18 09:15:58,506 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) ===END=== 192.168.192.198 -- GET
>
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,507 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-33:ctx-f566f6af job-135) Executing AsyncJobVO {id:135,
> userId: 2, accountId: 2, instanceType: Template, instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPubl
[jira] [Commented] (CLOUDSTACK-8964) Can't create template or volume from snapshot - "Are you sure you got the right type of server?"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044046#comment-15044046
]
ASF subversion and git services commented on CLOUDSTACK-8964:
-
Commit f66e78279571dcc339bf18e37b5b7f22c4711b9b in cloudstack's branch
refs/heads/4.6 from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f66e782 ]
Merge pull request #1177 from ustcweizhou/Ovm3-CopyCommand
CLOUDSTACK-8964: Ovm3HypervisorGuru handle only srcData with HypervisorType is
Ovm3This PR can only be applied after PR #1176
The CopyCommand on Ovm3 should be handled by Ovm3StorageProcessor, not SSVM.
Hence, I revert two commits on Ovm3HypervisorGuru, and add the hypervisorType
check so that only the this guru will only handle Ovm3 (not KVM)
* pr/1177:
CLOUDSTACK-8964: Ovm3HypervisorGuru handle only srcData with HypervisorType
is Ovm3
Revert "simple change to prevent failure and keep OVM3 snapshots working"
Revert "CLOUDSTACK-8964 side effect isolation"
Signed-off-by: Daan Hoogland
> Can't create template or volume from snapshot - "Are you sure you got the
> right type of server?"
>
>
> Key: CLOUDSTACK-8964
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8964
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs & mgmt
>Reporter: Nux
>Assignee: Wei Zhou
>Priority: Blocker
> Fix For: 4.6.0
>
>
> I have a couple of snapshots left-over from by now deleted instances. Trying
> to turn them into volumes fails with (UI/cloudmonkey shows this):
> "Failed to create templateUnsupported command issued:
> org.apache.cloudstack.storage.command.CopyCommand. Are you sure you got the
> right type of server?"
> mgmt server logs for when trying to create template:
> "2015-10-18 09:15:58,437 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be) ===START=== 192.168.192.198 -- GET
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,459 DEBUG [c.c.t.TemplateManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) This template is getting created
> from other template, setting source template Id to: 201
> 2015-10-18 09:15:58,500 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-33:ctx-f566f6af job-135) Add job-135 into job monitoring
> 2015-10-18 09:15:58,506 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) submit async job-135, details:
> AsyncJobVO {id:135, userId: 2, accountId: 2, instanceType: Template,
> instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-10-18 09:15:58,506 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) ===END=== 192.168.192.198 -- GET
>
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,507 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-33:ctx-f566f6af job-135) Executing AsyncJobVO {id:135,
> userId: 2, accountId: 2, instanceType: Template, instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPubl
[jira] [Commented] (CLOUDSTACK-8845) list snapshot without id is failing with Unable to determine the storage pool of the snapshot
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044048#comment-15044048
]
ASF GitHub Bot commented on CLOUDSTACK-8845:
Github user asfgit closed the pull request at:
https://github.com/apache/cloudstack/pull/1168
> list snapshot without id is failing with Unable to determine the storage pool
> of the snapshot
> -
>
> Key: CLOUDSTACK-8845
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8845
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.6.0
>Reporter: prashant kumar mishra
>Assignee: Anshul Gangwar
> Labels: snapshot
> Attachments: cloud.dmp, management-server.log
>
>
> steps
>
> Try to list snapshot using api/UI without passing id
> http://10.*.*.*:8080/client/api?command=listSnapshots&response=json&_=1442227513154
> {"listsnapshotsresponse":{"uuidList":[],"errorcode":530,"cserrorcode":4250,"errortext":"Unable
> to determine the storage pool of the snapshot"}}
> logs
> -
> 2015-09-14 10:23:10,579 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-4:ctx-600cffa2) ===START=== 10.252.193.23 -- GET
> command=listSnapshots&response=json&_=1442227513154
> 2015-09-14 10:23:10,635 ERROR [c.c.a.ApiServer] (catalina-exec-4:ctx-600cffa2
> ctx-92e1cd5e) unhandled exception executing api command:
> [Ljava.lang.String;@10e4744f
> com.cloud.utils.exception.CloudRuntimeException: Unable to determine the
> storage pool of the snapshot
> at
> org.apache.cloudstack.storage.snapshot.StorageSystemSnapshotStrategy.canHandle(StorageSystemSnapshotStrategy.java:455)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl$3.canHandle(StorageStrategyFactoryImpl.java:72)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl$3.canHandle(StorageStrategyFactoryImpl.java:69)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl.bestMatch(StorageStrategyFactoryImpl.java:95)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl.getSnapshotStrategy(StorageStrategyFactoryImpl.java:69)
> at
> org.apache.cloudstack.storage.snapshot.SnapshotObject.isRevertable(SnapshotObject.java:133)
> at
> com.cloud.api.ApiResponseHelper.createSnapshotResponse(ApiResponseHelper.java:499)
> at
> org.apache.cloudstack.api.command.user.snapshot.ListSnapshotsCmd.execute(ListSnapshotsCmd.java:114)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:704)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:529)
> at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:296)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:127)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:124)
> at com.cloud.api.ApiServlet.doGet(ApiServlet.java:86)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
> at
> org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
> at
> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2268)
> at
> java.ut
[jira] [Commented] (CLOUDSTACK-8964) Can't create template or volume from snapshot - "Are you sure you got the right type of server?"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044047#comment-15044047
]
ASF GitHub Bot commented on CLOUDSTACK-8964:
Github user asfgit closed the pull request at:
https://github.com/apache/cloudstack/pull/1177
> Can't create template or volume from snapshot - "Are you sure you got the
> right type of server?"
>
>
> Key: CLOUDSTACK-8964
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8964
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs & mgmt
>Reporter: Nux
>Assignee: Wei Zhou
>Priority: Blocker
> Fix For: 4.6.0
>
>
> I have a couple of snapshots left-over from by now deleted instances. Trying
> to turn them into volumes fails with (UI/cloudmonkey shows this):
> "Failed to create templateUnsupported command issued:
> org.apache.cloudstack.storage.command.CopyCommand. Are you sure you got the
> right type of server?"
> mgmt server logs for when trying to create template:
> "2015-10-18 09:15:58,437 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be) ===START=== 192.168.192.198 -- GET
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,459 DEBUG [c.c.t.TemplateManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) This template is getting created
> from other template, setting source template Id to: 201
> 2015-10-18 09:15:58,500 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-33:ctx-f566f6af job-135) Add job-135 into job monitoring
> 2015-10-18 09:15:58,506 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) submit async job-135, details:
> AsyncJobVO {id:135, userId: 2, accountId: 2, instanceType: Template,
> instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-10-18 09:15:58,506 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) ===END=== 192.168.192.198 -- GET
>
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,507 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-33:ctx-f566f6af job-135) Executing AsyncJobVO {id:135,
> userId: 2, accountId: 2, instanceType: Template, instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled:
[jira] [Commented] (CLOUDSTACK-9047) rename enums to match best practice naming pattern
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044053#comment-15044053 ] ASF GitHub Bot commented on CLOUDSTACK-9047: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1049#issuecomment-162337898 merging > rename enums to match best practice naming pattern > -- > > Key: CLOUDSTACK-9047 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9047 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > > Enums should have a name starting with a capital according to java best > practices. Rename those that don't and add unit tests where relevant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9046) Fix upgrade path from 4.4 and 4.5 to 4.6
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044056#comment-15044056 ] ASF subversion and git services commented on CLOUDSTACK-9046: - Commit c669c93b05f4529843d811ca9b1df52f34b8deb2 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c669c93 ] CLOUDSTACK-9046 rename enums to adhere to naming conventions > Fix upgrade path from 4.4 and 4.5 to 4.6 > > > Key: CLOUDSTACK-9046 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9046 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When upgrading to 4.6 from 4.5 or earlier, the systemvm template that is > registered upfront is not marked as SYSTEM and set as the template for the > existing systemvms. Therefore, new systemvms work fine but existing ones > don't. > RCA is missing code in the upgrade path, as is present when upgrading from > 4.4 to 4.5 for example. > The code in the Upgrade442to450.java is not generic, as the name suggests, > and simply configures the whole SystemVM and all the existing Domain VMs to > use the SystemVM-4.5.0 that was registered. It means that after the upgrade > all the routers were marked okay, but they were using the old stuff, from > 4.5.0. The attempt to deploy a new VM was also failing with the following > error (on the host): > 2015-11-07 18:17:31,135 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-4:null) Exit value is 1 > 2015-11-07 18:17:31,135 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-4:null) Traceback (most recent call last): File > "/opt/cloud/bin/update_con > fig.py", line 20, in from merge import QueueFile File > "/opt/cloud/bin/merge.py", line 23, in import cs_ip File > "/opt/cloud/bin/cs_ip.py", lin > e 19, in from netaddr import *ImportError: No module named netaddr > Why that? Because the KVM host has the new systemvm.iso, which contains all > the new python stuff, but the systemvm template, which installs the Guest OS > (Debian) is old and does not contain the modules we now need. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9047) rename enums to match best practice naming pattern
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044061#comment-15044061 ] ASF subversion and git services commented on CLOUDSTACK-9047: - Commit 638f1cf091056f518006af46b49bbb9dd7653b92 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=638f1cf ] Merge pull request #1049 from DaanHoogland/CLOUDSTACK-9047 CLOUDSTACK-9047 rename enumsmake enums adhere to best practice naming conventions * pr/1049: CLOUDSTACK-9046 rename enums to adhere to naming conventions CLOUDSTACK-9046 renamed enums in kvm plugin CLOUDSTACK-9047 use 'State's only with context there are more types called 'State' (or to be called so but now 'state') So remove imports and prepend their enclosing class/context to them. Signed-off-by: Daan Hoogland > rename enums to match best practice naming pattern > -- > > Key: CLOUDSTACK-9047 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9047 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > > Enums should have a name starting with a capital according to java best > practices. Rename those that don't and add unit tests where relevant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9047) rename enums to match best practice naming pattern
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044058#comment-15044058 ] ASF subversion and git services commented on CLOUDSTACK-9047: - Commit 638f1cf091056f518006af46b49bbb9dd7653b92 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=638f1cf ] Merge pull request #1049 from DaanHoogland/CLOUDSTACK-9047 CLOUDSTACK-9047 rename enumsmake enums adhere to best practice naming conventions * pr/1049: CLOUDSTACK-9046 rename enums to adhere to naming conventions CLOUDSTACK-9046 renamed enums in kvm plugin CLOUDSTACK-9047 use 'State's only with context there are more types called 'State' (or to be called so but now 'state') So remove imports and prepend their enclosing class/context to them. Signed-off-by: Daan Hoogland > rename enums to match best practice naming pattern > -- > > Key: CLOUDSTACK-9047 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9047 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > > Enums should have a name starting with a capital according to java best > practices. Rename those that don't and add unit tests where relevant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9046) Fix upgrade path from 4.4 and 4.5 to 4.6
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044055#comment-15044055 ] ASF subversion and git services commented on CLOUDSTACK-9046: - Commit 962d4b4afee6fb55aca09862b42c0f7c33f25a5f in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=962d4b4 ] CLOUDSTACK-9046 renamed enums in kvm plugin > Fix upgrade path from 4.4 and 4.5 to 4.6 > > > Key: CLOUDSTACK-9046 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9046 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When upgrading to 4.6 from 4.5 or earlier, the systemvm template that is > registered upfront is not marked as SYSTEM and set as the template for the > existing systemvms. Therefore, new systemvms work fine but existing ones > don't. > RCA is missing code in the upgrade path, as is present when upgrading from > 4.4 to 4.5 for example. > The code in the Upgrade442to450.java is not generic, as the name suggests, > and simply configures the whole SystemVM and all the existing Domain VMs to > use the SystemVM-4.5.0 that was registered. It means that after the upgrade > all the routers were marked okay, but they were using the old stuff, from > 4.5.0. The attempt to deploy a new VM was also failing with the following > error (on the host): > 2015-11-07 18:17:31,135 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-4:null) Exit value is 1 > 2015-11-07 18:17:31,135 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-4:null) Traceback (most recent call last): File > "/opt/cloud/bin/update_con > fig.py", line 20, in from merge import QueueFile File > "/opt/cloud/bin/merge.py", line 23, in import cs_ip File > "/opt/cloud/bin/cs_ip.py", lin > e 19, in from netaddr import *ImportError: No module named netaddr > Why that? Because the KVM host has the new systemvm.iso, which contains all > the new python stuff, but the systemvm template, which installs the Guest OS > (Debian) is old and does not contain the modules we now need. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9046) Fix upgrade path from 4.4 and 4.5 to 4.6
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044060#comment-15044060 ] ASF subversion and git services commented on CLOUDSTACK-9046: - Commit 638f1cf091056f518006af46b49bbb9dd7653b92 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=638f1cf ] Merge pull request #1049 from DaanHoogland/CLOUDSTACK-9047 CLOUDSTACK-9047 rename enumsmake enums adhere to best practice naming conventions * pr/1049: CLOUDSTACK-9046 rename enums to adhere to naming conventions CLOUDSTACK-9046 renamed enums in kvm plugin CLOUDSTACK-9047 use 'State's only with context there are more types called 'State' (or to be called so but now 'state') So remove imports and prepend their enclosing class/context to them. Signed-off-by: Daan Hoogland > Fix upgrade path from 4.4 and 4.5 to 4.6 > > > Key: CLOUDSTACK-9046 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9046 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When upgrading to 4.6 from 4.5 or earlier, the systemvm template that is > registered upfront is not marked as SYSTEM and set as the template for the > existing systemvms. Therefore, new systemvms work fine but existing ones > don't. > RCA is missing code in the upgrade path, as is present when upgrading from > 4.4 to 4.5 for example. > The code in the Upgrade442to450.java is not generic, as the name suggests, > and simply configures the whole SystemVM and all the existing Domain VMs to > use the SystemVM-4.5.0 that was registered. It means that after the upgrade > all the routers were marked okay, but they were using the old stuff, from > 4.5.0. The attempt to deploy a new VM was also failing with the following > error (on the host): > 2015-11-07 18:17:31,135 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-4:null) Exit value is 1 > 2015-11-07 18:17:31,135 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-4:null) Traceback (most recent call last): File > "/opt/cloud/bin/update_con > fig.py", line 20, in from merge import QueueFile File > "/opt/cloud/bin/merge.py", line 23, in import cs_ip File > "/opt/cloud/bin/cs_ip.py", lin > e 19, in from netaddr import *ImportError: No module named netaddr > Why that? Because the KVM host has the new systemvm.iso, which contains all > the new python stuff, but the systemvm template, which installs the Guest OS > (Debian) is old and does not contain the modules we now need. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9046) Fix upgrade path from 4.4 and 4.5 to 4.6
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044059#comment-15044059 ] ASF subversion and git services commented on CLOUDSTACK-9046: - Commit 638f1cf091056f518006af46b49bbb9dd7653b92 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=638f1cf ] Merge pull request #1049 from DaanHoogland/CLOUDSTACK-9047 CLOUDSTACK-9047 rename enumsmake enums adhere to best practice naming conventions * pr/1049: CLOUDSTACK-9046 rename enums to adhere to naming conventions CLOUDSTACK-9046 renamed enums in kvm plugin CLOUDSTACK-9047 use 'State's only with context there are more types called 'State' (or to be called so but now 'state') So remove imports and prepend their enclosing class/context to them. Signed-off-by: Daan Hoogland > Fix upgrade path from 4.4 and 4.5 to 4.6 > > > Key: CLOUDSTACK-9046 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9046 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When upgrading to 4.6 from 4.5 or earlier, the systemvm template that is > registered upfront is not marked as SYSTEM and set as the template for the > existing systemvms. Therefore, new systemvms work fine but existing ones > don't. > RCA is missing code in the upgrade path, as is present when upgrading from > 4.4 to 4.5 for example. > The code in the Upgrade442to450.java is not generic, as the name suggests, > and simply configures the whole SystemVM and all the existing Domain VMs to > use the SystemVM-4.5.0 that was registered. It means that after the upgrade > all the routers were marked okay, but they were using the old stuff, from > 4.5.0. The attempt to deploy a new VM was also failing with the following > error (on the host): > 2015-11-07 18:17:31,135 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-4:null) Exit value is 1 > 2015-11-07 18:17:31,135 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-4:null) Traceback (most recent call last): File > "/opt/cloud/bin/update_con > fig.py", line 20, in from merge import QueueFile File > "/opt/cloud/bin/merge.py", line 23, in import cs_ip File > "/opt/cloud/bin/cs_ip.py", lin > e 19, in from netaddr import *ImportError: No module named netaddr > Why that? Because the KVM host has the new systemvm.iso, which contains all > the new python stuff, but the systemvm template, which installs the Guest OS > (Debian) is old and does not contain the modules we now need. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9047) rename enums to match best practice naming pattern
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044057#comment-15044057 ] ASF subversion and git services commented on CLOUDSTACK-9047: - Commit 638f1cf091056f518006af46b49bbb9dd7653b92 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=638f1cf ] Merge pull request #1049 from DaanHoogland/CLOUDSTACK-9047 CLOUDSTACK-9047 rename enumsmake enums adhere to best practice naming conventions * pr/1049: CLOUDSTACK-9046 rename enums to adhere to naming conventions CLOUDSTACK-9046 renamed enums in kvm plugin CLOUDSTACK-9047 use 'State's only with context there are more types called 'State' (or to be called so but now 'state') So remove imports and prepend their enclosing class/context to them. Signed-off-by: Daan Hoogland > rename enums to match best practice naming pattern > -- > > Key: CLOUDSTACK-9047 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9047 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > > Enums should have a name starting with a capital according to java best > practices. Rename those that don't and add unit tests where relevant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9047) rename enums to match best practice naming pattern
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044054#comment-15044054 ] ASF subversion and git services commented on CLOUDSTACK-9047: - Commit 586c325167347eb1a2e7debb66d9b610b18807c5 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=586c325 ] CLOUDSTACK-9047 use 'State's only with context there are more types called 'State' (or to be called so but now 'state') So remove imports and prepend their enclosing class/context to them. > rename enums to match best practice naming pattern > -- > > Key: CLOUDSTACK-9047 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9047 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > > Enums should have a name starting with a capital according to java best > practices. Rename those that don't and add unit tests where relevant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9047) rename enums to match best practice naming pattern
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044062#comment-15044062 ] ASF GitHub Bot commented on CLOUDSTACK-9047: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1049 > rename enums to match best practice naming pattern > -- > > Key: CLOUDSTACK-9047 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9047 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > > Enums should have a name starting with a capital according to java best > practices. Rename those that don't and add unit tests where relevant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8656) fill empty catch blocks with info messages
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044064#comment-15044064 ] ASF subversion and git services commented on CLOUDSTACK-8656: - Commit f33195915ffe043b1f9d88c4ec3838ee587ceb18 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f331959 ] Merge pull request #850 from DaanHoogland/CLOUDSTACK-8656 CLOUDSTACK-8656: tests ignoring exceptionsfinal few ignored exceptions supplied with log messages. * pr/850: CLOUDSTACK-8656: tests ignoring exceptions Signed-off-by: Daan Hoogland > fill empty catch blocks with info messages > -- > > Key: CLOUDSTACK-8656 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8656 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > Fix For: 4.6.0 > > > operators and other trouble shooters need to know if unhandled exceptions > happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8656) fill empty catch blocks with info messages
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044065#comment-15044065 ] ASF subversion and git services commented on CLOUDSTACK-8656: - Commit f33195915ffe043b1f9d88c4ec3838ee587ceb18 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f331959 ] Merge pull request #850 from DaanHoogland/CLOUDSTACK-8656 CLOUDSTACK-8656: tests ignoring exceptionsfinal few ignored exceptions supplied with log messages. * pr/850: CLOUDSTACK-8656: tests ignoring exceptions Signed-off-by: Daan Hoogland > fill empty catch blocks with info messages > -- > > Key: CLOUDSTACK-8656 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8656 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > Fix For: 4.6.0 > > > operators and other trouble shooters need to know if unhandled exceptions > happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8656) fill empty catch blocks with info messages
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044066#comment-15044066 ] ASF subversion and git services commented on CLOUDSTACK-8656: - Commit f33195915ffe043b1f9d88c4ec3838ee587ceb18 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f331959 ] Merge pull request #850 from DaanHoogland/CLOUDSTACK-8656 CLOUDSTACK-8656: tests ignoring exceptionsfinal few ignored exceptions supplied with log messages. * pr/850: CLOUDSTACK-8656: tests ignoring exceptions Signed-off-by: Daan Hoogland > fill empty catch blocks with info messages > -- > > Key: CLOUDSTACK-8656 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8656 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > Fix For: 4.6.0 > > > operators and other trouble shooters need to know if unhandled exceptions > happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8656) fill empty catch blocks with info messages
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044067#comment-15044067 ] ASF GitHub Bot commented on CLOUDSTACK-8656: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/850 > fill empty catch blocks with info messages > -- > > Key: CLOUDSTACK-8656 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8656 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > Fix For: 4.6.0 > > > operators and other trouble shooters need to know if unhandled exceptions > happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8656) fill empty catch blocks with info messages
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044063#comment-15044063 ] ASF subversion and git services commented on CLOUDSTACK-8656: - Commit 52037e88e4b8de3368227565f45ae4c816d35adc in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=52037e8 ] CLOUDSTACK-8656: tests ignoring exceptions > fill empty catch blocks with info messages > -- > > Key: CLOUDSTACK-8656 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8656 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > Fix For: 4.6.0 > > > operators and other trouble shooters need to know if unhandled exceptions > happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9054) countIp6InRange(final String ip6Range) does not handle open range
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044069#comment-15044069 ] ASF GitHub Bot commented on CLOUDSTACK-9054: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1060#issuecomment-162339782 @rafaelweingartner we still allow for 1.7 so no 1.8 only features for now > countIp6InRange(final String ip6Range) does not handle open range > - > > Key: CLOUDSTACK-9054 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9054 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > > in case of '-1::0' or "0::0-" errors are thrown while the meaning of the > range is clear > In the testcase for this method an exception is thrown because of this: > 2015-11-11 10:20:57,997 ERROR [utils.net.NetUtils] (main:) Failed to convert > a string to an IPv6 address > java.lang.IllegalArgumentException: can not parse [] > at > com.googlecode.ipv6.IPv6Address.tryParseStringArrayIntoLongArray(IPv6Address.java:94) > at com.googlecode.ipv6.IPv6Address.fromString(IPv6Address.java:80) > at com.cloud.utils.net.NetUtils.countIp6InRange(NetUtils.java:1332) > at > com.cloud.utils.net.NetUtilsTest.testCountIp6InRangeWithNullStart(NetUtilsTest.java:153) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9025) Unable to deploy VM instance from template if template spin from linked clone snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044077#comment-15044077 ] ASF subversion and git services commented on CLOUDSTACK-9025: - Commit 2c4ea503f92bcf9c611f409d5cdecb42b0115b69 in cloudstack's branch refs/heads/4.6 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2c4ea50 ] Merge pull request #1176 from anshul1886/CLOUDSTACK-9025-4.6 CLOUDSTACK-9025: Fixed can't create usable template from snapshot in Xenserver and Vmwarehttps://issues.apache.org/jira/browse/CLOUDSTACK-9025 Fix also reverts below commit as below solution making assumption about hypervisor which are not applicable in case of XenServer and VmWare Revert "CLOUDSTACK-8964: Can't create template or volume from snapshot" This reverts commit ccf5d75cfbe769b34c021ab3653ed318cae25933. Testing: Able to deploy VM successfully from template created from linked clone snapshot on XenServer. * pr/1176: CLOUDSTACK-9025: Fixed can't create usable template from snapshot in Xenserver and Vmware Signed-off-by: Daan Hoogland > Unable to deploy VM instance from template if template spin from linked clone > snapshot > -- > > Key: CLOUDSTACK-9025 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9025 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.5.2 > Environment: XenServer 6.5 >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar >Priority: Critical > > As default, CloudStack create linked clone snapshot for VM instance . When we > take a snapshot for the VM, and create a template based on such snapshot, > CloudStack only download incremental VHD as template file, as a result, the > VM instance fail to deploy as it is incomplete. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9025) Unable to deploy VM instance from template if template spin from linked clone snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044075#comment-15044075 ] ASF subversion and git services commented on CLOUDSTACK-9025: - Commit 2c4ea503f92bcf9c611f409d5cdecb42b0115b69 in cloudstack's branch refs/heads/4.6 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2c4ea50 ] Merge pull request #1176 from anshul1886/CLOUDSTACK-9025-4.6 CLOUDSTACK-9025: Fixed can't create usable template from snapshot in Xenserver and Vmwarehttps://issues.apache.org/jira/browse/CLOUDSTACK-9025 Fix also reverts below commit as below solution making assumption about hypervisor which are not applicable in case of XenServer and VmWare Revert "CLOUDSTACK-8964: Can't create template or volume from snapshot" This reverts commit ccf5d75cfbe769b34c021ab3653ed318cae25933. Testing: Able to deploy VM successfully from template created from linked clone snapshot on XenServer. * pr/1176: CLOUDSTACK-9025: Fixed can't create usable template from snapshot in Xenserver and Vmware Signed-off-by: Daan Hoogland > Unable to deploy VM instance from template if template spin from linked clone > snapshot > -- > > Key: CLOUDSTACK-9025 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9025 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.5.2 > Environment: XenServer 6.5 >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar >Priority: Critical > > As default, CloudStack create linked clone snapshot for VM instance . When we > take a snapshot for the VM, and create a template based on such snapshot, > CloudStack only download incremental VHD as template file, as a result, the > VM instance fail to deploy as it is incomplete. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8964) Can't create template or volume from snapshot - "Are you sure you got the right type of server?"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044078#comment-15044078
]
ASF subversion and git services commented on CLOUDSTACK-8964:
-
Commit 2c4ea503f92bcf9c611f409d5cdecb42b0115b69 in cloudstack's branch
refs/heads/4.6 from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2c4ea50 ]
Merge pull request #1176 from anshul1886/CLOUDSTACK-9025-4.6
CLOUDSTACK-9025: Fixed can't create usable template from snapshot in Xenserver
and Vmwarehttps://issues.apache.org/jira/browse/CLOUDSTACK-9025
Fix also reverts below commit as below solution making assumption about
hypervisor which are not applicable in case of XenServer and VmWare
Revert "CLOUDSTACK-8964: Can't create template or volume from snapshot"
This reverts commit ccf5d75cfbe769b34c021ab3653ed318cae25933.
Testing:
Able to deploy VM successfully from template created from linked clone snapshot
on XenServer.
* pr/1176:
CLOUDSTACK-9025: Fixed can't create usable template from snapshot in
Xenserver and Vmware
Signed-off-by: Daan Hoogland
> Can't create template or volume from snapshot - "Are you sure you got the
> right type of server?"
>
>
> Key: CLOUDSTACK-8964
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8964
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs & mgmt
>Reporter: Nux
>Assignee: Wei Zhou
>Priority: Blocker
> Fix For: 4.6.0
>
>
> I have a couple of snapshots left-over from by now deleted instances. Trying
> to turn them into volumes fails with (UI/cloudmonkey shows this):
> "Failed to create templateUnsupported command issued:
> org.apache.cloudstack.storage.command.CopyCommand. Are you sure you got the
> right type of server?"
> mgmt server logs for when trying to create template:
> "2015-10-18 09:15:58,437 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be) ===START=== 192.168.192.198 -- GET
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,459 DEBUG [c.c.t.TemplateManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) This template is getting created
> from other template, setting source template Id to: 201
> 2015-10-18 09:15:58,500 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-33:ctx-f566f6af job-135) Add job-135 into job monitoring
> 2015-10-18 09:15:58,506 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) submit async job-135, details:
> AsyncJobVO {id:135, userId: 2, accountId: 2, instanceType: Template,
> instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-10-18 09:15:58,506 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) ===END=== 192.168.192.198 -- GET
>
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,507 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-33:ctx-f566f6af job-135) Executing AsyncJobVO {id:135,
> userId: 2, accountId: 2, instanceType: Template, instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"
[jira] [Commented] (CLOUDSTACK-8964) Can't create template or volume from snapshot - "Are you sure you got the right type of server?"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044074#comment-15044074
]
ASF subversion and git services commented on CLOUDSTACK-8964:
-
Commit f8790c3b9e822062bcdce88f62f57884bfc4 in cloudstack's branch
refs/heads/4.6 from [~anshulg]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f8790c3 ]
CLOUDSTACK-9025: Fixed can't create usable template from snapshot in Xenserver
and Vmware
Fix also reverts below commit as below solution making assumption about
hypervisor which are not applicable
in case of XenServer and VmWare
Revert "CLOUDSTACK-8964: Can't create template or volume from snapshot"
This reverts commit ccf5d75cfbe769b34c021ab3653ed318cae25933.
> Can't create template or volume from snapshot - "Are you sure you got the
> right type of server?"
>
>
> Key: CLOUDSTACK-8964
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8964
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs & mgmt
>Reporter: Nux
>Assignee: Wei Zhou
>Priority: Blocker
> Fix For: 4.6.0
>
>
> I have a couple of snapshots left-over from by now deleted instances. Trying
> to turn them into volumes fails with (UI/cloudmonkey shows this):
> "Failed to create templateUnsupported command issued:
> org.apache.cloudstack.storage.command.CopyCommand. Are you sure you got the
> right type of server?"
> mgmt server logs for when trying to create template:
> "2015-10-18 09:15:58,437 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be) ===START=== 192.168.192.198 -- GET
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,459 DEBUG [c.c.t.TemplateManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) This template is getting created
> from other template, setting source template Id to: 201
> 2015-10-18 09:15:58,500 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-33:ctx-f566f6af job-135) Add job-135 into job monitoring
> 2015-10-18 09:15:58,506 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) submit async job-135, details:
> AsyncJobVO {id:135, userId: 2, accountId: 2, instanceType: Template,
> instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
> com.cloud.storage.GuestOS\":\"ba03db1c-7359-11e5-b4d0-f2a3ece198a5\"}","displayText":"testsnap1","snapshotid":"da79387b-ecae-4d5c-b414-3942d29ad821","passwordEnabled":"false","name":"testsnap1","_":"1445156157698","uuid":"9c045e56-2463-47f8-a257-840656e1c0bd","ctxAccountId":"2","ctxStartEventId":"253"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2015-10-18 09:15:58,506 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-84b2a9be ctx-921b9b20) ===END=== 192.168.192.198 -- GET
>
> command=createTemplate&response=json&snapshotid=da79387b-ecae-4d5c-b414-3942d29ad821&name=testsnap1&displayText=testsnap1&osTypeId=ba03db1c-7359-11e5-b4d0-f2a3ece198a5&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1445156157698
> 2015-10-18 09:15:58,507 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-33:ctx-f566f6af job-135) Executing AsyncJobVO {id:135,
> userId: 2, accountId: 2, instanceType: Template, instanceId: 207, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"ba03db1c-7359-11e5-b4d0-f2a3ece198a5","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"207","ctxDetails":"{\"interface
>
> com.cloud.template.VirtualMachineTemplate\":\"9c045e56-2463-47f8-a257-840656e1c0bd\",\"interface
>
> com.cloud.storage.Snapshot\":\"da79387b-ecae-4d5c-b414-3942d29ad821\",\"interface
>
[jira] [Commented] (CLOUDSTACK-9025) Unable to deploy VM instance from template if template spin from linked clone snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044073#comment-15044073 ] ASF subversion and git services commented on CLOUDSTACK-9025: - Commit f8790c3b9e822062bcdce88f62f57884bfc4 in cloudstack's branch refs/heads/4.6 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f8790c3 ] CLOUDSTACK-9025: Fixed can't create usable template from snapshot in Xenserver and Vmware Fix also reverts below commit as below solution making assumption about hypervisor which are not applicable in case of XenServer and VmWare Revert "CLOUDSTACK-8964: Can't create template or volume from snapshot" This reverts commit ccf5d75cfbe769b34c021ab3653ed318cae25933. > Unable to deploy VM instance from template if template spin from linked clone > snapshot > -- > > Key: CLOUDSTACK-9025 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9025 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.5.2 > Environment: XenServer 6.5 >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar >Priority: Critical > > As default, CloudStack create linked clone snapshot for VM instance . When we > take a snapshot for the VM, and create a template based on such snapshot, > CloudStack only download incremental VHD as template file, as a result, the > VM instance fail to deploy as it is incomplete. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9025) Unable to deploy VM instance from template if template spin from linked clone snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044076#comment-15044076 ] ASF subversion and git services commented on CLOUDSTACK-9025: - Commit 2c4ea503f92bcf9c611f409d5cdecb42b0115b69 in cloudstack's branch refs/heads/4.6 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2c4ea50 ] Merge pull request #1176 from anshul1886/CLOUDSTACK-9025-4.6 CLOUDSTACK-9025: Fixed can't create usable template from snapshot in Xenserver and Vmwarehttps://issues.apache.org/jira/browse/CLOUDSTACK-9025 Fix also reverts below commit as below solution making assumption about hypervisor which are not applicable in case of XenServer and VmWare Revert "CLOUDSTACK-8964: Can't create template or volume from snapshot" This reverts commit ccf5d75cfbe769b34c021ab3653ed318cae25933. Testing: Able to deploy VM successfully from template created from linked clone snapshot on XenServer. * pr/1176: CLOUDSTACK-9025: Fixed can't create usable template from snapshot in Xenserver and Vmware Signed-off-by: Daan Hoogland > Unable to deploy VM instance from template if template spin from linked clone > snapshot > -- > > Key: CLOUDSTACK-9025 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9025 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.5.2 > Environment: XenServer 6.5 >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar >Priority: Critical > > As default, CloudStack create linked clone snapshot for VM instance . When we > take a snapshot for the VM, and create a template based on such snapshot, > CloudStack only download incremental VHD as template file, as a result, the > VM instance fail to deploy as it is incomplete. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9025) Unable to deploy VM instance from template if template spin from linked clone snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044079#comment-15044079 ] ASF subversion and git services commented on CLOUDSTACK-9025: - Commit 2c4ea503f92bcf9c611f409d5cdecb42b0115b69 in cloudstack's branch refs/heads/4.6 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2c4ea50 ] Merge pull request #1176 from anshul1886/CLOUDSTACK-9025-4.6 CLOUDSTACK-9025: Fixed can't create usable template from snapshot in Xenserver and Vmwarehttps://issues.apache.org/jira/browse/CLOUDSTACK-9025 Fix also reverts below commit as below solution making assumption about hypervisor which are not applicable in case of XenServer and VmWare Revert "CLOUDSTACK-8964: Can't create template or volume from snapshot" This reverts commit ccf5d75cfbe769b34c021ab3653ed318cae25933. Testing: Able to deploy VM successfully from template created from linked clone snapshot on XenServer. * pr/1176: CLOUDSTACK-9025: Fixed can't create usable template from snapshot in Xenserver and Vmware Signed-off-by: Daan Hoogland > Unable to deploy VM instance from template if template spin from linked clone > snapshot > -- > > Key: CLOUDSTACK-9025 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9025 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.5.2 > Environment: XenServer 6.5 >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar >Priority: Critical > > As default, CloudStack create linked clone snapshot for VM instance . When we > take a snapshot for the VM, and create a template based on such snapshot, > CloudStack only download incremental VHD as template file, as a result, the > VM instance fail to deploy as it is incomplete. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9025) Unable to deploy VM instance from template if template spin from linked clone snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044080#comment-15044080 ] ASF GitHub Bot commented on CLOUDSTACK-9025: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1176 > Unable to deploy VM instance from template if template spin from linked clone > snapshot > -- > > Key: CLOUDSTACK-9025 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9025 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.5.2 > Environment: XenServer 6.5 >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar >Priority: Critical > > As default, CloudStack create linked clone snapshot for VM instance . When we > take a snapshot for the VM, and create a template based on such snapshot, > CloudStack only download incremental VHD as template file, as a result, the > VM instance fail to deploy as it is incomplete. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9105) Logging enhancement: Handle/reference to track API calls end to end in the MS logs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044085#comment-15044085 ] ASF subversion and git services commented on CLOUDSTACK-9105: - Commit a4dc271253be5d6a504f644bf457cea38070857e in cloudstack's branch refs/heads/master from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a4dc271 ] CLOUDSTACK-9105: Logging enhancement: Handle/reference to track API calls end to end in the MS logs Added logid to logging framework, now all API call logs can be tracked with this id end to end > Logging enhancement: Handle/reference to track API calls end to end in the MS > logs > -- > > Key: CLOUDSTACK-9105 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9105 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.7.0 > > > Unique reference for each API call, so that it enables easier tracking and > debugging. > The reference handle should be propagated all the way down to the resource > layer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9105) Logging enhancement: Handle/reference to track API calls end to end in the MS logs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044086#comment-15044086 ] ASF subversion and git services commented on CLOUDSTACK-9105: - Commit c67d1da5dd1750cd7e5a95a91a2f31a340988713 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c67d1da ] Merge pull request #1167 from koushik-das/CLOUDSTACK-9105 CLOUDSTACK-9105: Logging enhancement: Handle/reference to track API calls end to end in the MS logs Added logid to logging framework, now all API call logs can be tracked with this id end to end * pr/1167: CLOUDSTACK-9105: Logging enhancement: Handle/reference to track API calls end to end in the MS logs Added logid to logging framework, now all API call logs can be tracked with this id end to end Signed-off-by: Daan Hoogland > Logging enhancement: Handle/reference to track API calls end to end in the MS > logs > -- > > Key: CLOUDSTACK-9105 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9105 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.7.0 > > > Unique reference for each API call, so that it enables easier tracking and > debugging. > The reference handle should be propagated all the way down to the resource > layer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9105) Logging enhancement: Handle/reference to track API calls end to end in the MS logs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044087#comment-15044087 ] ASF subversion and git services commented on CLOUDSTACK-9105: - Commit c67d1da5dd1750cd7e5a95a91a2f31a340988713 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c67d1da ] Merge pull request #1167 from koushik-das/CLOUDSTACK-9105 CLOUDSTACK-9105: Logging enhancement: Handle/reference to track API calls end to end in the MS logs Added logid to logging framework, now all API call logs can be tracked with this id end to end * pr/1167: CLOUDSTACK-9105: Logging enhancement: Handle/reference to track API calls end to end in the MS logs Added logid to logging framework, now all API call logs can be tracked with this id end to end Signed-off-by: Daan Hoogland > Logging enhancement: Handle/reference to track API calls end to end in the MS > logs > -- > > Key: CLOUDSTACK-9105 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9105 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.7.0 > > > Unique reference for each API call, so that it enables easier tracking and > debugging. > The reference handle should be propagated all the way down to the resource > layer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9105) Logging enhancement: Handle/reference to track API calls end to end in the MS logs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044089#comment-15044089 ] ASF GitHub Bot commented on CLOUDSTACK-9105: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1167 > Logging enhancement: Handle/reference to track API calls end to end in the MS > logs > -- > > Key: CLOUDSTACK-9105 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9105 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.7.0 > > > Unique reference for each API call, so that it enables easier tracking and > debugging. > The reference handle should be propagated all the way down to the resource > layer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9105) Logging enhancement: Handle/reference to track API calls end to end in the MS logs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044088#comment-15044088 ] ASF subversion and git services commented on CLOUDSTACK-9105: - Commit c67d1da5dd1750cd7e5a95a91a2f31a340988713 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c67d1da ] Merge pull request #1167 from koushik-das/CLOUDSTACK-9105 CLOUDSTACK-9105: Logging enhancement: Handle/reference to track API calls end to end in the MS logs Added logid to logging framework, now all API call logs can be tracked with this id end to end * pr/1167: CLOUDSTACK-9105: Logging enhancement: Handle/reference to track API calls end to end in the MS logs Added logid to logging framework, now all API call logs can be tracked with this id end to end Signed-off-by: Daan Hoogland > Logging enhancement: Handle/reference to track API calls end to end in the MS > logs > -- > > Key: CLOUDSTACK-9105 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9105 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.7.0 > > > Unique reference for each API call, so that it enables easier tracking and > debugging. > The reference handle should be propagated all the way down to the resource > layer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9104) VM naming convention in case vmware is used
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044091#comment-15044091 ] ASF GitHub Bot commented on CLOUDSTACK-9104: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1165#issuecomment-162341273 @priyankparihar I do not know any vmware users @bhaisaab Do you have any insight on this change? or do you know any candidate reviewer for this? > VM naming convention in case vmware is used > --- > > Key: CLOUDSTACK-9104 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9104 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Priyank Parihar > > ISSUE > == > VM naming convention in case vmware is used. > Description > == > User with different account cannot create VMs with the same name, which was > possible earlier (I am not sure in which CCP version). That time naming > convention used was like this “I--” > Currently if vm.instancename.flag is set to true the VM name will be exactly > as display name given. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9106) As a Developer I want the Redundant VPC private gateway feature fixed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044092#comment-15044092 ] ASF GitHub Bot commented on CLOUDSTACK-9106: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1179#issuecomment-162341294 @DaanHoogland Yes, sir! See linked PR above. > As a Developer I want the Redundant VPC private gateway feature fixed > - > > Key: CLOUDSTACK-9106 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9106 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues > Fix For: 4.7.0 > > > Bug in BasicNetworkTopology.applyRules() method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9025) Unable to deploy VM instance from template if template spin from linked clone snapshot
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044097#comment-15044097
]
ASF GitHub Bot commented on CLOUDSTACK-9025:
Github user ustcweizhou commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1176#discussion_r46774983
--- Diff:
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/XenServerGuru.java ---
@@ -185,7 +185,8 @@ public boolean trackVmHostChange() {
DataTO srcData = cpyCommand.getSrcTO();
DataTO destData = cpyCommand.getDestTO();
-if (srcData.getObjectType() == DataObjectType.SNAPSHOT &&
destData.getObjectType() == DataObjectType.TEMPLATE) {
+if (srcData.getHypervisorType() == HypervisorType.XenServer &&
srcData.getObjectType() == DataObjectType.SNAPSHOT &&
--- End diff --
ok, cool
> Unable to deploy VM instance from template if template spin from linked clone
> snapshot
> --
>
> Key: CLOUDSTACK-9025
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9025
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: XenServer
>Affects Versions: 4.5.2
> Environment: XenServer 6.5
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>Priority: Critical
>
> As default, CloudStack create linked clone snapshot for VM instance . When we
> take a snapshot for the VM, and create a template based on such snapshot,
> CloudStack only download incremental VHD as template file, as a result, the
> VM instance fail to deploy as it is incomplete.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044098#comment-15044098 ] ASF GitHub Bot commented on CLOUDSTACK-9074: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1094#issuecomment-162342223 Guys, I cannot build a cloud from this branch any more. The build itself works, but the database deployment gives an SQL error: `Can't DROP 'logicalrouter_uuid'; check that column/key exists` Details: ``` [INFO] --- exec-maven-plugin:1.2.1:java (create-schema) @ cloud-developer --- log4j:WARN No appenders could be found for logger (org.springframework.core.env.StandardEnvironment). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. > WARNING: Provided file does not exist: /data/git/cs1/cloudstack/developer/../utils/conf/db.properties.override > WARNING: Provided file does not exist: /data/git/cs1/cloudstack/developer/developer-prefill.sql.override > Initializing database=cloud with host=localhost port=3306 username=cloud password=cloud > Running query: drop database if exists `cloud` > Running query: create database `cloud` > Running query: GRANT ALL ON cloud.* to 'cloud'@`localhost` identified by 'cloud' > Running query: GRANT ALL ON cloud.* to 'cloud'@`%` identified by 'cloud' > Initializing database=cloud_usage with host=localhost port=3306 username=cloud password=cloud > Running query: drop database if exists `cloud_usage` > Running query: create database `cloud_usage` > Running query: GRANT ALL ON cloud_usage.* to 'cloud'@`localhost` identified by 'cloud' > Running query: GRANT ALL ON cloud_usage.* to 'cloud'@`%` identified by 'cloud' > Processing SQL file at /data/git/cs1/cloudstack/developer/target/db/create-schema.sql > Processing SQL file at /data/git/cs1/cloudstack/developer/target/db/create-schema-premium.sql > Processing SQL file at /data/git/cs1/cloudstack/developer/target/db/templates.sql > Processing SQL file at /data/git/cs1/cloudstack/developer/developer-prefill.sql > Processing upgrade: com.cloud.upgrade.DatabaseUpgradeChecker [WARNING] java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) at java.lang.Thread.run(Thread.java:745) Caused by: com.cloud.utils.exception.CloudRuntimeException: Unable to execute upgrade script: /data/git/cs1/cloudstack/developer/target/db/db/schema-410to420-cleanup.sql at com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseUpgradeChecker.java:290) at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:425) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:474) at com.cloud.upgrade.DatabaseCreator.main(DatabaseCreator.java:217) ... 6 more Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Can't DROP 'logicalrouter_uuid'; check that column/key exists at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:185) at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:87) at com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseUpgradeChecker.java:281) ... 9 more [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 19.639s (Wall Clock) [INFO] Finished at: Sun Dec 06 09:07:53 GMT 2015 [INFO] Final Memory: 43M/259M [INFO] [ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:java (create-schema) on project cloud-developer: An exception occured while executing the Java class. null: InvocationTargetException: Unable to execute upgrade script: /data/git/cs1/cloudstack/developer/target/db/db/schema-410to420-cleanup.sql: Can't DROP 'logicalrouter_uuid'; check that column/key exists -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[jira] [Commented] (CLOUDSTACK-9106) As a Developer I want the Redundant VPC private gateway feature fixed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044100#comment-15044100
]
ASF GitHub Bot commented on CLOUDSTACK-9106:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1179#issuecomment-162342338
Run this test: `nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
tags=advanced,required_hardware=true smoke/test_privategw_acl.py`
Result:
```
test_01_vpc_privategw_acl
(integration.smoke.test_privategw_acl.TestPrivateGwACL) ... === TestName:
test_01_vpc_privategw_acl | Status : SUCCESS ===
ok
test_02_vpc_privategw_static_routes
(integration.smoke.test_privategw_acl.TestPrivateGwACL) ... === TestName:
test_02_vpc_privategw_static_routes | Status : SUCCESS ===
ok
test_03_rvpc_privategw_static_routes
(integration.smoke.test_privategw_acl.TestPrivateGwACL) ... === TestName:
test_03_rvpc_privategw_static_routes | Status : SUCCESS ===
ok
--
Ran 3 tests in 2057.520s
OK
```
Nice work @wilderrodrigues !
> As a Developer I want the Redundant VPC private gateway feature fixed
> -
>
> Key: CLOUDSTACK-9106
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9106
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> Bug in BasicNetworkTopology.applyRules() method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9099) SecretKey is returned from the APIs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044102#comment-15044102 ] ASF GitHub Bot commented on CLOUDSTACK-9099: Github user DaanHoogland commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1152#discussion_r46775072 --- Diff: api/src/com/cloud/user/AccountService.java --- @@ -136,4 +140,6 @@ void checkAccess(Account account, AccessType accessType, boolean sameOwner, Stri */ UserAccount getUserAccountById(Long userId); +public String[] getKeys(ListKeysCmd cmd); --- End diff -- I agree with @jburwell > SecretKey is returned from the APIs > --- > > Key: CLOUDSTACK-9099 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9099 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kshitij Kansal >Assignee: Kshitij Kansal > > The sercreKey parameter is returned from the following APIs: > createAccount > createUser > disableAccount > disableUser > enableAccount > enableUser > listAccounts > listUsers > lockAccount > lockUser > registerUserKeys > updateAccount > updateUser -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9099) SecretKey is returned from the APIs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044104#comment-15044104 ] ASF GitHub Bot commented on CLOUDSTACK-9099: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1152#issuecomment-162342597 @kansal looking forward to your update. your intended change makes sense > SecretKey is returned from the APIs > --- > > Key: CLOUDSTACK-9099 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9099 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kshitij Kansal >Assignee: Kshitij Kansal > > The sercreKey parameter is returned from the following APIs: > createAccount > createUser > disableAccount > disableUser > enableAccount > enableUser > listAccounts > listUsers > lockAccount > lockUser > registerUserKeys > updateAccount > updateUser -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8968) UI icon over VM snapshot to deploy user instance
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044108#comment-15044108
]
ASF GitHub Bot commented on CLOUDSTACK-8968:
Github user DaanHoogland commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1150#discussion_r46775285
--- Diff: ui/scripts/instanceWizard.js ---
@@ -731,25 +746,33 @@
//step 1 : select zone
$.extend(deployVmData, {
-zoneid : args.data.zoneid
+zoneid : selectedZoneObj.id
});
//step 2: select template
-$.extend(deployVmData, {
-templateid : args.data.templateid
-});
+if (snapshotObjs) {
+$.extend(deployVmData, {
+vmsnapshotid : selectedSnapshotObj.id
+});
+}
+else {
+$.extend(deployVmData, {
+templateid : args.data.templateid
+});
+}
$.extend(deployVmData, {
hypervisor : selectedHypervisor
});
-if
(args.$wizard.find('input[name=rootDiskSize]').parent().css('display') !=
'none') {
-if
(args.$wizard.find('input[name=rootDiskSize]').val().length > 0) {
-$.extend(deployVmData, {
-rootdisksize :
args.$wizard.find('input[name=rootDiskSize]').val()
-});
-}
-}
+//Currently it is not supporting in backend
+//if
(args.$wizard.find('input[name=rootDiskSize]').parent().css('display') !=
'none') {
--- End diff --
please do not leave code commented in. this block should be deleted.
> UI icon over VM snapshot to deploy user instance
>
>
> Key: CLOUDSTACK-8968
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8968
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nitin Kumar Maharana
>
> A new icon over VM snapshot object, which upon invoked will open a deploy
> user instance wizard, where there is no choice to choose zone and ISO or
> template to deploy the user instance from.
> 1) A new icon to indicate deploy user instance from VM snapshot
> 2) The new icon is placed as an operation over each VM snapshot object.
> 3) Clicking this icon will show the wizard to deploy user instance, which is
> same as wizard for normal user instance except that zone selection page and
> ISO/template selection page would not be present in this wizard.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8858) listVolumes API fails for a particular domain with NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044126#comment-15044126
]
ASF GitHub Bot commented on CLOUDSTACK-8858:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/830#issuecomment-162345934
PIng @DaanHoogland can you review this please? I'll run some tests.
> listVolumes API fails for a particular domain with NPE
> --
>
> Key: CLOUDSTACK-8858
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8858
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.6.1
>
>
> ISSUE
> ==
> listVolumes API fails for a particular domain with NPE
> Using Firebug - API call from UI and return info
> curl
> 'https://ccp.mysecurecloud.com/client/api?command=listVolumes&response=json&sessionkey=IloZwsbwujqsU7D3PCIpNNYKFhw%3D&zoneid=6ab6c1a8-6ddd-4dfc-af0d-e3173ae248f2&domainid=0d00ce3f-c4b4-4a1e-83f9-a7d3cc33a0d7&listAll=true&page=1&pagesize=20&_=1420556952860'
> -H 'Host: ccp.mysecurecloud.com' -H 'User-Agent: Mozilla/5.0 (Windows NT
> 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0' -H 'Accept:
> application/json, text/javascript, */*; q=0.01' -H 'Accept-Language:
> en-US,en;q=0.5' -H 'Accept-Encoding: gzip, deflate' -H 'X-Requested-With:
> XMLHttpRequest' -H 'Referer: https://ccp.mysecurecloud.com/client/' -H
> 'Cookie: sessionKey=IloZwsbwujqsU7D3PCIpNNYKFhw%253D; username=jrapine;
> account=jrapine; domainid=1; role=1; userfullname=Jim%20Rapine;
> userid=396262ae-3412-4186-ad32-a6ed18103f79;
> capabilities=%5Bobject%20Object%5D; supportELB=false;
> kvmsnapshotenabled=false; regionsecondaryenabled=false;
> userpublictemplateenabled=true; userProjectsEnabled=true;
> JSESSIONID=F8EFA3C64B98928379FFEDCBC6E32DEB;
> NSC_DQ_Qsjwbuf=09671c1045525d5f4f58455e445a4a4229a0'
> Params
> _ 1420556952860
> command listVolumes
> domainid 0d00ce3f-c4b4-4a1e-83f9-a7d3cc33a0d7
> listAll true
> page 1
> pagesize 20
> response json
> sessionkeyIloZwsbwujqsU7D3PCIpNNYKFhw=
> zoneid6ab6c1a8-6ddd-4dfc-af0d-e3173ae248f2
> Response
> { "listvolumesresponse" : {"uuidList":[],"errorcode":530,"cserrorcode":} }
> TRACE logging on the management server and got the following trace of the API
> call
> Log trace of API call with TRACE logging enabled
> 2015-01-06 10:24:42,266 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-21:ctx-76704af2) ===START=== 10.111.1.3 -- GET
> command=listVolumes&response=json&sessionkey=PfDwFth3hoqeE1cgIUkfBWRHpgo%3D&zoneid=6ab6c1a8-6ddd-4dfc-af0d-e3173ae248f2&domainid=0d00ce3f-c4b4-4a1e-83f9-a7d3cc33a0d7&listAll=true&page=1&pagesize=20&_=1420557899743
> 2015-01-06 10:24:42,266 TRACE [c.c.u.d.T.Transaction]
> (catalina-exec-21:ctx-76704af2) Using current transaction: catalina-exec-21 :
> catalina-exec-21,
> 2015-01-06 10:24:42,267 TRACE [c.c.u.d.T.Connection]
> (catalina-exec-21:ctx-76704af2) Creating a DB connection with no txn: for
> 0: dbconn245854895. Stack:
> -TransactionLegacy.prepareStatement:467-TransactionLegacy.prepareAutoCloseStatement:460-GenericDaoBase.findById:977-GenericDaoBase.findByIdIncludingRemoved:946-GeneratedMethodAccessor122.invoke:-1-DelegatingMethodAccessorImpl.invoke:43-Method.invoke:622-AopUtils.invokeJoinpointUsingReflection:317-ReflectiveMethodInvocation.invokeJoinpoint:183-ReflectiveMethodInvocation.proceed:150-TransactionContextInterceptor.invoke:33-ReflectiveMethodInvocation.proceed:161
> 2015-01-06 10:24:42,267 TRACE [c.c.u.d.T.Statement]
> (catalina-exec-21:ctx-76704af2) Preparing: SELECT user.id, user.username,
> user.password, user.firstname, user.lastname, user.account_id, user.email,
> user.state, user.api_key, user.secret_key, user.created, user.removed,
> user.timezone, user.registration_token, user.is_registered, user.uuid,
> user.default FROM user WHERE user.id = ?
> 2015-01-06 10:24:42,271 TRACE [c.c.u.d.T.Statement]
> (catalina-exec-21:ctx-76704af2) Closing:
> com.mysql.jdbc.JDBC4PreparedStatement@135a46ad: SELECT user.id,
> user.username, user.password, user.firstname, user.lastname, user.account_id,
> user.email, user.state, user.api_key, user.secret_key, user.created,
> user.removed, user.timezone, user.registration_token, user.is_registered,
> user.uuid, user.default FROM user WHERE user.id = 46
> 2015-01-06 10:24:42,271 TRACE [c.c.u.d.T.Connection]
> (catalina-exec-21:ctx-76704af2) Closing DB connection: dbconn245854895
> 2015-01-06 10:24:42,271 TRACE [c.c.u.d.T.Transaction]
> (catalina-exec-21:ctx-76704af2) Using current transaction: catalina-exec-21 :
> catalina-exec-2
[jira] [Commented] (CLOUDSTACK-8847) ListServiceOfferings is returning incompatible tagged offerings when called with VM id
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044127#comment-15044127 ] ASF GitHub Bot commented on CLOUDSTACK-8847: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/823#issuecomment-162346076 Pinging @DaanHoogland to review. > ListServiceOfferings is returning incompatible tagged offerings when called > with VM id > -- > > Key: CLOUDSTACK-8847 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8847 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > When calling listServiceOfferings with VM id as parameter. It is returning > incompatible tagged offerings. It should only list all compatible tagged > offerings. The new service offering should contain all the tags of the > existing service offering. If that is the case It should list in the result. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8841) Storage XenMotion from XS 6.2 to XS 6.5 fails.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044129#comment-15044129 ] ASF GitHub Bot commented on CLOUDSTACK-8841: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/815#issuecomment-162346266 Pinging @DaanHoogland to review. Will run some tests. > Storage XenMotion from XS 6.2 to XS 6.5 fails. > -- > > Key: CLOUDSTACK-8841 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8841 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Priyank Parihar > > Storage XenMotion from XS 6.2 to XS 6.5 fails with error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9104) VM naming convention in case vmware is used
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044382#comment-15044382
]
ASF GitHub Bot commented on CLOUDSTACK-9104:
Github user bhaisaab commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1165#discussion_r46787171
--- Diff:
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
---
@@ -1889,11 +1889,20 @@ int getReservedCpuMHZ(VirtualMachineTO vmSpec) {
// Pair
private Pair composeVmNames(VirtualMachineTO vmSpec) {
-String vmInternalCSName = vmSpec.getName();
-String vmNameOnVcenter = vmSpec.getName();
-if (_instanceNameFlag && vmSpec.getHostName() != null) {
-vmNameOnVcenter = vmSpec.getHostName();
+
+String vmInternalCSName = null;
+String vmNameOnVcenter = null;
+if(vmSpec != null)
+{
+vmInternalCSName = vmNameOnVcenter = vmSpec.getName();
+if (_instanceNameFlag == true) {
+String[] tokens = vmInternalCSName.split("-");
+assert (tokens.length >= 3); // vmInternalCSName has
format i-x-y-
+vmNameOnVcenter = String.format("%s-%s-%s-%s", tokens[0],
tokens[1], tokens[2], vmSpec.getHostName());
--- End diff --
@priyankparihar can you comment on the issues and motivation around this?
Do you think we have users who would want to keep hostname as VM names on
vCenter side if the global setting is enabled (the _instanceNameFlag is true).
If this is not true, by default the name (as returned by the vmSpec) is
like: i-[0-9]*-[0-9]*-VM. (The suffix "VM", is taken from another global
setting where the default value is "VM").
> VM naming convention in case vmware is used
> ---
>
> Key: CLOUDSTACK-9104
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9104
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Priyank Parihar
>
> ISSUE
> ==
> VM naming convention in case vmware is used.
> Description
> ==
> User with different account cannot create VMs with the same name, which was
> possible earlier (I am not sure in which CCP version). That time naming
> convention used was like this “I--”
> Currently if vm.instancename.flag is set to true the VM name will be exactly
> as display name given.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9104) VM naming convention in case vmware is used
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044386#comment-15044386 ] ASF GitHub Bot commented on CLOUDSTACK-9104: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1165#issuecomment-162413895 @DaanHoogland yes I can do that, I'm personally dealt with a lot of vmware/cloudstack naming issues. The syntax/pattern has changes several times in the past between 4.0, 4.2, 4.3 causing VM sync issues when users upgrade. > VM naming convention in case vmware is used > --- > > Key: CLOUDSTACK-9104 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9104 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Priyank Parihar > > ISSUE > == > VM naming convention in case vmware is used. > Description > == > User with different account cannot create VMs with the same name, which was > possible earlier (I am not sure in which CCP version). That time naming > convention used was like this “I--” > Currently if vm.instancename.flag is set to true the VM name will be exactly > as display name given. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9086) ACS allows to create isolated networks with invalid gateway IP address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044398#comment-15044398 ] ASF GitHub Bot commented on CLOUDSTACK-9086: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1125#issuecomment-162415947 @kansal can you address some of the issues Daan has mentioned, if you can fix them today I help can review and merge this. Thanks. > ACS allows to create isolated networks with invalid gateway IP address > -- > > Key: CLOUDSTACK-9086 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9086 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kshitij Kansal >Assignee: Kshitij Kansal > > When entering invalid combination no check is performed anymore and VR is > created with invalid interface. Of course, nothing works in the isolated > network. For example, you are allowed to create network with 172.16.21.0 IP > address for GW and 255.255.255.0 for SM - this address is not valid, however > it is accepted and even used in VR. One more example - 192.168.255.255 for GW > address and 255.255.255.0 for SM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9095) Hypervisor changes to support UserData for Nuage VSP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044399#comment-15044399 ] ASF GitHub Bot commented on CLOUDSTACK-9095: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1142#issuecomment-162416088 @nlivens Nick, while it LGTM if you can resolve some of the code issues John can mentioned today, I can help review and merge this today before 4.7.0/master freeze. Thanks. > Hypervisor changes to support UserData for Nuage VSP > > > Key: CLOUDSTACK-9095 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9095 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nick Livens >Assignee: Nick Livens > > Hypervisor changes to support UserData for Nuage VSP -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8968) UI icon over VM snapshot to deploy user instance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044400#comment-15044400 ] ASF GitHub Bot commented on CLOUDSTACK-8968: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1150#issuecomment-162416679 @nitin-maharana if you can address what Daan has commented today, along with fix tabs with spaces (if any) I can help review this and merge this; before 4.7.0/master freeze is announced today. > UI icon over VM snapshot to deploy user instance > > > Key: CLOUDSTACK-8968 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8968 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > A new icon over VM snapshot object, which upon invoked will open a deploy > user instance wizard, where there is no choice to choose zone and ISO or > template to deploy the user instance from. > 1) A new icon to indicate deploy user instance from VM snapshot > 2) The new icon is placed as an operation over each VM snapshot object. > 3) Clicking this icon will show the wizard to deploy user instance, which is > same as wizard for normal user instance except that zone selection page and > ISO/template selection page would not be present in this wizard. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9069) Newly added project is not showing in the drop down until the browser is refreshed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044401#comment-15044401 ] ASF GitHub Bot commented on CLOUDSTACK-9069: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1082#issuecomment-162416751 @remibergsma @DaanHoogland anyone wants to review this one? > Newly added project is not showing in the drop down until the browser is > refreshed. > --- > > Key: CLOUDSTACK-9069 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9069 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > Steps to reproduce: > 1.Login as admin and navigate to Projects page. > 2.Add one project and navigate to Dashboard. > 3.Check for newly added project in Project drop down. > Actual behaviour: > New project is showing in drop down only after refreshing the browser. > Expected behaviour: > New project should be shown in drop down without refreshing the browser also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-9105) Logging enhancement: Handle/reference to track API calls end to end in the MS logs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koushik Das resolved CLOUDSTACK-9105. - Resolution: Fixed > Logging enhancement: Handle/reference to track API calls end to end in the MS > logs > -- > > Key: CLOUDSTACK-9105 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9105 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.7.0 > > > Unique reference for each API call, so that it enables easier tracking and > debugging. > The reference handle should be propagated all the way down to the resource > layer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9094) Multiple threads are being used to collect the stats from the same VR
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044417#comment-15044417
]
ASF GitHub Bot commented on CLOUDSTACK-9094:
Github user koushik-das commented on the pull request:
https://github.com/apache/cloudstack/pull/1140#issuecomment-162418800
LGTM based on code changes.
@bhaisaab Since VpcVirtualNetworkApplianceManager is derived from
VirtualNetworkApplianceManager, start() call on both managers ended up calling
VirtualNetworkApplianceManager.start(). This resulted in the same
threads/executors to get initialised/started twice.
> Multiple threads are being used to collect the stats from the same VR
> -
>
> Key: CLOUDSTACK-9094
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9094
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Virtual Router
>Affects Versions: 4.6.0
>Reporter: Harikrishna Patnala
>Assignee: Harikrishna Patnala
> Fix For: 4.7.0
>
>
> From the logs we can see that the management server is sending the
> networkusagecommand to a VR twice within a very short interval. This doesn't
> have any impact on the network usage being reported, however it seems to
> consume direct agent threads unnecessarily.
> See the below snippet from the logs where networkusage command was sent to
> the same VR at the same time
> 2014-03-04 00:02:07,178 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-113:null) Seq 10-1242718973: Executing request
> 2014-03-04 00:02:07,482 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-113:null) Seq 10-1242718973: Response Received:
> 2014-03-04 00:02:07,482 DEBUG [agent.transport.Request]
> (DirectAgent-113:null) Seq 10-1242718973: Processing: { Ans: , MgmtId:
> 144027776315500, via: 10, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-59-VM","bytesSent":2937782,"bytesReceived":114175352,"result":true,"details":"","wait":0}}]
> }
> 2014-03-04 00:02:07,482 DEBUG [agent.transport.Request]
> (RouterMonitor-1:null) Seq 10-1242718973: Received: { Ans: , MgmtId:
> 144027776315500, via: 10, Ver: v1, Flags: 10, { NetworkUsageAnswer } }
> 2014-03-04 00:02:07,482 DEBUG [agent.manager.AgentManagerImpl]
> (RouterMonitor-1:null) Details from executing class
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-03-04 00:02:07,198 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-244:null) Seq 10-1242718974: Executing request
> 2014-03-04 00:02:07,510 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-244:null) Seq 10-1242718974: Response Received:
> 2014-03-04 00:02:07,510 DEBUG [agent.transport.Request]
> (DirectAgent-244:null) Seq 10-1242718974: Processing: { Ans: , MgmtId:
> 144027776315500, via: 10, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-59-VM","bytesSent":2937782,"bytesReceived":114175352,"result":true,"details":"","wait":0}}]
> }
> 2014-03-04 00:02:07,510 DEBUG [agent.transport.Request]
> (RouterMonitor-1:null) Seq 10-1242718974: Received: { Ans: , MgmtId:
> 144027776315500, via: 10, Ver: v1, Flags: 10, { NetworkUsageAnswer } }
> 2014-03-04 00:02:07,510 DEBUG [agent.manager.AgentManagerImpl]
> (RouterMonitor-1:null) Details from executing class
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-03-04 00:02:07,513 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:null)
> Router stats changed from the time NetworkUsageCommand was sent. Ignoring
> current answer. Router: r-59-VM Rcvd: 114175352Sent: 2937782
> 2014-03-04 00:02:07,514 DEBUG [db.Transaction.Transaction]
> (RouterMonitor-1:null) Rolling back the transaction: Time = 2 Name =
> -VirtualNetworkApplianceManagerImpl$NetworkUsageTask.run:900-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWorker:1146-ThreadPoolExecutor$Worker.run:615-Thread.run:701;
> called by
> -Transaction.rollback:897-Transaction.removeUpTo:840-Transaction.close:664-VirtualNetworkApplianceManagerImpl$NetworkUsageTask.run:955-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWorker:1146-ThreadPoolExecutor$Worker.run:615-Thread.run:701
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9112) deployVM thread is holding the global lock on network longer and cause delays and some improvements in the planner
Harikrishna Patnala created CLOUDSTACK-9112: --- Summary: deployVM thread is holding the global lock on network longer and cause delays and some improvements in the planner Key: CLOUDSTACK-9112 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9112 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.6.0 Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Fix For: 4.7.0 There are some VM deployment failures happening when multiple VMs are deployed at a time, failures mainly due to NetworkModel code that iterates over all the vlans in the pod. This causes each deployVM thread to hold the global lock on Network longer and cause delays. This delay in turn causes more threads to choose same host and fail since capacity is not available on that host. Following are some changes required to be done to reduce delays during VM deployments which in turn causes some vm deployment failures when multiple VMs are launched at a time. - In Planner, remove the clusters that do not contain a host with matching service offering tag. This will save some iterations over clusters that dont have matching tagged host - In NetworkModel, do not query the vlans for the pod within the loop. Also optimized the logic to query the ip/ipv6 - In DeploymentPlanningManagerImpl, do not process the affinity group if the plan has hostId provided. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9094) Multiple threads are being used to collect the stats from the same VR
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044471#comment-15044471
]
ASF GitHub Bot commented on CLOUDSTACK-9094:
Github user bhaisaab commented on the pull request:
https://github.com/apache/cloudstack/pull/1140#issuecomment-162434058
@koushik-das thanks, in that case LGTM.
Will merge now.
> Multiple threads are being used to collect the stats from the same VR
> -
>
> Key: CLOUDSTACK-9094
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9094
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Virtual Router
>Affects Versions: 4.6.0
>Reporter: Harikrishna Patnala
>Assignee: Harikrishna Patnala
> Fix For: 4.7.0
>
>
> From the logs we can see that the management server is sending the
> networkusagecommand to a VR twice within a very short interval. This doesn't
> have any impact on the network usage being reported, however it seems to
> consume direct agent threads unnecessarily.
> See the below snippet from the logs where networkusage command was sent to
> the same VR at the same time
> 2014-03-04 00:02:07,178 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-113:null) Seq 10-1242718973: Executing request
> 2014-03-04 00:02:07,482 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-113:null) Seq 10-1242718973: Response Received:
> 2014-03-04 00:02:07,482 DEBUG [agent.transport.Request]
> (DirectAgent-113:null) Seq 10-1242718973: Processing: { Ans: , MgmtId:
> 144027776315500, via: 10, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-59-VM","bytesSent":2937782,"bytesReceived":114175352,"result":true,"details":"","wait":0}}]
> }
> 2014-03-04 00:02:07,482 DEBUG [agent.transport.Request]
> (RouterMonitor-1:null) Seq 10-1242718973: Received: { Ans: , MgmtId:
> 144027776315500, via: 10, Ver: v1, Flags: 10, { NetworkUsageAnswer } }
> 2014-03-04 00:02:07,482 DEBUG [agent.manager.AgentManagerImpl]
> (RouterMonitor-1:null) Details from executing class
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-03-04 00:02:07,198 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-244:null) Seq 10-1242718974: Executing request
> 2014-03-04 00:02:07,510 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-244:null) Seq 10-1242718974: Response Received:
> 2014-03-04 00:02:07,510 DEBUG [agent.transport.Request]
> (DirectAgent-244:null) Seq 10-1242718974: Processing: { Ans: , MgmtId:
> 144027776315500, via: 10, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-59-VM","bytesSent":2937782,"bytesReceived":114175352,"result":true,"details":"","wait":0}}]
> }
> 2014-03-04 00:02:07,510 DEBUG [agent.transport.Request]
> (RouterMonitor-1:null) Seq 10-1242718974: Received: { Ans: , MgmtId:
> 144027776315500, via: 10, Ver: v1, Flags: 10, { NetworkUsageAnswer } }
> 2014-03-04 00:02:07,510 DEBUG [agent.manager.AgentManagerImpl]
> (RouterMonitor-1:null) Details from executing class
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-03-04 00:02:07,513 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:null)
> Router stats changed from the time NetworkUsageCommand was sent. Ignoring
> current answer. Router: r-59-VM Rcvd: 114175352Sent: 2937782
> 2014-03-04 00:02:07,514 DEBUG [db.Transaction.Transaction]
> (RouterMonitor-1:null) Rolling back the transaction: Time = 2 Name =
> -VirtualNetworkApplianceManagerImpl$NetworkUsageTask.run:900-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWorker:1146-ThreadPoolExecutor$Worker.run:615-Thread.run:701;
> called by
> -Transaction.rollback:897-Transaction.removeUpTo:840-Transaction.close:664-VirtualNetworkApplianceManagerImpl$NetworkUsageTask.run:955-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWorker:1146-ThreadPoolExecutor$Worker.run:615-Thread.run:701
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
