[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8925:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1023#issuecomment-153613824
  
Thanks a lot, @karuturi !

I reproduce it and once fix write a new test to cover the fix.

Cheers,
WIlder


> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Chain FW_OUTBOUND (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 3   252 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED



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

[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9022:


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

https://github.com/apache/cloudstack/pull/1029#discussion_r43848708
  
--- Diff: server/src/com/cloud/configuration/Config.java ---
@@ -672,6 +672,7 @@
 "86400",
 "The interval (in seconds) to wait before running the storage 
cleanup thread.",
 null),
+StorageCleanupDelay("Advanced", StorageManager.class, Integer.class, 
"storage.cleanup.delay", "86400", "Determines how long (in seconds) to wait 
before actually expunging destroyed volumes. The default value = the default 
value of storage.cleanup.interval.", null),
--- End diff --

To make the configuration more readable, I will move all the 
storage-cleanup related configurations to Configurable interface.


> We should keep Destroyed volumes for some time
> --
>
> Key: CLOUDSTACK-9022
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> for now, the Destroyed volumes will be expunged in Storage cleanup thread, no 
> matter when they are destroyed.
> In Expunging vm, we only clean the Destroyed vms which have been destroyed at 
> least 'expunge.delay' seconds.
> We need to add the similar configuration for volumes.



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

[jira] [Commented] (CLOUDSTACK-7097) failing to add kvm host to MS

[Wei Zhou (JIRA)]

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

Wei Zhou commented on CLOUDSTACK-7097:
--

[~rootguy]it looks the virtualization technology is disabled in BIOS. 
Otherwise, you could see kvm_intel or kvm_amd in lsmod.

root@KVM001:~# lsmod|grep kvm
kvm_intel 151552  18
kvm   479232  1 kvm_intel


> failing to add  kvm host to MS
> --
>
> Key: CLOUDSTACK-7097
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7097
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Management Server
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.log.tar.gz
>
>
> Repro steps:
> Create a agent on rhel 6.3
> create a MS on rhel 6.3
> Try creating a zone
> Bug : zone creation fails at adding host step
> MS log shows :
> 014-07-11 03:33:46,284 WARN  [c.c.a.d.ParamGenericValidationWorker] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Received unknown parameters for 
> command addHost. Unknown parameters : clustertype
> 2014-07-11 03:33:46,294 INFO  [c.c.r.ResourceManagerImpl] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Trying to add a new host at 
> http://10.147.40.24 in data center 1
> 2014-07-11 03:33:46,487 DEBUG [c.c.u.s.SSHCmdHelper] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
> 2014-07-11 03:33:47,505 DEBUG [c.c.u.s.SSHCmdHelper] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
> 2014-07-11 03:33:48,556 DEBUG [c.c.u.s.SSHCmdHelper] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
> 2014-07-11 03:33:49,607 DEBUG [c.c.h.k.d.LibvirtServerDiscoverer] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) It's not a KVM enabled machine
> 2014-07-11 03:33:49,608 WARN  [c.c.r.ResourceManagerImpl] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Unable to find the server 
> resources at http://10.147.40.24
> 2014-07-11 03:33:49,611 INFO  [c.c.u.e.CSExceptionErrorCode] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Could not find exception: 
> com.cloud.exception.DiscoveryException in error code list for exceptions
> 2014-07-11 03:33:49,611 WARN  [o.a.c.a.c.a.h.AddHostCmd] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Exception:
> com.cloud.exception.DiscoveryException: Unable to add the host
> at 
> com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:791)
> at 
> com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy148.discoverHosts(Unknown Source)
> at 
> org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517)
> at 
> com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
> 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:115)
> at com.cloud.api.ApiServlet.doPost(A

[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8925:


Github user karuturi commented on the pull request:

https://github.com/apache/cloudstack/pull/1023#issuecomment-153605360
  
I upgraded an existing xenserver setup with the changes in this PR. (clear 
the tags on xenserver and restarted the networks to recreated VRs with new 
systemvm.iso) I also manually checked it has the latest configure.py file
(added details about setup on my first comment 
https://github.com/apache/cloudstack/pull/1023#issuecomment-153274765 )

In the default egress allow network, it has an existing egress rule to 
block port 22 and restarting it created a new router without egress chain.
when I deleted the rule and restarted network, it created new router with 
egress chain properly configured. 

to clear the confusion, I was able to reproduce it with the following steps
1. create a new network with default egress allow (network name: 
egress2_allow)
2. launch a vm in the network.
3. check that VR came up and running
4. ssh to VR and check the iptables. 
5. verified that iptables FW_EGRESS_RULES is present. 
6. test outgoing traffic from user vm created in this network. (ssh and 
ping were working fine)
7. create a egress rule to block port 22
8. verified that iptables drop rule is added in egress chain on VR
9. verified that ssh from user vm doesnt work
10. restart network and wait till a new VR  is created and running
11. observe that FW_EGRESS_RULES is missing in the iptables on the new VR
12. also, ping google.com and ssh doesnt work from user vm


> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Chain FW_OUTBOUND (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 3   252 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED



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

[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8925:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1023#issuecomment-153596954
  
Hi @karuturi,

Sorry, perhaps too earlier here, but I don't follow completely. :)

How did you setup your environment in order to test the case you explained 
above? You mentioned that the rules were not there, and you had to set them up 
manually. However, in the next comment, you said that is might have been caused 
by restarting the network.

Did you run the tests in an isolated environment with a new built 
systemvm.iso?

I just want to understand how you got that scenario - no rules. Based on 
the new code and test, the only issue we got was the UDP/53 on the RVR.

If it was all caused by the network restart, then it's clear. And by the 
way, that is another issue and I will have a look at.

Thanks again for the tests.

Cheers,
Wilder


> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Chain FW_OUTBOUND (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 3   252 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED



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

[jira] [Commented] (CLOUDSTACK-8906) /var/log/cloud/ doesn't get logrotated on xenserver

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8906:


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

https://github.com/apache/cloudstack/pull/883#discussion_r43846616
  
--- Diff: scripts/vm/hypervisor/xenserver/logrotate ---
@@ -0,0 +1,29 @@
+#!/bin/bash
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+
+# Version @VERSION@
+#
+# script to perform logrotation on xenserver 6.0.2 and later
+
+/usr/sbin/logrotate  /etc/logrotate.d/cloudlog
--- End diff --

@sspans  I think the files mentioned in the patch file are the only ones 
getting deployed to the xenserver. Of these I cloud find cloudlog is the only 
logrotate configuration file. 
Please let me know if I missed anything.


> /var/log/cloud/ doesn't get logrotated on xenserver 
> 
>
> Key: CLOUDSTACK-8906
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8906
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>




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

[jira] [Commented] (CLOUDSTACK-8958) add dedicated ips to domain

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8958:


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

https://github.com/apache/cloudstack/pull/1007#discussion_r43845446
  
--- Diff: server/src/com/cloud/configuration/ConfigurationManagerImpl.java 
---
@@ -3310,13 +3331,19 @@ public Vlan dedicatePublicIpRange(final 
DedicatePublicIpRangeCmd cmd) throws Res
 vlanOwner = 
_accountMgr.getAccount(project.getProjectAccountId());
 }
 
+Domain domain = null;
 if (accountName != null && domainId != null) {
 vlanOwner = _accountDao.findActiveAccount(accountName, 
domainId);
-}
-if (vlanOwner == null) {
-throw new InvalidParameterValueException("Unable to find 
account by name " + accountName);
-} else if (vlanOwner.getId() == Account.ACCOUNT_ID_SYSTEM) {
-throw new InvalidParameterValueException("Please specify a 
valid account. Cannot dedicate IP range to system account");
+if (vlanOwner == null) {
--- End diff --

vlanOwner check is now done only when account is specified. What about the 
project case which also can set the vlanOwner? 


> add dedicated ips to domain
> ---
>
> Key: CLOUDSTACK-8958
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8958
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> add dedicated ips to domain 
> ips are dedicated to Account for now, so other customers and projects in the 
> same domain will use the system ip. this is not what we need.



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

[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9022:


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

https://github.com/apache/cloudstack/pull/1029#discussion_r43844404
  
--- Diff: setup/db/db/schema-452to460.sql ---
@@ -420,3 +420,6 @@ INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` 
(uuid,hypervisor_type, hypervis
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(),'KVM', 'default', 'CentOS 7', 246, utc_timestamp(), 0);
 
 UPDATE  `cloud`.`hypervisor_capabilities` SET  `max_data_volumes_limit` =  
'32' WHERE  `hypervisor_capabilities`.`hypervisor_type` =  'KVM';
+
+INSERT IGNORE INTO `cloud`.`configuration` (`category`, `instance`, 
`component`, `name`, `value`, `default_value`, `description`) VALUES 
('Advanced', 'DEFAULT', 'StorageManager', 'storage.cleanup.delay', '86400', 
'86400', 'Determines how long (in seconds) to wait before actually expunging 
destroyed volumes. The default value = the default value of 
storage.cleanup.interval.');
--- End diff --

This is not required when Configurable interface is used


> We should keep Destroyed volumes for some time
> --
>
> Key: CLOUDSTACK-9022
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> for now, the Destroyed volumes will be expunged in Storage cleanup thread, no 
> matter when they are destroyed.
> In Expunging vm, we only clean the Destroyed vms which have been destroyed at 
> least 'expunge.delay' seconds.
> We need to add the similar configuration for volumes.



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

[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9022:


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

https://github.com/apache/cloudstack/pull/1029#discussion_r43844351
  
--- Diff: server/src/com/cloud/configuration/Config.java ---
@@ -672,6 +672,7 @@
 "86400",
 "The interval (in seconds) to wait before running the storage 
cleanup thread.",
 null),
+StorageCleanupDelay("Advanced", StorageManager.class, Integer.class, 
"storage.cleanup.delay", "86400", "Determines how long (in seconds) to wait 
before actually expunging destroyed volumes. The default value = the default 
value of storage.cleanup.interval.", null),
--- End diff --

Please use the Configurable interface for configuration parameters instead. 
Refer to https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration


> We should keep Destroyed volumes for some time
> --
>
> Key: CLOUDSTACK-9022
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> for now, the Destroyed volumes will be expunged in Storage cleanup thread, no 
> matter when they are destroyed.
> In Expunging vm, we only clean the Destroyed vms which have been destroyed at 
> least 'expunge.delay' seconds.
> We need to add the similar configuration for volumes.



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

[jira] [Resolved] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[Rohit Yadav (JIRA)]

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

Rohit Yadav resolved CLOUDSTACK-9019.
-
Resolution: Fixed

> Storage VM gets two mgmt nics when no storage net defined
> -
>
> Key: CLOUDSTACK-9019
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9019
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.5.3, 4.6.0
>
>
> If a dedicated storage network is not provided in a zone, secondary storage 
> VMs get two management nics. This eats up an additional IP, the fix would be 
> to allocate a storage nic only when storage network is defined.



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

[jira] [Commented] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9019:


Github user asfgit closed the pull request at:

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


> Storage VM gets two mgmt nics when no storage net defined
> -
>
> Key: CLOUDSTACK-9019
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9019
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.5.3, 4.6.0
>
>
> If a dedicated storage network is not provided in a zone, secondary storage 
> VMs get two management nics. This eats up an additional IP, the fix would be 
> to allocate a storage nic only when storage network is defined.



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

[jira] [Commented] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF subversion and git services (JIRA)]

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

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

Commit 7aeff217a3dd21fa93c9e6d3cf71276ab434361f in cloudstack's branch 
refs/heads/4.5 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7aeff21 ]

Merge pull request #1025 from shapeblue/CLOUDSTACK-9019-4.5

[4.5] CLOUDSTACK-9019: Add storage network offering in ssvm only if storage 
network is defined

During creation of SSVM, checks and adds NetworkOffering.SystemStorageNetwork to
offerings only if storage network exists for the target datacenter

(Manually tested)

* pr/1025:
  CLOUDSTACK-9019: Add storage network offering in ssvm only if storage network 
is defined

Signed-off-by: Rohit Yadav 


> Storage VM gets two mgmt nics when no storage net defined
> -
>
> Key: CLOUDSTACK-9019
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9019
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.5.3, 4.6.0
>
>
> If a dedicated storage network is not provided in a zone, secondary storage 
> VMs get two management nics. This eats up an additional IP, the fix would be 
> to allocate a storage nic only when storage network is defined.



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

[jira] [Commented] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF subversion and git services (JIRA)]

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

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

Commit 7aeff217a3dd21fa93c9e6d3cf71276ab434361f in cloudstack's branch 
refs/heads/4.5 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7aeff21 ]

Merge pull request #1025 from shapeblue/CLOUDSTACK-9019-4.5

[4.5] CLOUDSTACK-9019: Add storage network offering in ssvm only if storage 
network is defined

During creation of SSVM, checks and adds NetworkOffering.SystemStorageNetwork to
offerings only if storage network exists for the target datacenter

(Manually tested)

* pr/1025:
  CLOUDSTACK-9019: Add storage network offering in ssvm only if storage network 
is defined

Signed-off-by: Rohit Yadav 


> Storage VM gets two mgmt nics when no storage net defined
> -
>
> Key: CLOUDSTACK-9019
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9019
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.5.3, 4.6.0
>
>
> If a dedicated storage network is not provided in a zone, secondary storage 
> VMs get two management nics. This eats up an additional IP, the fix would be 
> to allocate a storage nic only when storage network is defined.



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

[jira] [Commented] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF subversion and git services (JIRA)]

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

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

Commit 7aeff217a3dd21fa93c9e6d3cf71276ab434361f in cloudstack's branch 
refs/heads/4.5 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7aeff21 ]

Merge pull request #1025 from shapeblue/CLOUDSTACK-9019-4.5

[4.5] CLOUDSTACK-9019: Add storage network offering in ssvm only if storage 
network is defined

During creation of SSVM, checks and adds NetworkOffering.SystemStorageNetwork to
offerings only if storage network exists for the target datacenter

(Manually tested)

* pr/1025:
  CLOUDSTACK-9019: Add storage network offering in ssvm only if storage network 
is defined

Signed-off-by: Rohit Yadav 


> Storage VM gets two mgmt nics when no storage net defined
> -
>
> Key: CLOUDSTACK-9019
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9019
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.5.3, 4.6.0
>
>
> If a dedicated storage network is not provided in a zone, secondary storage 
> VMs get two management nics. This eats up an additional IP, the fix would be 
> to allocate a storage nic only when storage network is defined.



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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9025:


Github user anshul1886 commented on the pull request:

https://github.com/apache/cloudstack/pull/1030#issuecomment-153575238
  
I am going on vacation so if there are any concerns then feel free to 
modify it.


> 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
> Fix For: 4.6.0
>
>
> 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-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF subversion and git services (JIRA)]

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

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

Commit 619f0eb276499a7b8f31d31f6479d27f215c7b3f in cloudstack's branch 
refs/heads/4.5 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=619f0eb ]

CLOUDSTACK-9019: Add storage network offering in ssvm only if storage network 
is defined

During creation of SSVM, checks and adds NetworkOffering.SystemStorageNetwork to
offerings only if storage network exists for the target datacenter

Signed-off-by: Rohit Yadav 


> Storage VM gets two mgmt nics when no storage net defined
> -
>
> Key: CLOUDSTACK-9019
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9019
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.5.3, 4.6.0
>
>
> If a dedicated storage network is not provided in a zone, secondary storage 
> VMs get two management nics. This eats up an additional IP, the fix would be 
> to allocate a storage nic only when storage network is defined.



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

[jira] [Commented] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9019:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/1025#issuecomment-153575105
  
Merging since #1024 is merged now.


> Storage VM gets two mgmt nics when no storage net defined
> -
>
> Key: CLOUDSTACK-9019
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9019
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.5.3, 4.6.0
>
>
> If a dedicated storage network is not provided in a zone, secondary storage 
> VMs get two management nics. This eats up an additional IP, the fix would be 
> to allocate a storage nic only when storage network is defined.



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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9025:


GitHub user anshul1886 opened a pull request:

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

CLOUDSTACK-9025 : [Xenserver] Sending template creation from snapshot 
command to Hypervisor

https://issues.apache.org/jira/browse/CLOUDSTACK-9025

In this fix we are sending command to hypervisor only if hypervisor version 
is not 6.1.0 and 6.2.0 without XSHotFix62ESP1004. I am not sure whether we 
support Xenserver 6.1.0 and 6.2.0 without XSHotFix62ESP1004. This conditional 
check is there to make sure users are able to upgrade in transition period. If 
that's not the case we can remove condition all together and can send command 
to hypervisor.

To test this issue we need different versions of XenServer. Versions which 
we are mentioning in condition in that case it should go to SSVM and in other 
cases it should go to Hypervsior. SSVM can't handle linked snapshots in case of 
XenServer. 

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

$ git pull https://github.com/anshul1886/cloudstack-1 CLOUDSTACK-9025

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

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

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

This closes #1030


commit 2251751177b6cb66a7e7682ada9ac83ee06a55e2
Author: Anshul Gangwar 
Date:   2015-10-28T09:15:52Z

CLOUDSTACK-9025 : [Xenserver] Sending template creation from snapshot 
command to Hypervisor
if hypervisor version is not 6.1.0 and 6.2.0 without XSHotFix62ESP1004.




> 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
> Fix For: 4.6.0
>
>
> 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] [Created] (CLOUDSTACK-9025) Unable to deploy VM instance from template if template spin from linked clone snapshot

[Anshul Gangwar (JIRA)]

Anshul Gangwar created CLOUDSTACK-9025:
--

 Summary: 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
 Fix For: 4.6.0


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-9006) ListTemplates API returns result in inconsistent order when called concurrently

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9006:


Github user rags22489664 commented on the pull request:

https://github.com/apache/cloudstack/pull/1009#issuecomment-153573303
  
Added Filter test which checks the Order By clause is being constructed 
properly by the Filter class


> ListTemplates API returns result in inconsistent order when called 
> concurrently
> ---
>
> Key: CLOUDSTACK-9006
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9006
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Ramamurti Subramanian
>Assignee: Ramamurti Subramanian
>




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

[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8925:


Github user karuturi commented on the pull request:

https://github.com/apache/cloudstack/pull/1023#issuecomment-153573013
  
@wilderrodrigues 
I think this has to do with restarting a egress default allow network with 
existing egress rules. 
When my network had an existing egress rule for port 22 and I restarted the 
network, none of the egress iptables rules were created.
But, if I delete the existing egress rules, restart the network, egress 
rules chain got created.

restarting a default egress deny network works fine. 


> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Chain FW_OUTBOUND (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 3   252 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED



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

[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8925:


Github user karuturi commented on the pull request:

https://github.com/apache/cloudstack/pull/1023#issuecomment-153572067
  
testing steps same as above.

iptables rules on default egress ALLOW router
```
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   
destination
0 0 NETWORK_STATS  all  --  *  *   0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT all  --  eth0   eth10.0.0.0/0
0.0.0.0/0state RELATED,ESTABLISHED
0 0 ACCEPT all  --  eth0   eth00.0.0.0/0
0.0.0.0/0state NEW
0 0 ACCEPT all  --  eth2   eth00.0.0.0/0
0.0.0.0/0state RELATED,ESTABLISHED
0 0 ACCEPT all  --  eth0   eth00.0.0.0/0
0.0.0.0/0state RELATED,ESTABLISHED
0 0 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
0.0.0.0/0

Chain OUTPUT (policy ACCEPT 76 packets, 10157 bytes)
 pkts bytes target prot opt in out source   
destination
  436 61159 NETWORK_STATS  all  --  *  *   0.0.0.0/0
0.0.0.0/0

Chain FW_OUTBOUND (1 references)
 pkts bytes target prot opt in out source   
destination
0 0 ACCEPT all  --  *  *   0.0.0.0/0
0.0.0.0/0state RELATED,ESTABLISHED

```
iptables rules on default egress DENY router
```
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   
destination
0 0 NETWORK_STATS  all  --  *  *   0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT all  --  eth0   eth10.0.0.0/0
0.0.0.0/0state RELATED,ESTABLISHED
0 0 ACCEPT all  --  eth0   eth00.0.0.0/0
0.0.0.0/0state NEW
0 0 ACCEPT all  --  eth2   eth00.0.0.0/0
0.0.0.0/0state RELATED,ESTABLISHED
0 0 ACCEPT all  --  eth0   eth00.0.0.0/0
0.0.0.0/0state RELATED,ESTABLISHED
0 0 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
0.0.0.0/0

Chain OUTPUT (policy ACCEPT 39 packets, 3932 bytes)
 pkts bytes target prot opt in out source   
destination
  436 61098 NETWORK_STATS  all  --  *  *   0.0.0.0/0
0.0.0.0/0

Chain FW_EGRESS_RULES (1 references)
 pkts bytes target prot opt in out source   
destination
0 0 DROP   all  --  *  *   0.0.0.0/0
0.0.0.0/0

Chain FW_OUTBOUND (1 references)
 pkts bytes target prot opt in out source   
destination
0 0 ACCEPT all  --  *  *   0.0.0.0/0
0.0.0.0/0state RELATED,ESTABLISHED
0 0 FW_EGRESS_RULES  all  --  *  *   0.0.0.0/0
0.0.0.0/0
```

uservms in both the networks are not able to ping google.com
```
specific tools.
[root@egress-allow-vm ~]# ping google.com
PING google.com (216.58.192.110) 56(84) bytes of data.

--- google.com ping statistics ---
16 packets transmitted, 0 received, 100% packet loss, time 15007ms

[root@egress-deny-vm ~]# ping google.com
PING google.com (216.58.192.110) 56(84) bytes of data.

--- google.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2010ms
```

FW_EGRESS_RULES is missing in the default egress allow vr
I executed the following on the egress allow router
```
iptables -N FW_EGRESS_RULES
iptables -A FW_OUTBOUND -j FW_EGRESS_RULES
iptables -A FW_EGRESS_RULES -j ACCEPT
```
now the new iptables
```
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   
destination
   16  1344 NETWORK_STATS  all  --  *  *   0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT all  --  eth0   eth10.0.0.0/0
0.0.0.0/0state RELATED,ESTABLISHED
0 0 ACCEPT all  --  eth0   eth00.0.0.0/0
0.0.0.0/0state NEW
0 0 ACCEPT all  --  eth2   eth00.0.0.0/0
0.0.0.0/0state RELATED,ESTABLISHED
0 0 ACCEPT all  --  eth0   eth00.0.0.0/0
0.0.0.0/0state RELATED,ESTABLISHED
   16  1344 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
0.0.0.0/0
   

[jira] [Updated] (CLOUDSTACK-8592) Enhance usage server to provide quota service

[Abhinandan Prateek (JIRA)]

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

Abhinandan Prateek updated CLOUDSTACK-8592:
---
Fix Version/s: (was: 4.6.0)
   4.7.0

> Enhance usage server to provide quota service
> -
>
> Key: CLOUDSTACK-8592
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8592
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.6.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
>Priority: Critical
> Fix For: 4.7.0
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quota+Service+-+FS
> Quota service while allowing for scalability will make sure that the cloud is 
> not exploited by attacks, careless use and program errors. To address this 
> problem, we propose to employ a quota-enforcement service that allows 
> resource usage within certain bounds as defined by policies and available 
> quotas for various entities. 
> Quota service extends the functionality of usage server to provide a 
> measurement for the resources used by the accounts and domains using a common 
> unit referred to as cloud currency in this document. It can be configured to 
> ensure that your usage won’t exceed the budget allocated to accounts/domain 
> in cloud currency.
> It will let user know how much of the cloud resources he is using. It will 
> help the cloud admins, if they want, to ensure that a user does not go beyond 
> his allocated quota. Per usage cycle if a account is found to be exceeding 
> its quota then it is locked. Locking an account means that it will not be 
> able to initiat
> e a new resource allocation request, whether it is more storage or an 
> additional ip. Needless to say quota service as well as any action on the 
> account is configurable.



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

[jira] [Commented] (CLOUDSTACK-8480) Unable to create instances

[Nagaraju (JIRA)]

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

Nagaraju commented on CLOUDSTACK-8480:
--

Cloudstack is unstable can't rely on  issues getting raised day by day and
there is no proper document to bring Cloudstack up.

And after a long time am getting update by this time I hv found some other
alternate opensource  cloud solution I.E openstack and its perfectly
working fine.

Initially I liked Cloudstack very much tried a lot to implement but I was
unsuccessful.

Cloudstack is not up to the mark..




> Unable to create instances
> --
>
> Key: CLOUDSTACK-8480
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8480
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nagaraju
>
> Getting the below error while creating the instances,
> Job failed due to exception Resource [Host:1] is unreachable: Host 1: Unable 
> to start instance due to Unable to send command. Upgrade in progress. Please 
> contact administrator
> ==
> 2015-05-19 15:00:02,850 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-16:ctx-dcffc068 job-125) Unexpected exception while 
> executing org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin
> java.lang.RuntimeException: Job failed due to exception Resource [Host:1] is 
> unreachable: Host 1: Unable to start instance due to Unable to send command. 
> Upgrade in progress. Please contact administrator.
> at 
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:114)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:502)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:459)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> 2015-05-19 15:00:02,851 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-16:ctx-dcffc068 job-125) Complete async job-125, jobStatus: 
> FAILED, resultCode: 530, result: 
> org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"Job
>  failed due to exception Resource [Host:1] is unreachable: Host 1: Unable to 
> start instance due to Unable to send command. Upgrade in progress. Please 
> contact administrator."}
> 2015-05-19 15:00:02,855 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-16:ctx-dcffc068 job-125) Done executing 
> org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin for job-125
> 2015-05-19 15:00:02,857 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (API-Job-Executor-16:ctx-dcffc068 job-125) Remove job-125 from job monitoring
> 2015-05-19 15:00:03,251 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-5:ctx-a4b13d5e) ===START===  172.21.8.77 -- GET  
> command=queryAsyncJobResult&jobId=c03c551f-c842-4060-ae97-e0a8da17d2f4&response=json&sessionkey=%2BWBJtQkjw7Ik31mK6ZaCSGjNkhQ%3D&_=1432027785178
> 2015-05-19 15:00:03,266 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-5:ctx-a4b13d5e ctx-8add23f3) ===END===  172.21.8.77 -- GET  
> command=queryAsyncJobResult&jobId=c03c551f-c842-4060-ae97-e0a8da17d2f4&response=json&sessionkey=%2BWBJtQkjw7Ik31mK6ZaCSGjNkhQ%3D&_=1432027785178
> 2015-05-19 15:00:03,280 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-11:ctx-436e689a) ===START===  172.21.8.77 -- GET  
> command=listVirtualMachines&id=3ee9904f-ba12-45e9-afe0-d5022534d849&response=json&sessionkey=%2BWBJtQkjw7Ik31mK6ZaCSGjNkhQ%3D&_=1432027785200
> 2015-05-19 15:00:03,302 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-11:ctx-436e689a ctx-3dbb961a) ===END===  172.21.8.77 -- GET  
> command=listVirtualMachines&id=3ee9904f-ba12-45e9-afe0-d5022534d849&response=json&sessionkey=%2BWBJtQkjw7Ik31mK6ZaCSGjNkhQ%3D&_=1432027785200
> 2015-05-19 15:00:10,115 DEB

[jira] [Comment Edited] (CLOUDSTACK-7097) failing to add kvm host to MS

[Imran Ahmed (JIRA)]

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

Imran Ahmed edited comment on CLOUDSTACK-7097 at 11/4/15 2:30 AM:
--

I faced this issue while adding a host manually on cloudstack 4.4  here is what 
I can see in management-server.log:

2015-11-03 20:10:25,836 WARN  [c.c.a.d.ParamGenericValidationWorker] 
(catalina-exec-18:ctx-e0055fb6 ctx-16be7693) Received unknown parameters for 
command addHost. Unknown parameters : clustertype
Checking KVM...[Failed]
2015-11-03 20:12:11,903 WARN  [o.a.c.alerts] (HA-2:ctx-72908537)  alertType:: 
13 // dataCenterId:: 0 // podId:: 0 // clusterId:: null // message:: No usage 
server process running
2015-11-03 20:15:28,447 DEBUG [c.c.h.k.d.LibvirtServerDiscoverer] 
(catalina-exec-18:ctx-e0055fb6 ctx-16be7693) Timeout, to wait for the host 
connecting to mgt svr, assuming it is failed
2015-11-03 20:15:28,449 WARN  [c.c.r.ResourceManagerImpl] 
(catalina-exec-18:ctx-e0055fb6 ctx-16be7693) Unable to find the server 
resources at http://192.168.2.29
2015-11-03 20:15:28,449 INFO  [c.c.u.e.CSExceptionErrorCode] 
(catalina-exec-18:ctx-e0055fb6 ctx-16be7693) Could not find exception: 
com.cloud.exception.DiscoveryException in error code list for exceptions
2015-11-03 20:15:28,450 WARN  [o.a.c.a.c.a.h.AddHostCmd] 
(catalina-exec-18:ctx-e0055fb6 ctx-16be7693) Exception:
com.cloud.exception.DiscoveryException: Unable to add the host
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
2015-11-03 20:15:28,452 INFO  [c.c.a.ApiServer] (catalina-exec-18:ctx-e0055fb6 
ctx-16be7693) Unable to add the host



But at the same time when I do lsmod on the  KVM hypervisor host  I can see kvm 
as :

:~#  lsmod |grep kvm
kvm   479232  0



was (Author: rootguy):
I faced this issue while adding a host manually on cloudstack 4.4  here is what 
I can see in management-server.log:

2015-11-03 20:10:25,836 WARN  [c.c.a.d.ParamGenericValidationWorker] 
(catalina-exec-18:ctx-e0055fb6 ctx-16be7693) Received unknown parameters for 
command addHost. Unknown parameters : clustertype
Checking KVM...[Failed]
2015-11-03 20:12:11,903 WARN  [o.a.c.alerts] (HA-2:ctx-72908537)  alertType:: 
13 // dataCenterId:: 0 // podId:: 0 // clusterId:: null // message:: No usage 
server process running
2015-11-03 20:15:28,447 DEBUG [c.c.h.k.d.LibvirtServerDiscoverer] 
(catalina-exec-18:ctx-e0055fb6 ctx-16be7693) Timeout, to wait for the host 
connecting to mgt svr, assuming it is failed
2015-11-03 20:15:28,449 WARN  [c.c.r.ResourceManagerImpl] 
(catalina-exec-18:ctx-e0055fb6 ctx-16be7693) Unable to find the server 
resources at http://192.168.2.29
2015-11-03 20:15:28,449 INFO  [c.c.u.e.CSExceptionErrorCode] 
(catalina-exec-18:ctx-e0055fb6 ctx-16be7693) Could not find exception: 
com.cloud.exception.DiscoveryException in error code list for exceptions
2015-11-03 20:15:28,450 WARN  [o.a.c.a.c.a.h.AddHostCmd] 
(catalina-exec-18:ctx-e0055fb6 ctx-16be7693) Exception:
com.cloud.exception.DiscoveryException: Unable to add the host
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
2015-11-03 20:15:28,452 INFO  [c.c.a.ApiServer] (catalina-exec-18:ctx-e0055fb6 
ctx-16be7693) Unable to add the host


> failing to add  kvm host to MS
> --
>
> Key: CLOUDSTACK-7097
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7097
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Management Server
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.log.tar.gz
>
>
> Repro steps:
> Create a agent on rhel 6.3
> create a MS on rhel 6.3
> Try creating a zone
> Bug : zone creation fails at adding host step
> MS log shows :
> 014-07-11 03:33:46,284 WARN  [c.c.a.d.ParamGenericValidationWorker] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Received unknown parameters for 
> command addHost. Unknown parameters : clustertype
> 2014-07-11 03:33:46,294 INFO  [c.c.r.ResourceManagerImpl] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Trying to add a new host at 
> http://10.147.40.24 in data center 1
> 2014-07-11 03:33:46,487 DEBUG [c.c.u.s.SSHCmdHelper] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
> 2014-07-11 03:33:47,505 DEBUG [c.c.u.s.SSHCmdHelper] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
> 2014-07-11 03:33:48,556 DEBUG [c.c.u.s.SSHCmdHelper] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
> 2014-07-11 03:33:49,607 DEBUG [c.c.h.k.d.LibvirtSe

[jira] [Commented] (CLOUDSTACK-7097) failing to add kvm host to MS

[Imran Ahmed (JIRA)]

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

Imran Ahmed commented on CLOUDSTACK-7097:
-

I faced this issue while adding a host manually on cloudstack 4.4  here is what 
I can see in management-server.log:

2015-11-03 20:10:25,836 WARN  [c.c.a.d.ParamGenericValidationWorker] 
(catalina-exec-18:ctx-e0055fb6 ctx-16be7693) Received unknown parameters for 
command addHost. Unknown parameters : clustertype
Checking KVM...[Failed]
2015-11-03 20:12:11,903 WARN  [o.a.c.alerts] (HA-2:ctx-72908537)  alertType:: 
13 // dataCenterId:: 0 // podId:: 0 // clusterId:: null // message:: No usage 
server process running
2015-11-03 20:15:28,447 DEBUG [c.c.h.k.d.LibvirtServerDiscoverer] 
(catalina-exec-18:ctx-e0055fb6 ctx-16be7693) Timeout, to wait for the host 
connecting to mgt svr, assuming it is failed
2015-11-03 20:15:28,449 WARN  [c.c.r.ResourceManagerImpl] 
(catalina-exec-18:ctx-e0055fb6 ctx-16be7693) Unable to find the server 
resources at http://192.168.2.29
2015-11-03 20:15:28,449 INFO  [c.c.u.e.CSExceptionErrorCode] 
(catalina-exec-18:ctx-e0055fb6 ctx-16be7693) Could not find exception: 
com.cloud.exception.DiscoveryException in error code list for exceptions
2015-11-03 20:15:28,450 WARN  [o.a.c.a.c.a.h.AddHostCmd] 
(catalina-exec-18:ctx-e0055fb6 ctx-16be7693) Exception:
com.cloud.exception.DiscoveryException: Unable to add the host
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
2015-11-03 20:15:28,452 INFO  [c.c.a.ApiServer] (catalina-exec-18:ctx-e0055fb6 
ctx-16be7693) Unable to add the host


> failing to add  kvm host to MS
> --
>
> Key: CLOUDSTACK-7097
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7097
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Management Server
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.log.tar.gz
>
>
> Repro steps:
> Create a agent on rhel 6.3
> create a MS on rhel 6.3
> Try creating a zone
> Bug : zone creation fails at adding host step
> MS log shows :
> 014-07-11 03:33:46,284 WARN  [c.c.a.d.ParamGenericValidationWorker] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Received unknown parameters for 
> command addHost. Unknown parameters : clustertype
> 2014-07-11 03:33:46,294 INFO  [c.c.r.ResourceManagerImpl] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Trying to add a new host at 
> http://10.147.40.24 in data center 1
> 2014-07-11 03:33:46,487 DEBUG [c.c.u.s.SSHCmdHelper] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
> 2014-07-11 03:33:47,505 DEBUG [c.c.u.s.SSHCmdHelper] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
> 2014-07-11 03:33:48,556 DEBUG [c.c.u.s.SSHCmdHelper] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm
> 2014-07-11 03:33:49,607 DEBUG [c.c.h.k.d.LibvirtServerDiscoverer] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) It's not a KVM enabled machine
> 2014-07-11 03:33:49,608 WARN  [c.c.r.ResourceManagerImpl] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Unable to find the server 
> resources at http://10.147.40.24
> 2014-07-11 03:33:49,611 INFO  [c.c.u.e.CSExceptionErrorCode] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Could not find exception: 
> com.cloud.exception.DiscoveryException in error code list for exceptions
> 2014-07-11 03:33:49,611 WARN  [o.a.c.a.c.a.h.AddHostCmd] 
> (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Exception:
> com.cloud.exception.DiscoveryException: Unable to add the host
> at 
> com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:791)
> at 
> com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
>

[jira] [Commented] (CLOUDSTACK-8480) Unable to create instances

[dsclose (JIRA)]

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

dsclose commented on CLOUDSTACK-8480:
-

This appears to be related to 
http://mail-archives.apache.org/mod_mbox/cloudstack-issues/201404.mbox/%3CJIRA.12702823.1395389698479.84432.1397027055318@arcas%3E

The virtual routers have been marked as needing an upgrade (probably as part of 
the Cloudstack updgrade process).

Probably two solutions:

1. Restart (with a clean-up) the network you're trying to attach a VM to.
2. Disable the version check by setting the router.version.check global setting 
to false.

> Unable to create instances
> --
>
> Key: CLOUDSTACK-8480
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8480
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nagaraju
>
> Getting the below error while creating the instances,
> Job failed due to exception Resource [Host:1] is unreachable: Host 1: Unable 
> to start instance due to Unable to send command. Upgrade in progress. Please 
> contact administrator
> ==
> 2015-05-19 15:00:02,850 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-16:ctx-dcffc068 job-125) Unexpected exception while 
> executing org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin
> java.lang.RuntimeException: Job failed due to exception Resource [Host:1] is 
> unreachable: Host 1: Unable to start instance due to Unable to send command. 
> Upgrade in progress. Please contact administrator.
> at 
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:114)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:502)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:459)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> 2015-05-19 15:00:02,851 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-16:ctx-dcffc068 job-125) Complete async job-125, jobStatus: 
> FAILED, resultCode: 530, result: 
> org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"Job
>  failed due to exception Resource [Host:1] is unreachable: Host 1: Unable to 
> start instance due to Unable to send command. Upgrade in progress. Please 
> contact administrator."}
> 2015-05-19 15:00:02,855 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-16:ctx-dcffc068 job-125) Done executing 
> org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin for job-125
> 2015-05-19 15:00:02,857 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (API-Job-Executor-16:ctx-dcffc068 job-125) Remove job-125 from job monitoring
> 2015-05-19 15:00:03,251 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-5:ctx-a4b13d5e) ===START===  172.21.8.77 -- GET  
> command=queryAsyncJobResult&jobId=c03c551f-c842-4060-ae97-e0a8da17d2f4&response=json&sessionkey=%2BWBJtQkjw7Ik31mK6ZaCSGjNkhQ%3D&_=1432027785178
> 2015-05-19 15:00:03,266 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-5:ctx-a4b13d5e ctx-8add23f3) ===END===  172.21.8.77 -- GET  
> command=queryAsyncJobResult&jobId=c03c551f-c842-4060-ae97-e0a8da17d2f4&response=json&sessionkey=%2BWBJtQkjw7Ik31mK6ZaCSGjNkhQ%3D&_=1432027785178
> 2015-05-19 15:00:03,280 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-11:ctx-436e689a) ===START===  172.21.8.77 -- GET  
> command=listVirtualMachines&id=3ee9904f-ba12-45e9-afe0-d5022534d849&response=json&sessionkey=%2BWBJtQkjw7Ik31mK6ZaCSGjNkhQ%3D&_=1432027785200
> 2015-05-19 15:00:03,302 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-11:ctx-436e689a ctx-3dbb961a) ===END===  172.21.8.77 -- GET  
> command=listVirtualMachines&id=3ee9904f-ba12-45e9-afe0-d5022534d849&response=json&sessionkey=%2BWBJtQkjw7Ik31mK6ZaCSGj

[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8925:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1023#issuecomment-153525534
  
Updated test results:

```
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
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 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 public IP ... === 
TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status : 
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... === 
TestName: test_network_rules_acquired_public_ip_2_nat_rule | Status : SUCCESS 
===
ok
Test for Router rules for network rules on acquired public IP ... === 
TestName: test_network_rules_acquired_public_ip

[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8832:


Github user KrisSterckx commented on the pull request:

https://github.com/apache/cloudstack/pull/801#issuecomment-153518941
  
Thanks @mlsorensen .

We wanted to bring this plugin update in 4.6 still for the exact reason to 
update the community with enriched functionality with our latest released Nuage 
SDN platform. We kept changes to the core to the minimum for the sake of 
maximizing the acceptance (knowing we were pretty late in the cycle) and at the 
same time maximizing the benefits to the community, with added unit- & marvin 
test coverage. 

Myself and the entire engineering who worked at this upstream contribution 
(dev & QA team) are still hoping for Apache CloudStack to welcome the support 
for the latest released Nuage VSP SDN platform and benefit the features & bug 
fixes it brings.



> Update Nuage VSP plugin to work with Nuage VSP release 3.2
> --
>
> Key: CLOUDSTACK-8832
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.0
>Reporter: Nick Livens
>Assignee: Nick Livens
> Attachments: nuageVspMarvinLogs.tar.gz
>
>
> Nuage VSP 3.2 is being released, we want to bring the plugin up to date for 
> this release



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

[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8832:


Github user mike-tutkowski commented on the pull request:

https://github.com/apache/cloudstack/pull/801#issuecomment-153517886
  
I liked Edison's approach to reviewing storage plug-in code: Since our 
storage plug-ins don't really run in "sandboxes," his approach was to mainly 
examine the code to try to make sure it wasn't inadvertently doing something 
bad to the data in the DB. For example, storage plug-ins have direct access to 
the DB via DAO objects and can accidentally delete data that doesn't belong to 
them.

Aside from those kinds of actions, Edison didn't encourage spending too 
much time trying to verify the correctness of storage plug-in code (that was an 
exercise left to the vendor).

Personally, though, I'd like to get to the point where I can bring my 
Marvin integration tests to the CloudStack repo and have them execute against 
virtual hardware. At the time being, however, this is not an option.

I also like having the ability to run these integration tests against 
different hypervisor types and versions, but am not yet confident I know how to 
do this within CloudStack's integration-test environment (so I just do this in 
house at SolidFire).


> Update Nuage VSP plugin to work with Nuage VSP release 3.2
> --
>
> Key: CLOUDSTACK-8832
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.0
>Reporter: Nick Livens
>Assignee: Nick Livens
> Attachments: nuageVspMarvinLogs.tar.gz
>
>
> Nuage VSP 3.2 is being released, we want to bring the plugin up to date for 
> this release



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

[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8832:


Github user mlsorensen commented on the pull request:

https://github.com/apache/cloudstack/pull/801#issuecomment-153499188
  
I largely agree, it provides the best experience for our end users if
we can always verify that plugins are functional and maintainable. On the
flip side, it seems that's part of the point of plugins. It isolates vendor
or implementation-specific code, making it easier to pick up by someone
else who may have domain knowledge but not CloudStack knowledge, or to easy
to remove if it becomes dead code.

In the case of vendors, if they stop their involvement, the most likely
end result is that the code won't be maintained, and if we haven't been
given means to test then we won't know on our own if it is functional. If
the vendor has ended involvement though, even if they've provided means to
test the code then those means may become defunct as well (e.g. software,
system, or license is deprecated), so providing means to the community for
testing doesn't seem to help much if we don't have continued vendor
support. In the past we have simply held a community vote to determine who
cares about the plugin, followed by removal, or if there's someone who
cares about the code and is in a position to maintain and provide testing
for it, they become the community maintainer for that code.

 One note of caution, the nature of the plugin architecture also
provides room for vendors to work on their own and provide their code
and/or artifacts to their customers. Short of the tiny core changes in this
request, they don't need to provide this code to the community. I'd prefer
to err on the side of being inviting to vendor contributions and bring the
developers into the community, rather than holding them at arm's length and
asking for a clean handoff or insurance policy in case they disappear.
We've seen community members jump jobs and still stick around because they
found an inviting environment where their contributions were welcomed and
valued, and they grew within the community, and I almost consider that
culture more important than ensuring any maintainer's duties can be
replaced by someone else in the community.

Then again, I'm only tangentially involved in the community right now,
so I won't feel bad if anyone takes my opinion with a grain of salt.

 TL; DR - While I'd really, really like to see vendors provide support
to make their plugins testable by the community, I don't think that it buys
us much in regards to maintaining the plugin if the vendor stops their
community involvement, short of having donated hardware with perpetual
license and free updates. As such, I'd rather lower the bar for developers
to maintain their plugin code, with the fallback of being able to easily
remove abandoned plugin code as a last resort.

On Tue, Nov 3, 2015 at 12:11 PM, John Burwell 
wrote:

> @ustcweizhou  @remibergsma
>  this is a massive technical debt that we
> are carrying with other plugins, and I think we need to stop to expanding
> that debt. In some cases, we (i.e. ASF) have been granted licenses for
> virtual appliances to test plugin operation (a completely valid way to
> verify operation). For others, we are shipping code that has not been
> verified for a number of releases. In the past, plugins have been
> contributed and tested for a release, but those contributors have not
> remained active to maintain the plugin. Since the community lacks the
> equipment or test rigs, no one else can pick up maintenance -- leaving us
> with bit rotting code. In summary, as a community, we should not be
> accepting the responsibility to support and maintain code whose operation
> we cannot verify -- plugin or core. The question of what to do with
> existing plugi ns that don't meet this criteria is a discussion for 
another
> thread.
>
> —
> Reply to this email directly or view it on GitHub
> .
>



> Update Nuage VSP plugin to work with Nuage VSP release 3.2
> --
>
> Key: CLOUDSTACK-8832
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>

[jira] [Commented] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF subversion and git services (JIRA)]

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

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

Commit 0ba871b127f83b7ba6dca1d55ada16bf5b971959 in cloudstack's branch 
refs/heads/master from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0ba871b ]

Merge pull request #1024 from shapeblue/CLOUDSTACK-9019-master

[4.6/master] CLOUDSTACK-9019: Add storage network offering in ssvm only if 
storage network is defined

During creation of SSVM, checks and adds NetworkOffering.SystemStorageNetwork to
offerings only if storage network exists for the target datacenter.

(Manually tested)

* pr/1024:
  CLOUDSTACK-9019: Add storage network offering in ssvm only if storage network 
is defined

Signed-off-by: Remi Bergsma 


> Storage VM gets two mgmt nics when no storage net defined
> -
>
> Key: CLOUDSTACK-9019
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9019
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.5.3, 4.6.0
>
>
> If a dedicated storage network is not provided in a zone, secondary storage 
> VMs get two management nics. This eats up an additional IP, the fix would be 
> to allocate a storage nic only when storage network is defined.



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

[jira] [Commented] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9019:


Github user asfgit closed the pull request at:

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


> Storage VM gets two mgmt nics when no storage net defined
> -
>
> Key: CLOUDSTACK-9019
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9019
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.5.3, 4.6.0
>
>
> If a dedicated storage network is not provided in a zone, secondary storage 
> VMs get two management nics. This eats up an additional IP, the fix would be 
> to allocate a storage nic only when storage network is defined.



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

[jira] [Commented] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF subversion and git services (JIRA)]

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

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

Commit 8922707076632d478d7ed088a08bf24261e07c82 in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8922707 ]

CLOUDSTACK-9019: Add storage network offering in ssvm only if storage network 
is defined

During creation of SSVM, checks and adds NetworkOffering.SystemStorageNetwork to
offerings only if storage network exists for the target datacenter

Signed-off-by: Rohit Yadav 


> Storage VM gets two mgmt nics when no storage net defined
> -
>
> Key: CLOUDSTACK-9019
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9019
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.5.3, 4.6.0
>
>
> If a dedicated storage network is not provided in a zone, secondary storage 
> VMs get two management nics. This eats up an additional IP, the fix would be 
> to allocate a storage nic only when storage network is defined.



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

[jira] [Commented] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF subversion and git services (JIRA)]

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

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

Commit 0ba871b127f83b7ba6dca1d55ada16bf5b971959 in cloudstack's branch 
refs/heads/master from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0ba871b ]

Merge pull request #1024 from shapeblue/CLOUDSTACK-9019-master

[4.6/master] CLOUDSTACK-9019: Add storage network offering in ssvm only if 
storage network is defined

During creation of SSVM, checks and adds NetworkOffering.SystemStorageNetwork to
offerings only if storage network exists for the target datacenter.

(Manually tested)

* pr/1024:
  CLOUDSTACK-9019: Add storage network offering in ssvm only if storage network 
is defined

Signed-off-by: Remi Bergsma 


> Storage VM gets two mgmt nics when no storage net defined
> -
>
> Key: CLOUDSTACK-9019
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9019
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.5.3, 4.6.0
>
>
> If a dedicated storage network is not provided in a zone, secondary storage 
> VMs get two management nics. This eats up an additional IP, the fix would be 
> to allocate a storage nic only when storage network is defined.



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

[jira] [Commented] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF subversion and git services (JIRA)]

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

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

Commit 0ba871b127f83b7ba6dca1d55ada16bf5b971959 in cloudstack's branch 
refs/heads/master from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0ba871b ]

Merge pull request #1024 from shapeblue/CLOUDSTACK-9019-master

[4.6/master] CLOUDSTACK-9019: Add storage network offering in ssvm only if 
storage network is defined

During creation of SSVM, checks and adds NetworkOffering.SystemStorageNetwork to
offerings only if storage network exists for the target datacenter.

(Manually tested)

* pr/1024:
  CLOUDSTACK-9019: Add storage network offering in ssvm only if storage network 
is defined

Signed-off-by: Remi Bergsma 


> Storage VM gets two mgmt nics when no storage net defined
> -
>
> Key: CLOUDSTACK-9019
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9019
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.5.3, 4.6.0
>
>
> If a dedicated storage network is not provided in a zone, secondary storage 
> VMs get two management nics. This eats up an additional IP, the fix would be 
> to allocate a storage nic only when storage network is defined.



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

[jira] [Commented] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9019:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1024#issuecomment-153477674
  
LGTM, based on a set of tests that I run on this branch (which I rebased 
myself first):

```
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
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
Stop existing router, add a PF rule and check we can access the VM ... === 
TestName: test_isolate_network_FW_PF_default_routes | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_RVR_Network_FW_PF_SSH_default_routes | 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 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 public IP ... === 
TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status : 
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... === 
TestName: test_network_rules_acquired_public_ip_2_nat_rule | Status : SUCCESS 
===
ok
Test for Router rules for network rules on acquired public IP ... === 
TestName: test_network_rules_acquired_public_ip_3_Load_Balancer_Rule | Status : 
SUCCESS ===
ok

--
Ran 29 tests in 12562.634s

OK
```


And:

``

[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8832:


Github user jburwell commented on the pull request:

https://github.com/apache/cloudstack/pull/801#issuecomment-153473377
  
@ustcweizhou @remibergsma this is a massive technical debt that we are 
carrying with other plugins, and I think we need to stop to expanding that 
debt.  In some cases, we (i.e. ASF) have been granted licenses for virtual 
appliances to test plugin operation (a completely valid way to verify 
operation).  For others, we are shipping code that has not been verified for a 
number of releases.  In the past, plugins have been contributed and tested for 
a release, but those contributors have not remained active to maintain the 
plugin.  Since the community lacks the equipment or test rigs, no one else can 
pick up maintenance -- leaving us with bit rotting code.  In summary, as a 
community, we should not be accepting the responsibility to support and 
maintain code whose operation we cannot verify -- plugin or core.  The question 
of what to do with existing plugins that don't meet this criteria is a 
discussion for another thread.


> Update Nuage VSP plugin to work with Nuage VSP release 3.2
> --
>
> Key: CLOUDSTACK-8832
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.0
>Reporter: Nick Livens
>Assignee: Nick Livens
> Attachments: nuageVspMarvinLogs.tar.gz
>
>
> Nuage VSP 3.2 is being released, we want to bring the plugin up to date for 
> this release



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

[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9022:


Github user NuxRo commented on the pull request:

https://github.com/apache/cloudstack/pull/1029#issuecomment-153467987
  
Excellent! I thought this feature was already implemented via 
expunge.delay, good to know it doesn't work as I thought it was.


> We should keep Destroyed volumes for some time
> --
>
> Key: CLOUDSTACK-9022
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> for now, the Destroyed volumes will be expunged in Storage cleanup thread, no 
> matter when they are destroyed.
> In Expunging vm, we only clean the Destroyed vms which have been destroyed at 
> least 'expunge.delay' seconds.
> We need to add the similar configuration for volumes.



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

[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8832:


Github user ustcweizhou commented on the pull request:

https://github.com/apache/cloudstack/pull/801#issuecomment-153468143
  
I agree with @remibergsma .
If the plugin is provided by the vendor, I would say they are responsible 
for the code maintenance and update.What we need to check are the changes in 
other projects (api,engine/schema,server,etc).
This PR LGTM +1.


> Update Nuage VSP plugin to work with Nuage VSP release 3.2
> --
>
> Key: CLOUDSTACK-8832
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.0
>Reporter: Nick Livens
>Assignee: Nick Livens
> Attachments: nuageVspMarvinLogs.tar.gz
>
>
> Nuage VSP 3.2 is being released, we want to bring the plugin up to date for 
> this release



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

[jira] [Created] (CLOUDSTACK-9024) Restart network fails if redundant router is missing

[dsclose (JIRA)]

dsclose created CLOUDSTACK-9024:
---

 Summary: Restart network fails if redundant router is missing
 Key: CLOUDSTACK-9024
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9024
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API, Network Controller, Virtual Router
Affects Versions: 4.5.2
 Environment: Cloudstack installed on CentOS 6.5
Reporter: dsclose


Restart network action fails if a network is missing a redundant virtual 
router. This occurs if triggered via the UI (Networks -> Select Network -> 
Restart -> Clean-ip: False -> OK) or via the API.

Steps to reproduce:

1. Create a redundant router network offering.
2. Create a network using the redundant router network offering.
3. Destroy a redundant router from the network. Leave one functioning.
4. Initiate the restart network action or restartNetwork API call with clean-up 
set to False.

Expected Behaviour:
--
Cloudstack should boot a new redundant virtual router to replace the missing 
router. The Network Restart action should return successfully.

Actual Behaviour:
---
Cloudstack boots a replacement redundant router but the API call returns 
unsucessful. The Web UI reports that the router fails.

Timeline:
---
2015-11-03 17:12:08,256 Destroying router "r-985-VM".
2015-11-03 17:12:24,511 Performing network restart.
2015-11-03 17:14:02,851 Failed to restart network

Management Log Sample
-
2015-11-03 17:12:14,943 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(Work-Job-Executor-12:ctx-a671c200 job-163/job-164) Remove job-164 from job 
monitoring
2015-11-03 17:12:15,739 INFO  [o.a.c.s.v.VolumeServiceImpl] 
(API-Job-Executor-12:ctx-33b24483 job-163 ctx-4d95a357) Volume 985 is not 
referred anywhere, remove it from volumes table
2015-11-03 17:12:15,850 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-12:ctx-33b24483 job-163) Remove job-163 from job monitoring
2015-11-03 17:12:18,698 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-13:ctx-c29ad7f0 job-165) Add job-165 into job monitoring
2015-11-03 17:12:18,985 INFO  [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(API-Job-Executor-13:ctx-c29ad7f0 job-165 ctx-7945f6f9) Use same MAC as 
previous RvR, the MAC is 06:9c:86:00:00:0e
2015-11-03 17:12:19,829 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(Work-Job-Executor-13:ctx-06672650 job-165/job-166) Add job-166 into job 
monitoring
2015-11-03 17:12:20,078 INFO  [c.c.s.StorageManagerImpl] 
(Work-Job-Executor-13:ctx-06672650 job-165/job-166 ctx-81c163bb) Storage pool 
null (1) does not supply IOPS capacity, assuming enough capacity
2015-11-03 17:12:40,248 INFO  [c.c.v.VirtualMachineManagerImpl] 
(DirectAgentCronJob-492:ctx-1fb6ecea) There is pending job or HA tasks working 
on the VM. vm id: 992, postpone power-change report by resetting power-change 
counters
2015-11-03 17:13:40,384 INFO  [c.c.v.VirtualMachineManagerImpl] 
(DirectAgentCronJob-280:ctx-846ef4f0) There is pending job or HA tasks working 
on the VM. vm id: 992, postpone power-change report by resetting power-change 
counters
2015-11-03 17:13:49,799 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
(AsyncJobMgr-Heartbeat-1:ctx-10ff7f5f) Begin cleanup expired async-jobs
2015-11-03 17:13:49,825 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
(AsyncJobMgr-Heartbeat-1:ctx-10ff7f5f) End cleanup expired async-jobs
2015-11-03 17:13:55,688 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(Work-Job-Executor-13:ctx-06672650 job-165/job-166) Remove job-166 from job 
monitoring
2015-11-03 17:13:55,730 WARN  [o.a.c.e.o.NetworkOrchestrator] 
(API-Job-Executor-13:ctx-c29ad7f0 job-165 ctx-7945f6f9) Failed to implement 
network Ntwk[208|Guest|15] elements and resources as a part of network restart 
due to
com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is 
unreachable: Can't find all necessary running routers!
at 
com.cloud.network.element.VirtualRouterElement.implement(VirtualRouterElement.java:202)
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1103)
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.restartNetwork(NetworkOrchestrator.java:2546)
at 
com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1891)
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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springfra

[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8832:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/801#issuecomment-153424524
  
@jburwell How do we do this with other such plugins? Nicira, SolidFire & 
friends. Since we do not have the hardware, there is no way to verify its 
functionality other than doing a code review and trusting the Marvin test that 
shows SUCCESS. I think @KrisSterckx will be the one that needs to address bugs, 
should they pop-up (like for example @mike-tutkowski does for SolidFire). I see 
no difference with the other plugins and am OK with merging (if LGTM on code 
review), once 4.6 is out and we merge PRs to build 4.7.

I will post test results once they're done.


> Update Nuage VSP plugin to work with Nuage VSP release 3.2
> --
>
> Key: CLOUDSTACK-8832
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.0
>Reporter: Nick Livens
>Assignee: Nick Livens
> Attachments: nuageVspMarvinLogs.tar.gz
>
>
> Nuage VSP 3.2 is being released, we want to bring the plugin up to date for 
> this release



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

[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8832:


Github user jburwell commented on the pull request:

https://github.com/apache/cloudstack/pull/801#issuecomment-153418530
  
@KrisSterckx it not a matter of trust.  By contributing this code to our 
community, we are responsible for its long-term support and maintenance.  
Therefore, we must be able to independently verify the plugin's operation.  
Before I am comfortable approving this PR, we must be able to verify the proper 
operation of this plugin.  


> Update Nuage VSP plugin to work with Nuage VSP release 3.2
> --
>
> Key: CLOUDSTACK-8832
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.0
>Reporter: Nick Livens
>Assignee: Nick Livens
> Attachments: nuageVspMarvinLogs.tar.gz
>
>
> Nuage VSP 3.2 is being released, we want to bring the plugin up to date for 
> this release



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

[jira] [Updated] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time

[Wei Zhou (JIRA)]

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

Wei Zhou updated CLOUDSTACK-9022:
-
Status: Reviewable  (was: In Progress)

> We should keep Destroyed volumes for some time
> --
>
> Key: CLOUDSTACK-9022
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> for now, the Destroyed volumes will be expunged in Storage cleanup thread, no 
> matter when they are destroyed.
> In Expunging vm, we only clean the Destroyed vms which have been destroyed at 
> least 'expunge.delay' seconds.
> We need to add the similar configuration for volumes.



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

[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9022:


GitHub user ustcweizhou opened a pull request:

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

CLOUDSTACK-9022: keep Destroyed volumes for sometime

for now, the Destroyed volumes will be expunged in Storage cleanup thread, 
no matter when they are destroyed.
In Expunging vm thread, we expunge the Destroyed vms which have been 
destroyed at least 'expunge.delay' seconds. We add the similar configuration 
for volumes.

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

$ git pull https://github.com/ustcweizhou/cloudstack storage-cleanup-delay

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

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

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

This closes #1029


commit e411f00fdb49615e45f3e0f3fe709d97734d3db2
Author: Wei Zhou 
Date:   2015-11-03T16:04:55Z

CLOUDSTACK-9022: keep Destroyed volumes for sometime




> We should keep Destroyed volumes for some time
> --
>
> Key: CLOUDSTACK-9022
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> for now, the Destroyed volumes will be expunged in Storage cleanup thread, no 
> matter when they are destroyed.
> In Expunging vm, we only clean the Destroyed vms which have been destroyed at 
> least 'expunge.delay' seconds.
> We need to add the similar configuration for volumes.



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

[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8715:


Github user ustcweizhou commented on the pull request:

https://github.com/apache/cloudstack/pull/1027#issuecomment-153404172
  
The virtio console is a bridge between hypervisor and vm instance. I am not 
sure if customers feel good/friendly with this.

I donot know if libvirt-java 0.5.1 supports qemu guest agent. If yes, we 
can send commands/data directly from java. It is another way for implementation.
python script and java have their own benifits.


> Add support for qemu-guest-agent to libvirt provider
> 
>
> Key: CLOUDSTACK-8715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Reporter: Sten Spans
>Assignee: Wido den Hollander
>  Labels: kvm, libvirt, qemu, systemvm
> Fix For: Future
>
>
> The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite 
> a lot of useful functionality, which can only be provided by having an agent 
> on the VM. This includes things like freezing/thawing filesystems (for 
> backups), reading files on the guest, listing interfaces / ip addresses, etc.
> This feature has been requested by users, but is currently not implemented.
> http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent
> The first change needed is to add the following to the XML generated for KVM 
> virtual machines,:
> 
>   
>   
> 
> This provides the communication channel between libvirt and the agent on the 
> host. All in all a pretty simple change to LibvirtComputingResource.java / 
> LibvirtVMDef.java
> Secondly the qemu-guest-agent package needs to be added to the systemvm 
> template.



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

[jira] [Created] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time

[Wei Zhou (JIRA)]

Wei Zhou created CLOUDSTACK-9022:


 Summary: We should keep Destroyed volumes for some time
 Key: CLOUDSTACK-9022
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Wei Zhou
Assignee: Wei Zhou


for now, the Destroyed volumes will be expunged in Storage cleanup thread, no 
matter when they are destroyed.

In Expunging vm, we only clean the Destroyed vms which have been destroyed at 
least 'expunge.delay' seconds.

We need to add the similar configuration for volumes.





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

[jira] [Comment Edited] (CLOUDSTACK-9020) Metrics Views for CloudStack UI

[haijiao (JIRA)]

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

haijiao edited comment on CLOUDSTACK-9020 at 11/3/15 3:42 PM:
--

it sounds like a 'new feature' or 'improvement' instead of 'bug' :-)


was (Author: haijiao):
it sounds like a 'improvement' instead of 'bug' :-)

> Metrics Views for CloudStack UI
> ---
>
> Key: CLOUDSTACK-9020
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9020
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.6.0
>
>
> In order to identify issues within CloudStack, a CloudStack admin would go 
> through various resources such as zones/clusters/hosts/storage pool or with 
> VMs or volumes, using a CLI or some other tool/script to find 
> CPU/Memory/Disk/Network usage of that resource to figure out if that resource 
> is exhausted, or having issues for example host is down, storage pool is full 
> etc. The metrics view aims to solve that problem by showing metrics 
> information for these resources in a table which would allow hierarchical 
> navigation to triage issue (for example, Zone -> Cluster -> Host -> Instances 
> -> Volumes -> Storage Pool -> Volumes), allow common operation (like those of 
> quick view), show cells that need attention (such as coloring a tabular cell 
> where threshold/disable limits have been crossed), allow data to be sorted 
> and refreshed.
> FS: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Metrics+Views+for+CloudStack+UI



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

[jira] [Commented] (CLOUDSTACK-9020) Metrics Views for CloudStack UI

[haijiao (JIRA)]

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

haijiao commented on CLOUDSTACK-9020:
-

it sounds like a 'improvement' instead of 'bug' :-)

> Metrics Views for CloudStack UI
> ---
>
> Key: CLOUDSTACK-9020
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9020
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.6.0
>
>
> In order to identify issues within CloudStack, a CloudStack admin would go 
> through various resources such as zones/clusters/hosts/storage pool or with 
> VMs or volumes, using a CLI or some other tool/script to find 
> CPU/Memory/Disk/Network usage of that resource to figure out if that resource 
> is exhausted, or having issues for example host is down, storage pool is full 
> etc. The metrics view aims to solve that problem by showing metrics 
> information for these resources in a table which would allow hierarchical 
> navigation to triage issue (for example, Zone -> Cluster -> Host -> Instances 
> -> Volumes -> Storage Pool -> Volumes), allow common operation (like those of 
> quick view), show cells that need attention (such as coloring a tabular cell 
> where threshold/disable limits have been crossed), allow data to be sorted 
> and refreshed.
> FS: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Metrics+Views+for+CloudStack+UI



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

[jira] [Resolved] (CLOUDSTACK-9021) test_ssvm is failing due to wrong interface check on VMware and HyperV

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-9021.
--
Resolution: Fixed

merged

> test_ssvm is failing due to wrong interface check on VMware and HyperV
> --
>
> Key: CLOUDSTACK-9021
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9021
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> In case of VMWare and Hyper-v , linc local is on eth1. So the command in
> all the failed tests to verify link local IP should be modified.
> "cat /var/cache/cloud/cmdline | xargs | sed \"s/ /\\n/g\" | grep eth0ip= |
> sed \"s/\=/ /g\" | awk '{print $2}'",.
> It is using eth0ip. However, it should be eth1ip.



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

[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8925:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1023#issuecomment-153376651
  
The last test failed because the connection timed out without printing 
"Giving up.", as I expected in the test. You can see the output below:

```
{Cmd: wget -t 1 -T 1 www.google.com via Host: 192.168.23.6} {returns: 
[u'--2015-11-03 14:44:03--  http://www.google.com/', u'Resolving 
www.google.com... failed: Connection timed out.', u"wget: unable to resolve 
host address 'www.google.com'"]}
{Cmd: wget -t 1 -T 1 www.google.com via Host: 192.168.23.6} {returns: 
[u'--2015-11-03 14:44:03--  http://www.google.com/', u'Resolving 
www.google.com... failed: Connection timed out.', u"wget: unable to resolve 
host address 'www.google.com'"]}
{Cmd: wget -t 1 -T 1 www.google.com via Host: 192.168.23.6} {returns: 
[u'--2015-11-03 14:44:03--  http://www.google.com/', u'Resolving 
www.google.com... failed: Connection timed out.', u"wget: unable to resolve 
host address 'www.google.com'"]}
{Cmd: wget -t 1 -T 1 www.google.com via Host: 192.168.23.6} {returns: 
[u'--2015-11-03 14:44:03--  http://www.google.com/', u'Resolving 
www.google.com... failed: Connection timed out.', u"wget: unable to resolve 
host address 'www.google.com'"]}
```

I will push another time and will rely on a better test string. But no 
worries, the fix is fine!

* Test results:

```
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 : FAILED ===
FAIL

==
FAIL: Test redundant router internals
--
Traceback (most recent call last):
  File 
"/data/git/cs1/cloudstack/test/integration/component/test_routers_network_ops.py",
 line 473, in test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false
"Attempt to retrieve google.com index page should NOT be successful"
AssertionError: Attempt to retrieve google.com index page should NOT be 
successful
```


> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Ch

[jira] [Commented] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9019:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1024#issuecomment-153374008
  
code looks good to me too. what happened to the policy of not accepting 
anything without test?


> Storage VM gets two mgmt nics when no storage net defined
> -
>
> Key: CLOUDSTACK-9019
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9019
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.5.3, 4.6.0
>
>
> If a dedicated storage network is not provided in a zone, secondary storage 
> VMs get two management nics. This eats up an additional IP, the fix would be 
> to allocate a storage nic only when storage network is defined.



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

[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8832:


Github user KrisSterckx commented on the pull request:

https://github.com/apache/cloudstack/pull/801#issuecomment-153373302
  
@jburwell we have added unit testing and Marvin tests, and we posted the 
results of Marvin in the Jira ticket, but in order to run the Marvin tests you 
need a Nuage VSP solution. I believe that was made clear and it is also 
@remibergsma 's understanding as we talked in Dublin.
Having that said I do understand your request, and we can work at 
facilitating more community testing in next releases. Also we can certainly 
have the conversation on how we can help you on the short hand, or we could 
organize a live demo of the functionality or whatever helps in building trust. 
Thanks.



> Update Nuage VSP plugin to work with Nuage VSP release 3.2
> --
>
> Key: CLOUDSTACK-8832
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.0
>Reporter: Nick Livens
>Assignee: Nick Livens
> Attachments: nuageVspMarvinLogs.tar.gz
>
>
> Nuage VSP 3.2 is being released, we want to bring the plugin up to date for 
> this release



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

[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8925:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1023#issuecomment-153373615
  
LGTM, based on a set of tests that I run on this branch (which I rebased 
myself first):

```
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
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 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 public IP ... === 
TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status : 
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... === 
TestName: test_network_rules_acquired_public_ip_2_nat_rule | Status : SUCCESS 
===
ok
Test for Router rules for network rules on acquired

[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8925:


Github user karuturi commented on the pull request:

https://github.com/apache/cloudstack/pull/1023#issuecomment-153372412
  
Thanks @wilderrodrigues I will test this tomorrow morning IST


> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Chain FW_OUTBOUND (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 3   252 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED



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

[jira] [Commented] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9019:


Github user karuturi commented on the pull request:

https://github.com/apache/cloudstack/pull/1024#issuecomment-153371665
  
 :+1: (code review only) good improvement.
A test case would have been nice.


> Storage VM gets two mgmt nics when no storage net defined
> -
>
> Key: CLOUDSTACK-9019
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9019
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.5.3, 4.6.0
>
>
> If a dedicated storage network is not provided in a zone, secondary storage 
> VMs get two management nics. This eats up an additional IP, the fix would be 
> to allocate a storage nic only when storage network is defined.



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

[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8925:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1023#issuecomment-153371614
  
@wilderrodrigues my bubble is very busy but ping if you are ready and need 
testing


> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Chain FW_OUTBOUND (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 3   252 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/977#issuecomment-153371179
  
My bad, there is no libvirt-java upgrade possible at this point. I was 
mistaking libvirt 1.1.0 for a possibility.


> 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-8715) Add support for qemu-guest-agent to libvirt provider

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8715:


Github user wido commented on the pull request:

https://github.com/apache/cloudstack/pull/1027#issuecomment-153370288
  
Overall this seems OK, but I personally think that we can enable it by 
default on all KVM guests. It doesn't hurt to add the port.

We can detect if the port is open or not. Also, we don't need external 
Python code to send commands, we can do this directly from Java.


> Add support for qemu-guest-agent to libvirt provider
> 
>
> Key: CLOUDSTACK-8715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Reporter: Sten Spans
>Assignee: Wido den Hollander
>  Labels: kvm, libvirt, qemu, systemvm
> Fix For: Future
>
>
> The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite 
> a lot of useful functionality, which can only be provided by having an agent 
> on the VM. This includes things like freezing/thawing filesystems (for 
> backups), reading files on the guest, listing interfaces / ip addresses, etc.
> This feature has been requested by users, but is currently not implemented.
> http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent
> The first change needed is to add the following to the XML generated for KVM 
> virtual machines,:
> 
>   
>   
> 
> This provides the communication channel between libvirt and the agent on the 
> host. All in all a pretty simple change to LibvirtComputingResource.java / 
> LibvirtVMDef.java
> Secondly the qemu-guest-agent package needs to be added to the systemvm 
> template.



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

[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8925:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1023#issuecomment-153370030
  
Ping @remibergsma @karuturi @borisroman @DaanHoogland 

The test is ready! It now does the following:

1. Creates network + VM + FW + PF + Default Egress ALLOW
2. Tries to ping google and wget google.com
  - Should ALLOW traffic
3. Add Egress rule to block port 80
  - Should DENY traffic

1. Creates network + VM + FW + PF + Default Egress DENY
2. Tries to ping google and wget google.com
  - Should DENY traffic
3. Add Egress rule to allow port 80
  - Should ALLOW traffic

1. Creates redundant network + VM + FW + PF + Default Egress ALLOW
2. Tries to ping google and wget google.com
  - Should ALLOW traffic
3. Add Egress rule to block port 80
  - Should DENY traffic

1. Creates redundant network + VM + FW + PF + Default Egress DENY
2. Tries to ping google and wget google.com
  - Should DENY traffic
3. Add Egress rule to allow port 80
  - Should ALLOW traffic

Only waiting for the last step to complete then will paste the results here.

Cheers,
Wilder


> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Chain FW_OUTBOUND (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 3   252 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


Github user wido commented on the pull request:

https://github.com/apache/cloudstack/pull/977#issuecomment-153369869
  
@DaanHoogland I meant the version of libvirt running on the HV which is out 
of our control.

I still vote for no longer supporting Ubuntu 12.04 for that reason for 
example.


> 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-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8832:


Github user jburwell commented on the pull request:

https://github.com/apache/cloudstack/pull/801#issuecomment-153369716
  
@KrisSterckx this plugin is part of the code that is the responsibility of 
the community.  Therefore, we need to verify its operation in addition to the 
core changes.  My understanding is that a virtual device is available for 
testing the plugin.  Is that correct?


> Update Nuage VSP plugin to work with Nuage VSP release 3.2
> --
>
> Key: CLOUDSTACK-8832
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.0
>Reporter: Nick Livens
>Assignee: Nick Livens
> Attachments: nuageVspMarvinLogs.tar.gz
>
>
> Nuage VSP 3.2 is being released, we want to bring the plugin up to date for 
> this release



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

[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8832:


Github user KrisSterckx commented on the pull request:

https://github.com/apache/cloudstack/pull/801#issuecomment-153367941
  
@jburwell  @remibergsma  Pls note all again that the changes to core are 
very minimal and are limited to convenience extensions only. I would expect 
running the CI should be good in verifying that the plugin changes don't break 
anything in core.

Thanks


> Update Nuage VSP plugin to work with Nuage VSP release 3.2
> --
>
> Key: CLOUDSTACK-8832
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.0
>Reporter: Nick Livens
>Assignee: Nick Livens
> Attachments: nuageVspMarvinLogs.tar.gz
>
>
> Nuage VSP 3.2 is being released, we want to bring the plugin up to date for 
> this release



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

[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8925:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1023#issuecomment-153363457
  
Ping @remibergsma @karuturi @DaanHoogland @borisroman 

It's working already, but I'm modifying the tests. I pushed by mistake. If 
you want to start testing now - manually - be my guest.

Cheers,
Wilder


> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Chain FW_OUTBOUND (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 3   252 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED



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

[jira] [Commented] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere

[Daan Hoogland (JIRA)]

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

Daan Hoogland commented on CLOUDSTACK-4787:
---

[~sateeshc] Chris Sciarrino, did you verify the above? can we close?

> Allow selection of scsi controller type in vSphere
> --
>
> Key: CLOUDSTACK-4787
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, UI, VMware
>Affects Versions: 4.2.0, 4.3.0
> Environment: vSphere 5.1
>Reporter: Chris Sciarrino
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.6.0
>
>
> When adding an OVA template for a vSphere environment allow the selection of 
> the scsi controller type. 
> Currently the instances are deployed with the the LSI Parallel controller 
> type. This results in a blue screen on boot when attempting to deploy 
> templates that use the LSI SAS controller.



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

[jira] [Commented] (CLOUDSTACK-6930) Listing all the packages that are installed on the systemVM template

[Daan Hoogland (JIRA)]

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

Daan Hoogland commented on CLOUDSTACK-6930:
---

[~abhi_shapeblue][~bhaisaab]this is partly done I think but I am removing 4.6 
anyway (pinging [~remibergsma])

> Listing all the packages that are installed on the systemVM template
> 
>
> Key: CLOUDSTACK-6930
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6930
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.4.0
>Reporter: Abhinandan Prateek
>Assignee: Jayapal Reddy
>Priority: Critical
> Fix For: Future
>
>
> Make a list of packages that are there on system vm templates. If they are 
> unused they should be removed. This is a step to harden the system vm 
> template.



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

[jira] [Updated] (CLOUDSTACK-6930) Listing all the packages that are installed on the systemVM template

[Daan Hoogland (JIRA)]

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

Daan Hoogland updated CLOUDSTACK-6930:
--
Fix Version/s: (was: 4.6.0)

> Listing all the packages that are installed on the systemVM template
> 
>
> Key: CLOUDSTACK-6930
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6930
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.4.0
>Reporter: Abhinandan Prateek
>Assignee: Jayapal Reddy
>Priority: Critical
> Fix For: Future
>
>
> Make a list of packages that are there on system vm templates. If they are 
> unused they should be removed. This is a step to harden the system vm 
> template.



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

[jira] [Commented] (CLOUDSTACK-8592) Enhance usage server to provide quota service

[Daan Hoogland (JIRA)]

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

Daan Hoogland commented on CLOUDSTACK-8592:
---

[~abhi_shapeblue][~rohiitj] does it make sense to adjust fix-version to 4.7 for 
this one?

> Enhance usage server to provide quota service
> -
>
> Key: CLOUDSTACK-8592
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8592
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.6.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
>Priority: Critical
> Fix For: 4.6.0
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quota+Service+-+FS
> Quota service while allowing for scalability will make sure that the cloud is 
> not exploited by attacks, careless use and program errors. To address this 
> problem, we propose to employ a quota-enforcement service that allows 
> resource usage within certain bounds as defined by policies and available 
> quotas for various entities. 
> Quota service extends the functionality of usage server to provide a 
> measurement for the resources used by the accounts and domains using a common 
> unit referred to as cloud currency in this document. It can be configured to 
> ensure that your usage won’t exceed the budget allocated to accounts/domain 
> in cloud currency.
> It will let user know how much of the cloud resources he is using. It will 
> help the cloud admins, if they want, to ensure that a user does not go beyond 
> his allocated quota. Per usage cycle if a account is found to be exceeding 
> its quota then it is locked. Locking an account means that it will not be 
> able to initiat
> e a new resource allocation request, whether it is more storage or an 
> additional ip. Needless to say quota service as well as any action on the 
> account is configurable.



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

[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8832:


Github user jburwell commented on the pull request:

https://github.com/apache/cloudstack/pull/801#issuecomment-153351842
  
@remibergsma agree regarding the rebase effort.  However, I am not going to 
spend time testing now knowing that it will need to be retested when master is 
unfrozen.


> Update Nuage VSP plugin to work with Nuage VSP release 3.2
> --
>
> Key: CLOUDSTACK-8832
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.0
>Reporter: Nick Livens
>Assignee: Nick Livens
> Attachments: nuageVspMarvinLogs.tar.gz
>
>
> Nuage VSP 3.2 is being released, we want to bring the plugin up to date for 
> this release



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

[jira] [Commented] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9019:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/1024#issuecomment-153351476
  
Thanks @remibergsma 


> Storage VM gets two mgmt nics when no storage net defined
> -
>
> Key: CLOUDSTACK-9019
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9019
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.5.3, 4.6.0
>
>
> If a dedicated storage network is not provided in a zone, secondary storage 
> VMs get two management nics. This eats up an additional IP, the fix would be 
> to allocate a storage nic only when storage network is defined.



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

[jira] [Commented] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9019:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1024#issuecomment-153341635
  
Result before this PR:

```
root@s-58-VM:~# ifconfig 
eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:03:b0  
  inet addr:169.254.3.176  Bcast:169.254.255.255  Mask:255.255.0.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:1362 errors:0 dropped:0 overruns:0 frame:0
  TX packets:74 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:68093 (66.4 KiB)  TX bytes:11731 (11.4 KiB)

eth1  Link encap:Ethernet  HWaddr 06:8f:3c:00:00:0e  
  inet addr:192.168.22.143  Bcast:192.168.22.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:63121 errors:0 dropped:1 overruns:0 frame:0
  TX packets:31637 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:84701257 (80.7 MiB)  TX bytes:125724065 (119.8 MiB)

eth2  Link encap:Ethernet  HWaddr 06:3c:56:00:00:16  
  inet addr:192.168.23.2  Bcast:192.168.23.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:1009 errors:0 dropped:0 overruns:0 frame:0
  TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:47700 (46.5 KiB)  TX bytes:3072 (3.0 KiB)

eth3  Link encap:Ethernet  HWaddr 06:9b:9e:00:00:14  
  inet addr:192.168.22.149  Bcast:192.168.22.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:3599 errors:0 dropped:1 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:193180 (188.6 KiB)  TX bytes:0 (0.0 B)

loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
```

```
root@s-58-VM:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse 
Iface
0.0.0.0 192.168.22.10.0.0.0 UG0  00 eth1
8.8.4.4 192.168.22.1255.255.255.255 UGH   0  00 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0  00 eth0
192.168.22.00.0.0.0 255.255.255.0   U 0  00 eth1
192.168.22.00.0.0.0 255.255.255.0   U 0  00 eth3
192.168.23.00.0.0.0 255.255.255.0   U 0  00 eth2
```

After this PR:

```
root@s-1-VM:~# ifconfig 
eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:03:44  
  inet addr:169.254.3.68  Bcast:169.254.255.255  Mask:255.255.0.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:30 errors:0 dropped:0 overruns:0 frame:0
  TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:1748 (1.7 KiB)  TX bytes:687 (687.0 B)

eth1  Link encap:Ethernet  HWaddr 06:00:c6:00:00:01  
  inet addr:192.168.22.130  Bcast:192.168.22.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:39717 errors:0 dropped:0 overruns:0 frame:0
  TX packets:17889 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:43372312 (41.3 MiB)  TX bytes:63330617 (60.3 MiB)

eth2  Link encap:Ethernet  HWaddr 06:82:d6:00:00:16  
  inet addr:192.168.23.2  Bcast:192.168.23.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:32 errors:0 dropped:0 overruns:0 frame:0
  TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:3128 (3.0 KiB)  TX bytes:2844 (2.7 KiB)

loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   

[jira] [Commented] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9019:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1025#issuecomment-153341540
  
Result before this PR:

```
root@s-58-VM:~# ifconfig 
eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:03:b0  
  inet addr:169.254.3.176  Bcast:169.254.255.255  Mask:255.255.0.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:1362 errors:0 dropped:0 overruns:0 frame:0
  TX packets:74 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:68093 (66.4 KiB)  TX bytes:11731 (11.4 KiB)

eth1  Link encap:Ethernet  HWaddr 06:8f:3c:00:00:0e  
  inet addr:192.168.22.143  Bcast:192.168.22.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:63121 errors:0 dropped:1 overruns:0 frame:0
  TX packets:31637 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:84701257 (80.7 MiB)  TX bytes:125724065 (119.8 MiB)

eth2  Link encap:Ethernet  HWaddr 06:3c:56:00:00:16  
  inet addr:192.168.23.2  Bcast:192.168.23.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:1009 errors:0 dropped:0 overruns:0 frame:0
  TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:47700 (46.5 KiB)  TX bytes:3072 (3.0 KiB)

eth3  Link encap:Ethernet  HWaddr 06:9b:9e:00:00:14  
  inet addr:192.168.22.149  Bcast:192.168.22.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:3599 errors:0 dropped:1 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:193180 (188.6 KiB)  TX bytes:0 (0.0 B)

loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
```

```
root@s-58-VM:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse 
Iface
0.0.0.0 192.168.22.10.0.0.0 UG0  00 eth1
8.8.4.4 192.168.22.1255.255.255.255 UGH   0  00 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0  00 eth0
192.168.22.00.0.0.0 255.255.255.0   U 0  00 eth1
192.168.22.00.0.0.0 255.255.255.0   U 0  00 eth3
192.168.23.00.0.0.0 255.255.255.0   U 0  00 eth2
```

After this PR:

```
root@s-1-VM:~# ifconfig 
eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:03:44  
  inet addr:169.254.3.68  Bcast:169.254.255.255  Mask:255.255.0.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:30 errors:0 dropped:0 overruns:0 frame:0
  TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:1748 (1.7 KiB)  TX bytes:687 (687.0 B)

eth1  Link encap:Ethernet  HWaddr 06:00:c6:00:00:01  
  inet addr:192.168.22.130  Bcast:192.168.22.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:39717 errors:0 dropped:0 overruns:0 frame:0
  TX packets:17889 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:43372312 (41.3 MiB)  TX bytes:63330617 (60.3 MiB)

eth2  Link encap:Ethernet  HWaddr 06:82:d6:00:00:16  
  inet addr:192.168.23.2  Bcast:192.168.23.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:32 errors:0 dropped:0 overruns:0 frame:0
  TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:3128 (3.0 KiB)  TX bytes:2844 (2.7 KiB)

loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   

[jira] [Commented] (CLOUDSTACK-8751) Minimise VR downtime during network update

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8751:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/866#issuecomment-153339945
  
LGTM, based on a set of tests that I run on this branch (which I rebased 
myself first):

```
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
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
Stop existing router, add a PF rule and check we can access the VM ... === 
TestName: test_isolate_network_FW_PF_default_routes | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_RVR_Network_FW_PF_SSH_default_routes | 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 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 public IP ... === 
TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status : 
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... === 
TestName: test_network_rules_acquired_public_ip_2_nat_rule | Status : SUCCESS 
===
ok
Test for Router rules for network rules on acquired public IP ... === 
TestName: test_network_rules_acquired_public_ip_3_Load_Balancer_Rule | Status : 
SUCCESS ===
ok

--
Ran 29 tests in 12815.696s

OK
```


And:

```

[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8485:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1021#issuecomment-153338874
  
The field level annotation was discussed as a prefered solution but in the 
end a regexp on field names was used. I am fine with re-using the LogLevel 
annotation. It does what is needed and the name suggests this use.


> listAPIs are taking too long to return results
> --
>
> Key: CLOUDSTACK-8485
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.1, 4.6.0
>Reporter: Sowmya Krishnan
>Assignee: Koushik Das
> Fix For: 4.6.0
>
>
> listAPIs are taking significantly longer than before (4.2.x)
> I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K 
> Routers. Here are few results:
> listVirtualMachines is taking > 25 sec to return with pagesize set to 50. 
> This is in comparison to 2 sec in earlier cases such as 4.2.
> listVolumes with pagesize = 1000 took more than 10 mins and finally times out.
> Further observations show that there are also lot of slow queries being 
> logged in catalina.out and in MySQL slow query logs. I am not sure if this 
> could be the reason for DB performance getting impacted in turn causing an 
> impact on listAPIs too.
> Here's a sample of slow queries from catalina.out:
> Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 3305 ms, connection-id: 637759, statement-id: 3218312, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 
> ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name, 
> user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE 
> user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler 
> Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 3305 ms, connection-id: 637843, statement-id: 3218311, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 
> ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, 
> host.private_ip_address, host.private_mac_address, host.private_netmask, 
> host.public_netmask, host.public_ip_address, host.public_mac_address, 
> host.storage_ip_address, host.cluster_id, host.storage_netmask, 
> host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, 
> host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, 
> host.resource, host.fs_type, host.available, host.setup, host.resource_state, 
> host.hypervisor_version, host.update_count, host.uuid, host.data_center_id, 
> host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram, 
> host.parent, host.guid, host.capabilities, host.total_size, host.last_ping, 
> host.mgmt_server_id, host.dom0_memory, host.version, host.created, 
> host.removed FROM host WHERE host.id = 345  AND host.removed IS NULL
>  Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 6458 ms, connection-id: 637623, statement-id: 3218243, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458 
> ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref  INNER 
> JOIN host ON storage_pool_host_ref.host_id=host.id WHERE 
> storage_pool_host_ref.pool_id = 197  AND  (host.status = 'Up'  AND 
> host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler 
> Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 2402 ms, connection-id: 637754, statement-id: 3218371, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402 
> ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, 
> host.private_ip_address, host.private_mac_address, host.private_netmask, 
> host.public_netmask, host.public_ip_address, host.public_mac_address, 
> host.storage_ip_address, host.cluster_id, host.storage_netmask, 
> host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, 
> host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, 
> host.resource, host.fs_type, ho

[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8485:


Github user koushik-das commented on the pull request:

https://github.com/apache/cloudstack/pull/1021#issuecomment-153337620
  
@DaanHoogland @bhaisaab I also couldn't find any annotation on API fields 
for this. So ended up using the LogLevel which is also used in the agent 
commands.


> listAPIs are taking too long to return results
> --
>
> Key: CLOUDSTACK-8485
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.1, 4.6.0
>Reporter: Sowmya Krishnan
>Assignee: Koushik Das
> Fix For: 4.6.0
>
>
> listAPIs are taking significantly longer than before (4.2.x)
> I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K 
> Routers. Here are few results:
> listVirtualMachines is taking > 25 sec to return with pagesize set to 50. 
> This is in comparison to 2 sec in earlier cases such as 4.2.
> listVolumes with pagesize = 1000 took more than 10 mins and finally times out.
> Further observations show that there are also lot of slow queries being 
> logged in catalina.out and in MySQL slow query logs. I am not sure if this 
> could be the reason for DB performance getting impacted in turn causing an 
> impact on listAPIs too.
> Here's a sample of slow queries from catalina.out:
> Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 3305 ms, connection-id: 637759, statement-id: 3218312, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 
> ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name, 
> user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE 
> user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler 
> Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 3305 ms, connection-id: 637843, statement-id: 3218311, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 
> ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, 
> host.private_ip_address, host.private_mac_address, host.private_netmask, 
> host.public_netmask, host.public_ip_address, host.public_mac_address, 
> host.storage_ip_address, host.cluster_id, host.storage_netmask, 
> host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, 
> host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, 
> host.resource, host.fs_type, host.available, host.setup, host.resource_state, 
> host.hypervisor_version, host.update_count, host.uuid, host.data_center_id, 
> host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram, 
> host.parent, host.guid, host.capabilities, host.total_size, host.last_ping, 
> host.mgmt_server_id, host.dom0_memory, host.version, host.created, 
> host.removed FROM host WHERE host.id = 345  AND host.removed IS NULL
>  Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 6458 ms, connection-id: 637623, statement-id: 3218243, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458 
> ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref  INNER 
> JOIN host ON storage_pool_host_ref.host_id=host.id WHERE 
> storage_pool_host_ref.pool_id = 197  AND  (host.status = 'Up'  AND 
> host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler 
> Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 2402 ms, connection-id: 637754, statement-id: 3218371, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402 
> ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, 
> host.private_ip_address, host.private_mac_address, host.private_netmask, 
> host.public_netmask, host.public_ip_address, host.public_mac_address, 
> host.storage_ip_address, host.cluster_id, host.storage_netmask, 
> host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, 
> host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, 
> host.resource, host.fs_type, host.available, host.setup, host.resource_state, 
> host.hyperv

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/977#issuecomment-153336055
  
@wido any chance libvirt can be upgraded?


> 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-9021) test_ssvm is failing due to wrong interface check on VMware and HyperV

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9021:


Github user asfgit closed the pull request at:

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


> test_ssvm is failing due to wrong interface check on VMware and HyperV
> --
>
> Key: CLOUDSTACK-9021
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9021
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> In case of VMWare and Hyper-v , linc local is on eth1. So the command in
> all the failed tests to verify link local IP should be modified.
> "cat /var/cache/cloud/cmdline | xargs | sed \"s/ /\\n/g\" | grep eth0ip= |
> sed \"s/\=/ /g\" | awk '{print $2}'",.
> It is using eth0ip. However, it should be eth1ip.



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

[jira] [Commented] (CLOUDSTACK-9021) test_ssvm is failing due to wrong interface check on VMware and HyperV

[ASF subversion and git services (JIRA)]

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

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

Commit 0c62c611ddf1761dd15cb7850b55021f746e579b in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0c62c61 ]

Merge pull request #1026 from ekholabs/fix/test_ssvm-CLOUDSTACK-9021

CLOUDSTACK-9021 - Add right interface when test is executed against 
HyperV/VMwareThe test now check the IP taking into account the right interface 
for VMware/HyperV (eth1).

@karuturi could you please have a look? Unfortunately, I do not have 
HyperV/VMware test environment.

* pr/1026:
  CLOUDSTACK-9021 - Add right interface when test is executed against 
HyperV/VMware

Signed-off-by: Rajani Karuturi 


> test_ssvm is failing due to wrong interface check on VMware and HyperV
> --
>
> Key: CLOUDSTACK-9021
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9021
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> In case of VMWare and Hyper-v , linc local is on eth1. So the command in
> all the failed tests to verify link local IP should be modified.
> "cat /var/cache/cloud/cmdline | xargs | sed \"s/ /\\n/g\" | grep eth0ip= |
> sed \"s/\=/ /g\" | awk '{print $2}'",.
> It is using eth0ip. However, it should be eth1ip.



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

[jira] [Commented] (CLOUDSTACK-9021) test_ssvm is failing due to wrong interface check on VMware and HyperV

[ASF subversion and git services (JIRA)]

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

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

Commit 86d1b9632c0aecbc711f8f8243d56e7f515a1364 in cloudstack's branch 
refs/heads/master from [~wilder.rodrigues]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=86d1b96 ]

CLOUDSTACK-9021 - Add right interface when test is executed against 
HyperV/VMware


> test_ssvm is failing due to wrong interface check on VMware and HyperV
> --
>
> Key: CLOUDSTACK-9021
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9021
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> In case of VMWare and Hyper-v , linc local is on eth1. So the command in
> all the failed tests to verify link local IP should be modified.
> "cat /var/cache/cloud/cmdline | xargs | sed \"s/ /\\n/g\" | grep eth0ip= |
> sed \"s/\=/ /g\" | awk '{print $2}'",.
> It is using eth0ip. However, it should be eth1ip.



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

[jira] [Commented] (CLOUDSTACK-9021) test_ssvm is failing due to wrong interface check on VMware and HyperV

[ASF subversion and git services (JIRA)]

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

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

Commit 0c62c611ddf1761dd15cb7850b55021f746e579b in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0c62c61 ]

Merge pull request #1026 from ekholabs/fix/test_ssvm-CLOUDSTACK-9021

CLOUDSTACK-9021 - Add right interface when test is executed against 
HyperV/VMwareThe test now check the IP taking into account the right interface 
for VMware/HyperV (eth1).

@karuturi could you please have a look? Unfortunately, I do not have 
HyperV/VMware test environment.

* pr/1026:
  CLOUDSTACK-9021 - Add right interface when test is executed against 
HyperV/VMware

Signed-off-by: Rajani Karuturi 


> test_ssvm is failing due to wrong interface check on VMware and HyperV
> --
>
> Key: CLOUDSTACK-9021
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9021
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> In case of VMWare and Hyper-v , linc local is on eth1. So the command in
> all the failed tests to verify link local IP should be modified.
> "cat /var/cache/cloud/cmdline | xargs | sed \"s/ /\\n/g\" | grep eth0ip= |
> sed \"s/\=/ /g\" | awk '{print $2}'",.
> It is using eth0ip. However, it should be eth1ip.



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

[jira] [Commented] (CLOUDSTACK-9021) test_ssvm is failing due to wrong interface check on VMware and HyperV

[ASF subversion and git services (JIRA)]

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

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

Commit 0c62c611ddf1761dd15cb7850b55021f746e579b in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0c62c61 ]

Merge pull request #1026 from ekholabs/fix/test_ssvm-CLOUDSTACK-9021

CLOUDSTACK-9021 - Add right interface when test is executed against 
HyperV/VMwareThe test now check the IP taking into account the right interface 
for VMware/HyperV (eth1).

@karuturi could you please have a look? Unfortunately, I do not have 
HyperV/VMware test environment.

* pr/1026:
  CLOUDSTACK-9021 - Add right interface when test is executed against 
HyperV/VMware

Signed-off-by: Rajani Karuturi 


> test_ssvm is failing due to wrong interface check on VMware and HyperV
> --
>
> Key: CLOUDSTACK-9021
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9021
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> In case of VMWare and Hyper-v , linc local is on eth1. So the command in
> all the failed tests to verify link local IP should be modified.
> "cat /var/cache/cloud/cmdline | xargs | sed \"s/ /\\n/g\" | grep eth0ip= |
> sed \"s/\=/ /g\" | awk '{print $2}'",.
> It is using eth0ip. However, it should be eth1ip.



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

[jira] [Commented] (CLOUDSTACK-9021) test_ssvm is failing due to wrong interface check on VMware and HyperV

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9021:


Github user karuturi commented on the pull request:

https://github.com/apache/cloudstack/pull/1026#issuecomment-153331810
  
2 LGTMs merging. 


> test_ssvm is failing due to wrong interface check on VMware and HyperV
> --
>
> Key: CLOUDSTACK-9021
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9021
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> In case of VMWare and Hyper-v , linc local is on eth1. So the command in
> all the failed tests to verify link local IP should be modified.
> "cat /var/cache/cloud/cmdline | xargs | sed \"s/ /\\n/g\" | grep eth0ip= |
> sed \"s/\=/ /g\" | awk '{print $2}'",.
> It is using eth0ip. However, it should be eth1ip.



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

[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8485:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1021#issuecomment-153330895
  
@bhaisaab @koushik-das Isn't there an annotation on field level for APIs as 
well? A change was accepted for that. I am looking for it and will update this 
comment.


> listAPIs are taking too long to return results
> --
>
> Key: CLOUDSTACK-8485
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.1, 4.6.0
>Reporter: Sowmya Krishnan
>Assignee: Koushik Das
> Fix For: 4.6.0
>
>
> listAPIs are taking significantly longer than before (4.2.x)
> I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K 
> Routers. Here are few results:
> listVirtualMachines is taking > 25 sec to return with pagesize set to 50. 
> This is in comparison to 2 sec in earlier cases such as 4.2.
> listVolumes with pagesize = 1000 took more than 10 mins and finally times out.
> Further observations show that there are also lot of slow queries being 
> logged in catalina.out and in MySQL slow query logs. I am not sure if this 
> could be the reason for DB performance getting impacted in turn causing an 
> impact on listAPIs too.
> Here's a sample of slow queries from catalina.out:
> Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 3305 ms, connection-id: 637759, statement-id: 3218312, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 
> ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name, 
> user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE 
> user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler 
> Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 3305 ms, connection-id: 637843, statement-id: 3218311, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 
> ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, 
> host.private_ip_address, host.private_mac_address, host.private_netmask, 
> host.public_netmask, host.public_ip_address, host.public_mac_address, 
> host.storage_ip_address, host.cluster_id, host.storage_netmask, 
> host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, 
> host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, 
> host.resource, host.fs_type, host.available, host.setup, host.resource_state, 
> host.hypervisor_version, host.update_count, host.uuid, host.data_center_id, 
> host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram, 
> host.parent, host.guid, host.capabilities, host.total_size, host.last_ping, 
> host.mgmt_server_id, host.dom0_memory, host.version, host.created, 
> host.removed FROM host WHERE host.id = 345  AND host.removed IS NULL
>  Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 6458 ms, connection-id: 637623, statement-id: 3218243, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458 
> ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref  INNER 
> JOIN host ON storage_pool_host_ref.host_id=host.id WHERE 
> storage_pool_host_ref.pool_id = 197  AND  (host.status = 'Up'  AND 
> host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler 
> Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 2402 ms, connection-id: 637754, statement-id: 3218371, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402 
> ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, 
> host.private_ip_address, host.private_mac_address, host.private_netmask, 
> host.public_netmask, host.public_ip_address, host.public_mac_address, 
> host.storage_ip_address, host.cluster_id, host.storage_netmask, 
> host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, 
> host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, 
> host.resource, host.fs_type, host.available, host.setup, host.resource_state, 
> hos

[jira] [Commented] (CLOUDSTACK-9021) test_ssvm is failing due to wrong interface check on VMware and HyperV

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9021:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1026#issuecomment-153329985
  
change makes sense, I have no hyperv or vmware to test on.

LGTM


> test_ssvm is failing due to wrong interface check on VMware and HyperV
> --
>
> Key: CLOUDSTACK-9021
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9021
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> In case of VMWare and Hyper-v , linc local is on eth1. So the command in
> all the failed tests to verify link local IP should be modified.
> "cat /var/cache/cloud/cmdline | xargs | sed \"s/ /\\n/g\" | grep eth0ip= |
> sed \"s/\=/ /g\" | awk '{print $2}'",.
> It is using eth0ip. However, it should be eth1ip.



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

[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8715:


GitHub user ustcweizhou opened a pull request:

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

CLOUDSTACK-8715: qemu-guest-agent support on KVM

@wido can you check if these codes are useful for you? 

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

$ git pull https://github.com/ustcweizhou/cloudstack guest-agent

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

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

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

This closes #1027


commit 9317ef728f66ca7ff26166592ca2083432fdc805
Author: Wido den Hollander 
Date:   2015-10-27T10:03:49Z

CLOUDSTACK-8715: Add VirtIO channel to all Instances for the Qemu Guest 
Agent

This commit adds a additional VirtIO channel with the name 
'org.qemu.guest_agent.0'
to all Instances.

With the Qemu Guest Agent the Hypervisor gains more control over the 
Instance if
these tools are present inside the Instance, for example:

* Power control
* Flushing filesystems

In the future this should allow safer snapshots on KVM since we can 
instruct the
Instance to flush the filesystems prior to snapshotting the disk.

More information: http://wiki.qemu.org/Features/QAPI/GuestAgent

Keep in mind that on Ubuntu AppArmor still needs to be disabled since the 
default
AppArmor profile doesn't allow libvirt to write into /var/lib/libvirt/qemu

commit dbf8d0271eee8fd6a79f0159e377c636a0960011
Author: Wido den Hollander 
Date:   2015-10-30T11:33:27Z

Install the Qemu Guest Agent inside the SSVM

commit f6e4955e128d4079692900630f8cbc1096840696
Author: Wei Zhou 
Date:   2015-11-01T20:56:09Z

[Guest Agent] add guest_agent column in vm_template table

commit 13c7b8d472f1ae3992398a17317df48f3900317c
Author: Wei Zhou 
Date:   2015-11-02T07:52:18Z

[Guest Agent] add guest agent support in kvm hypervisor plugin

commit 8df88e484ef0140a7ead5fdd6c49aebcae45
Author: Wei Zhou 
Date:   2015-11-02T09:15:41Z

[Guest Agent] add rebootVM and stopVM via guest agent

commit 83abf9f0d9a125449a48a6211f6a6e9898088026
Author: Wei Zhou 
Date:   2015-11-03T09:44:32Z

[Guest Agent] send boot args to systemvms by send_to_vm_agent.py

commit 010e5a7699bbc871473363530bb890bddbf1ed99
Author: Wei Zhou 
Date:   2015-11-03T11:46:00Z

[Guest Agent] fix UI bugs




> Add support for qemu-guest-agent to libvirt provider
> 
>
> Key: CLOUDSTACK-8715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Reporter: Sten Spans
>Assignee: Wido den Hollander
>  Labels: kvm, libvirt, qemu, systemvm
> Fix For: Future
>
>
> The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite 
> a lot of useful functionality, which can only be provided by having an agent 
> on the VM. This includes things like freezing/thawing filesystems (for 
> backups), reading files on the guest, listing interfaces / ip addresses, etc.
> This feature has been requested by users, but is currently not implemented.
> http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent
> The first change needed is to add the following to the XML generated for KVM 
> virtual machines,:
> 
>   
>   
> 
> This provides the communication channel between libvirt and the agent on the 
> host. All in all a pretty simple change to LibvirtComputingResource.java / 
> LibvirtVMDef.java
> Secondly the qemu-guest-agent package needs to be added to the systemvm 
> template.



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

[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8485:


Github user koushik-das commented on the pull request:

https://github.com/apache/cloudstack/pull/1021#issuecomment-153327157
  
@bhaisaab What are your reasons for saying that @LogLevel(Log4jLevel.Off) 
is inappropriate?

By sensitive param/annotation are you referring to the existing @APICommand 
annotation params requestHasSensitiveInfo/responseHasSensitiveInfo? The problem 
with this approach is that it doesn't tell about the specific field which is 
sensitive and so the entire response needs to be searched for sensitive data by 
means of regex which is very bad in terms of performance.
 



> listAPIs are taking too long to return results
> --
>
> Key: CLOUDSTACK-8485
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.1, 4.6.0
>Reporter: Sowmya Krishnan
>Assignee: Koushik Das
> Fix For: 4.6.0
>
>
> listAPIs are taking significantly longer than before (4.2.x)
> I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K 
> Routers. Here are few results:
> listVirtualMachines is taking > 25 sec to return with pagesize set to 50. 
> This is in comparison to 2 sec in earlier cases such as 4.2.
> listVolumes with pagesize = 1000 took more than 10 mins and finally times out.
> Further observations show that there are also lot of slow queries being 
> logged in catalina.out and in MySQL slow query logs. I am not sure if this 
> could be the reason for DB performance getting impacted in turn causing an 
> impact on listAPIs too.
> Here's a sample of slow queries from catalina.out:
> Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 3305 ms, connection-id: 637759, statement-id: 3218312, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 
> ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name, 
> user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE 
> user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler 
> Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 3305 ms, connection-id: 637843, statement-id: 3218311, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 
> ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, 
> host.private_ip_address, host.private_mac_address, host.private_netmask, 
> host.public_netmask, host.public_ip_address, host.public_mac_address, 
> host.storage_ip_address, host.cluster_id, host.storage_netmask, 
> host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, 
> host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, 
> host.resource, host.fs_type, host.available, host.setup, host.resource_state, 
> host.hypervisor_version, host.update_count, host.uuid, host.data_center_id, 
> host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram, 
> host.parent, host.guid, host.capabilities, host.total_size, host.last_ping, 
> host.mgmt_server_id, host.dom0_memory, host.version, host.created, 
> host.removed FROM host WHERE host.id = 345  AND host.removed IS NULL
>  Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 6458 ms, connection-id: 637623, statement-id: 3218243, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458 
> ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref  INNER 
> JOIN host ON storage_pool_host_ref.host_id=host.id WHERE 
> storage_pool_host_ref.pool_id = 197  AND  (host.status = 'Up'  AND 
> host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler 
> Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 2402 ms, connection-id: 637754, statement-id: 3218371, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402 
> ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, 
> host.private_ip_address, host.private_mac_address, host.private_netmask, 
> host.public_netmask, host.public_ip_address, host.public_

[jira] [Commented] (CLOUDSTACK-9021) test_ssvm is failing due to wrong interface check on VMware and HyperV

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9021:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1026#issuecomment-153327095
  
Got LGTM from Sanjeev on the mail list:

```
On 03 Nov 2015, at 12:13, Sanjeev N  wrote:

Ran one test

Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status :
SUCCESS ===
ok

LGTM!!
```

Ping @remibergsma @borisroman @DaanHoogland 

Cheers,
Wilder


> test_ssvm is failing due to wrong interface check on VMware and HyperV
> --
>
> Key: CLOUDSTACK-9021
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9021
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> In case of VMWare and Hyper-v , linc local is on eth1. So the command in
> all the failed tests to verify link local IP should be modified.
> "cat /var/cache/cloud/cmdline | xargs | sed \"s/ /\\n/g\" | grep eth0ip= |
> sed \"s/\=/ /g\" | awk '{print $2}'",.
> It is using eth0ip. However, it should be eth1ip.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


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

https://github.com/apache/cloudstack/pull/977#discussion_r43734962
  
--- Diff: 
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/wrapper/LibvirtDeleteVMSnapshotCommandWrapper.java
 ---
@@ -0,0 +1,108 @@
+//
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements.  See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership.  The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License.  You may obtain a copy of the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied.  See the License for the
+// specific language governing permissions and limitations
+// under the License.
+//
+
+package com.cloud.hypervisor.kvm.resource.wrapper;
+
+import org.apache.cloudstack.storage.to.PrimaryDataStoreTO;
+import org.apache.cloudstack.storage.to.VolumeObjectTO;
+import org.apache.log4j.Logger;
+import org.libvirt.Connect;
+import org.libvirt.Domain;
+import org.libvirt.DomainSnapshot;
+import org.libvirt.LibvirtException;
+
+import com.cloud.agent.api.Answer;
+import com.cloud.agent.api.DeleteVMSnapshotAnswer;
+import com.cloud.agent.api.DeleteVMSnapshotCommand;
+import com.cloud.hypervisor.kvm.resource.LibvirtComputingResource;
+import com.cloud.hypervisor.kvm.storage.KVMPhysicalDisk;
+import com.cloud.hypervisor.kvm.storage.KVMStoragePoolManager;
+import com.cloud.resource.CommandWrapper;
+import com.cloud.resource.ResourceWrapper;
+import com.cloud.storage.Volume;
+import com.cloud.utils.script.Script;
+
+@ResourceWrapper(handles =  DeleteVMSnapshotCommand.class)
+public final class LibvirtDeleteVMSnapshotCommandWrapper extends 
CommandWrapper {
+
+private static final Logger s_logger = 
Logger.getLogger(LibvirtDeleteVMSnapshotCommandWrapper.class);
+
+@Override
+public Answer execute(final DeleteVMSnapshotCommand cmd, final 
LibvirtComputingResource libvirtComputingResource) {
+String vmName = cmd.getVmName();
+
+final KVMStoragePoolManager storagePoolMgr = 
libvirtComputingResource.getStoragePoolMgr();
+Domain dm = null;
+try {
+final LibvirtUtilitiesHelper libvirtUtilitiesHelper = 
libvirtComputingResource.getLibvirtUtilitiesHelper();
+Connect conn = libvirtUtilitiesHelper.getConnection();
+dm = libvirtComputingResource.getDomain(conn, vmName);
+
+DomainSnapshot snapshot = null;
+try {
+snapshot = 
dm.snapshotLookupByName(cmd.getTarget().getSnapshotName());
+} catch (LibvirtException e) {
+s_logger.warn("Cannot find vmSnapshot with name: " + 
cmd.getTarget().getSnapshotName());
+return new DeleteVMSnapshotAnswer(cmd, cmd.getVolumeTOs());
+}
+
+snapshot.delete(0); // only remove this snapshot, not children
+
+return new DeleteVMSnapshotAnswer(cmd, cmd.getVolumeTOs());
+} catch (LibvirtException e) {
+String msg = " Delete VM snapshot failed due to " + 
e.toString();
--- End diff --

This is because I wanted to display different error/warning message when 
exceptions are thown on snapshotLookupByName and snapshot.delete(0).
It looks not necessary. I will modify it.


> 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-9021) test_ssvm is failing due to wrong interface check on VMware and HyperV

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9021:


GitHub user wilderrodrigues opened a pull request:

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

CLOUDSTACK-9021 - Add right interface when test is executed against 
HyperV/VMware

The test now check the IP taking into account the right interface for 
VMware/HyperV (eth1).

@karuturi could you please have a look? Unfortunately, I do not have 
HyperV/VMware test environment.

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

$ git pull https://github.com/ekholabs/cloudstack 
fix/test_ssvm-CLOUDSTACK-9021

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

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

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

This closes #1026


commit 86d1b9632c0aecbc711f8f8243d56e7f515a1364
Author: Wilder Rodrigues 
Date:   2015-11-03T10:18:11Z

CLOUDSTACK-9021 - Add right interface when test is executed against 
HyperV/VMware




> test_ssvm is failing due to wrong interface check on VMware and HyperV
> --
>
> Key: CLOUDSTACK-9021
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9021
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> In case of VMWare and Hyper-v , linc local is on eth1. So the command in
> all the failed tests to verify link local IP should be modified.
> "cat /var/cache/cloud/cmdline | xargs | sed \"s/ /\\n/g\" | grep eth0ip= |
> sed \"s/\=/ /g\" | awk '{print $2}'",.
> It is using eth0ip. However, it should be eth1ip.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


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

https://github.com/apache/cloudstack/pull/977#discussion_r43734583
  
--- Diff: 
api/src/org/apache/cloudstack/api/command/user/snapshot/CreateSnapshotFromVMSnapshotCmd.java
 ---
@@ -0,0 +1,219 @@
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements.  See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership.  The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License.  You may obtain a copy of the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied.  See the License for the
+// specific language governing permissions and limitations
+// under the License.
+package org.apache.cloudstack.api.command.user.snapshot;
+
+import org.apache.cloudstack.api.APICommand;
+import org.apache.cloudstack.api.ApiCommandJobType;
+import org.apache.cloudstack.api.ApiConstants;
+import org.apache.cloudstack.api.ApiErrorCode;
+import org.apache.cloudstack.api.BaseAsyncCmd;
+import org.apache.cloudstack.api.BaseAsyncCreateCmd;
+import org.apache.cloudstack.api.Parameter;
+import org.apache.cloudstack.api.ServerApiException;
+import org.apache.cloudstack.api.response.SnapshotResponse;
+import org.apache.cloudstack.api.response.VMSnapshotResponse;
+import org.apache.cloudstack.api.response.VolumeResponse;
+import org.apache.cloudstack.context.CallContext;
+import org.apache.log4j.Logger;
+
+import com.cloud.event.EventTypes;
+import com.cloud.exception.InvalidParameterValueException;
+import com.cloud.exception.PermissionDeniedException;
+import com.cloud.exception.ResourceAllocationException;
+import com.cloud.projects.Project;
+import com.cloud.storage.Snapshot;
+import com.cloud.user.Account;
+import com.cloud.uservm.UserVm;
+import com.cloud.vm.snapshot.VMSnapshot;
+
+@APICommand(name = "createSnapshotFromVMSnapshot", description = "Creates 
an instant snapshot of a volume from existing vm snapshot.", responseObject = 
SnapshotResponse.class, entityType = {Snapshot.class}, since = "4.6.0",
+requestHasSensitiveInfo = false, responseHasSensitiveInfo = false)
+public class CreateSnapshotFromVMSnapshotCmd extends BaseAsyncCreateCmd {
+public static final Logger s_logger = 
Logger.getLogger(CreateSnapshotFromVMSnapshotCmd.class.getName());
+private static final String s_name = 
"createsnapshotfromvmsnapshotresponse";
+
+// ///
+// // API parameters /
+// ///
+
+@Parameter(name = ApiConstants.VOLUME_ID, type = CommandType.UUID, 
entityType = VolumeResponse.class, required = true, description = "The ID of 
the disk volume")
+private Long volumeId;
+
+@Parameter(name=ApiConstants.VM_SNAPSHOT_ID, type=CommandType.UUID, 
entityType=VMSnapshotResponse.class,
+required=true, description="The ID of the VM snapshot")
+private Long vmSnapshotId;
+
+@Parameter(name = ApiConstants.NAME, type = CommandType.STRING, 
description = "the name of the snapshot")
+private String snapshotName;
+
+private String syncObjectType = BaseAsyncCmd.snapshotHostSyncObject;
+
+// ///
+// / Accessors ///
+// ///
+
+public Long getVolumeId() {
+return volumeId;
+}
+
+public Long getVMSnapshotId() {
+return vmSnapshotId;
+}
+
+public String getSnapshotName() {
+return snapshotName;
+}
+
+private Long getVmId() {
+VMSnapshot vmsnapshot = _entityMgr.findById(VMSnapshot.class, 
getVMSnapshotId());
+if (vmsnapshot == null) {
+throw new InvalidParameterValueException("Unable to find vm 
snapshot by id=" + getVMSnapshotId());
+}
+UserVm vm = _entityMgr.findById(UserVm.class, 
vmsnapshot.getVmId());
+if (vm =

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


Github user wido commented on the pull request:

https://github.com/apache/cloudstack/pull/977#issuecomment-153312402
  
@DaanHoogland @ustcweizhou Overall it seems good! It's just hard to test 
this since it can break migration of VMs and you also have to deal with all the 
versions of libvirt.

But overall I think it's OK. If you can take a look at my comments?


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



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


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

https://github.com/apache/cloudstack/pull/977#discussion_r43734401
  
--- Diff: 
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/wrapper/LibvirtRestoreVMSnapshotCommandWrapper.java
 ---
@@ -0,0 +1,103 @@
+//
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements.  See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership.  The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License.  You may obtain a copy of the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied.  See the License for the
+// specific language governing permissions and limitations
+// under the License.
+//
+
+package com.cloud.hypervisor.kvm.resource.wrapper;
+
+import java.util.List;
+import java.util.Map;
+
+import org.apache.cloudstack.storage.to.VolumeObjectTO;
+import org.apache.log4j.Logger;
+import org.libvirt.Connect;
+import org.libvirt.Domain;
+import org.libvirt.LibvirtException;
+
+import com.cloud.agent.api.Answer;
+import com.cloud.agent.api.RestoreVMSnapshotAnswer;
+import com.cloud.agent.api.RestoreVMSnapshotCommand;
+import com.cloud.agent.api.VMSnapshotTO;
+import com.cloud.hypervisor.kvm.resource.LibvirtComputingResource;
+import com.cloud.resource.CommandWrapper;
+import com.cloud.resource.ResourceWrapper;
+import com.cloud.vm.VirtualMachine;
+
+@ResourceWrapper(handles =  RestoreVMSnapshotCommand.class)
+public final class LibvirtRestoreVMSnapshotCommandWrapper extends 
CommandWrapper {
+
+private static final Logger s_logger = 
Logger.getLogger(LibvirtRestoreVMSnapshotCommandWrapper.class);
+
+@Override
+public Answer execute(final RestoreVMSnapshotCommand cmd, final 
LibvirtComputingResource libvirtComputingResource) {
+String vmName = cmd.getVmName();
+List listVolumeTo = cmd.getVolumeTOs();
+VirtualMachine.PowerState vmState = 
VirtualMachine.PowerState.PowerOn;
+
+Domain dm = null;
+try {
+final LibvirtUtilitiesHelper libvirtUtilitiesHelper = 
libvirtComputingResource.getLibvirtUtilitiesHelper();
+Connect conn = libvirtUtilitiesHelper.getConnection();
+dm = libvirtComputingResource.getDomain(conn, vmName);
+
+if (dm == null) {
+return new RestoreVMSnapshotAnswer(cmd, false,
+"Restore VM Snapshot Failed due to can not find 
vm: " + vmName);
+}
+String xmlDesc = dm.getXMLDesc(0);
+
+List snapshots = cmd.getSnapshots();
+Map snapshotAndParents = 
cmd.getSnapshotAndParents();
+for (VMSnapshotTO snapshot: snapshots) {
+VMSnapshotTO parent = 
snapshotAndParents.get(snapshot.getId());
+String parentName = (parent == null)? "": ("  
" + parent.getSnapshotName() + "\n");
+String vmSnapshotXML = "\n"
--- End diff --

Can we maybe offload this to a helper which generates the XML? We have this 
for multiple things. That allows us to Unit Test the XML generation. That is 
very hard to do when it's inline.


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



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


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

https://github.com/apache/cloudstack/pull/977#discussion_r43734254
  
--- Diff: 
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/wrapper/LibvirtDeleteVMSnapshotCommandWrapper.java
 ---
@@ -0,0 +1,108 @@
+//
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements.  See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership.  The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License.  You may obtain a copy of the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied.  See the License for the
+// specific language governing permissions and limitations
+// under the License.
+//
+
+package com.cloud.hypervisor.kvm.resource.wrapper;
+
+import org.apache.cloudstack.storage.to.PrimaryDataStoreTO;
+import org.apache.cloudstack.storage.to.VolumeObjectTO;
+import org.apache.log4j.Logger;
+import org.libvirt.Connect;
+import org.libvirt.Domain;
+import org.libvirt.DomainSnapshot;
+import org.libvirt.LibvirtException;
+
+import com.cloud.agent.api.Answer;
+import com.cloud.agent.api.DeleteVMSnapshotAnswer;
+import com.cloud.agent.api.DeleteVMSnapshotCommand;
+import com.cloud.hypervisor.kvm.resource.LibvirtComputingResource;
+import com.cloud.hypervisor.kvm.storage.KVMPhysicalDisk;
+import com.cloud.hypervisor.kvm.storage.KVMStoragePoolManager;
+import com.cloud.resource.CommandWrapper;
+import com.cloud.resource.ResourceWrapper;
+import com.cloud.storage.Volume;
+import com.cloud.utils.script.Script;
+
+@ResourceWrapper(handles =  DeleteVMSnapshotCommand.class)
+public final class LibvirtDeleteVMSnapshotCommandWrapper extends 
CommandWrapper {
+
+private static final Logger s_logger = 
Logger.getLogger(LibvirtDeleteVMSnapshotCommandWrapper.class);
+
+@Override
+public Answer execute(final DeleteVMSnapshotCommand cmd, final 
LibvirtComputingResource libvirtComputingResource) {
+String vmName = cmd.getVmName();
+
+final KVMStoragePoolManager storagePoolMgr = 
libvirtComputingResource.getStoragePoolMgr();
+Domain dm = null;
+try {
+final LibvirtUtilitiesHelper libvirtUtilitiesHelper = 
libvirtComputingResource.getLibvirtUtilitiesHelper();
+Connect conn = libvirtUtilitiesHelper.getConnection();
+dm = libvirtComputingResource.getDomain(conn, vmName);
+
+DomainSnapshot snapshot = null;
+try {
+snapshot = 
dm.snapshotLookupByName(cmd.getTarget().getSnapshotName());
+} catch (LibvirtException e) {
+s_logger.warn("Cannot find vmSnapshot with name: " + 
cmd.getTarget().getSnapshotName());
+return new DeleteVMSnapshotAnswer(cmd, cmd.getVolumeTOs());
+}
+
+snapshot.delete(0); // only remove this snapshot, not children
+
+return new DeleteVMSnapshotAnswer(cmd, cmd.getVolumeTOs());
+} catch (LibvirtException e) {
+String msg = " Delete VM snapshot failed due to " + 
e.toString();
+
+if (dm == null) {
+s_logger.debug("Can not find vm: " + vmName + ", delete 
the snapshot using qemu-img");
--- End diff --

Is this an action to be taken by the admin? The log line seems to suggest it


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



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


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

https://github.com/apache/cloudstack/pull/977#discussion_r43734224
  
--- Diff: 
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/wrapper/LibvirtDeleteVMSnapshotCommandWrapper.java
 ---
@@ -0,0 +1,108 @@
+//
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements.  See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership.  The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License.  You may obtain a copy of the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied.  See the License for the
+// specific language governing permissions and limitations
+// under the License.
+//
+
+package com.cloud.hypervisor.kvm.resource.wrapper;
+
+import org.apache.cloudstack.storage.to.PrimaryDataStoreTO;
+import org.apache.cloudstack.storage.to.VolumeObjectTO;
+import org.apache.log4j.Logger;
+import org.libvirt.Connect;
+import org.libvirt.Domain;
+import org.libvirt.DomainSnapshot;
+import org.libvirt.LibvirtException;
+
+import com.cloud.agent.api.Answer;
+import com.cloud.agent.api.DeleteVMSnapshotAnswer;
+import com.cloud.agent.api.DeleteVMSnapshotCommand;
+import com.cloud.hypervisor.kvm.resource.LibvirtComputingResource;
+import com.cloud.hypervisor.kvm.storage.KVMPhysicalDisk;
+import com.cloud.hypervisor.kvm.storage.KVMStoragePoolManager;
+import com.cloud.resource.CommandWrapper;
+import com.cloud.resource.ResourceWrapper;
+import com.cloud.storage.Volume;
+import com.cloud.utils.script.Script;
+
+@ResourceWrapper(handles =  DeleteVMSnapshotCommand.class)
+public final class LibvirtDeleteVMSnapshotCommandWrapper extends 
CommandWrapper {
+
+private static final Logger s_logger = 
Logger.getLogger(LibvirtDeleteVMSnapshotCommandWrapper.class);
+
+@Override
+public Answer execute(final DeleteVMSnapshotCommand cmd, final 
LibvirtComputingResource libvirtComputingResource) {
+String vmName = cmd.getVmName();
+
+final KVMStoragePoolManager storagePoolMgr = 
libvirtComputingResource.getStoragePoolMgr();
+Domain dm = null;
+try {
+final LibvirtUtilitiesHelper libvirtUtilitiesHelper = 
libvirtComputingResource.getLibvirtUtilitiesHelper();
+Connect conn = libvirtUtilitiesHelper.getConnection();
+dm = libvirtComputingResource.getDomain(conn, vmName);
+
+DomainSnapshot snapshot = null;
+try {
+snapshot = 
dm.snapshotLookupByName(cmd.getTarget().getSnapshotName());
+} catch (LibvirtException e) {
+s_logger.warn("Cannot find vmSnapshot with name: " + 
cmd.getTarget().getSnapshotName());
+return new DeleteVMSnapshotAnswer(cmd, cmd.getVolumeTOs());
+}
+
+snapshot.delete(0); // only remove this snapshot, not children
+
+return new DeleteVMSnapshotAnswer(cmd, cmd.getVolumeTOs());
+} catch (LibvirtException e) {
+String msg = " Delete VM snapshot failed due to " + 
e.toString();
--- End diff --

Can't you move this down to where you actually throw the Answer back?


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



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


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

https://github.com/apache/cloudstack/pull/977#discussion_r43734035
  
--- Diff: 
api/src/org/apache/cloudstack/api/command/user/snapshot/CreateSnapshotFromVMSnapshotCmd.java
 ---
@@ -0,0 +1,219 @@
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements.  See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership.  The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License.  You may obtain a copy of the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied.  See the License for the
+// specific language governing permissions and limitations
+// under the License.
+package org.apache.cloudstack.api.command.user.snapshot;
+
+import org.apache.cloudstack.api.APICommand;
+import org.apache.cloudstack.api.ApiCommandJobType;
+import org.apache.cloudstack.api.ApiConstants;
+import org.apache.cloudstack.api.ApiErrorCode;
+import org.apache.cloudstack.api.BaseAsyncCmd;
+import org.apache.cloudstack.api.BaseAsyncCreateCmd;
+import org.apache.cloudstack.api.Parameter;
+import org.apache.cloudstack.api.ServerApiException;
+import org.apache.cloudstack.api.response.SnapshotResponse;
+import org.apache.cloudstack.api.response.VMSnapshotResponse;
+import org.apache.cloudstack.api.response.VolumeResponse;
+import org.apache.cloudstack.context.CallContext;
+import org.apache.log4j.Logger;
+
+import com.cloud.event.EventTypes;
+import com.cloud.exception.InvalidParameterValueException;
+import com.cloud.exception.PermissionDeniedException;
+import com.cloud.exception.ResourceAllocationException;
+import com.cloud.projects.Project;
+import com.cloud.storage.Snapshot;
+import com.cloud.user.Account;
+import com.cloud.uservm.UserVm;
+import com.cloud.vm.snapshot.VMSnapshot;
+
+@APICommand(name = "createSnapshotFromVMSnapshot", description = "Creates 
an instant snapshot of a volume from existing vm snapshot.", responseObject = 
SnapshotResponse.class, entityType = {Snapshot.class}, since = "4.6.0",
+requestHasSensitiveInfo = false, responseHasSensitiveInfo = false)
+public class CreateSnapshotFromVMSnapshotCmd extends BaseAsyncCreateCmd {
+public static final Logger s_logger = 
Logger.getLogger(CreateSnapshotFromVMSnapshotCmd.class.getName());
+private static final String s_name = 
"createsnapshotfromvmsnapshotresponse";
+
+// ///
+// // API parameters /
+// ///
+
+@Parameter(name = ApiConstants.VOLUME_ID, type = CommandType.UUID, 
entityType = VolumeResponse.class, required = true, description = "The ID of 
the disk volume")
+private Long volumeId;
+
+@Parameter(name=ApiConstants.VM_SNAPSHOT_ID, type=CommandType.UUID, 
entityType=VMSnapshotResponse.class,
+required=true, description="The ID of the VM snapshot")
+private Long vmSnapshotId;
+
+@Parameter(name = ApiConstants.NAME, type = CommandType.STRING, 
description = "the name of the snapshot")
+private String snapshotName;
+
+private String syncObjectType = BaseAsyncCmd.snapshotHostSyncObject;
+
+// ///
+// / Accessors ///
+// ///
+
+public Long getVolumeId() {
+return volumeId;
+}
+
+public Long getVMSnapshotId() {
+return vmSnapshotId;
+}
+
+public String getSnapshotName() {
+return snapshotName;
+}
+
+private Long getVmId() {
+VMSnapshot vmsnapshot = _entityMgr.findById(VMSnapshot.class, 
getVMSnapshotId());
+if (vmsnapshot == null) {
+throw new InvalidParameterValueException("Unable to find vm 
snapshot by id=" + getVMSnapshotId());
+}
+UserVm vm = _entityMgr.findById(UserVm.class, 
vmsnapshot.getVmId());
+if (vm == null)

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8746:


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

https://github.com/apache/cloudstack/pull/977#discussion_r43733925
  
--- Diff: 
api/src/org/apache/cloudstack/api/command/user/snapshot/CreateSnapshotFromVMSnapshotCmd.java
 ---
@@ -0,0 +1,197 @@
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements.  See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership.  The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License.  You may obtain a copy of the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied.  See the License for the
+// specific language governing permissions and limitations
+// under the License.
+package org.apache.cloudstack.api.command.user.snapshot;
+
+import org.apache.cloudstack.api.APICommand;
+import org.apache.cloudstack.api.ApiCommandJobType;
+import org.apache.cloudstack.api.ApiConstants;
+import org.apache.cloudstack.api.ApiErrorCode;
+import org.apache.cloudstack.api.BaseAsyncCmd;
+import org.apache.cloudstack.api.BaseAsyncCreateCmd;
+import org.apache.cloudstack.api.Parameter;
+import org.apache.cloudstack.api.ServerApiException;
+import org.apache.cloudstack.api.response.SnapshotResponse;
+import org.apache.cloudstack.api.response.VMSnapshotResponse;
+import org.apache.cloudstack.context.CallContext;
+import org.apache.log4j.Logger;
+
+import com.cloud.event.EventTypes;
+import com.cloud.exception.InvalidParameterValueException;
+import com.cloud.exception.PermissionDeniedException;
+import com.cloud.exception.ResourceAllocationException;
+import com.cloud.projects.Project;
+import com.cloud.storage.Snapshot;
+import com.cloud.user.Account;
+import com.cloud.uservm.UserVm;
+import com.cloud.vm.snapshot.VMSnapshot;
+
+@APICommand(name = "createSnapshotFromVMSnapshot", description = "Creates 
an instant snapshot of a volume from vm snapshot.", responseObject = 
SnapshotResponse.class)
+public class CreateSnapshotFromVMSnapshotCmd extends BaseAsyncCreateCmd {
+public static final Logger s_logger = 
Logger.getLogger(CreateSnapshotFromVMSnapshotCmd.class.getName());
+private static final String s_name = 
"createsnapshotfromvmsnapshotresponse";
+
+// ///
+// // API parameters /
+// ///
+
+@Parameter(name=ApiConstants.VM_SNAPSHOT_ID, type=CommandType.UUID, 
entityType=VMSnapshotResponse.class,
+required=true, description="The ID of the VM snapshot")
+ private Long vmSnapshotId;
+
+@Parameter(name = ApiConstants.NAME, type = CommandType.STRING, 
description = "the name of the snapshot")
+private String snapshotName;
+
+private String syncObjectType = BaseAsyncCmd.snapshotHostSyncObject;
+
+// ///
+// / Accessors ///
+// ///
+
+public Long getVMSnapshotId() {
+return vmSnapshotId;
+}
+
+public String getSnapshotName() {
+return snapshotName;
+}
+
+private Long getVmId() {
+VMSnapshot vmsnapshot = _entityMgr.findById(VMSnapshot.class, 
getVMSnapshotId());
+if (vmsnapshot == null) {
+throw new InvalidParameterValueException("Unable to find vm 
snapshot by id=" + getVMSnapshotId());
+}
+UserVm vm = _entityMgr.findById(UserVm.class, 
vmsnapshot.getVmId());
+if (vm == null) {
+throw new InvalidParameterValueException("Unable to find vm by 
vm snapshot id=" + getVMSnapshotId());
+}
+return vm.getId();
+}
+private Long getHostId() {
+VMSnapshot vmsnapshot = _entityMgr.findById(VMSnapshot.class, 
getVMSnapshotId());
+if (vmsnapshot == null) {
+throw new InvalidParameterValueException("Unable to find vm 
snapshot by id=" + getVMSnapshotId());
+}
+ 

[jira] [Commented] (CLOUDSTACK-9019) Storage VM gets two mgmt nics when no storage net defined

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9019:


Github user wido commented on the pull request:

https://github.com/apache/cloudstack/pull/1024#issuecomment-153311038
  
Seems like a good fix to me. Can't test it manually at this moment though


> Storage VM gets two mgmt nics when no storage net defined
> -
>
> Key: CLOUDSTACK-9019
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9019
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.5.3, 4.6.0
>
>
> If a dedicated storage network is not provided in a zone, secondary storage 
> VMs get two management nics. This eats up an additional IP, the fix would be 
> to allocate a storage nic only when storage network is defined.



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

[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8485:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/1021#issuecomment-153309944
  
Usage of @LogLevel(Log4jLevel.Off) seems inappropriate to avoid logging 
sensitive information, why not still check the sensitive param/annotation to 
log or not log data?


> listAPIs are taking too long to return results
> --
>
> Key: CLOUDSTACK-8485
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.1, 4.6.0
>Reporter: Sowmya Krishnan
>Assignee: Koushik Das
> Fix For: 4.6.0
>
>
> listAPIs are taking significantly longer than before (4.2.x)
> I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K 
> Routers. Here are few results:
> listVirtualMachines is taking > 25 sec to return with pagesize set to 50. 
> This is in comparison to 2 sec in earlier cases such as 4.2.
> listVolumes with pagesize = 1000 took more than 10 mins and finally times out.
> Further observations show that there are also lot of slow queries being 
> logged in catalina.out and in MySQL slow query logs. I am not sure if this 
> could be the reason for DB performance getting impacted in turn causing an 
> impact on listAPIs too.
> Here's a sample of slow queries from catalina.out:
> Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 3305 ms, connection-id: 637759, statement-id: 3218312, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 
> ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name, 
> user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE 
> user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler 
> Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 3305 ms, connection-id: 637843, statement-id: 3218311, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 
> ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, 
> host.private_ip_address, host.private_mac_address, host.private_netmask, 
> host.public_netmask, host.public_ip_address, host.public_mac_address, 
> host.storage_ip_address, host.cluster_id, host.storage_netmask, 
> host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, 
> host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, 
> host.resource, host.fs_type, host.available, host.setup, host.resource_state, 
> host.hypervisor_version, host.update_count, host.uuid, host.data_center_id, 
> host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram, 
> host.parent, host.guid, host.capabilities, host.total_size, host.last_ping, 
> host.mgmt_server_id, host.dom0_memory, host.version, host.created, 
> host.removed FROM host WHERE host.id = 345  AND host.removed IS NULL
>  Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 6458 ms, connection-id: 637623, statement-id: 3218243, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458 
> ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref  INNER 
> JOIN host ON storage_pool_host_ref.host_id=host.id WHERE 
> storage_pool_host_ref.pool_id = 197  AND  (host.status = 'Up'  AND 
> host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler 
> Event: [SLOW QUERY] at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
>  duration: 2402 ms, connection-id: 637754, statement-id: 3218371, 
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402 
> ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, 
> host.private_ip_address, host.private_mac_address, host.private_netmask, 
> host.public_netmask, host.public_ip_address, host.public_mac_address, 
> host.storage_ip_address, host.cluster_id, host.storage_netmask, 
> host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, 
> host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, 
> host.resource, host.fs_type, host.available, host.setup, host.resource_state, 
> h

[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8925:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1023#issuecomment-153309653
  
More test results. It did not break existing functionality, but still I 
will fix the one @karuturi found.

Cheers,
Wilder

```
test_privategw_acl (integration.smoke.test_privategw_acl.TestPrivateGwACL) 
... === TestName: test_privategw_acl | Status : SUCCESS ===
ok
Test reset virtual machine on reboot ... === TestName: 
test_01_reset_vm_on_reboot | Status : SUCCESS ===
ok
Test to create service offering ... === TestName: 
test_01_create_service_offering | Status : SUCCESS ===
ok
Test to update existing service offering ... === TestName: 
test_02_edit_service_offering | Status : SUCCESS ===
ok
Test to delete service offering ... === TestName: 
test_03_delete_service_offering | Status : SUCCESS ===
ok
Test create VPC offering ... === TestName: test_01_create_vpc_offering | 
Status : SUCCESS ===
ok
Test VPC offering without load balancing service ... === TestName: 
test_03_vpc_off_without_lb | Status : SUCCESS ===
ok
Test VPC offering without static NAT service ... === TestName: 
test_04_vpc_off_without_static_nat | Status : SUCCESS ===
ok
Test VPC offering without port forwarding service ... === TestName: 
test_05_vpc_off_without_pf | Status : SUCCESS ===
ok
Test VPC offering with invalid services ... === TestName: 
test_06_vpc_off_invalid_services | Status : SUCCESS ===
ok
Test update VPC offering ... === TestName: test_07_update_vpc_off | Status 
: SUCCESS ===
ok
Test list VPC offering ... === TestName: test_08_list_vpc_off | Status : 
SUCCESS ===
ok
test_09_create_redundant_vpc_offering 
(integration.component.test_vpc_offerings.TestVPCOffering) ... === TestName: 
test_09_create_redundant_vpc_offering | Status : SUCCESS ===
ok

--
Ran 13 tests in 3403.790s

OK
/tmp//MarvinLogs/test_vpc_offerings_6W7KGH/results.txt (END)
```


> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Chain FW_OUTBOUND (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 3   252 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED



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

[jira] [Created] (CLOUDSTACK-9021) test_ssvm is failing due to wrong interface check on VMware and HyperV

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9021:


 Summary: test_ssvm is failing due to wrong interface check on 
VMware and HyperV
 Key: CLOUDSTACK-9021
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9021
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Test
Affects Versions: 4.6.0
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues


In case of VMWare and Hyper-v , linc local is on eth1. So the command in
all the failed tests to verify link local IP should be modified.
"cat /var/cache/cloud/cmdline | xargs | sed \"s/ /\\n/g\" | grep eth0ip= |
sed \"s/\=/ /g\" | awk '{print $2}'",.

It is using eth0ip. However, it should be eth1ip.



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