[jira] [Created] (CLOUDSTACK-7952) listSslCerts returns private key
Will Stevens created CLOUDSTACK-7952: Summary: listSslCerts returns private key Key: CLOUDSTACK-7952 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7952 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.6.0 Reporter: Will Stevens The listSslCerts API call returns the private key which has been flagged as a security concern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7952) listSslCerts returns private key
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219137#comment-14219137 ] ASF subversion and git services commented on CLOUDSTACK-7952: - Commit 8ea79020751dffe9f84ab1b17a943bd385f9a50c in cloudstack's branch refs/heads/master from [~sahmed] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8ea7902 ] CLOUDSTACK-7952: Remove private key from SslCertResponse (listSslCerts) Signed-off-by: Will Stevens > listSslCerts returns private key > > > Key: CLOUDSTACK-7952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.6.0 >Reporter: Will Stevens > > The listSslCerts API call returns the private key which has been flagged as a > security concern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7952) listSslCerts returns private key
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219139#comment-14219139 ] Will Stevens commented on CLOUDSTACK-7952: -- Here is the code submitted for review for this issue by Syed: https://reviews.apache.org/r/27464/ > listSslCerts returns private key > > > Key: CLOUDSTACK-7952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.6.0 >Reporter: Will Stevens > > The listSslCerts API call returns the private key which has been flagged as a > security concern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7952) listSslCerts returns private key
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219155#comment-14219155 ] Rohit Yadav commented on CLOUDSTACK-7952: - Can you also backport to at least 4.5, looks like this applies to 4.3 as well? Thanks. > listSslCerts returns private key > > > Key: CLOUDSTACK-7952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.6.0 >Reporter: Will Stevens > > The listSslCerts API call returns the private key which has been flagged as a > security concern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7952) listSslCerts returns private key
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219162#comment-14219162 ] Will Stevens commented on CLOUDSTACK-7952: -- Yes, this applies to all of; 4.3, 4.4, 4.5 and master (which I just fixed). Unfortunately the backports will not have the same commit id, but I can apply the same changes to those branches... > listSslCerts returns private key > > > Key: CLOUDSTACK-7952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.6.0 >Reporter: Will Stevens > > The listSslCerts API call returns the private key which has been flagged as a > security concern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7951) cloudstack-agent jsvc gets too large virtual memory space.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219178#comment-14219178
]
Keiichi Yusa commented on CLOUDSTACK-7951:
--
This is a patch: https://reviews.apache.org/r/28279/
> cloudstack-agent jsvc gets too large virtual memory space.
> --
>
> Key: CLOUDSTACK-7951
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7951
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.3.0
> Environment: - Builds up with 155 physical machines and a cloudstack
> server.
> - Each physical machine equips these.
> + Xeon E5-2680 (10 cores, 20 threads).
> + 128GB memory (and is not set swap space).
> + 600GB Solid State Drive.
> - All physical machines are networked by InfiniBand and 10GBase-T.
> - Using CentOS6.6 (64bit)
>Reporter: Keiichi Yusa
>Priority: Critical
>
> cloudstack-agent jsvc gets too large virtual memory space on huge
> memory equipped machine.
> We have 155 physical machines that each is equipped 128GB RAM and
> is installed CentOS6.6 (64bit). On these physical machines, I use
> KVM as hypervisor.
> I create Compute Offering with 120GB RAM and I deploy VM with this
> Compute Offering on this environment.
> Now, I have a problem that qemu-kvm process often fails deploying VM
> in the above conditions. I confirm that the following message is
> outputted in /var/log/libvirt/qemu/i-X-X-VM.log.
> {noformat}
> "Cannot set up guest memory 'pc.ram': Cannot allocate memory"
> {noformat}
> I find that cloudstack-agent jsvc gets virtual memory about 35GB.
> {noformat}
> $ top -a
> (snip)
>PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 5787 root 20 0 34.9g 667m 18m S 0.0 0.5 8:45.20 jsvc
> (snip)
> {noformat}
>
> I suspect that this failure is caused by what cloudstack-agent jsvc
> gets too large virtual memory.
> I try to patch /etc/init.d/cloudstack-agent as follows:
> {noformat}
> @@ -66,7 +66,7 @@
> start() {
> echo -n $"Starting $PROGNAME: "
> if hostname --fqdn >/dev/null 2>&1 ; then
> -$JSVC -cp "$CLASSPATH" -pidfile "$PIDFILE" \
> +$JSVC -Xms1024m -Xmx2048m -cp "$CLASSPATH" -pidfile "$PIDFILE" \
> -errfile $LOGDIR/cloudstack-agent.err -outfile
> $LOGDIR/cloudstack-agent.out $CLASS
> RETVAL=$?
> echo
> {noformat}
> Then, I restart cloudstack-agent.
> As a result, cloudstack agent jsvc reduces virtual memory about 6GB.
> Also, qemu-kvm process does not fail deploying VM for now.
> {noformat}
> $ top -a
> (snip)
>PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 141405 root 20 0 6290m 393m 18m S 0.0 0.3 1:11.44 jsvc
> (snip)
> {noformat}
> If that helps, our CloudStack environment is as follows:
> {noformat}
> - Builds up with 155 physical machines and a cloudstack server.
> - Each physical machine equips these.
> + Xeon E5-2680 (10 cores, 20 threads)
> + 128GB memory (and is not set swap space).
> + 600GB Solid State Drive.
> - All physical machines are networked by InfiniBand and 10GBase-T.
> - Using CentOS6.6 (64bit)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7412) Can't create proper template from VM on S3 secondary storage environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akihiko Ota updated CLOUDSTACK-7412: Fix Version/s: 4.3.0 > Can't create proper template from VM on S3 secondary storage environment > > > Key: CLOUDSTACK-7412 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7412 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Template >Affects Versions: Future, 4.2.1, 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3.0 on CentOS 6.5. > KVM Hypervisor. > using S3 provider as socondary storage. The storage system is using RADOS. > using local storage as primary storage. >Reporter: Akihiko Ota > Fix For: 4.3.0 > > > When I create more than one templates from an existing virtual machine, the > second and the subsequent template is created the same as first one. > It doesn't occur in the case of using NFS secondary storage. So I guess this > is the S3 provider specific issue. > This could reproduce as following procedure. > (1) create a virtual machine (name "foo" tentatively), and modify some files > on ROOT volume of "foo". > (2) stop "foo". and create template "template-foo.1" from ROOT volume of > "foo". > (3) reboot (not re-create) "foo", and modify some files on ROOT volume again. > (4) stop "foo". and create template "template-foo.2" from ROOT volume of > "foo". > I expect that template-foo.2 keeps (3)'s changes. But template-foo.2 is the > same as template-foo.1. (3)'s changes are not recorded. > As of (4), CloudStack outputs the following DEBUG message to > cloudstack-management.log. > 2014-08-07 19:23:20,094 DEBUG [o.a.c.s.c.m.StorageCacheManagerImpl] > (Job-Executor-58:ctx-b00fbe22 ctx-6339bae6) there is already one in the cache > store > When creating templates on NFS secondary storage environment, this message is > not output. > This issue also exists on CloudStack 4.2.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7412) Can't create proper template from VM on S3 secondary storage environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akihiko Ota updated CLOUDSTACK-7412: Fix Version/s: 4.6.0 4.5.0 4.4.0 > Can't create proper template from VM on S3 secondary storage environment > > > Key: CLOUDSTACK-7412 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7412 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Template >Affects Versions: Future, 4.2.1, 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3.0 on CentOS 6.5. > KVM Hypervisor. > using S3 provider as socondary storage. The storage system is using RADOS. > using local storage as primary storage. >Reporter: Akihiko Ota > Fix For: 4.3.0, 4.4.0, 4.5.0, 4.6.0 > > > When I create more than one templates from an existing virtual machine, the > second and the subsequent template is created the same as first one. > It doesn't occur in the case of using NFS secondary storage. So I guess this > is the S3 provider specific issue. > This could reproduce as following procedure. > (1) create a virtual machine (name "foo" tentatively), and modify some files > on ROOT volume of "foo". > (2) stop "foo". and create template "template-foo.1" from ROOT volume of > "foo". > (3) reboot (not re-create) "foo", and modify some files on ROOT volume again. > (4) stop "foo". and create template "template-foo.2" from ROOT volume of > "foo". > I expect that template-foo.2 keeps (3)'s changes. But template-foo.2 is the > same as template-foo.1. (3)'s changes are not recorded. > As of (4), CloudStack outputs the following DEBUG message to > cloudstack-management.log. > 2014-08-07 19:23:20,094 DEBUG [o.a.c.s.c.m.StorageCacheManagerImpl] > (Job-Executor-58:ctx-b00fbe22 ctx-6339bae6) there is already one in the cache > store > When creating templates on NFS secondary storage environment, this message is > not output. > This issue also exists on CloudStack 4.2.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7539) [S3] Parallel deployment makes reference count of a cache in nfs secondary staging store negative(-1)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiroki Ohashi updated CLOUDSTACK-7539:
--
Fix Version/s: 4.4.3
Futue
4.6.0
4.3.1
4.5.0
> [S3] Parallel deployment makes reference count of a cache in nfs secondary
> staging store negative(-1)
> -
>
> Key: CLOUDSTACK-7539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7539
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, Template
>Affects Versions: Future, 4.3.0, 4.4.0, 4.5.0
> Environment: OS: CentOS 6.5, CloudStack Version: 4.3.0, Hypervisor:
> KVM, Primary Storage: Local Storage, Secondary Storage: S3(RADOS), Zone:
> Advanced
>Reporter: Hiroki Ohashi
>Priority: Critical
> Fix For: 4.5.0, 4.3.1, 4.6.0, Futue, 4.4.3
>
>
> When we create some instances in parallel in an environment shown above, an
> exception like ([#2]) happens. After that, reference count of a cache in NFS
> Secondary Staging Store(SSS) becomes negative([#3]).
> In this situcation, we can't use a template used for creating the instances
> because negative reference count will cause another
> exception([#4]). Furthermore, template caches in NFS SSS aren't cleaned up.
> I think this is related to CLOUDSTACK-6236. I'm using CloudStack 4.3.0
> branch. The code was applied a patch of CLOUDSTACK-6236 to and also fixed
> about volume reference count setter problem by myself. But the reference
> count problem still happens.
> Conditions to trigger
> - A cache of a template isn't on NFS SSS.
> - Choose compute offering that occupies all resources in a host.(ex. Use
> all cores and almost all memory)
> - Create multiple instances ([#1]).
> Other behaviors
> - Management server inserts multiple entries for template cache(ImageCache)
> to cloud.template_store_ref.
> - SSVM probably downloads same template from S3 and creates multiple caches
> to NFS SSS concurrently. Sometimes, SSVM retries download and cache creation.
> (1)
> {anchor:1}
> {noformat}
> #! /bin/bash
> COMPUTE_OFFERING="b6fc0598-6903-48cc-b894-ead3bb0e39f5"
> TEMPLATE="ef1d5a8e-5951-4036-a236-fe2d47224fe4"
> ZONE="23156857-4722-4fc4-86d4-a12ca1028197"
> NETWORK="4ba56179-f7b9-4560-a00e-80c946856ff8"
> KEYPAIR=mykey
> NAME1="test-template-error-0003"
> NAME2="test-template-error-0004"
> cloudmonkey deploy virtualmachine serviceofferingid=${COMPUTE_OFFERING}
> templateid=${TEMPLATE} zoneid=${ZONE} networkids=${NETWORK}
> displayname=${NAME1} name=${NAME1} keypair=${KEYPAIR}
> sleep 1
> cloudmonkey deploy virtualmachine serviceofferingid=${COMPUTE_OFFERING}
> templateid=${TEMPLATE} zoneid=${ZONE} networkids=${NETWORK}
> displayname=${NAME2} name=${NAME2} keypair=${KEYPAIR}
> {noformat}
> (2)
> {anchor:2}
> {noformat}
> 2014-09-10 17:22:51,249 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null)
> Seq 171-1789133096: Processing: { Ans: , MgmtId: 98532524288, via: 171, Ver:
> v1, Flags: 10,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"newData":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/3/330/22e69a40-0916-4d11-a07a-63d38e76887f.qcow2","id":0,"accountId":0,"hvm":false,"name":"22e69a40-0916-4d11-a07a-63d38e76887f.qcow2","size":14340259840,"physicalSize":14340259840}},"result":true,"wait":0}}]
> }
> 2014-09-10 17:22:51,249 DEBUG [c.c.a.t.Request]
> (Job-Executor-162:ctx-4a2eb345 ctx-fbf59f27) Seq 171-1789133096: Received: {
> Ans: , MgmtId: 98532524288, via: 171, Ver: v1, Flags: 10, { CopyCmdAnswer } }
> 2014-09-10 17:22:51,257 DEBUG [o.a.c.s.i.s.TemplateObject]
> (Job-Executor-162:ctx-4a2eb345 ctx-fbf59f27) failed to update state
> com.cloud.utils.fsm.NoTransitionException: Unable to transition to a new
> state from Allocated via OperationSuccessed
> at
> com.cloud.utils.fsm.StateMachine2.getNextState(StateMachine2.java:83)
> at com.cloud.utils.fsm.StateMachine2.transitTo(StateMachine2.java:100)
> at
> org.apache.cloudstack.storage.datastore.ObjectInDataStoreManagerImpl.update(ObjectInDataStoreManagerImpl.java:297)
> at
> org.apache.cloudstack.storage.image.store.TemplateObject.processEvent(TemplateObject.java:225)
> at
> org.apache.cloudstack.storage.cache.manager.StorageCacheManagerImpl.createCacheObject(StorageCacheManagerImpl.java:240)
> at
> org.apache.cloudstack.storage.cache.manager.StorageCacheManagerImpl.createCacheObject(StorageCacheManagerImpl.java:267)
> at
> org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyObject(AncientDataMotionStrategy.ja
[jira] [Updated] (CLOUDSTACK-7412) Can't create proper template from VM on S3 secondary storage environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akihiko Ota updated CLOUDSTACK-7412: Fix Version/s: Future > Can't create proper template from VM on S3 secondary storage environment > > > Key: CLOUDSTACK-7412 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7412 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Template >Affects Versions: Future, 4.2.1, 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3.0 on CentOS 6.5. > KVM Hypervisor. > using S3 provider as socondary storage. The storage system is using RADOS. > using local storage as primary storage. >Reporter: Akihiko Ota > Fix For: Future, 4.3.0, 4.4.0, 4.5.0, 4.6.0 > > > When I create more than one templates from an existing virtual machine, the > second and the subsequent template is created the same as first one. > It doesn't occur in the case of using NFS secondary storage. So I guess this > is the S3 provider specific issue. > This could reproduce as following procedure. > (1) create a virtual machine (name "foo" tentatively), and modify some files > on ROOT volume of "foo". > (2) stop "foo". and create template "template-foo.1" from ROOT volume of > "foo". > (3) reboot (not re-create) "foo", and modify some files on ROOT volume again. > (4) stop "foo". and create template "template-foo.2" from ROOT volume of > "foo". > I expect that template-foo.2 keeps (3)'s changes. But template-foo.2 is the > same as template-foo.1. (3)'s changes are not recorded. > As of (4), CloudStack outputs the following DEBUG message to > cloudstack-management.log. > 2014-08-07 19:23:20,094 DEBUG [o.a.c.s.c.m.StorageCacheManagerImpl] > (Job-Executor-58:ctx-b00fbe22 ctx-6339bae6) there is already one in the cache > store > When creating templates on NFS secondary storage environment, this message is > not output. > This issue also exists on CloudStack 4.2.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7953) test_snapshot_limits.TestSnapshotLimit.test_04_snapshot_limit failed with "Check list response returns a valid list"
Ashutosk Kelkar created CLOUDSTACK-7953: --- Summary: test_snapshot_limits.TestSnapshotLimit.test_04_snapshot_limit failed with "Check list response returns a valid list" Key: CLOUDSTACK-7953 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7953 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Fix For: 4.5.0 The test case failed because of faulty wait period for checking snapshots created by snapshot policy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7952) listSslCerts returns private key
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Stevens updated CLOUDSTACK-7952: - Fix Version/s: 4.6.0 > listSslCerts returns private key > > > Key: CLOUDSTACK-7952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.6.0 >Reporter: Will Stevens > Fix For: 4.6.0 > > > The listSslCerts API call returns the private key which has been flagged as a > security concern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7822) test SSL cert expired
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219396#comment-14219396
]
ASF subversion and git services commented on CLOUDSTACK-7822:
-
Commit 9258b8350e934c5e23ebdfaa9899f13d28cdf997 in cloudstack's branch
refs/heads/4.3 from [~wstevens]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9258b83 ]
CLOUDSTACK-7822: Fixed SSL Cert Tests and relaxed chain validation
(cherry picked from commit 92d4a41a69da34b0b6f435f95fd959e2110b662c)
Signed-off-by: Rohit Yadav
Conflicts:
server/test/org/apache/cloudstack/network/lb/CertServiceTest.java
server/test/resources/certs/root_chain.crt
server/test/resources/certs/root_chain.key
server/test/resources/certs/rsa_ca_signed2.crt
(cherry picked from commit 9c0c4f713f95e5fa228a8b22c51a0f59e5f8a9d1)
Signed-off-by: Rohit Yadav
Conflicts:
server/src/org/apache/cloudstack/network/lb/CertServiceImpl.java
server/test/org/apache/cloudstack/network/lb/CertServiceTest.java
server/test/resources/certs/rsa_ca_signed.crt
server/test/resources/certs/rsa_ca_signed.key
server/test/resources/certs/rsa_self_signed.crt
server/test/resources/certs/rsa_self_signed.key
server/test/resources/certs/rsa_self_signed_with_pwd.crt
server/test/resources/certs/rsa_self_signed_with_pwd.key
> test SSL cert expired
> -
>
> Key: CLOUDSTACK-7822
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7822
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Test
>Affects Versions: 4.4.0, 4.5.0, 4.4.1
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Minor
> Fix For: Future, 4.5.0
>
>
> Building from source (apache-cloudstack-4.4.1-src.tar.bz2) fail to build
> using {{mvn install}} or package.sh due to test ssl cert that are expired.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-3383) GetHostStatsCommand fails when agent is running Ubuntu 13.04 (raring)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219398#comment-14219398
]
ASF subversion and git services commented on CLOUDSTACK-3383:
-
Commit 5cd0d258126a1ce78113c09c5e1ebe832110f2ee in cloudstack's branch
refs/heads/4.3 from [~widodh]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5cd0d25 ]
CLOUDSTACK-3383: Fetch CPU utilization more reliable.
This should fix that we can't gather CPU statistics on hypervisors
> Ubuntu 12.04
(cherry picked from commit 69ee01af9df8d72ccd8901d146726e74edda95d7)
Signed-off-by: Rohit Yadav
Conflicts:
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
> GetHostStatsCommand fails when agent is running Ubuntu 13.04 (raring)
> -
>
> Key: CLOUDSTACK-3383
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3383
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.1.0
> Environment: Ubuntu 13.04
>Reporter: Harm van Tilborg
>Assignee: Wido den Hollander
> Labels: agent, kvm, libvirt
> Attachments: ubuntu14-usage-stats.patch
>
>
> 2013-07-05 13:02:37,782 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Processing command:
> com.cloud.agent.api.GetHostStatsCommand
> 2013-07-05 13:02:37,782 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Executing: /bin/bash -c idle=$(top -b -n 1|grep
> Cpu\(s\):|cut -d% -f4|cut -d, -f2);echo $idle
> 2013-07-05 13:02:37,940 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Execution is successful.
> 2013-07-05 13:02:37,941 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Seq 1-2144469000: { Ans: , MgmtId:
> 159497075554, via: 1, Ver: v1, Flags: 10,
> [{"Answer":{"result":false,"details":"empty String","wait":0}}] }
> When I check the output of Ubuntu's 13.04 top (top -v = procps-ng version
> 3.3.3), it's formatted like this:
> raring# top -b -n 1|grep Cpu\(s\):
> %Cpu(s): 0.2 us, 0.2 sy, 0.0 ni, 99.5 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0
> st
> While on Ubuntu 12.04 (top -v = procps version 3.2.8) it looks like this:
> precise# top -b -n 1|grep Cpu\(s\):
> Cpu(s): 0.3%us, 0.1%sy, 0.0%ni, 99.6%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
> So I believe it is better to split the string on a comma (,) than using the
> percentage (%).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7952) listSslCerts returns private key
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219397#comment-14219397 ] ASF subversion and git services commented on CLOUDSTACK-7952: - Commit 56d8b173a0910d73a292fac2405d8c1f3dc1d37a in cloudstack's branch refs/heads/4.3 from [~sahmed] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=56d8b17 ] CLOUDSTACK-7952: Remove private key from SslCertResponse (listSslCerts) Signed-off-by: Will Stevens (cherry picked from commit 8ea79020751dffe9f84ab1b17a943bd385f9a50c) Signed-off-by: Rohit Yadav > listSslCerts returns private key > > > Key: CLOUDSTACK-7952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.6.0 >Reporter: Will Stevens > Fix For: 4.6.0 > > > The listSslCerts API call returns the private key which has been flagged as a > security concern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7936) System VM's are getting stuck in starting mode after Hypervisor reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dusan Batas updated CLOUDSTACK-7936: Affects Version/s: (was: 4.1.1) 4.4.1 > System VM's are getting stuck in starting mode after Hypervisor reboot > -- > > Key: CLOUDSTACK-7936 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7936 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.1 > Environment: Xenserver 6.2 SP1, Cloudstack 4.4.1 on CentOS 6.4 > (x86_64) >Reporter: Dusan Batas > Labels: build > > once a Xenserver 6.2 (running system VMs) gets rebooted, Infrastructure -> > Sytem VMs will show "VM State=Starting" and "Agent State=Disconnected". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7952) listSslCerts returns private key
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219449#comment-14219449 ] ASF subversion and git services commented on CLOUDSTACK-7952: - Commit 9f83a4d43b36306c9c9ea231c1b25db40d616691 in cloudstack's branch refs/heads/hotfix/4.4-7952 from [~sahmed] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9f83a4d ] CLOUDSTACK-7952: Remove private key from SslCertResponse (listSslCerts) Signed-off-by: Will Stevens > listSslCerts returns private key > > > Key: CLOUDSTACK-7952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.6.0 >Reporter: Will Stevens > Fix For: 4.6.0 > > > The listSslCerts API call returns the private key which has been flagged as a > security concern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7952) listSslCerts returns private key
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219457#comment-14219457 ] ASF subversion and git services commented on CLOUDSTACK-7952: - Commit 9f83a4d43b36306c9c9ea231c1b25db40d616691 in cloudstack's branch refs/heads/4.4 from [~sahmed] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9f83a4d ] CLOUDSTACK-7952: Remove private key from SslCertResponse (listSslCerts) Signed-off-by: Will Stevens > listSslCerts returns private key > > > Key: CLOUDSTACK-7952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.6.0 >Reporter: Will Stevens > Fix For: 4.6.0 > > > The listSslCerts API call returns the private key which has been flagged as a > security concern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7952) listSslCerts returns private key
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219486#comment-14219486 ] Rohit Yadav commented on CLOUDSTACK-7952: - Thanks Will, I went ahead and backported your fix for 4.3. Let me know if there are more, I can help backport them. > listSslCerts returns private key > > > Key: CLOUDSTACK-7952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.6.0 >Reporter: Will Stevens > Fix For: 4.6.0 > > > The listSslCerts API call returns the private key which has been flagged as a > security concern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7952) listSslCerts returns private key
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219489#comment-14219489 ] ASF subversion and git services commented on CLOUDSTACK-7952: - Commit b846bbe2624b2ab0e21c75545a75258760618c89 in cloudstack's branch refs/heads/hotfix/4.5-7952 from [~sahmed] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b846bbe ] CLOUDSTACK-7952: Remove private key from SslCertResponse (listSslCerts) Signed-off-by: Will Stevens > listSslCerts returns private key > > > Key: CLOUDSTACK-7952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.6.0 >Reporter: Will Stevens > Fix For: 4.6.0 > > > The listSslCerts API call returns the private key which has been flagged as a > security concern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7952) listSslCerts returns private key
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Stevens updated CLOUDSTACK-7952: - Fix Version/s: 4.4.0 4.3.0 > listSslCerts returns private key > > > Key: CLOUDSTACK-7952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.6.0 >Reporter: Will Stevens > Fix For: 4.3.0, 4.4.0, 4.6.0 > > > The listSslCerts API call returns the private key which has been flagged as a > security concern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7703) Cloudstack server endless loop when trying to create a volume while storage pool is full
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219501#comment-14219501 ] Rohit Yadav commented on CLOUDSTACK-7703: - Hi [~anshulg], can you also help backport this fix for 4.3 branch? Thanks. > Cloudstack server endless loop when trying to create a volume while storage > pool is full > > > Key: CLOUDSTACK-7703 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7703 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Centos 6.5 >Reporter: JF Vincent >Assignee: Anshul Gangwar >Priority: Critical > Fix For: 4.5.0 > > > When trying to create a VM, and thus a volume for it and the primary storage > is full (over 90%), the managament server enter in and endless loop (extract > below) and we have to restart it to exit this loop. > 2014-10-14 11:39:20,701 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found for > volume: Vol[5436|vm=5855|DATADISK] under cluster: 2 > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable storagePools found > under this Cluster: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Could not find suitable > Deployment Destination for this VM under any clusters, returning. > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Searching all possible resources > under this Zone: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Listing clusters in order of > aggregate capacity, that have (atleast one host with) enough CPU and RAM > capacity under this Zone: 2 > 2014-10-14 11:39:20,707 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Removing from the clusterId list > these clusters from avoid set: [] > 2014-10-14 11:39:20,714 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Checking resources in Cluster: 2 > under Pod: 2 > 2014-10-14 11:39:20,714 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for hosts in dc: 2 pod:2 cluster:2 > 2014-10-14 11:39:20,716 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) > FirstFitAllocator has 3 hosts to check for allocation: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Found 3 > hosts for allocation after prioritization: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for speed=500Mhz, Ram=500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host: 79 > has cpu capability (cpu:8, speed:2399) to support requested CPU: 1 and > requested speed: 500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Checking > if host: 79 has enough capacity for requested CPU: 500 and requested RAM: > 524288000 , cpuOverprovisioningFactor: 4.0 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Hosts's > actual total CPU: 19192 and CPU after applying overprovisioning: 76768 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > CPU: 57268 , Requested CPU: 500 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > RAM: 93916725248 , Requested RAM: 524288000 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host has > enough CPU and RAM available > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManager
[jira] [Updated] (CLOUDSTACK-7887) fail to push snapshot to secondary storage if using multipart using swift
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7887: Fix Version/s: 4.4.2 > fail to push snapshot to secondary storage if using multipart using swift > - > > Key: CLOUDSTACK-7887 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7887 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, XenServer >Affects Versions: 4.4.0, 4.4.1 >Reporter: Pierre-Luc Dion >Assignee: Pierre-Luc Dion > Fix For: 4.5.0, 4.4.2 > > > Using Swift as secondary storage with XenServer, creating a snapshot from a > big disk will display as succeed in CloudStack but the snapshot file will > fail to upload in Swift. So snapshot are not working for Swift with > XenServer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7822) test SSL cert expired
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre-Luc Dion updated CLOUDSTACK-7822:
Fix Version/s: 4.4.2
> test SSL cert expired
> -
>
> Key: CLOUDSTACK-7822
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7822
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Test
>Affects Versions: 4.4.0, 4.5.0, 4.4.1
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Minor
> Fix For: Future, 4.5.0, 4.4.2
>
>
> Building from source (apache-cloudstack-4.4.1-src.tar.bz2) fail to build
> using {{mvn install}} or package.sh due to test ssl cert that are expired.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7722) add.label: Add button for tags show the label not "Add" text
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7722: Fix Version/s: 4.4.2 > add.label: Add button for tags show the label not "Add" text > > > Key: CLOUDSTACK-7722 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7722 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.4.0, 4.4.1 >Reporter: Pierre-Luc Dion >Priority: Trivial > Fix For: 4.5.0, 4.4.2 > > > on every language, all sections the "Add" button display "add.label" instead > of "Add" on the button of the UI. > example: at the bottom of the page for a selected template in tags section. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7952) listSslCerts returns private key
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Stevens updated CLOUDSTACK-7952: - Affects Version/s: (was: 4.6.0) Fix Version/s: (was: 4.6.0) (was: 4.4.0) (was: 4.3.0) 4.4.2 Future Assignee: Will Stevens > listSslCerts returns private key > > > Key: CLOUDSTACK-7952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.5.0 >Reporter: Will Stevens >Assignee: Will Stevens > Fix For: Future, 4.4.2 > > > The listSslCerts API call returns the private key which has been flagged as a > security concern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7822) test SSL cert expired
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre-Luc Dion resolved CLOUDSTACK-7822.
-
Resolution: Fixed
> test SSL cert expired
> -
>
> Key: CLOUDSTACK-7822
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7822
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Test
>Affects Versions: 4.4.0, 4.5.0, 4.4.1
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Minor
> Fix For: Future, 4.5.0, 4.4.2
>
>
> Building from source (apache-cloudstack-4.4.1-src.tar.bz2) fail to build
> using {{mvn install}} or package.sh due to test ssl cert that are expired.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7822) test SSL cert expired
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219578#comment-14219578
]
ASF subversion and git services commented on CLOUDSTACK-7822:
-
Commit 5ac9f2dc5b1f623e57cdee470218540d654a9a3d in cloudstack's branch
refs/heads/hotfix/4.5-7822 from [~wstevens]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5ac9f2d ]
CLOUDSTACK-7822: Fixed SSL Cert Tests and relaxed chain validation
Signed-off-by: Will Stevens
> test SSL cert expired
> -
>
> Key: CLOUDSTACK-7822
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7822
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Test
>Affects Versions: 4.4.0, 4.5.0, 4.4.1
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Minor
> Fix For: Future, 4.5.0, 4.4.2
>
>
> Building from source (apache-cloudstack-4.4.1-src.tar.bz2) fail to build
> using {{mvn install}} or package.sh due to test ssl cert that are expired.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7752) Management Server goes in infinite loop while creating a vm with tagged local data disk when the pool is not tagged
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7752: Fix Version/s: 4.4.2 > Management Server goes in infinite loop while creating a vm with tagged local > data disk when the pool is not tagged > --- > > Key: CLOUDSTACK-7752 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7752 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar >Priority: Critical > Fix For: 4.4.2 > > > Steps to reproduce: > Setup must have a single cluster with both local and shared storage. > 1) Create a local disk offering and tag it T1 > 2) Deploy vm with shared root disk and local data disk > Management server goes in an infinite loop. The vm is never started/expunged. > Also this causes vmops.log size to go very high. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-3383) GetHostStatsCommand fails when agent is running Ubuntu 13.04 (raring)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219586#comment-14219586
]
Pierre-Luc Dion commented on CLOUDSTACK-3383:
-
Hi Wido, does this get fixed in 4.4.2 since their is commit in 4.4 branch?
thanks
> GetHostStatsCommand fails when agent is running Ubuntu 13.04 (raring)
> -
>
> Key: CLOUDSTACK-3383
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3383
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.1.0
> Environment: Ubuntu 13.04
>Reporter: Harm van Tilborg
>Assignee: Wido den Hollander
> Labels: agent, kvm, libvirt
> Attachments: ubuntu14-usage-stats.patch
>
>
> 2013-07-05 13:02:37,782 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Processing command:
> com.cloud.agent.api.GetHostStatsCommand
> 2013-07-05 13:02:37,782 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Executing: /bin/bash -c idle=$(top -b -n 1|grep
> Cpu\(s\):|cut -d% -f4|cut -d, -f2);echo $idle
> 2013-07-05 13:02:37,940 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Execution is successful.
> 2013-07-05 13:02:37,941 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Seq 1-2144469000: { Ans: , MgmtId:
> 159497075554, via: 1, Ver: v1, Flags: 10,
> [{"Answer":{"result":false,"details":"empty String","wait":0}}] }
> When I check the output of Ubuntu's 13.04 top (top -v = procps-ng version
> 3.3.3), it's formatted like this:
> raring# top -b -n 1|grep Cpu\(s\):
> %Cpu(s): 0.2 us, 0.2 sy, 0.0 ni, 99.5 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0
> st
> While on Ubuntu 12.04 (top -v = procps version 3.2.8) it looks like this:
> precise# top -b -n 1|grep Cpu\(s\):
> Cpu(s): 0.3%us, 0.1%sy, 0.0%ni, 99.6%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
> So I believe it is better to split the string on a comma (,) than using the
> percentage (%).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7883) Allow infrastructure to handle delete of volume from DB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7883: Fix Version/s: (was: 4.4.1) 4.4.2 > Allow infrastructure to handle delete of volume from DB > --- > > Key: CLOUDSTACK-7883 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7883 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.4.1 > Environment: N/A >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.4.2 > > > To do this, remove this line (from SolidfirePrimaryDataStoreDriver): > _volumeDao.deleteVolumesByInstance(volumeInfo.getId()); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7246) VM deployment failed due to wrong in script name createipalias.sh
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7246: Fix Version/s: 4.4.2 > VM deployment failed due to wrong in script name createipalias.sh > -- > > Key: CLOUDSTACK-7246 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7246 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.5.0 >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Labels: DEVREV > Fix For: 4.5.0, 4.4.2 > > > 1. added multiple ip range. > 2. deployed vm in shared network failed. > 3. createipalias failed because cloudstack referring 'createipalias.sh' but > the file in VR is 'createIpAlias.sh' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7826) UI - dialog widget - dependent dropdown field (dependsOn property specified) - fix a bug that default opton in dependent dropdown field didn't trigger change event h
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7826: Fix Version/s: 4.4.2 > UI - dialog widget - dependent dropdown field (dependsOn property specified) > - fix a bug that default opton in dependent dropdown field didn't trigger > change event handler until another option in dependent dropdown field was > selected. > -- > > Key: CLOUDSTACK-7826 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7826 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.5.0, 4.4.2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7871) Fix update VirtualMachine/Template API to allow nic/disk controller details for VMWare VMs/Templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7871: Fix Version/s: 4.4.2 4.5.0 > Fix update VirtualMachine/Template API to allow nic/disk controller details > for VMWare VMs/Templates > > > Key: CLOUDSTACK-7871 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7871 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0, 4.5.0, 4.3.1, 4.4.1 >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.5.0, 4.4.2 > > > In case of VMWare, when we register a new template we can pass in nic type > and disk controller but there is no API (or parameter passable to current > APIs) to change nic type and disk controller for both VM and template. The > fix is that we add a details map type to the updateTemplate and > updateVirtualMachine API which updates the nic/disk controller values in the > database. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7855) Sec storage/network MTU should be on nic3 and not nic1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7855: Fix Version/s: 4.4.2 > Sec storage/network MTU should be on nic3 and not nic1 > -- > > Key: CLOUDSTACK-7855 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7855 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.3.1, 4.4.1 >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.5.0, 4.4.2 > > > In cloud-early-config, the nic3 on ssvm should have MTU set and not nic1, the > MTU is defined by a global settings variable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7954) ListTags API is ignoring the resourceID and displaying all the tags of all resources
Min Chen created CLOUDSTACK-7954:
Summary: ListTags API is ignoring the resourceID and displaying
all the tags of all resources
Key: CLOUDSTACK-7954
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7954
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: API
Affects Versions: 4.2.0
Reporter: Min Chen
Fix For: 4.5.0
Steps to reproduce:
Deployed First VM
Created three resource tags on the First VM
On Clicking on the first VM:
{code}
http://localhost:8080/client/api?command=listTags&response=json&sessionkey=lja4Hf9zlnMFiMwNl6L8g1TFpok%3D&resourceId=e22ae536-4711-4570-b4fa-834179e6bc1b&resourceType=UserVm&listAll=true&_=1416009164305
{ "listtagsresponse" : { "count":3 ,"tag" : [
{"key":"description","value":"puppetdb","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
{"key":"group","value":"ops","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
{"key":"owner","value":"klaemm","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"}
] } }
{code}
Deployed Second VM
Created two more resource tags on the newly deployed VM
On Clicking on the Second VM:
{code}
http://localhost:8080/client/api?command=listTags&response=json&sessionkey=lja4Hf9zlnMFiMwNl6L8g1TFpok%3D&resourceId=3cd7d704-580d-4f5b-8155-684da7237502&resourceType=UserVm&listAll=true&_=1416009422177
{ "listtagsresponse" : { "count":5 ,"tag" : [
{"key":"description","value":"puppetdb","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
{"key":"group","value":"ops","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
{"key":"owner","value":"klaemm","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
{"key":"parrot","value":"bird","resourcetype":"UserVm","resourceid":"3cd7d704-580d-4f5b-8155-684da7237502","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
{"key":"elephant","value":"animal","resourcetype":"UserVm","resourceid":"3cd7d704-580d-4f5b-8155-684da7237502","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"}
] } }
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7954) ListTags API is ignoring the resourceID and displaying all the tags of all resources
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen reassigned CLOUDSTACK-7954:
Assignee: Min Chen
> ListTags API is ignoring the resourceID and displaying all the tags of all
> resources
>
>
> Key: CLOUDSTACK-7954
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7954
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.2.0
>Reporter: Min Chen
>Assignee: Min Chen
> Fix For: 4.5.0
>
>
>
> Steps to reproduce:
>
> Deployed First VM
> Created three resource tags on the First VM
> On Clicking on the first VM:
> {code}
> http://localhost:8080/client/api?command=listTags&response=json&sessionkey=lja4Hf9zlnMFiMwNl6L8g1TFpok%3D&resourceId=e22ae536-4711-4570-b4fa-834179e6bc1b&resourceType=UserVm&listAll=true&_=1416009164305
> { "listtagsresponse" : { "count":3 ,"tag" : [
> {"key":"description","value":"puppetdb","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"group","value":"ops","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"owner","value":"klaemm","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"}
> ] } }
> {code}
> Deployed Second VM
> Created two more resource tags on the newly deployed VM
> On Clicking on the Second VM:
> {code}
> http://localhost:8080/client/api?command=listTags&response=json&sessionkey=lja4Hf9zlnMFiMwNl6L8g1TFpok%3D&resourceId=3cd7d704-580d-4f5b-8155-684da7237502&resourceType=UserVm&listAll=true&_=1416009422177
> { "listtagsresponse" : { "count":5 ,"tag" : [
> {"key":"description","value":"puppetdb","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"group","value":"ops","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"owner","value":"klaemm","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"parrot","value":"bird","resourcetype":"UserVm","resourceid":"3cd7d704-580d-4f5b-8155-684da7237502","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"elephant","value":"animal","resourcetype":"UserVm","resourceid":"3cd7d704-580d-4f5b-8155-684da7237502","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"}
> ] } }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3383) GetHostStatsCommand fails when agent is running Ubuntu 13.04 (raring)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wido den Hollander updated CLOUDSTACK-3383:
---
Fix Version/s: 4.4.2
4.6.0
4.5.0
> GetHostStatsCommand fails when agent is running Ubuntu 13.04 (raring)
> -
>
> Key: CLOUDSTACK-3383
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3383
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.1.0
> Environment: Ubuntu 13.04
>Reporter: Harm van Tilborg
>Assignee: Wido den Hollander
> Labels: agent, kvm, libvirt
> Fix For: 4.5.0, 4.6.0, 4.4.2
>
> Attachments: ubuntu14-usage-stats.patch
>
>
> 2013-07-05 13:02:37,782 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Processing command:
> com.cloud.agent.api.GetHostStatsCommand
> 2013-07-05 13:02:37,782 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Executing: /bin/bash -c idle=$(top -b -n 1|grep
> Cpu\(s\):|cut -d% -f4|cut -d, -f2);echo $idle
> 2013-07-05 13:02:37,940 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Execution is successful.
> 2013-07-05 13:02:37,941 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Seq 1-2144469000: { Ans: , MgmtId:
> 159497075554, via: 1, Ver: v1, Flags: 10,
> [{"Answer":{"result":false,"details":"empty String","wait":0}}] }
> When I check the output of Ubuntu's 13.04 top (top -v = procps-ng version
> 3.3.3), it's formatted like this:
> raring# top -b -n 1|grep Cpu\(s\):
> %Cpu(s): 0.2 us, 0.2 sy, 0.0 ni, 99.5 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0
> st
> While on Ubuntu 12.04 (top -v = procps version 3.2.8) it looks like this:
> precise# top -b -n 1|grep Cpu\(s\):
> Cpu(s): 0.3%us, 0.1%sy, 0.0%ni, 99.6%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
> So I believe it is better to split the string on a comma (,) than using the
> percentage (%).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-3383) GetHostStatsCommand fails when agent is running Ubuntu 13.04 (raring)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219644#comment-14219644
]
Wido den Hollander commented on CLOUDSTACK-3383:
Yes, it will be in 4.4.2. Rohit also pulled it to 4.3.2
> GetHostStatsCommand fails when agent is running Ubuntu 13.04 (raring)
> -
>
> Key: CLOUDSTACK-3383
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3383
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.1.0
> Environment: Ubuntu 13.04
>Reporter: Harm van Tilborg
>Assignee: Wido den Hollander
> Labels: agent, kvm, libvirt
> Attachments: ubuntu14-usage-stats.patch
>
>
> 2013-07-05 13:02:37,782 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Processing command:
> com.cloud.agent.api.GetHostStatsCommand
> 2013-07-05 13:02:37,782 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Executing: /bin/bash -c idle=$(top -b -n 1|grep
> Cpu\(s\):|cut -d% -f4|cut -d, -f2);echo $idle
> 2013-07-05 13:02:37,940 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Execution is successful.
> 2013-07-05 13:02:37,941 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Seq 1-2144469000: { Ans: , MgmtId:
> 159497075554, via: 1, Ver: v1, Flags: 10,
> [{"Answer":{"result":false,"details":"empty String","wait":0}}] }
> When I check the output of Ubuntu's 13.04 top (top -v = procps-ng version
> 3.3.3), it's formatted like this:
> raring# top -b -n 1|grep Cpu\(s\):
> %Cpu(s): 0.2 us, 0.2 sy, 0.0 ni, 99.5 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0
> st
> While on Ubuntu 12.04 (top -v = procps version 3.2.8) it looks like this:
> precise# top -b -n 1|grep Cpu\(s\):
> Cpu(s): 0.3%us, 0.1%sy, 0.0%ni, 99.6%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
> So I believe it is better to split the string on a comma (,) than using the
> percentage (%).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7954) ListTags API is ignoring the resourceID and displaying all the tags of all resources
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219657#comment-14219657
]
ASF subversion and git services commented on CLOUDSTACK-7954:
-
Commit 5fa7801b20f3ffb4fe0ae0380167873dfbc346ba in cloudstack's branch
refs/heads/master from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5fa7801 ]
CLOUDSTACK-7954:ListTags API is ignoring the resourceID and displaying
all the tags of all resources.
> ListTags API is ignoring the resourceID and displaying all the tags of all
> resources
>
>
> Key: CLOUDSTACK-7954
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7954
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.2.0
>Reporter: Min Chen
>Assignee: Min Chen
> Fix For: 4.5.0
>
>
>
> Steps to reproduce:
>
> Deployed First VM
> Created three resource tags on the First VM
> On Clicking on the first VM:
> {code}
> http://localhost:8080/client/api?command=listTags&response=json&sessionkey=lja4Hf9zlnMFiMwNl6L8g1TFpok%3D&resourceId=e22ae536-4711-4570-b4fa-834179e6bc1b&resourceType=UserVm&listAll=true&_=1416009164305
> { "listtagsresponse" : { "count":3 ,"tag" : [
> {"key":"description","value":"puppetdb","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"group","value":"ops","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"owner","value":"klaemm","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"}
> ] } }
> {code}
> Deployed Second VM
> Created two more resource tags on the newly deployed VM
> On Clicking on the Second VM:
> {code}
> http://localhost:8080/client/api?command=listTags&response=json&sessionkey=lja4Hf9zlnMFiMwNl6L8g1TFpok%3D&resourceId=3cd7d704-580d-4f5b-8155-684da7237502&resourceType=UserVm&listAll=true&_=1416009422177
> { "listtagsresponse" : { "count":5 ,"tag" : [
> {"key":"description","value":"puppetdb","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"group","value":"ops","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"owner","value":"klaemm","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"parrot","value":"bird","resourcetype":"UserVm","resourceid":"3cd7d704-580d-4f5b-8155-684da7237502","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"elephant","value":"animal","resourcetype":"UserVm","resourceid":"3cd7d704-580d-4f5b-8155-684da7237502","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"}
> ] } }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7954) ListTags API is ignoring the resourceID and displaying all the tags of all resources
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219672#comment-14219672
]
ASF subversion and git services commented on CLOUDSTACK-7954:
-
Commit 66e0f049db0a996476a2e6bbf3dd9041ef1ace1a in cloudstack's branch
refs/heads/4.5 from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=66e0f04 ]
CLOUDSTACK-7954:ListTags API is ignoring the resourceID and displaying
all the tags of all resources.
> ListTags API is ignoring the resourceID and displaying all the tags of all
> resources
>
>
> Key: CLOUDSTACK-7954
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7954
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.2.0
>Reporter: Min Chen
>Assignee: Min Chen
> Fix For: 4.5.0
>
>
>
> Steps to reproduce:
>
> Deployed First VM
> Created three resource tags on the First VM
> On Clicking on the first VM:
> {code}
> http://localhost:8080/client/api?command=listTags&response=json&sessionkey=lja4Hf9zlnMFiMwNl6L8g1TFpok%3D&resourceId=e22ae536-4711-4570-b4fa-834179e6bc1b&resourceType=UserVm&listAll=true&_=1416009164305
> { "listtagsresponse" : { "count":3 ,"tag" : [
> {"key":"description","value":"puppetdb","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"group","value":"ops","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"owner","value":"klaemm","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"}
> ] } }
> {code}
> Deployed Second VM
> Created two more resource tags on the newly deployed VM
> On Clicking on the Second VM:
> {code}
> http://localhost:8080/client/api?command=listTags&response=json&sessionkey=lja4Hf9zlnMFiMwNl6L8g1TFpok%3D&resourceId=3cd7d704-580d-4f5b-8155-684da7237502&resourceType=UserVm&listAll=true&_=1416009422177
> { "listtagsresponse" : { "count":5 ,"tag" : [
> {"key":"description","value":"puppetdb","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"group","value":"ops","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"owner","value":"klaemm","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"parrot","value":"bird","resourcetype":"UserVm","resourceid":"3cd7d704-580d-4f5b-8155-684da7237502","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"elephant","value":"animal","resourcetype":"UserVm","resourceid":"3cd7d704-580d-4f5b-8155-684da7237502","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"}
> ] } }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7954) ListTags API is ignoring the resourceID and displaying all the tags of all resources
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-7954.
--
Resolution: Fixed
Failed in mySQL executing search criteria resource_tag_view.resource_id =
or resource_tag_view.resource_uuid = . If
passed is UUID string, MySQL is trying to take its long prefix to match with
resource_tag_view.resource_id, thus causing the error.
> ListTags API is ignoring the resourceID and displaying all the tags of all
> resources
>
>
> Key: CLOUDSTACK-7954
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7954
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.2.0
>Reporter: Min Chen
>Assignee: Min Chen
> Fix For: 4.5.0
>
>
>
> Steps to reproduce:
>
> Deployed First VM
> Created three resource tags on the First VM
> On Clicking on the first VM:
> {code}
> http://localhost:8080/client/api?command=listTags&response=json&sessionkey=lja4Hf9zlnMFiMwNl6L8g1TFpok%3D&resourceId=e22ae536-4711-4570-b4fa-834179e6bc1b&resourceType=UserVm&listAll=true&_=1416009164305
> { "listtagsresponse" : { "count":3 ,"tag" : [
> {"key":"description","value":"puppetdb","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"group","value":"ops","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"owner","value":"klaemm","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"}
> ] } }
> {code}
> Deployed Second VM
> Created two more resource tags on the newly deployed VM
> On Clicking on the Second VM:
> {code}
> http://localhost:8080/client/api?command=listTags&response=json&sessionkey=lja4Hf9zlnMFiMwNl6L8g1TFpok%3D&resourceId=3cd7d704-580d-4f5b-8155-684da7237502&resourceType=UserVm&listAll=true&_=1416009422177
> { "listtagsresponse" : { "count":5 ,"tag" : [
> {"key":"description","value":"puppetdb","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"group","value":"ops","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"owner","value":"klaemm","resourcetype":"UserVm","resourceid":"e22ae536-4711-4570-b4fa-834179e6bc1b","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"parrot","value":"bird","resourcetype":"UserVm","resourceid":"3cd7d704-580d-4f5b-8155-684da7237502","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"},
>
> {"key":"elephant","value":"animal","resourcetype":"UserVm","resourceid":"3cd7d704-580d-4f5b-8155-684da7237502","account":"atoms","domainid":"96ce6f7e-142b-11e4-a917-06e27a00073f","domain":"ROOT"}
> ] } }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7951) cloudstack-agent jsvc gets too large virtual memory space.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219705#comment-14219705
]
ASF subversion and git services commented on CLOUDSTACK-7951:
-
Commit 1d6ca5eacb1725cc8485c4564aaf7332682ab5b2 in cloudstack's branch
refs/heads/4.5 from [~yusa]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1d6ca5e ]
CLOUDSTACK-7951
Limit amount of memory used by cloudstack-agent jsvc.
Signed-off-by: Edison Su
> cloudstack-agent jsvc gets too large virtual memory space.
> --
>
> Key: CLOUDSTACK-7951
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7951
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.3.0
> Environment: - Builds up with 155 physical machines and a cloudstack
> server.
> - Each physical machine equips these.
> + Xeon E5-2680 (10 cores, 20 threads).
> + 128GB memory (and is not set swap space).
> + 600GB Solid State Drive.
> - All physical machines are networked by InfiniBand and 10GBase-T.
> - Using CentOS6.6 (64bit)
>Reporter: Keiichi Yusa
>Priority: Critical
>
> cloudstack-agent jsvc gets too large virtual memory space on huge
> memory equipped machine.
> We have 155 physical machines that each is equipped 128GB RAM and
> is installed CentOS6.6 (64bit). On these physical machines, I use
> KVM as hypervisor.
> I create Compute Offering with 120GB RAM and I deploy VM with this
> Compute Offering on this environment.
> Now, I have a problem that qemu-kvm process often fails deploying VM
> in the above conditions. I confirm that the following message is
> outputted in /var/log/libvirt/qemu/i-X-X-VM.log.
> {noformat}
> "Cannot set up guest memory 'pc.ram': Cannot allocate memory"
> {noformat}
> I find that cloudstack-agent jsvc gets virtual memory about 35GB.
> {noformat}
> $ top -a
> (snip)
>PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 5787 root 20 0 34.9g 667m 18m S 0.0 0.5 8:45.20 jsvc
> (snip)
> {noformat}
>
> I suspect that this failure is caused by what cloudstack-agent jsvc
> gets too large virtual memory.
> I try to patch /etc/init.d/cloudstack-agent as follows:
> {noformat}
> @@ -66,7 +66,7 @@
> start() {
> echo -n $"Starting $PROGNAME: "
> if hostname --fqdn >/dev/null 2>&1 ; then
> -$JSVC -cp "$CLASSPATH" -pidfile "$PIDFILE" \
> +$JSVC -Xms1024m -Xmx2048m -cp "$CLASSPATH" -pidfile "$PIDFILE" \
> -errfile $LOGDIR/cloudstack-agent.err -outfile
> $LOGDIR/cloudstack-agent.out $CLASS
> RETVAL=$?
> echo
> {noformat}
> Then, I restart cloudstack-agent.
> As a result, cloudstack agent jsvc reduces virtual memory about 6GB.
> Also, qemu-kvm process does not fail deploying VM for now.
> {noformat}
> $ top -a
> (snip)
>PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 141405 root 20 0 6290m 393m 18m S 0.0 0.3 1:11.44 jsvc
> (snip)
> {noformat}
> If that helps, our CloudStack environment is as follows:
> {noformat}
> - Builds up with 155 physical machines and a cloudstack server.
> - Each physical machine equips these.
> + Xeon E5-2680 (10 cores, 20 threads)
> + 128GB memory (and is not set swap space).
> + 600GB Solid State Drive.
> - All physical machines are networked by InfiniBand and 10GBase-T.
> - Using CentOS6.6 (64bit)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7951) cloudstack-agent jsvc gets too large virtual memory space.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219706#comment-14219706
]
ASF subversion and git services commented on CLOUDSTACK-7951:
-
Commit 7884c750a205fa8962de4ac65960a9f514770817 in cloudstack's branch
refs/heads/master from [~yusa]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7884c75 ]
CLOUDSTACK-7951
Limit amount of memory used by cloudstack-agent jsvc.
Signed-off-by: Edison Su
> cloudstack-agent jsvc gets too large virtual memory space.
> --
>
> Key: CLOUDSTACK-7951
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7951
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.3.0
> Environment: - Builds up with 155 physical machines and a cloudstack
> server.
> - Each physical machine equips these.
> + Xeon E5-2680 (10 cores, 20 threads).
> + 128GB memory (and is not set swap space).
> + 600GB Solid State Drive.
> - All physical machines are networked by InfiniBand and 10GBase-T.
> - Using CentOS6.6 (64bit)
>Reporter: Keiichi Yusa
>Priority: Critical
>
> cloudstack-agent jsvc gets too large virtual memory space on huge
> memory equipped machine.
> We have 155 physical machines that each is equipped 128GB RAM and
> is installed CentOS6.6 (64bit). On these physical machines, I use
> KVM as hypervisor.
> I create Compute Offering with 120GB RAM and I deploy VM with this
> Compute Offering on this environment.
> Now, I have a problem that qemu-kvm process often fails deploying VM
> in the above conditions. I confirm that the following message is
> outputted in /var/log/libvirt/qemu/i-X-X-VM.log.
> {noformat}
> "Cannot set up guest memory 'pc.ram': Cannot allocate memory"
> {noformat}
> I find that cloudstack-agent jsvc gets virtual memory about 35GB.
> {noformat}
> $ top -a
> (snip)
>PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 5787 root 20 0 34.9g 667m 18m S 0.0 0.5 8:45.20 jsvc
> (snip)
> {noformat}
>
> I suspect that this failure is caused by what cloudstack-agent jsvc
> gets too large virtual memory.
> I try to patch /etc/init.d/cloudstack-agent as follows:
> {noformat}
> @@ -66,7 +66,7 @@
> start() {
> echo -n $"Starting $PROGNAME: "
> if hostname --fqdn >/dev/null 2>&1 ; then
> -$JSVC -cp "$CLASSPATH" -pidfile "$PIDFILE" \
> +$JSVC -Xms1024m -Xmx2048m -cp "$CLASSPATH" -pidfile "$PIDFILE" \
> -errfile $LOGDIR/cloudstack-agent.err -outfile
> $LOGDIR/cloudstack-agent.out $CLASS
> RETVAL=$?
> echo
> {noformat}
> Then, I restart cloudstack-agent.
> As a result, cloudstack agent jsvc reduces virtual memory about 6GB.
> Also, qemu-kvm process does not fail deploying VM for now.
> {noformat}
> $ top -a
> (snip)
>PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 141405 root 20 0 6290m 393m 18m S 0.0 0.3 1:11.44 jsvc
> (snip)
> {noformat}
> If that helps, our CloudStack environment is as follows:
> {noformat}
> - Builds up with 155 physical machines and a cloudstack server.
> - Each physical machine equips these.
> + Xeon E5-2680 (10 cores, 20 threads)
> + 128GB memory (and is not set swap space).
> + 600GB Solid State Drive.
> - All physical machines are networked by InfiniBand and 10GBase-T.
> - Using CentOS6.6 (64bit)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7955) [Automation] Fix the script "test_project_limits.py" - Template created from VM's Volume does not belong to the Project
Chandan Purushothama created CLOUDSTACK-7955: Summary: [Automation] Fix the script "test_project_limits.py" - Template created from VM's Volume does not belong to the Project Key: CLOUDSTACK-7955 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7955 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 Based on Fix for CLOUDSTACK-7394, Caller should be owner after creating template from snapshot/volume. This requires the test case test_07_templates_per_project to be changed. The test case should test the limits by registering the template in the project instead of creating templates from Volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7948) [Automation] Two "VOLUME.DELETE" Events are being registered instead of one - On Destroying a User VM belonging to a Project
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-7948:
---
Assignee: Damodar Reddy T
> [Automation] Two "VOLUME.DELETE" Events are being registered instead of one -
> On Destroying a User VM belonging to a Project
>
>
> Key: CLOUDSTACK-7948
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7948
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Damodar Reddy T
> Fix For: 4.5.0
>
>
> ==
> User VM in Project Events Information in the Database:
> ==
> {noformat}
> mysql> select * from usage_event where account_id=6;
> ++-++-+-+-++-+-+-++---+--+
> | id | type| account_id | created | zone_id |
> resource_id | resource_name | offering_id | template_id | size|
> resource_type | processed | virtual_size |
> ++-++-+-+-++-+-+-++---+--+
> | 19 | TEMPLATE.CREATE | 6 | 2014-11-19 21:28:14 | 1 |
> 202 | TestTemplate-1 |NULL |NULL | 1708331520 | NULL
> | 0 | 8589934592 |
> | 20 | VOLUME.CREATE | 6 | 2014-11-19 21:32:23 | 1 |
> 9 | ROOT-9 | 1 | 5 | 21474836480 | NULL
> | 0 | NULL |
> | 21 | VM.CREATE | 6 | 2014-11-19 21:32:23 | 1 |
> 9 | Project-VM-1 | 1 | 5 |NULL |
> XenServer | 0 | NULL |
> | 22 | NET.IPASSIGN| 6 | 2014-11-19 21:32:25 | 1 |
> 6 | 10.219.196.151 |NULL | 0 | 0 |
> DirectAttached | 0 | NULL |
> | 23 | NETWORK.OFFERING.ASSIGN | 6 | 2014-11-19 21:32:33 | 1 |
> 9 | 19 | 6 |NULL | 1 | NULL
> | 0 | NULL |
> | 24 | SG.ASSIGN | 6 | 2014-11-19 21:32:33 | 1 |
> 9 | NULL | 4 |NULL |NULL | NULL
> | 0 | NULL |
> | 25 | VM.START| 6 | 2014-11-19 21:32:33 | 1 |
> 9 | Project-VM-1 | 1 | 5 |NULL |
> XenServer | 0 | NULL |
> | 26 | SG.REMOVE | 6 | 2014-11-19 21:33:10 | 1 |
> 9 | NULL | 4 |NULL |NULL | NULL
> | 0 | NULL |
> | 27 | VM.STOP | 6 | 2014-11-19 21:33:10 | 1 |
> 9 | Project-VM-1 | 1 | 5 |NULL |
> XenServer | 0 | NULL |
> | 28 | NETWORK.OFFERING.REMOVE | 6 | 2014-11-19 21:33:10 | 1 |
> 9 | 19 | 6 |NULL | 0 | NULL
> | 0 | NULL |
> | 31 | VM.DESTROY | 6 | 2014-11-20 00:08:37 | 1 |
> 9 | Project-VM-1 | 1 | 5 |NULL |
> XenServer | 0 | NULL |
> | 32 | VOLUME.DELETE | 6 | 2014-11-20 00:08:37 | 1 |
> 9 | ROOT-9 |NULL |NULL |NULL | NULL
> | 0 | NULL |
> | 33 | NET.IPRELEASE | 6 | 2014-11-20 00:08:39 | 1 |
> 6 | 10.219.196.151 |NULL | 0 | 0 |
> DirectAttached | 0 | NULL |
> | 34 | VOLUME.DELETE | 6 | 2014-11-20 00:08:39 | 1 |
> 9 | ROOT-9 |NULL |NULL |NULL | NULL
> | 0 | NULL |
> ++-++-+-+-++-+-+-++---+--+
> 14 rows in set (0.00 sec)
> {noformat}
> =
> Destroy VM Job Log:
> =
> {noformat}
> 2014-11-20 00:08:35,021 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (cata
[jira] [Commented] (CLOUDSTACK-5426) Cannot deploy instance having multiple volumes that use different storage tags for storage pools in same cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219937#comment-14219937 ] Prachi Damle commented on CLOUDSTACK-5426: -- Yes the fix was tested on 4.3 as well as 4.5 But this need not be backported to 4.3 branch. The issue is already fixed for 4.3 - once by me (https://issues.apache.org/jira/browse/CLOUDSTACK-5426) and also by Marcus ( https://issues.apache.org/jira/browse/CLOUDSTACK-5853). Carrying both the fixes in 4.3 should not cause any problems. But Marcus's fix exposes the allocator to face some issues in future - hence I have reverted it for 4.5. > Cannot deploy instance having multiple volumes that use different storage > tags for storage pools in same cluster > > > Key: CLOUDSTACK-5426 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5426 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0, 4.2.1, 4.3.0 >Reporter: Prachi Damle >Assignee: Prachi Damle >Priority: Critical > Fix For: 4.3.0 > > > This issue can be observed when VM being deployed has multiple volumes (>=2) > where 2 adjacent volumes are to be created with 2 different disk offerings > with different storage tags. > Ex: > 1. VM1 has 2 volumes root volume & 1 data volume. > 2. root volume is to be created using a disk offering with storage tag > 'root_disk' > 3. data volume is to be created using a disk offering with storage tag > 'data_disk' > 4. There exists a cluster wide storage pool suitable for root volume with > storage tag 'root_disk' > 5. There exists a cluster wide storage pool suitable for data volume with > storage tag 'data_disk' > The deploy VM fails in this case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7956) [Automation] Fix the script "test_project_usage.py" - Template created from VM's Volume does not belong to the Project
Chandan Purushothama created CLOUDSTACK-7956: Summary: [Automation] Fix the script "test_project_usage.py" - Template created from VM's Volume does not belong to the Project Key: CLOUDSTACK-7956 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7956 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 Based on Fix for CLOUDSTACK-7394, Caller should be owner after creating template from snapshot/volume. This requires the test case test_07_templates_per_project to be changed. The test case should test the limits by registering the template in the project instead of creating templates from Volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7956) [Automation] Fix the script "test_project_usage.py" - Template created from VM's Volume does not belong to the Project
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chandan Purushothama updated CLOUDSTACK-7956: - Description: Based on Fix for CLOUDSTACK-7394, Caller should be owner after creating template from snapshot/volume. This requires the test case test_01_template_usage to be changed. The test case should test the limits by registering the template in the project instead of creating templates from Volumes. (was: Based on Fix for CLOUDSTACK-7394, Caller should be owner after creating template from snapshot/volume. This requires the test case test_07_templates_per_project to be changed. The test case should test the limits by registering the template in the project instead of creating templates from Volumes.) > [Automation] Fix the script "test_project_usage.py" - Template created from > VM's Volume does not belong to the Project > -- > > Key: CLOUDSTACK-7956 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7956 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Test >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Chandan Purushothama >Priority: Critical > Fix For: 4.5.0 > > > Based on Fix for CLOUDSTACK-7394, Caller should be owner after creating > template from snapshot/volume. This requires the test case > test_01_template_usage to be changed. The test case should test the limits by > registering the template in the project instead of creating templates from > Volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-3995) No error notification is generated when Primary storage (Zonelevel) is added with wrong path and it is allowed to add
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su resolved CLOUDSTACK-3995.
---
Resolution: Fixed
fixed by 7ea8c5fd9a19b9f34158e2ab8db840967db6663d, which will delete db entry
in case of adding primary storage failure.
> No error notification is generated when Primary storage (Zonelevel) is added
> with wrong path and it is allowed to add
> -
>
> Key: CLOUDSTACK-3995
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3995
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, VMware
>Affects Versions: 4.2.0
>Reporter: Sailaja Mada
>Assignee: edison su
>Priority: Minor
> Fix For: 4.5.0
>
> Attachments: apilog.log, management-server.log
>
>
> Steps:
> 1. Configure Adv zone with VMWARE
> 2. Tried to add wrong Zone wide primary storage point
> Observation:
> It is allowed to add with wrong path and there is no failure error
> notification. But in the logs it says storage pool addition failed.
> 2013-08-01 10:11:30,741 DEBUG [cloud.api.ApiServlet] (catalina-exec-17:null)
> ===START=== 10.144.6.19 -- GET
> command=createStoragePool&scope=zone&zoneid=176d7081-e1d2-4472-8a17-eff1322ddd39&hypervisor=VMware&name=wrongzwps1&url=nfs%3A%2F%2F10.102.192.100%2Fcpg_vol%2Fsailaja%2Fwrongzwps1&response=json&sessionkey=x8JP8GtGm4LirW0b8AK9sVj26D0%3D&_=1375332320686
> 2013-08-01 10:11:30,748 DEBUG
> [datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl]
> (catalina-exec-17:null) createPool Params @ scheme - nfs storageHost -
> 10.102.192.100 hostPath - /cpg_vol/sailaja/wrongzwps1 port - -1
> 2013-08-01 10:11:30,763 DEBUG [cloud.storage.StorageManagerImpl]
> (catalina-exec-17:null) Adding pool null to host 1
> 2013-08-01 10:11:30,767 DEBUG [agent.transport.Request]
> (catalina-exec-17:null) Seq 1-757532167: Sending { Cmd , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.ModifyStoragePoolCommand":{"add":true,"pool":{"id":6,"uuid":"8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","host":"10.102.192.100","path":"/cpg_vol/sailaja/wrongzwps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","wait":0}}]
> }
> 2013-08-01 10:11:30,767 DEBUG [agent.transport.Request]
> (catalina-exec-17:null) Seq 1-757532167: Executing: { Cmd , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.ModifyStoragePoolCommand":{"add":true,"pool":{"id":6,"uuid":"8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","host":"10.102.192.100","path":"/cpg_vol/sailaja/wrongzwps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","wait":0}}]
> }
> 2013-08-01 10:11:30,768 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-52:null) Seq 1-757532167: Executing request
> 2013-08-01 10:11:30,768 INFO [vmware.resource.VmwareResource]
> (DirectAgent-52:10.102.192.18) Executing resource ModifyStoragePoolCommand:
> {"add":true,"pool":{"id":6,"uuid":"8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","host":"10.102.192.100","path":"/cpg_vol/sailaja/wrongzwps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","wait":0}
> 2013-08-01 10:11:30,949 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RouterStatusMonitor-1:null) Found 3 routers to update status.
> 2013-08-01 10:11:30,951 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RouterStatusMonitor-1:null) Found 0 networks to update RvR status.
> 2013-08-01 10:11:30,962 INFO [vmware.mo.HostMO]
> (DirectAgent-52:10.102.192.18) Creation of NFS datastore on vCenter failed.
> Details: vCenter API trace - mountDatastore(). target MOR: host-8973, vmfs:
> false, poolHost: 10.102.192.100, poolHostPort: 2049, poolPath:
> /cpg_vol/sailaja/wrongzwps1, poolUuid: 8f4e2b4b76a23f11b98c2ee8108ab900.
> Exception mesg: An error occurred during host configuration.
> 2013-08-01 10:11:30,962 ERROR [vmware.resource.VmwareResource]
> (DirectAgent-52:10.102.192.18) ModifyStoragePoolCommand failed due to
> Exception: java.lang.Exception
> Message: Creation of NFS datastore on vCenter failed.
> java.lang.Exception: Creation of NFS datastore on vCenter failed.
> at
> com.cloud.hypervisor.vmware.mo.HostMO.mountDatastore(HostMO.java:772)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4102)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:472)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.ja
[jira] [Created] (CLOUDSTACK-7957) [Automation] After Assigning a VM to a Different Account - PrimaryStorageTotal value of the Different Account is not Updated properly
Chandan Purushothama created CLOUDSTACK-7957:
Summary: [Automation] After Assigning a VM to a Different Account
- PrimaryStorageTotal value of the Different Account is not Updated properly
Key: CLOUDSTACK-7957
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7957
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
Fix For: 4.5.0
*Steps to Reproduce:*
1. Create an Account. Observe the primarystoragetotal Information:
{noformat}
{
primarystorageavailable: u'Unlimited',
domain: u'ROOT',
domainid: u'd32d07d4-6fe6-11e4-8b15-0e412070d892',
vpclimit: u'Unlimited',
iplimit: u'Unlimited',
volumelimit: u'Unlimited',
memorytotal: 0,
secondarystorageavailable: u'Unlimited',
vmtotal: 0,
cputotal: 0,
vpctotal: 0,
id: u'40f4c89b-2964-4c54-9aff-5e537faee4f9',
cpuavailable: u'Unlimited',
snapshotlimit: u'Unlimited',
networklimit: u'Unlimited',
iptotal: 0,
volumetotal: 0,
projectlimit: u'Unlimited',
state: u'enabled',
networktotal: 0,
accounttype: 2,
networkavailable: u'Unlimited',
primarystoragetotal: 0,
templatelimit: u'Unlimited',
snapshottotal: 0,
templateavailable: u'Unlimited',
vmlimit: u'Unlimited',
vpcavailable: u'Unlimited',
memoryavailable: u'Unlimited',
secondarystoragetotal: 0,
templatetotal: 0,
projecttotal: 0,
user: [
{
username:
u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
account:
u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
domainid: u'd32d07d4-6fe6-11e4-8b15-0e412070d892',
firstname: u'test',
created: u'2014-11-19T14: 24: 52+',
lastname: u'test',
domain: u'ROOT',
id: u'3108696d-5bb2-43e4-a5dc-9b7e095e5e6d',
iscallerchilddomain: False,
state: u'enabled',
accounttype: 2,
email: u'test-acco...@test.com',
isdefault: False,
accountid: u'40f4c89b-2964-4c54-9aff-5e537faee4f9'
}
],
groups: [
],
projectavailable: u'Unlimited',
isdefault: False,
primarystoragelimit: u'Unlimited',
secondarystoragelimit: u'Unlimited',
volumeavailable: u'Unlimited',
name:
u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
vmavailable: u'Unlimited',
ipavailable: u'Unlimited',
memorylimit: u'Unlimited',
cpulimit: u'Unlimited',
snapshotavailable: u'Unlimited'
}
{noformat}
2. Deploy a VM from the default template (2 GB Size) with a disk offering of
2GB. Observe primarystoragetotal Information of the account as 4GB.
{noformat}
{
primarystorageavailable: u'Unlimited',
domain: u'ROOT',
domainid: u'd32d07d4-6fe6-11e4-8b15-0e412070d892',
vpclimit: u'Unlimited',
iplimit: u'Unlimited',
volumelimit: u'Unlimited',
memorytotal: 128,
secondarystorageavailable: u'Unlimited',
vmtotal: 1,
cputotal: 1,
vpctotal: 0,
id: u'40f4c89b-2964-4c54-9aff-5e537faee4f9',
networkavailable: u'Unlimited',
snapshotlimit: u'Unlimited',
networklimit: u'Unlimited',
iptotal: 1,
volumetotal: 2,
projectlimit: u'Unlimited',
state: u'enabled',
networktotal: 1,
sentbytes: 0,
accounttype: 2,
receivedbytes: 0,
cpuavailable: u'Unlimited',
primarystoragetotal: 4,
templatelimit: u'Unlimited',
snapshottotal: 0,
templateavailable: u'Unlimited',
vmlimit: u'Unlimited',
vpcavailable: u'Unlimited',
memoryavailable: u'Unlimited',
secondarystoragetotal: 0,
templatetotal: 0,
projecttotal: 0,
vmrunning: 1,
groups: [
],
projectavailable: u'Unlimited',
isdefault: False,
primarystoragelimit: u'Unlimited',
secondarystoragelimit: u'Unlimited',
volumeavailable: u'Unlimited',
name:
u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
vmavailable: u'Unlimited',
ipavailable: u'Unlimited',
memorylimit: u'Unlimited',
cpulimit: u'Unlimited',
snapshotavailable: u'Unlimited',
user: [
{
username:
u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
account:
u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
domainid: u'd32d07d4-6fe6-11e4-8b15-0e412070d892',
firstname: u'test',
created: u'2014-11-19T14: 24: 52+',
lastname: u'test',
domain: u'R
[jira] [Updated] (CLOUDSTACK-7957) [Automation] After Assigning a VM to a Different Account - PrimaryStorageTotal value of the Different Account is not Updated properly
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chandan Purushothama updated CLOUDSTACK-7957:
-
Description:
*Steps to Reproduce:*
1. Create an Account. Observe the primarystoragetotal Information:
{noformat}
{
primarystorageavailable: u'Unlimited',
domain: u'ROOT',
domainid: u'd32d07d4-6fe6-11e4-8b15-0e412070d892',
vpclimit: u'Unlimited',
iplimit: u'Unlimited',
volumelimit: u'Unlimited',
memorytotal: 0,
secondarystorageavailable: u'Unlimited',
vmtotal: 0,
cputotal: 0,
vpctotal: 0,
id: u'40f4c89b-2964-4c54-9aff-5e537faee4f9',
cpuavailable: u'Unlimited',
snapshotlimit: u'Unlimited',
networklimit: u'Unlimited',
iptotal: 0,
volumetotal: 0,
projectlimit: u'Unlimited',
state: u'enabled',
networktotal: 0,
accounttype: 2,
networkavailable: u'Unlimited',
primarystoragetotal: 0,
templatelimit: u'Unlimited',
snapshottotal: 0,
templateavailable: u'Unlimited',
vmlimit: u'Unlimited',
vpcavailable: u'Unlimited',
memoryavailable: u'Unlimited',
secondarystoragetotal: 0,
templatetotal: 0,
projecttotal: 0,
user: [
{
username:
u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
account:
u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
domainid: u'd32d07d4-6fe6-11e4-8b15-0e412070d892',
firstname: u'test',
created: u'2014-11-19T14: 24: 52+',
lastname: u'test',
domain: u'ROOT',
id: u'3108696d-5bb2-43e4-a5dc-9b7e095e5e6d',
iscallerchilddomain: False,
state: u'enabled',
accounttype: 2,
email: u'test-acco...@test.com',
isdefault: False,
accountid: u'40f4c89b-2964-4c54-9aff-5e537faee4f9'
}
],
groups: [
],
projectavailable: u'Unlimited',
isdefault: False,
primarystoragelimit: u'Unlimited',
secondarystoragelimit: u'Unlimited',
volumeavailable: u'Unlimited',
name:
u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
vmavailable: u'Unlimited',
ipavailable: u'Unlimited',
memorylimit: u'Unlimited',
cpulimit: u'Unlimited',
snapshotavailable: u'Unlimited'
}
{noformat}
2. Deploy a VM from the default template (2 GB Size) with a disk offering of
2GB. Observe primarystoragetotal Information of the account as 4GB.
{noformat}
{
primarystorageavailable: u'Unlimited',
domain: u'ROOT',
domainid: u'd32d07d4-6fe6-11e4-8b15-0e412070d892',
vpclimit: u'Unlimited',
iplimit: u'Unlimited',
volumelimit: u'Unlimited',
memorytotal: 128,
secondarystorageavailable: u'Unlimited',
vmtotal: 1,
cputotal: 1,
vpctotal: 0,
id: u'40f4c89b-2964-4c54-9aff-5e537faee4f9',
networkavailable: u'Unlimited',
snapshotlimit: u'Unlimited',
networklimit: u'Unlimited',
iptotal: 1,
volumetotal: 2,
projectlimit: u'Unlimited',
state: u'enabled',
networktotal: 1,
sentbytes: 0,
accounttype: 2,
receivedbytes: 0,
cpuavailable: u'Unlimited',
primarystoragetotal: 4,
templatelimit: u'Unlimited',
snapshottotal: 0,
templateavailable: u'Unlimited',
vmlimit: u'Unlimited',
vpcavailable: u'Unlimited',
memoryavailable: u'Unlimited',
secondarystoragetotal: 0,
templatetotal: 0,
projecttotal: 0,
vmrunning: 1,
groups: [
],
projectavailable: u'Unlimited',
isdefault: False,
primarystoragelimit: u'Unlimited',
secondarystoragelimit: u'Unlimited',
volumeavailable: u'Unlimited',
name:
u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
vmavailable: u'Unlimited',
ipavailable: u'Unlimited',
memorylimit: u'Unlimited',
cpulimit: u'Unlimited',
snapshotavailable: u'Unlimited',
user: [
{
username:
u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
account:
u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
domainid: u'd32d07d4-6fe6-11e4-8b15-0e412070d892',
firstname: u'test',
created: u'2014-11-19T14: 24: 52+',
lastname: u'test',
domain: u'ROOT',
id: u'3108696d-5bb2-43e4-a5dc-9b7e095e5e6d',
iscallerchilddomain: False,
state: u'enabled',
accounttype: 2,
email: u'test-acco...@test.com',
isdefault: False,
accountid: u'40f4c89b-2964-4c54-9aff-5e537faee4f9'
}
]
}
]
{noformat}
3. Create a new Account. Observe the primarystoragetotal value of the Account
{noformat}
{
primarystorageavaila
[jira] [Updated] (CLOUDSTACK-7951) cloudstack-agent jsvc gets too large virtual memory space.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keiichi Yusa updated CLOUDSTACK-7951:
-
Fix Version/s: 4.6.0
4.5.0
4.4.0
4.3.0
Future
> cloudstack-agent jsvc gets too large virtual memory space.
> --
>
> Key: CLOUDSTACK-7951
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7951
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.3.0
> Environment: - Builds up with 155 physical machines and a cloudstack
> server.
> - Each physical machine equips these.
> + Xeon E5-2680 (10 cores, 20 threads).
> + 128GB memory (and is not set swap space).
> + 600GB Solid State Drive.
> - All physical machines are networked by InfiniBand and 10GBase-T.
> - Using CentOS6.6 (64bit)
>Reporter: Keiichi Yusa
>Priority: Critical
> Fix For: Future, 4.3.0, 4.4.0, 4.5.0, 4.6.0
>
>
> cloudstack-agent jsvc gets too large virtual memory space on huge
> memory equipped machine.
> We have 155 physical machines that each is equipped 128GB RAM and
> is installed CentOS6.6 (64bit). On these physical machines, I use
> KVM as hypervisor.
> I create Compute Offering with 120GB RAM and I deploy VM with this
> Compute Offering on this environment.
> Now, I have a problem that qemu-kvm process often fails deploying VM
> in the above conditions. I confirm that the following message is
> outputted in /var/log/libvirt/qemu/i-X-X-VM.log.
> {noformat}
> "Cannot set up guest memory 'pc.ram': Cannot allocate memory"
> {noformat}
> I find that cloudstack-agent jsvc gets virtual memory about 35GB.
> {noformat}
> $ top -a
> (snip)
>PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 5787 root 20 0 34.9g 667m 18m S 0.0 0.5 8:45.20 jsvc
> (snip)
> {noformat}
>
> I suspect that this failure is caused by what cloudstack-agent jsvc
> gets too large virtual memory.
> I try to patch /etc/init.d/cloudstack-agent as follows:
> {noformat}
> @@ -66,7 +66,7 @@
> start() {
> echo -n $"Starting $PROGNAME: "
> if hostname --fqdn >/dev/null 2>&1 ; then
> -$JSVC -cp "$CLASSPATH" -pidfile "$PIDFILE" \
> +$JSVC -Xms1024m -Xmx2048m -cp "$CLASSPATH" -pidfile "$PIDFILE" \
> -errfile $LOGDIR/cloudstack-agent.err -outfile
> $LOGDIR/cloudstack-agent.out $CLASS
> RETVAL=$?
> echo
> {noformat}
> Then, I restart cloudstack-agent.
> As a result, cloudstack agent jsvc reduces virtual memory about 6GB.
> Also, qemu-kvm process does not fail deploying VM for now.
> {noformat}
> $ top -a
> (snip)
>PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 141405 root 20 0 6290m 393m 18m S 0.0 0.3 1:11.44 jsvc
> (snip)
> {noformat}
> If that helps, our CloudStack environment is as follows:
> {noformat}
> - Builds up with 155 physical machines and a cloudstack server.
> - Each physical machine equips these.
> + Xeon E5-2680 (10 cores, 20 threads)
> + 128GB memory (and is not set swap space).
> + 600GB Solid State Drive.
> - All physical machines are networked by InfiniBand and 10GBase-T.
> - Using CentOS6.6 (64bit)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7600) [Automation] VM Failed to Start due to ConcurrentOperationException - Unable to change the state of Virtual Router
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14220451#comment-14220451
]
Sheng Yang commented on CLOUDSTACK-7600:
Hi Chandan,
Can you reproduce this issue? It looks like a racy issue to me. How often does
this happen?
> [Automation] VM Failed to Start due to ConcurrentOperationException - Unable
> to change the state of Virtual Router
> --
>
> Key: CLOUDSTACK-7600
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7600
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test, Virtual Router
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Sheng Yang
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.zip
>
>
> *ConcurrentOperationException: Unable to change the state of VM*
> {noformat}
> 2014-09-21 14:38:20,648 ERROR [c.c.v.VirtualMachineManagerImpl]
> (Work-Job-Executor-65:ctx-cfa1f316 job-1953/job-1954 ctx-6fd40296) Failed to
> start instance VM[User|i-115-279-VM]
> com.cloud.exception.ConcurrentOperationException: Unable to change the state
> of VM[DomainRouter|r-271-VM]
> at
> com.cloud.vm.VirtualMachineManagerImpl.changeToStartState(VirtualMachineManagerImpl.java:717)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:808)
> at
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:762)
> at
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2981)
> at
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:2055)
> at
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouters(VirtualNetworkApplianceManagerImpl.java:2155)
> at
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:2137)
> at sun.reflect.GeneratedMethodAccessor335.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at
> org.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 $Proxy190.deployVirtualRouterInGuestNetwork(Unknown Source)
> at
> com.cloud.network.element.VirtualRouterElement.prepare(VirtualRouterElement.java:234)
> at
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1239)
> at
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1373)
> at
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1309)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:970)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4590)
> at sun.reflect.GeneratedMethodAccessor379.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4746)
> at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:516)
> 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.DefaultMan
[jira] [Updated] (CLOUDSTACK-7950) AttachIsoCmd shoud give correct messge when trying to attach vmwaretools installer iso on non supported guestvm deployed by ISO
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saksham Srivastava updated CLOUDSTACK-7950: --- Affects Version/s: 4.5.0 > AttachIsoCmd shoud give correct messge when trying to attach vmwaretools > installer iso on non supported guestvm deployed by ISO > --- > > Key: CLOUDSTACK-7950 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7950 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.0 >Reporter: Saksham Srivastava >Assignee: Saksham Srivastava > Fix For: 4.5.0 > > > Deploy vm from iso say centos 6.4 > Try attach vmware iso tools from cloudstack > The log message/UI is not clear about the failure. > INFO [c.c.h.v.m.HostMO] (DirectAgent-341:ctx-2492ca8c 10.102.192.14, job-79, > cmd: AttachCommand) VM i-2-8-VM not found in host cache > ERROR [c.c.s.r.VmwareStorageProcessor] (DirectAgent-341:ctx-2492ca8c > 10.102.192.14, job-79, cmd: AttachCommand) AttachIsoCommand(attach) failed > due to Exception: javax.xml.ws.soap.SOAPFaultException > Message: The required VMware Tools ISO image does not exist or is > inaccessible. > javax.xml.ws.soap.SOAPFaultException: The required VMware Tools ISO image > does not exist or is inaccessible. > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > Message should contain info about non supported gues os. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7703) Cloudstack server endless loop when trying to create a volume while storage pool is full
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14220511#comment-14220511 ] Anshul Gangwar commented on CLOUDSTACK-7703: Its already backported to 4.4 and 4.3 branch Commit 14e048dadabba67d09f85d12019fcd39b8b47db1 in cloudstack's branch refs/heads/4.3 from Anshul Gangwar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=14e048d ] CLOUDSTACK-7752: Fixed deployment planner stuck in infinite loop. If we create VM with shared service offering and attach disk with local disk offering, and one of storage pool is full(cannot be allocated) and other is not full then we are not putting the cluster in avoid list which is causing this infinite loop. Fixed by putting the cluster in avoid list even if one of the storage pool is full(cannot be allocated) Signed-off-by: Daan Hoogland Commit 5b620951a399188bd956f1198cd35d96b4008862 in cloudstack's branch refs/heads/4.4 from Anshul Gangwar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5b62095 ] > Cloudstack server endless loop when trying to create a volume while storage > pool is full > > > Key: CLOUDSTACK-7703 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7703 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Centos 6.5 >Reporter: JF Vincent >Assignee: Anshul Gangwar >Priority: Critical > Fix For: 4.5.0 > > > When trying to create a VM, and thus a volume for it and the primary storage > is full (over 90%), the managament server enter in and endless loop (extract > below) and we have to restart it to exit this loop. > 2014-10-14 11:39:20,701 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found for > volume: Vol[5436|vm=5855|DATADISK] under cluster: 2 > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable storagePools found > under this Cluster: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Could not find suitable > Deployment Destination for this VM under any clusters, returning. > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Searching all possible resources > under this Zone: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Listing clusters in order of > aggregate capacity, that have (atleast one host with) enough CPU and RAM > capacity under this Zone: 2 > 2014-10-14 11:39:20,707 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Removing from the clusterId list > these clusters from avoid set: [] > 2014-10-14 11:39:20,714 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Checking resources in Cluster: 2 > under Pod: 2 > 2014-10-14 11:39:20,714 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for hosts in dc: 2 pod:2 cluster:2 > 2014-10-14 11:39:20,716 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) > FirstFitAllocator has 3 hosts to check for allocation: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Found 3 > hosts for allocation after prioritization: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for speed=500Mhz, Ram=500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host: 79 > has cpu capability (cpu:8, speed:2399) to support requested CPU: 1 and > requested speed: 500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Checking > if host: 79 has enough capacity for requested CPU: 500 and requested RAM: > 524288000 , cpuOverprovisioningFactor: 4.0 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.Cap
[jira] [Updated] (CLOUDSTACK-7283) Allow regular user to execute listUsers API call
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-7283: --- Assignee: Radhika Nair > Allow regular user to execute listUsers API call > > > Key: CLOUDSTACK-7283 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7283 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Doc >Affects Versions: 4.5.0 >Reporter: Alena Prokharchyk >Assignee: Radhika Nair > Fix For: 4.5.0 > > > Since normal-user role can have access to listAccounts API that returns user > info + he can update users info by calling updateUser, he should have an > access to listUsers API. The response should return his user info only. Other > users belonging to the same user's account, shouldn't be returned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
