[jira] [Commented] (CLOUDSTACK-9144) VMware in Basic Zone: VR never leaves the "Starting" state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16112002#comment-16112002 ] Mike Tutkowski commented on CLOUDSTACK-9144: I was able to get the VR into the Started state using Paul's method; however, I was not able to get a user VM running: com.cloud.exception.ResourceUnavailableException: Resource [VirtualRouter:42] is unreachable: Unable to send command. Router requires upgrade at com.cloud.network.router.NetworkHelperImpl.sendCommandsToRouter(NetworkHelperImpl.java:168) at org.apache.cloudstack.network.topology.BasicNetworkVisitor.visit(BasicNetworkVisitor.java:203) at com.cloud.network.rules.DhcpEntryRules.accept(DhcpEntryRules.java:62) at org.apache.cloudstack.network.topology.BasicNetworkTopology.applyRules(BasicNetworkTopology.java:390) at org.apache.cloudstack.network.topology.BasicNetworkTopology.applyDhcpEntry(BasicNetworkTopology.java:163) at com.cloud.network.element.VirtualRouterElement.applyDhcpEntries(VirtualRouterElement.java:1084) at com.cloud.network.element.VirtualRouterElement.addDhcpEntry(VirtualRouterElement.java:1052) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1275) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1584) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1518) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1005) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4742) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) at com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4903) at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:558) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:506) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-12:ctx-6341a43d job-501/job-503) (logid:bb593183) Remove job-503 from job monitoring WARN [o.a.c.alerts] (API-Job-Executor-6:ctx-c53b769f job-501 ctx-40f4551d) (logid:bb593183) AlertType:: 8 | dataCenterId:: 1 | podId:: 1 | clusterId:: null | message:: Failed to deploy Vm with Id: 44, on Host with Id: null ERROR [c.c.a.ApiAsyncJobDispatcher] (API-Job-Executor-6:ctx-c53b769f job-501) (logid:bb593183) Unexpected exception while executing org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin com.cloud.utils.exception.CloudRuntimeException: Network is unavailable. Please contact administrator at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:628) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:245) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:212) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:4174) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3753) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3741) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
[jira] [Commented] (CLOUDSTACK-8906) /var/log/cloud/ doesn't get logrotated on xenserver
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16111878#comment-16111878 ] ASF subversion and git services commented on CLOUDSTACK-8906: - Commit 5397106a7621e974343927c70ec19abe819237bf in cloudstack's branch refs/heads/master from [~sudharmaj] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=5397106 ] CLOUDSTACK-8906: /var/log/cloud/ doesn't get logrotated on xenserver (#883) After integrating XS with CCP the following folder gets created: /var/log/cloud/ however the logs in that are not rotated resulting in root file system fill up. It was a known issue and link http://support.citrix.com/article/CTX138064 describes the issue and solution. Used the article and added corresponding changes to Cloudstack. > /var/log/cloud/ doesn't get logrotated on xenserver > > > Key: CLOUDSTACK-8906 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8906 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: sudharma jain > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9925) Quota: fix tariff description for memory. Tariff value is for 1MB of RAM used per month (not hour).
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16111873#comment-16111873 ] ASF subversion and git services commented on CLOUDSTACK-9925: - Commit e0b6dcbe4a31ddb2f3c0dedbedab85a44e6f84c6 in cloudstack's branch refs/heads/master from [~brascher] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=e0b6dcb ] CLOUDSTACK-9925: Quota memory tariff value is for 1MB of RAM used per month (not hour) (#2119) The quota memory tariff description in the CloudStack UI is wrong when defines that the value is for "using 1MB or RAM for 1 hour". The quota currency values reflect the value of a resource used per month, not an hour. Quota divides the tariff value by the number of hours a month has (30 days - 720 hours); then it calculates the credits used by a client based on the amount of resources used per hour. The memory tariff description in the interface is wrong and can guide users to configure values for an hour. > Quota: fix tariff description for memory. Tariff value is for 1MB of RAM used > per month (not hour). > --- > > Key: CLOUDSTACK-9925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Gabriel Beims Bräscher >Assignee: Gabriel Beims Bräscher >Priority: Minor > > The quota memory tariff description in the CloudStack UI is wrong when > defines that the value is for "using 1MB or RAM for 1 hour". The quota > currency values reflect the value of a resource used per month, not an hour. > Quota divides the tariff value by the number of hours a month has (30 days - > 720 hours); then it calculates the credits used by a client based on the > amount of resources used per hour. The memory tariff description in the > interface is wrong and can guide users to configure values for an hour. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9697) Better error message on UI user if tries to shrink the VM ROOT volume size
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16111869#comment-16111869 ] ASF subversion and git services commented on CLOUDSTACK-9697: - Commit e43a4b9a09eb330ab148a4913c36e1ca2738adc3 in cloudstack's branch refs/heads/master from Rashmi D [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=e43a4b9 ] CLOUDSTACK-9697: Added better error message user if tries to shrink (#2145) the VM ROOT volume size Skip the API call altogether if the UI detects this and throw a more user friendly message > Better error message on UI user if tries to shrink the VM ROOT volume size > -- > > Key: CLOUDSTACK-9697 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9697 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.7.0, 4.8.0, 4.9.0 >Reporter: Rashmi Dixit >Assignee: Rashmi Dixit > Fix For: 4.9.1.0 > > > If a user tries to shrink the size of the root volume of a VM, the operation > fails with an error > Going from existing size of 10737418240 to size of 8589934592 would shrink > the volume.Need to sign off by supplying the shrinkok parameter with value of > true. > Instead, the UI can simply not allow shrink operation on the ROOT volume. > Throw a more user friendly message on the UI > "Shrink operation on ROOT volume not supported" -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9950) listUsageRecords doesnt return required fields
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16111862#comment-16111862 ] ASF subversion and git services commented on CLOUDSTACK-9950: - Commit b936feb108bd4f91a13f735f8ae2d8f47a926525 in cloudstack's branch refs/heads/master from mrunalinikankariya [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=b936feb ] CLOUDSTACK-9950:listUsageRecords doesnt return required fields (#2137) There is no cpuspeed, cpunumber or memory details in the listUsageRecords output as documented In DB (cloud_usage table) we have cpu_speed, cpu_cores and ram fileds, but these are not populated for all the VM's. These fields are only populated for the VM's which are deployed with custom service offerings. > listUsageRecords doesnt return required fields > -- > > Key: CLOUDSTACK-9950 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9950 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Reporter: mrunalini > > There is no cpuspeed, cpunumber or memory details in the listUsageRecords > output as documented > In DB (cloud_usage table) we have cpu_speed, cpu_cores and ram fileds, but > these are not populated for all the VM's. These fields are only populated for > the VM's which are deployed with custom service offerings. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9840) Datetime format of snapshot events is inconsistent with other events
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16111854#comment-16111854 ] ASF subversion and git services commented on CLOUDSTACK-9840: - Commit 43ae8e3503bc746f412e34e3fe6488e00def4ed0 in cloudstack's branch refs/heads/master from [~olemasle] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=43ae8e3 ] CLOUDSTACK-9840: Fix datetime format of snapshots events (#2008) Include the timezone in datetime format of snapshot events, to be consistent with every other events. "eventDateTime" was added by @chipchilders in commit 14ee684ce3 and was updated the same day to add the timezone (commit bf967eb622f) except for Snapshots. > Datetime format of snapshot events is inconsistent with other events > > > Key: CLOUDSTACK-9840 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9840 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1, 4.4.2, 4.4.3, 4.3.2, > 4.5.1, 4.4.4, 4.5.2, 4.6.0, 4.6.1, 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0, > 4.9.2.0, 4.9.1.0, 4.8.1.1, 4.9.0.1, 4.5.2.2 >Reporter: Olivier Lemasle >Assignee: Olivier Lemasle > > The timezone is not included in datetime format of snapshot events, whereas > it is included for other events. > "eventDateTime" was added by [~chipchilders] in commit 14ee684 and was > updated the same day to add the timezone (commit bf967eb) except for > Snapshots. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10011) Several issues with logrotation for CS Agents on Debians
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16111849#comment-16111849 ] ASF subversion and git services commented on CLOUDSTACK-10011: -- Commit 974e01ed088524a03b8de1d578f029a1b4c7e9f9 in cloudstack's branch refs/heads/master from [~The_Loeki] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=974e01e ] CLOUDSTACK-10011: Fix Agent logrotation (#2094) * CS Agent: Correct logrotation for agent log * CS Agent: Logrotate security_group as well * CS Agent: fix logrotation file perms so logrotate doesnt skip it > Several issues with logrotation for CS Agents on Debians > > > Key: CLOUDSTACK-10011 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10011 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: cloudstack-agent >Affects Versions: 4.9.0 >Reporter: Ronald van Zantvoort >Priority: Minor > > The logrotation configuration file doesn't work for a variety of reasons, > security_group logs aren't considered at all. > https://github.com/apache/cloudstack/pull/2094 > fixes the following things: > * wrong paths > * wrong files > * wrong acls > * some logs skipped -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10011) Several issues with logrotation for CS Agents on Debians
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16111846#comment-16111846 ] ASF subversion and git services commented on CLOUDSTACK-10011: -- Commit 974e01ed088524a03b8de1d578f029a1b4c7e9f9 in cloudstack's branch refs/heads/4.10 from [~The_Loeki] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=974e01e ] CLOUDSTACK-10011: Fix Agent logrotation (#2094) * CS Agent: Correct logrotation for agent log * CS Agent: Logrotate security_group as well * CS Agent: fix logrotation file perms so logrotate doesnt skip it > Several issues with logrotation for CS Agents on Debians > > > Key: CLOUDSTACK-10011 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10011 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: cloudstack-agent >Affects Versions: 4.9.0 >Reporter: Ronald van Zantvoort >Priority: Minor > > The logrotation configuration file doesn't work for a variety of reasons, > security_group logs aren't considered at all. > https://github.com/apache/cloudstack/pull/2094 > fixes the following things: > * wrong paths > * wrong files > * wrong acls > * some logs skipped -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10011) Several issues with logrotation for CS Agents on Debians
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16111843#comment-16111843 ] ASF subversion and git services commented on CLOUDSTACK-10011: -- Commit 974e01ed088524a03b8de1d578f029a1b4c7e9f9 in cloudstack's branch refs/heads/4.9 from [~The_Loeki] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=974e01e ] CLOUDSTACK-10011: Fix Agent logrotation (#2094) * CS Agent: Correct logrotation for agent log * CS Agent: Logrotate security_group as well * CS Agent: fix logrotation file perms so logrotate doesnt skip it > Several issues with logrotation for CS Agents on Debians > > > Key: CLOUDSTACK-10011 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10011 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: cloudstack-agent >Affects Versions: 4.9.0 >Reporter: Ronald van Zantvoort >Priority: Minor > > The logrotation configuration file doesn't work for a variety of reasons, > security_group logs aren't considered at all. > https://github.com/apache/cloudstack/pull/2094 > fixes the following things: > * wrong paths > * wrong files > * wrong acls > * some logs skipped -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9954) Unable to create service offering with networkrate=0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16111830#comment-16111830 ] ASF subversion and git services commented on CLOUDSTACK-9954: - Commit 7fea069e8ad8c694b18aed1ebbb73b3946297653 in cloudstack's branch refs/heads/master from [~sowjanya_patha] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=7fea069 ] CLOUDSTACK-9954 Unable to create service offering with networkrate=0 (#2142) Unable to create service offering with networkrate=0(Unlimited network throttling) with an error "Failed to create service offering xxx: specify the network rate value more than 0". > Unable to create service offering with networkrate=0 > > > Key: CLOUDSTACK-9954 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9954 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Sowjanya_Patha > > Unable to create service offering with networkrate=0(Unlimited network > throttling) with an error "Failed to create service offering xxx: specify > the network rate value more than 0". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-8961) Making the VPN user management more intutive
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16111822#comment-16111822 ] ASF subversion and git services commented on CLOUDSTACK-8961: - Commit 1b898d610c7c8fe6da34e299052d71faee64bbeb in cloudstack's branch refs/heads/master from [~nitinkumar.maharana] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=1b898d6 ] CLOUDSTACK-8961: Changes related to the UI of VPN Users management. (#2130) The current VPN users are added in the VPN tab inside the public IP after the VPN is enabled. For each network(for which VPN is supported and enabled), the VPN users are shared. As the Cloudstack doc says “ The account owner can create and manage users for their VPN. CloudStack does not use its account database for this purpose but uses a separate table. The VPN user database is shared across all the VPNs created by the account owner. All VPN users get access to all VPNs created by the account owner.” The current implementation of going inside each network and adding VPN users give the first feel as if the users are network based. To fix this, Shifted the VPN users to networks tab view. > Making the VPN user management more intutive > > > Key: CLOUDSTACK-8961 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8961 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kshitij Kansal > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
