[jira] [Created] (CLOUDSTACK-9415) Update previous release documentation to point users to new location for systemvm and builtin templates
Chiradeep Vittal created CLOUDSTACK-9415: Summary: Update previous release documentation to point users to new location for systemvm and builtin templates Key: CLOUDSTACK-9415 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9415 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Chiradeep Vittal Assignee: Rajani Karuturi Since download.cloud.com is being retired and all templates have been copied over to download.apachecloudstack.net, documentation for previous releases should have a section to patch templates.sql to point to the new location. I don't know how the documentation gets built actually. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9414) Provide better and modern "built-in" templates for 4.9.0 and beyond
Chiradeep Vittal created CLOUDSTACK-9414: Summary: Provide better and modern "built-in" templates for 4.9.0 and beyond Key: CLOUDSTACK-9414 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9414 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Template Affects Versions: 4.9.0 Reporter: Chiradeep Vittal The default (builtin) templates in ACS as encoded in setup/templates.sql are outdated, too big and sometimes do not support functions such as ssh key upload, password change and userdata. For example, the set of templates available in http://dl.openvm.eu/cloudstack/ While the reliability and capacity of the dl.openvm.eu server is not guaranteed, we can copy the latest template to the current default download location (download.apachecloudstack.net) and update templates.sql appropriately. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7404) Failed to start an instance when originating template has been deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14111656#comment-14111656 ] Chiradeep Vittal commented on CLOUDSTACK-7404: -- You might want to change VirtualMachineTemplate template = _entityMgr.findById(VirtualMachineTemplate.class, vm.getTemplateId()); to VirtualMachineTemplate template = _entityMgr.findByIdIncludingRemoved(VirtualMachineTemplate.class, vm.getTemplateId()); in orchestrateStart Failed to start an instance when originating template has been deleted -- Key: CLOUDSTACK-7404 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7404 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM, Management Server Affects Versions: 4.3.0 Environment: Ubuntu 12.04, KVM, basic networking, Cloudstack 4.3.0 Reporter: Loic Lambiel Hi, I have an issue were I cannot start an instance that was previously stopped when it's originating template has been deleted. Steps to reproduce: Deploy an instance Stop the instance Delete it's originating template Wait a few minutes Start the instance This was working ok on CS 4.0.x Management server log: 2014-08-22 14:01:51,163 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped to Starting with event: StartReques tedvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,164 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to start state for VM[User|VM-69b4c242-fcd1 -47ec-9afa-a798c370da5d] reservation id = 7bc0e976-6ba3-4b58-aa59-1eb011c1de4e 2014-08-22 14:01:51,167 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: 1 and podId: 1 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) advanceStart: DeploymentPlan is provided, using dcId:1, podId: 1, clu sterId: 1, hostId: 48, poolId: null 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, clusters: null, hosts: null 2014-08-22 14:01:51,177 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Starting to Stopped with event: OperationFa iledvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,188 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped to Starting with event: StartReques tedvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,189 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to start state for VM[User|VM-69b4c242-fcd1 -47ec-9afa-a798c370da5d] reservation id = 342cb1d2-fc32-4cdf-94c6-049cf16d5509 2014-08-22 14:01:51,191 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: 1 and podId: 1 2014-08-22 14:01:51,192 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, clusters: null, hosts: null 2014-08-22 14:01:51,198 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Starting to Stopped with event: OperationFa iledvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,210 ERROR [cloud.api.ApiAsyncJobDispatcher] (Job-Executor-87:ctx-17783fe6) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.StartVMCmd java.lang.NullPointerException at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:858) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:601) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:237) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:207) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3581) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2043) at
[jira] [Commented] (CLOUDSTACK-6202) Support signature version 3 in Cloudmonkey
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979098#comment-13979098 ] Chiradeep Vittal commented on CLOUDSTACK-6202: -- SignatureVersion=3 has been supported since 2011-08-10 Support signature version 3 in Cloudmonkey -- Key: CLOUDSTACK-6202 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6202 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Cloudmonkey Reporter: Chiradeep Vittal Assignee: Yichi Lu Cloudstack has signatureVersion=3 which supports an 'expires' timestamp. This enhances security by making replay attacks less likely. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6323) GetUser API always returns admin info
Chiradeep Vittal created CLOUDSTACK-6323: Summary: GetUser API always returns admin info Key: CLOUDSTACK-6323 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6323 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0, 4.1.0, 4.0.0, 4.3.0, 4.4.0 Reporter: Chiradeep Vittal Assignee: Kishan Kavala The annotation is API_KEY for the parameter apikey which automatically gets set to the requesters api key instead of the requested API key. The annotation should be USER_API_KEY instead. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6202) Support signature version 3 in Cloudmonkey
Chiradeep Vittal created CLOUDSTACK-6202: Summary: Support signature version 3 in Cloudmonkey Key: CLOUDSTACK-6202 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6202 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Cloudmonkey Reporter: Chiradeep Vittal Cloudstack has signatureVersion=3 which supports an 'expires' timestamp. This enhances security by making replay attacks less likely. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6031) Virtual Router count not displaying in UI Infrastructure Screen
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal updated CLOUDSTACK-6031: - Labels: 4.3.0 UI (was: 4.0.3 UI) Virtual Router count not displaying in UI Infrastructure Screen --- Key: CLOUDSTACK-6031 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6031 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Environment: CloudStack 4.0.3 RC3 running on CentOS 6.5, Advanced Zone, XenServer 6.2 Reporter: Geoff Higgibottom Priority: Critical Labels: 4.3.0, UI the Virtual Router count is not displaying in Infrastructure Screen, it is always at ZERO, even with multiple Virtual Routers running. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6031) Virtual Router count not displaying in UI Infrastructure Screen
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal updated CLOUDSTACK-6031: - Environment: CloudStack 4.3.0 RC3 running on CentOS 6.5, Advanced Zone, XenServer 6.2 (was: CloudStack 4.0.3 RC3 running on CentOS 6.5, Advanced Zone, XenServer 6.2) Virtual Router count not displaying in UI Infrastructure Screen --- Key: CLOUDSTACK-6031 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6031 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Environment: CloudStack 4.3.0 RC3 running on CentOS 6.5, Advanced Zone, XenServer 6.2 Reporter: Geoff Higgibottom Priority: Critical Labels: 4.3.0, UI the Virtual Router count is not displaying in Infrastructure Screen, it is always at ZERO, even with multiple Virtual Routers running. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-4575) [Portable IP] disassociating a transferred public IP is failing with exception
Chiradeep Vittal created CLOUDSTACK-4575: Summary: [Portable IP] disassociating a transferred public IP is failing with exception Key: CLOUDSTACK-4575 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4575 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Reporter: Chiradeep Vittal Steps to reproduce: 1. Have latest CloudStack with at least 2 advanced zone. 2. Go to Regions - local - portable IP - add an ip range like below Gateway : 10.147.33.1 startIp : 10.147.33.3 endip : 10.147.33.10 vlan : 33 subnet : 255.255.255.128 3. login as a non-ROOT admin username : dom1User1 password : password domain : dom1 4. create the following isolated networks in each zone - Network1Zone1 - Network1Zone2 5. deploy the following VMs in each network - vm1Zone1 connected to Network1Zone1 - vm1Zone2 connected to Network1Zone2 6. Acquire and associate a portable IP to Network1Zone1 7. enable staticNAT on the above portableIP and associate it to vm1Zone2 of Network1Zone2 and add firewall rule for ssh port Observations: (i) portable IP got transferred from Zone1 to Network1Zone2 successfully and able ssh to the portable IP without any issuees. 8. disassociate above portable IP from Network1Zone2. Observations: (ii) sequence of things happened as mentioned below - disassociate happened without any issues which cleaned the eth interface from router etc.., but, - it again initiated IPASSOC on its own for the same portable IP which resulted in the following error and thus this IP stuck in release state forever. (iii) above behaviour made all further IPASSOCs to fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4559) DeployVm failure on XCP (DevCloud2)
Chiradeep Vittal created CLOUDSTACK-4559: Summary: DeployVm failure on XCP (DevCloud2) Key: CLOUDSTACK-4559 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4559 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: XCP Affects Versions: 4.2.0 Environment: DevCloud2 Reporter: Chiradeep Vittal Assignee: edison su Priority: Critical While copying the VHD from NFS secondary to primary, there is an exception. 2013-08-28 15:29:45,585 WARN [xen.resource.XenServerStorageProcessor] (DirectAgent-2:null) Catch Exception com.cloud.utils.exception.CloudRuntimeException for template + due to com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for cmd: getVhdParent with args snapshotUuid: 36594ef2-18a4-4b90-894e-48145ddaebda, isISCSI: false, primaryStorageSRUuid: 9f3f9262-3f77-09cc-2df7-0d8475676260, due to There was a failure communicating with the plugin. com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for cmd: getVhdParent with args snapshotUuid: 36594ef2-18a4-4b90-894e-48145ddaebda, isISCSI: false, primaryStorageSRUuid: 9f3f9262-3f77-09cc-2df7-0d8475676260, due to There was a failure communicating with the plugin. at com.cloud.hypervisor.xen.resource.CitrixResourceBase.callHostPlugin(CitrixResourceBase.java:4188) at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.getVhdParent(XenServerStorageProcessor.java:823) at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copyTemplateToPrimaryStorage(XenServerStorageProcessor.java:868) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:70) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:617) at com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOssResource.java:143) at com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4559) DeployVm failure on XCP (DevCloud2)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13753828#comment-13753828 ] Chiradeep Vittal commented on CLOUDSTACK-4559: -- The root cause appears to be commit 4277bcf8f4a634f19dc41fdd8a8edd9b33c7a439 in scripts/vm/hypervisor/xenserver/xcposs/vmopsSnapshot DeployVm failure on XCP (DevCloud2) --- Key: CLOUDSTACK-4559 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4559 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: XCP Affects Versions: 4.2.0 Environment: DevCloud2 Reporter: Chiradeep Vittal Assignee: edison su Priority: Critical While copying the VHD from NFS secondary to primary, there is an exception. 2013-08-28 15:29:45,585 WARN [xen.resource.XenServerStorageProcessor] (DirectAgent-2:null) Catch Exception com.cloud.utils.exception.CloudRuntimeException for template + due to com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for cmd: getVhdParent with args snapshotUuid: 36594ef2-18a4-4b90-894e-48145ddaebda, isISCSI: false, primaryStorageSRUuid: 9f3f9262-3f77-09cc-2df7-0d8475676260, due to There was a failure communicating with the plugin. com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for cmd: getVhdParent with args snapshotUuid: 36594ef2-18a4-4b90-894e-48145ddaebda, isISCSI: false, primaryStorageSRUuid: 9f3f9262-3f77-09cc-2df7-0d8475676260, due to There was a failure communicating with the plugin. at com.cloud.hypervisor.xen.resource.CitrixResourceBase.callHostPlugin(CitrixResourceBase.java:4188) at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.getVhdParent(XenServerStorageProcessor.java:823) at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copyTemplateToPrimaryStorage(XenServerStorageProcessor.java:868) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:70) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:617) at com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOssResource.java:143) at com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4563) Initial zone wizard UI label issue
Chiradeep Vittal created CLOUDSTACK-4563: Summary: Initial zone wizard UI label issue Key: CLOUDSTACK-4563 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4563 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.0 Reporter: Chiradeep Vittal On the 'add secondary storage' wizard step, the label for the dropdown shows 'label.provider' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4564) Initial zone creation wizard does not guide Guest Ip range correctly
Chiradeep Vittal created CLOUDSTACK-4564: Summary: Initial zone creation wizard does not guide Guest Ip range correctly Key: CLOUDSTACK-4564 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4564 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.0 Reporter: Chiradeep Vittal During the wizard, it asks for Guest IP range without any guidance. The only range that will work is if the range is within the pod ip range. Any other range will lead to a lot of pain. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4532) updateConfiguration fails to validate type and range of certain configuration data
Chiradeep Vittal created CLOUDSTACK-4532: Summary: updateConfiguration fails to validate type and range of certain configuration data Key: CLOUDSTACK-4532 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4532 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Chiradeep Vittal Assignee: Alex Huang Since some keys moved to ConfigDepot, updateConfiguration API is no longer able to validate the type and range of some config values -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4132) current dnsmasq config does not allow guest virtual machines(clients) to update its hostnames with a DNS server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739020#comment-13739020 ] Chiradeep Vittal commented on CLOUDSTACK-4132: -- Looks OK to me. Here's what needs to be checked: 1. With dhcp-client-update, does dnsmasq now respond to dns requests for the windows hosts. That is, if the windows client vm hostname is foo.cs1cloud.internal then can dnsmasq now resolve this in a shared or isolated network? Check from another vm in the same network 2. Ditto for linux client vms current dnsmasq config does not allow guest virtual machines(clients) to update its hostnames with a DNS server Key: CLOUDSTACK-4132 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4132 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.0 Reporter: Ram Ganesh Assignee: Bharat Kumar Priority: Critical Fix For: 4.2.0 Current dnsmasq.conf does not have dhcp-client-update flag enabled thereby preventing say Windows clients to update AD servers with its hostname. We should enhance the config file to support this. More information about this parameter can be found here - http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4184) VM password reset works inconsistently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737669#comment-13737669 ] Chiradeep Vittal commented on CLOUDSTACK-4184: -- #1. if you add fork to the TCP_LISTEN option of SOCAT, then it will fork a process for each connection, allowing more parallelism #2. There is a bug in serve_password.sh (see below) #3. You can also add 'su=nobody' to the TCP4_LISTEN option to increase the security of the procedure (after all we are blindly accepting strings from potentially untrusted vm) diff --git a/patches/systemvm/debian/config/opt/cloud/bin/passwd_server_ip b/patches/systemvm/debian/config/opt/cloud/bin/passwd_server_ip index 8d62dff..4622860 100755 --- a/patches/systemvm/debian/config/opt/cloud/bin/passwd_server_ip +++ b/patches/systemvm/debian/config/opt/cloud/bin/passwd_server_ip @@ -20,7 +20,7 @@ addr=$1; while [ $ENABLED == 1 ] do - socat -lf /var/log/cloud.log TCP4-LISTEN:8080,reuseaddr,crnl,bind=$addr SYSTEM:/opt/cloud/bin/serve_password.sh \\$SOCAT_PEERADDR\ + socat -lf /var/log/cloud.log TCP4-LISTEN:8080,reuseaddr,su=nobody,fork,crnl,bind=$addr SYSTEM:/opt/cloud/bin/serve_password.sh \\$SOCAT_PEERADDR\ rc=$? if [ $rc -ne 0 ] diff --git a/patches/systemvm/debian/config/opt/cloud/bin/serve_password.sh b/patches/systemvm/debian/config/opt/cloud/bin/serve_password.sh index b829b54..a3a2732 100755 --- a/patches/systemvm/debian/config/opt/cloud/bin/serve_password.sh +++ b/patches/systemvm/debian/config/opt/cloud/bin/serve_password.sh @@ -62,7 +62,7 @@ do break fi - request=$(echo $input | grep DomU_Request: | cut -d: -f2 | sed 's/^[ \t]*//') + request=$(echo $input | grep DomU_Request: | cut -d: -f2 | sed 's/^[ \t]*//') if [ $request != ] then VM password reset works inconsistently -- Key: CLOUDSTACK-4184 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4184 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.0 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Priority: Blocker Fix For: 4.2.0 Attachments: cloud-set-guest-password, pass4.pcap, pass.pcap, passwords, test.log, test.log 1. When password reset fails for one vm then password reset is not working then on. 2. In router the password entries are made properly. 3. serve password script is giving the password correctly but the vm did not recieved it Here are the logs: === serve_password.sh debug logs + PASSWD_FILE=/var/cache/cloud/passwords + ip=10.1.1.143 + logger -t cloud 'serve_password called to service a request for 10.1.1.143.' + read input + '[' 'GET / HTTP/1.0' == '' ']' ++ sed 's/^[ \t]*//' ++ cut -d: -f2 ++ grep DomU_Request: ++ echo GET / HTTP/1.0 + request= + '[' '' '!=' '' ']' + read input + '[' 'User-Agent: Wget/1.11.4 Red Hat modified' == '' ']' ++ sed 's/^[ \t]*//' ++ cut -d: -f2 ++ grep DomU_Request: ++ echo User-Agent: Wget/1.11.4 Red Hat modified + request= + '[' '' '!=' '' ']' + read input + '[' 'Accept: */*' == '' ']' ++ sed 's/^[ \t]*//' ++ cut -d: -f2 ++ grep DomU_Request: ++ echo Accept: redundant_router/arping_gateways.sh.templ redundant_router/backup.sh.templ redundant_router/check_bumpup.sh redundant_router/check_heartbeat.sh.templ redundant_router/checkrouter.sh.templ redundant_router/conntrackd.conf.templ redundant_router/disable_pubip.sh redundant_router/enable_pubip.sh.templ redundant_router/fault.sh.templ redundant_router/heartbeat.sh.templ redundant_router/keepalived.conf.templ redundant_router/master.sh.templ redundant_router/primary-backup.sh.templ redundant_router/services.sh + request= + '[' '' '!=' '' ']' + read input + '[' 'Host: 10.1.1.1:8080' == '' ']' ++ sed 's/^[ \t]*//' ++ cut -d: -f2 ++ grep DomU_Request: ++ echo Host: 10.1.1.1:8080 + request= + '[' '' '!=' '' ']' + read input + '[' 'Connection: Keep-Alive' == '' ']' ++ sed 's/^[ \t]*//' ++ cut -d: -f2 ++ grep DomU_Request: ++ echo Connection: Keep-Alive + request= + '[' '' '!=' '' ']' + read input + '[' 'DomU_Request: send_my_password' == '' ']' ++ sed 's/^[ \t]*//' ++ cut -d: -f2 ++ grep DomU_Request: ++ echo DomU_Request: send_my_password + request=send_my_password + '[' send_my_password '!=' '' ']' + break + '[' send_my_password == send_my_password ']' ++ get_value /var/cache/cloud/passwords 10.1.1.143 ++ local filename=/var/cache/cloud/passwords ++ local keyname=10.1.1.143 ++ cut -d= -f2 ++ grep -i 10.1.1.143= /var/cache/cloud/passwords + password=bG9wrskhw + '[' bG9wrskhw == '' ']' + logger -t cloud 'serve_password sent a
[jira] [Created] (CLOUDSTACK-4163) QuickCloud : fix problem introduced by object store work
Chiradeep Vittal created CLOUDSTACK-4163: Summary: QuickCloud : fix problem introduced by object store work Key: CLOUDSTACK-4163 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4163 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: Chiradeep Vittal Assignee: Donal Lafferty Fix For: 4.2.0 Object store work changed the semantics of the NFS - management server API. MS no longer accepts 'Answer' as an Answer, but expects the specific subclass of Answer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-4163) QuickCloud : fix problem introduced by object store work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal resolved CLOUDSTACK-4163. -- Resolution: Fixed Fix Version/s: Future QuickCloud : fix problem introduced by object store work Key: CLOUDSTACK-4163 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4163 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: Chiradeep Vittal Assignee: Donal Lafferty Fix For: 4.2.0, Future Object store work changed the semantics of the NFS - management server API. MS no longer accepts 'Answer' as an Answer, but expects the specific subclass of Answer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2492) System VM Clock Drift
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal resolved CLOUDSTACK-2492. -- Resolution: Fixed On the 4.2 systemvm $ dpkg --get-selections | grep ntp ntp install ps -ef | grep ntp reveals ntpd running System VM Clock Drift - Key: CLOUDSTACK-2492 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2492 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: ISO Affects Versions: pre-4.0.0 Environment: devcloud/Xen Reporter: John Burwell Assignee: Chiradeep Vittal Priority: Blocker Labels: documentaion Fix For: 4.2.0 Testing of S3-backed Secondary Storage has revealed that the SSVM (and likely all other system VMs) have no provision for clock synchronization (e.g. NTP to dom0 for Xen, vmware-tools for VMWare, etc). In particular, the S3 protocol is sensitive to drift between clients and S3. As an example, the following is the stack trace caused by clock drift S3: 2013-05-14 06:51:55,400 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) Putting directory /mnt/SecStorage/93fd0cb0-033b-3248-bcd0-ef6d460635ef/template/tmpl/1/5 in S3 bucket jsb-cloudstack-templates. 2013-05-14 06:51:55,401 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) Creating S3 client with configuration: [protocol: https, connectionTimeOut: 5, maxErrorRetry: 3, socketTimeout: 5] 2013-05-14 06:51:55,403 DEBUG [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-3:) Determining key using account id 1 and template id 5 2013-05-14 06:51:55,403 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) Putting file /mnt/SecStorage/93fd0cb0-033b-3248-bcd0-ef6d460635ef/template/tmpl/1/5/template.properties into bucket jsb-cloudstack-templates with key template/tmpl/1/5/template.properties. 2013-05-14 06:51:55,578 ERROR [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-3:) Failed to upload template id 5 Status Code: 403, AWS Service: Amazon S3, AWS Request ID: 970A274E132A9ACB, AWS Error Code: RequestTimeTooSkewed, AWS Error Message: The difference between the request time and the current time is too large., S3 Extended Request ID: 9w8a6YBxTn+WlBg96s9stxWuuP8oQ7ksZtg6++wVRHJfE2qmucrilhoEJVetJui4 at com.amazonaws.http.AmazonHttpClient.handleErrorResponse(AmazonHttpClient.java:609) at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:309) at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:164) at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:2863) at com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:1100) at com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:963) at com.cloud.utils.S3Utils.putDirectory(S3Utils.java:282) at com.cloud.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:414) at com.cloud.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:212) at com.cloud.agent.Agent.processRequest(Agent.java:525) at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852) at com.cloud.utils.nio.Task.run(Task.java:83) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) In addition to impacting S3, this clock drift also makes log correlation between the management server and system VMs very difficult, if not, impossible. Finally, there are suspicions that the clock drift could also impact operation of console proxy and virtual router VMs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2492) System VM Clock Drift
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665418#comment-13665418 ] Chiradeep Vittal commented on CLOUDSTACK-2492: -- On the 4.2 systemvm $ dpkg --get-selections | grep ntp ntp install ps -ef | grep ntp reveals ntpd running System VM Clock Drift - Key: CLOUDSTACK-2492 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2492 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: ISO Affects Versions: pre-4.0.0 Environment: devcloud/Xen Reporter: John Burwell Assignee: Chiradeep Vittal Priority: Blocker Labels: documentaion Fix For: 4.2.0 Testing of S3-backed Secondary Storage has revealed that the SSVM (and likely all other system VMs) have no provision for clock synchronization (e.g. NTP to dom0 for Xen, vmware-tools for VMWare, etc). In particular, the S3 protocol is sensitive to drift between clients and S3. As an example, the following is the stack trace caused by clock drift S3: 2013-05-14 06:51:55,400 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) Putting directory /mnt/SecStorage/93fd0cb0-033b-3248-bcd0-ef6d460635ef/template/tmpl/1/5 in S3 bucket jsb-cloudstack-templates. 2013-05-14 06:51:55,401 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) Creating S3 client with configuration: [protocol: https, connectionTimeOut: 5, maxErrorRetry: 3, socketTimeout: 5] 2013-05-14 06:51:55,403 DEBUG [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-3:) Determining key using account id 1 and template id 5 2013-05-14 06:51:55,403 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) Putting file /mnt/SecStorage/93fd0cb0-033b-3248-bcd0-ef6d460635ef/template/tmpl/1/5/template.properties into bucket jsb-cloudstack-templates with key template/tmpl/1/5/template.properties. 2013-05-14 06:51:55,578 ERROR [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-3:) Failed to upload template id 5 Status Code: 403, AWS Service: Amazon S3, AWS Request ID: 970A274E132A9ACB, AWS Error Code: RequestTimeTooSkewed, AWS Error Message: The difference between the request time and the current time is too large., S3 Extended Request ID: 9w8a6YBxTn+WlBg96s9stxWuuP8oQ7ksZtg6++wVRHJfE2qmucrilhoEJVetJui4 at com.amazonaws.http.AmazonHttpClient.handleErrorResponse(AmazonHttpClient.java:609) at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:309) at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:164) at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:2863) at com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:1100) at com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:963) at com.cloud.utils.S3Utils.putDirectory(S3Utils.java:282) at com.cloud.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:414) at com.cloud.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:212) at com.cloud.agent.Agent.processRequest(Agent.java:525) at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852) at com.cloud.utils.nio.Task.run(Task.java:83) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) In addition to impacting S3, this clock drift also makes log correlation between the management server and system VMs very difficult, if not, impossible. Finally, there are suspicions that the clock drift could also impact operation of console proxy and virtual router VMs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-1813) QuickCloud - faster cloud startup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal resolved CLOUDSTACK-1813. -- Resolution: Fixed Commits are bf56403d828aa50c0650cc41cdc51aae79b1c19e 2e6c65fd34dc5f4f885c12a4e5469b505975685d 271d232d620f27c6b8b10bc85f849563c528e3ae 778a59fbf6bc8957771718123079bd8a2707affa 5ff8bcaa2e16035197c6d58bb212ba1696411dce 936973aff7ba372abe442a7a40e112219fba7570 c5b11df6b78dd755acc4141dc2063608e581996d a806ce43d32e8d5ac064b79dd623c01be4489126 1d70b9ea77fd1e9fce98f7d9cd5fd92cfe444c39 21b4635948152710935ba420cee50b823fd7a2b4 3d78019e571677f1b2ac87acebe6192f2a4fa96c 790d2ce82ef6b1ac910124c8c9ab519e2431e622 16790446e51645dc3e2623ebf57f88e0cfe2c89c e7983b2569abe0304a0b8d720c4c85c4561a QuickCloud - faster cloud startup - Key: CLOUDSTACK-1813 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1813 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller, Storage Controller Reporter: Chiradeep Vittal Assignee: Chiradeep Vittal Fix For: 4.2.0 https://cwiki.apache.org/confluence/display/CLOUDSTACK/QuickCloud To enable a cloud to boot with services managed and running on non-cloudstack-managed servers To enable a development environment based on DevCloud (QuickCloud) that eschews the use of system vms To allow the cloud administrator to choose to provide these services the old way after booting in the QuickCloud fashion -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-2521) System template build failed in Jenkins.cloudstack.org
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal closed CLOUDSTACK-2521. Resolution: Fixed Fix Version/s: 4.2.0 see above System template build failed in Jenkins.cloudstack.org -- Key: CLOUDSTACK-2521 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2521 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Projects Affects Versions: 4.2.0 Reporter: Rayees Namathponnan Priority: Critical Fix For: 4.2.0 System template build failed in Jenkins.cloudstack.org more than 2 weeks, We dont have any template after below fix https://issues.apache.org/jira/browse/CLOUDSTACK-2324 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-2324) [XenServer][SystemVM] [Automation] haproxy is not running on the virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal closed CLOUDSTACK-2324. Resolution: Fixed see commit log above [XenServer][SystemVM] [Automation] haproxy is not running on the virtual router --- Key: CLOUDSTACK-2324 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2324 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Environment: commit # 09af15035b9febe6f55e73a1389f950ab042564f Reporter: venkata swamybabu budumuru Priority: Blocker Fix For: 4.2.0 Attachments: logs.tgz Steps to reproduce : 1. Have at least one advanced zone with Xen cluster 2. Have a latest systemVM template version I used here is : Cloudstack Release 4.2.0 Wed Apr 10 07:46:46 UTC 2013 3. deploy a VM connected to isolated network (which will automatically spin a virtual router) 4. verify whether haproxy is running on the virtual router or not Observations: (i) root@r-28-VM:~# ps -aef | grep -i haproxy root 7689 7457 0 14:21 pts/100:00:00 grep -i haproxy (ii) find / -name *haproxy* /etc/haproxy /etc/haproxy/haproxy.cfg.new /etc/haproxy/haproxy.cfg /etc/logrotate.d/haproxy /var/lib/haproxy /var/log/haproxy.log (iii) here is the snippet from /var/log/messages of virtual router May 3 12:40:10 r-28-VM cloud: Starting ssh May 3 12:40:10 r-28-VM cloud: Starting haproxy May 3 12:40:10 r-28-VM cloud: Starting apache2 May 3 12:40:10 r-28-VM cloud: Starting dnsmasq May 3 12:40:10 r-28-VM cloud: Starting cloud-passwd-srvr May 3 12:40:10 r-28-VM cloud: Stopping cloud May 3 12:40:11 r-28-VM cloud: Stopping nfs-common May 3 12:40:11 r-28-VM cloud: Stopping portmap May 3 12:40:11 r-28-VM cloud: Stopping keepalived May 3 12:40:11 r-28-VM cloud: Stopping conntrackd (iv) snippet from /var/log/cloud.log Fri May 3 12:38:50 UTC 2013 Enable service dnsmasq = 1 Fri May 3 12:38:50 UTC 2013 Enable service haproxy = 1 Attaching the /var/log folder from router VM and mgmt server logs to the bug. (vi) Because of the above issue, unable to create LB rules. when tried it throws the following error in the SMlog of the xenserver. Here is the snippet from /var/log/SMLog on the xenserver. + local cfg=/tmp/169_254_2_213.cfg + scp -P 3922 -q -o StrictHostKeyChecking=no -i /root/.ssh/id_rsa.cloud /tmp/169_254_2_213.cfg root@169.254.2.213:/etc/haproxy/haproxy.cfg.new + return 0 + '[' 0 -gt 0 ']' + ssh -p 3922 -q -o StrictHostKeyChecking=no -i /root/.ssh/id_rsa.cloud root@169.254.2.213 '/root/loadbalancer.sh -i 169.254.2.213 -f /tmp/169_254_2_213.cfg -a 10.147.44.61:22:, -s 10.147.44.64:8081:0/0:,,' mv: cannot stat `/var/run/haproxy.pid': No such file or directory cat: /var/run/haproxy.pid.old: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] /root/reconfigLB.sh: line 28: haproxy: command not found cat: /var/run/haproxy.pid.old: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] mv: cannot stat `/var/run/haproxy.pid.old': No such file or directory + exit 1 ' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-1994) [SSVM] Unable to start agent: Resource class not found: org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource due to: java.lang.ClassNotFoundException: o
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal closed CLOUDSTACK-1994. Resolution: Fixed commit f35272b6c585f85c5c0f1e92f99b8224feceb29e Author: Kelven Yang kelv...@gmail.com Date: Thu Apr 11 11:41:10 2013 -0700 Fix the systemvm packaging issue [SSVM] Unable to start agent: Resource class not found: org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource due to: java.lang.ClassNotFoundException: org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource --- Key: CLOUDSTACK-1994 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1994 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Environment: commit 97c2f7d0c4b330f3456e8c1b5236e280b9931197 Reporter: venkata swamybabu budumuru Priority: Blocker Fix For: 4.2.0 Attachments: logs.tgz Steps to reproduce : 1. Have the latest master and deploy an advanced zone with Xen Cluster 2. use system vm template systemvmtemplate-2013-03-27-master-xen.vhd.bz2 from http://jenkins.cloudstack.org 3. verify whether system vms come up fine or not Observations : (i) both v-2-VM and s-1-VM are shown in running state (ii) cloud.host table doesn't show the SSVM but, shows the console proxy in host table. (iii) default centos template download doesn't happen. New template registration as well fails to download (iv) Here is the snippet from SSVM:/var/log/cloud/cloud.out log4j:WARN No appenders could be found for logger (org.apache.commons.httpclient.params.DefaultHttpParams). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. 08:15:40,493 ERROR AgentShell:610 - Unable to start agent: Resource class not found: org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource due to: java.lang.ClassNotFoundException: org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource Unable to start agent: Resource class not found: org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource due to: java.lang.ClassNotFoundException: org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource (v) Based on the above log, it looks like agent on the ssvm is failing to start. ps -aef | grep -i java doesn't show up an process. Attaching all the required logs to bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-524) http proxy used by ssvm (secstorage.proxy) NOT working
[
https://issues.apache.org/jira/browse/CLOUDSTACK-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chiradeep Vittal closed CLOUDSTACK-524.
---
Resolution: Fixed
Assignee: Chiradeep Vittal (was: Prasanna Santhanam)
in some cases (especially the built-in CentOS template), the template
downloader does not use the configured http proxy The DownloadProgress command
is used to restart failed or stuck download jobs -- It would not include the
proxy information, unlike the DownloadCommand which always did
ref 67a99cb
http proxy used by ssvm (secstorage.proxy) NOT working
--
Key: CLOUDSTACK-524
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-524
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Install and Setup
Affects Versions: 4.0.0
Environment: Ubuntu 12.04 - package installation
Reporter: Dimitri Desmidt
Assignee: Chiradeep Vittal
Priority: Critical
Fix For: 4.2.0
In my lab, the SSVM has access to Internet ONLY via a Proxy.
I configured for that the Global Setting secstorage.proxy with the value
http://proxy.xyz.com:3128; (without the quotes ).
Then I restarted the cloud management and destroyed the SSVM.
The new SSVM tries to download again
http://download.cloud.com/templates/builtin/centos56-x86_64.vhd.bz2;.
This still fails and when I look at the Management Log, it looks like there
is still no Proxy used:
2012-11-20 06:44:31,438 DEBUG [agent.transport.Request] (Timer-4:null) Seq
18-550436874: Sending { Cmd , MgmtId: 345051959742, via: 18, Ver: v1, Flags:
100011,
[{storage.DownloadProgressCommand:{jobId:38d18cba-470a-46da-821d-37cfacd2bb40,request:GET_STATUS,hvm:false,description:CentOS
5.6(64-bit) no GUI
(XenServer),checksum:905cec879afd9c9d22ecc8036131a180,maxDownloadSizeInBytes:53687091200,id:5,resourceType:TEMPLATE,url:http://download.cloud.com/templates/builtin/centos56-x86_64.vhd.bz2,format:VHD,accountId:1,name:centos56-x86_64-xen,secUrl:nfs://10.30.1.3/export/secondary,wait:0}}]
}
2012-11-20 06:44:31,485 DEBUG [agent.transport.Request]
(AgentManager-Handler-2:null) Seq 18-550436874: Processing: { Ans: , MgmtId:
345051959742, via: 18, Ver: v1, Flags: 10,
[{storage.DownloadAnswer:{jobId:38d18cba-470a-46da-821d-37cfacd2bb40,downloadPct:0,errorString:
,downloadStatus:NOT_DOWNLOADED,downloadPath:/mnt/SecStorage/ff53ffad-7c5d-382f-942c-e527528c5699/template/tmpl/1/5/dnld5122201514511320578tmp_,templateSize:0,templatePhySicalSize:0,checkSum:905cec879afd9c9d22ecc8036131a180,result:false,details:
,wait:0}}] }
Conclusion;
Looks like the Global Setting information is NOT applied :-(
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-1955) Packaging: package cloudstack-sysdaemons
Chiradeep Vittal created CLOUDSTACK-1955: Summary: Packaging: package cloudstack-sysdaemons Key: CLOUDSTACK-1955 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1955 Project: CloudStack Issue Type: Sub-task Security Level: Public (Anyone can view this level - this is the default.) Reporter: Chiradeep Vittal Copying systemvm.zip around and starting daemons without some kind of init script isn't ideal. Probably have a meta-package (perhaps the root cloudstack package) that would require cloudstack-sysdaemons. A person would still be able to 'yum install cloudstack-server and not get those dameons, but the 'default' install (yum install cloudstack) would have SS/CP as a dependency and thus have it installed and started. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-524) http proxy used by ssvm (secstorage.proxy) NOT working
[
https://issues.apache.org/jira/browse/CLOUDSTACK-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13622736#comment-13622736
]
Chiradeep Vittal commented on CLOUDSTACK-524:
-
Sounds counter-intuitive, but you should be able to initiate download of *new*
template - you can give the same URL of the original built-in template and it
should use the proxy.
http proxy used by ssvm (secstorage.proxy) NOT working
--
Key: CLOUDSTACK-524
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-524
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Install and Setup
Affects Versions: 4.0.0
Environment: Ubuntu 12.04 - package installation
Reporter: Dimitri Desmidt
Assignee: Prasanna Santhanam
Priority: Critical
Fix For: 4.2.0
In my lab, the SSVM has access to Internet ONLY via a Proxy.
I configured for that the Global Setting secstorage.proxy with the value
http://proxy.xyz.com:3128; (without the quotes ).
Then I restarted the cloud management and destroyed the SSVM.
The new SSVM tries to download again
http://download.cloud.com/templates/builtin/centos56-x86_64.vhd.bz2;.
This still fails and when I look at the Management Log, it looks like there
is still no Proxy used:
2012-11-20 06:44:31,438 DEBUG [agent.transport.Request] (Timer-4:null) Seq
18-550436874: Sending { Cmd , MgmtId: 345051959742, via: 18, Ver: v1, Flags:
100011,
[{storage.DownloadProgressCommand:{jobId:38d18cba-470a-46da-821d-37cfacd2bb40,request:GET_STATUS,hvm:false,description:CentOS
5.6(64-bit) no GUI
(XenServer),checksum:905cec879afd9c9d22ecc8036131a180,maxDownloadSizeInBytes:53687091200,id:5,resourceType:TEMPLATE,url:http://download.cloud.com/templates/builtin/centos56-x86_64.vhd.bz2,format:VHD,accountId:1,name:centos56-x86_64-xen,secUrl:nfs://10.30.1.3/export/secondary,wait:0}}]
}
2012-11-20 06:44:31,485 DEBUG [agent.transport.Request]
(AgentManager-Handler-2:null) Seq 18-550436874: Processing: { Ans: , MgmtId:
345051959742, via: 18, Ver: v1, Flags: 10,
[{storage.DownloadAnswer:{jobId:38d18cba-470a-46da-821d-37cfacd2bb40,downloadPct:0,errorString:
,downloadStatus:NOT_DOWNLOADED,downloadPath:/mnt/SecStorage/ff53ffad-7c5d-382f-942c-e527528c5699/template/tmpl/1/5/dnld5122201514511320578tmp_,templateSize:0,templatePhySicalSize:0,checkSum:905cec879afd9c9d22ecc8036131a180,result:false,details:
,wait:0}}] }
Conclusion;
Looks like the Global Setting information is NOT applied :-(
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1389) Interactive Password Prompts during Management Server Startup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal updated CLOUDSTACK-1389: - Fix Version/s: (was: 4.1.0) 4.2.0 Interactive Password Prompts during Management Server Startup - Key: CLOUDSTACK-1389 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1389 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.0 Environment: devcloud Reporter: John Burwell Assignee: Abhinandan Prateek Labels: security Fix For: 4.2.0 When starting the management with no SSL certificate present, the system attempts to run a shell script that requires interactive password entry. Executing the following steps with a user that is either non-sudoer or a sudoer that requires a password authentication to perform sudo actions (and who has not already authenticated to sudo), execute the following commands from root directory of a cloudstack/4.1 checkout: 1. mvn -P developer clean install 2. mvn -pl :cloud-client-ui jetty:run During the startup process, the management server will not find the cloud.keystore in the the client/target/cloud-client-ui-4.1-SNAPSHOT/WEB-INF/classes directory, and attempt to generate an SSL certificate using the following shell scripts: sudo keytool -genkey -keystore /Users/jburwell/Documents/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore -store pass vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname cn=Cloudstack User,ou=0.8.31,o=0.8.31,c=Unknown The following is a capture of the script timeout error from the vmops.log: 2013-02-27 09:52:17,157 INFO [cloud.server.ConfigurationServerImpl] (Timer-2:null) SSL keystore located at /Users/jburwell/Docum ents/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore 2013-02-27 09:52:17,176 DEBUG [utils.script.Script] (Timer-2:null) Executing: sudo keytool -genkey -keystore /Users/jburwell/Docu ments/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore -store pass vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname cn=Cloudstack User,ou=0.8.31,o=0.8.31,c=Unknown 2013-02-27 09:52:22,188 WARN [utils.script.Script] (Script-1:null) Interrupting script. 2013-02-27 09:52:22,190 WARN [utils.script.Script] (Timer-2:null) Timed out: sudo keytool -genkey -keystore /Users/jburwell/Docu ments/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore -store pass vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname cn=Cloudstack User,ou=0.8.31,o=0.8.31,c=Unknown . Ou tput is: dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid 2013-02-27 09:52:22,191 WARN [cloud.server.ConfigurationServerImpl] (Timer-2:null) Would use fail-safe keystore to continue. java.io.IOException: Fail to generate certificate!: timeout at com.cloud.server.ConfigurationServerImpl.generateDefaultKeystore(ConfigurationServerImpl.java:490) at com.cloud.server.ConfigurationServerImpl.updateSSLKeystore(ConfigurationServerImpl.java:511) at com.cloud.server.ConfigurationServerImpl.persistDefaultValues(ConfigurationServerImpl.java:272) at com.cloud.server.ConfigurationServerImpl.configure(ConfigurationServerImpl.java:144) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:319) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:8 0) at com.cloud.utils.db.TransactionContextBuilder.AroundAnyMethod(TransactionContextBuilder.java:37) at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) at
[jira] [Reopened] (CLOUDSTACK-1389) Interactive Password Prompts during Management Server Startup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal reopened CLOUDSTACK-1389: -- This is still a problem. Let's fix in 4.2 Interactive Password Prompts during Management Server Startup - Key: CLOUDSTACK-1389 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1389 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.0 Environment: devcloud Reporter: John Burwell Assignee: Abhinandan Prateek Labels: security Fix For: 4.2.0 When starting the management with no SSL certificate present, the system attempts to run a shell script that requires interactive password entry. Executing the following steps with a user that is either non-sudoer or a sudoer that requires a password authentication to perform sudo actions (and who has not already authenticated to sudo), execute the following commands from root directory of a cloudstack/4.1 checkout: 1. mvn -P developer clean install 2. mvn -pl :cloud-client-ui jetty:run During the startup process, the management server will not find the cloud.keystore in the the client/target/cloud-client-ui-4.1-SNAPSHOT/WEB-INF/classes directory, and attempt to generate an SSL certificate using the following shell scripts: sudo keytool -genkey -keystore /Users/jburwell/Documents/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore -store pass vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname cn=Cloudstack User,ou=0.8.31,o=0.8.31,c=Unknown The following is a capture of the script timeout error from the vmops.log: 2013-02-27 09:52:17,157 INFO [cloud.server.ConfigurationServerImpl] (Timer-2:null) SSL keystore located at /Users/jburwell/Docum ents/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore 2013-02-27 09:52:17,176 DEBUG [utils.script.Script] (Timer-2:null) Executing: sudo keytool -genkey -keystore /Users/jburwell/Docu ments/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore -store pass vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname cn=Cloudstack User,ou=0.8.31,o=0.8.31,c=Unknown 2013-02-27 09:52:22,188 WARN [utils.script.Script] (Script-1:null) Interrupting script. 2013-02-27 09:52:22,190 WARN [utils.script.Script] (Timer-2:null) Timed out: sudo keytool -genkey -keystore /Users/jburwell/Docu ments/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore -store pass vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname cn=Cloudstack User,ou=0.8.31,o=0.8.31,c=Unknown . Ou tput is: dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid 2013-02-27 09:52:22,191 WARN [cloud.server.ConfigurationServerImpl] (Timer-2:null) Would use fail-safe keystore to continue. java.io.IOException: Fail to generate certificate!: timeout at com.cloud.server.ConfigurationServerImpl.generateDefaultKeystore(ConfigurationServerImpl.java:490) at com.cloud.server.ConfigurationServerImpl.updateSSLKeystore(ConfigurationServerImpl.java:511) at com.cloud.server.ConfigurationServerImpl.persistDefaultValues(ConfigurationServerImpl.java:272) at com.cloud.server.ConfigurationServerImpl.configure(ConfigurationServerImpl.java:144) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:319) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:8 0) at com.cloud.utils.db.TransactionContextBuilder.AroundAnyMethod(TransactionContextBuilder.java:37) at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) at
