[jira] [Updated] (CLOUDSTACK-4783) Unable to see a derieved template if the parent template is deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-4783: --- Assignee: Kishan Kavala > Unable to see a derieved template if the parent template is deleted > --- > > Key: CLOUDSTACK-4783 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4783 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.2.0 >Reporter: Nitin Mehta >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.2.1 > > > Functionality required/broken – For a template, if the parent template info > (template Id) is provided in the listTemplates API then one should be able to > query for the parent template id as well (whether existing/removed doesn't > matter) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4783) Unable to see a derieved template if the parent template is deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-4783: --- Assignee: (was: Harikrishna Patnala) > Unable to see a derieved template if the parent template is deleted > --- > > Key: CLOUDSTACK-4783 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4783 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.2.0 >Reporter: Nitin Mehta >Priority: Critical > Fix For: 4.2.1 > > > Functionality required/broken – For a template, if the parent template info > (template Id) is provided in the listTemplates API then one should be able to > query for the parent template id as well (whether existing/removed doesn't > matter) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Reopened] (CLOUDSTACK-1637) LDAP:UI related issues
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sadhu suresh reopened CLOUDSTACK-1637: -- registered details shown in the UI but quick view is not showing the registered details. > LDAP:UI related issues > -- > > Key: CLOUDSTACK-1637 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1637 > 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 >Reporter: sadhu suresh > Fix For: 4.3.0 > > > case 1:Clear the port number value when we check the ssl check box. > when we check the SSL ,Port value shows 389 but required value is 636. > expected result: when ssl enabled ,clear the default389 value from port field > and restrict the user to enter value.so that end user enter proper value(in > case of AD its 636) > Case2: no automatic page refresh when we configured new LDAP,i.e we are > seeing both records(current and previous configuration details) till you > refresh the page manually. > Steps: > 1.configured the LDAP from UI > 2.again congured the another LDAP > 3.check the UI > Actual result: > able to see both previous and current LDAP configuration details till you > refresh the page manually. once you fresh it showing the correct details. > Expected results: > when we add new LDAP configuration details,previous details should be > overwritten with current value and same thing should be reflected in UI > automatically instead of showing both details till you refresh the page. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-3994) Wrong error notification is generated when Primary storage (Cluster wide) is added with wrong path
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anshul Gangwar resolved CLOUDSTACK-3994.
Resolution: Fixed
Fix Version/s: 4.2.1
returning false when one tries to delete non-existent storage pool
> Wrong error notification is generated when Primary storage (Cluster wide) is
> added with wrong path
> --
>
> Key: CLOUDSTACK-3994
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3994
> 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
>Priority: Minor
> Fix For: 4.2.1, 4.3.0
>
> Attachments: apilog.log, management-server.log
>
>
> Steps:
> 1. Configure Adv Zone with VMWARE
> 2. Tried to add wrong cluster wide primary storage point
> It failed saying " Failed to delete storage pool on host"
> 2013-08-01 10:00:12,928 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-230:null) Seq 1-757532143: Executing request
> 2013-08-01 10:00:12,928 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-230:null) Seq 1-757532143: Response Received:
> 2013-08-01 10:00:12,929 DEBUG [agent.transport.Request]
> (DirectAgent-230:null) Seq 1-757532143: Processing: { Ans: , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"success","wait":0}}]
> }
> 2013-08-01 10:00:12,933 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-757532143: Received: { Ans: , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 10, { Answer } }
> 2013-08-01 10:00:12,933 DEBUG [agent.manager.AgentManagerImpl]
> (catalina-exec-23:null) Details from executing class
> com.cloud.agent.api.CreateStoragePoolCommand: success
> 2013-08-01 10:00:12,933 DEBUG
> [datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl]
> (catalina-exec-23:null) In createPool Adding the pool to each of the hosts
> 2013-08-01 10:00:12,935 DEBUG [cloud.storage.StorageManagerImpl]
> (catalina-exec-23:null) Adding pool null to host 1
> 2013-08-01 10:00:12,940 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-757532144: Sending { Cmd , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.ModifyStoragePoolCommand":{"add":true,"pool":{"id":5,"uuid":"86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","host":"10.102.192.100","path":"/cpg_vol/sailaja/ps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","wait":0}}]
> }
> 2013-08-01 10:00:12,941 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-757532144: Executing: { Cmd , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.ModifyStoragePoolCommand":{"add":true,"pool":{"id":5,"uuid":"86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","host":"10.102.192.100","path":"/cpg_vol/sailaja/ps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","wait":0}}]
> }
> 2013-08-01 10:00:12,941 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-230:null) Seq 1-757532144: Executing request
> 2013-08-01 10:00:12,942 INFO [vmware.resource.VmwareResource]
> (DirectAgent-230:10.102.192.18) Executing resource ModifyStoragePoolCommand:
> {"add":true,"pool":{"id":5,"uuid":"86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","host":"10.102.192.100","path":"/cpg_vol/sailaja/ps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","wait":0}
> 2013-08-01 10:00:13,144 INFO [vmware.mo.HostMO]
> (DirectAgent-230: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/ps1, poolUuid: 86ee525833e736f0b3c1f6029e5c8bdf. Exception
> mesg: An error occurred during host configuration.
> 2013-08-01 10:00:13,145 ERROR [vmware.resource.VmwareResource]
> (DirectAgent-230: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.java:186)
> at
> java.util.concurrent.Execu
[jira] [Resolved] (CLOUDSTACK-1899) SRX firewall external devices - static NAT does not function
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy resolved CLOUDSTACK-1899. --- Resolution: Cannot Reproduce It worked for me. No route to host, It might be srx route setup issue. > SRX firewall external devices - static NAT does not function > > > Key: CLOUDSTACK-1899 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1899 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.0.0 > Environment: MSASF 4.0.0 GA RHEL6.3 > host KVM ASF 4.0.0 GA RHEL6.3 >Reporter: angeline shen >Assignee: Jayapal Reddy > Fix For: 4.3.0 > > > 1. advance zone, create network offering for external device firewall SRX, > add SRX device > 2. create instances using above network offering. Port forwarding rules > work. > allocate public IP, enable static NAT, set TCP port 22 rule for IP. > ssh to static NAT IP FAIL: > [ashen@localhost ~]$ ssh root@10.223.123.22 > ssh: connect to host 10.223.123.22 port 22: No route to hos > 3. create VPC, VPC network, instances. Both static NAT and Port forwarding > rules work for VPC network -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar updated CLOUDSTACK-4792: --- Status: Ready To Review (was: In Progress) > Invalid SMTP breaks HA > -- > > Key: CLOUDSTACK-4792 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 > 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.2.1 > > > Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from > working. If the smtp ip is listening but does not send a proper HELO HA hangs > and will not proceed. It seems as if the code > (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not > proceed. > I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe > we need to make HA independent of smtp alerts or at least put in a timeout so > HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798768#comment-13798768 ] Anshul Gangwar commented on CLOUDSTACK-4792: Sorry for not updating the jira. Fix for this is already submitted on review board https://reviews.apache.org/r/14467/ > Invalid SMTP breaks HA > -- > > Key: CLOUDSTACK-4792 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 > 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.2.1 > > > Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from > working. If the smtp ip is listening but does not send a proper HELO HA hangs > and will not proceed. It seems as if the code > (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not > proceed. > I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe > we need to make HA independent of smtp alerts or at least put in a timeout so > HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar reassigned CLOUDSTACK-4792: -- Assignee: Anshul Gangwar (was: Milamber) > Invalid SMTP breaks HA > -- > > Key: CLOUDSTACK-4792 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 > 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.2.1 > > > Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from > working. If the smtp ip is listening but does not send a proper HELO HA hangs > and will not proceed. It seems as if the code > (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not > proceed. > I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe > we need to make HA independent of smtp alerts or at least put in a timeout so > HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4786) Redundant router: the priority limitation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798751#comment-13798751 ] ASF subversion and git services commented on CLOUDSTACK-4786: - Commit 85dc65c7f766e76ff57816127578adca5ade1c54 in branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=85dc65c ] CLOUDSTACK-4786: Reset Redundant Router priority after all the routers are stopped This patch would reset the priority in such condition: 1. All redundant routers are stopped, e.g. due to network GC 2. User start one VM in the network 3. The routers would be brought up with reseted priority(100 & 99). This would resolve the issue of network GC result in lower limit of redundant router priority reached. > Redundant router: the priority limitation > - > > Key: CLOUDSTACK-4786 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4786 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.2.0 >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.2.1 > > > The limitation states that when using RVR, Network GC can run only 40 times > or RVR can only be restarted 40 times or Guest VM can only be restart 40 > times before having the need to restart the network with cleanup=true > (downtime). > Example: > 1. Let us say there is one VM in an account/network, VM1. > 2. It is using 1 network, say N1 and it's created from a network offering that > has redundant router enabled. > 3. When VM1 was launched, two RVRs were created, say R1 and R2. > 4. At that time R1 has priority set to 100 and R2 99. This is the default > behavior. > 5. Network GC is set to run every 30 minutes. > 6. Let us draw a base line here, VM1 is running, R1 is running and has > priority set to 100, R2 is running as has priority set to 99. > 7. Stop VM1. > 8. Wait for 30+ minutes. > 9. Check R1 and R2, they will be stopped. > 10. Start VM1. > 11. R1 and R2 will be started and their priorities will now be set to 99 and > 98 resp. > 12. If you repeat steps #7 through #10, you will observe that after 40 tries > priorities of R1 and R2 would be 20 and 19. You will observe that the RVR > won't start. It will complain about the priority being too low. > The only workaround now is to restart network with cleanup=true, basically > destroy old routers and create new ones. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4786) Redundant router: the priority limitation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang updated CLOUDSTACK-4786: --- Fix Version/s: (was: 4.3.0) 4.2.1 > Redundant router: the priority limitation > - > > Key: CLOUDSTACK-4786 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4786 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.2.0 >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.2.1 > > > The limitation states that when using RVR, Network GC can run only 40 times > or RVR can only be restarted 40 times or Guest VM can only be restart 40 > times before having the need to restart the network with cleanup=true > (downtime). > Example: > 1. Let us say there is one VM in an account/network, VM1. > 2. It is using 1 network, say N1 and it's created from a network offering that > has redundant router enabled. > 3. When VM1 was launched, two RVRs were created, say R1 and R2. > 4. At that time R1 has priority set to 100 and R2 99. This is the default > behavior. > 5. Network GC is set to run every 30 minutes. > 6. Let us draw a base line here, VM1 is running, R1 is running and has > priority set to 100, R2 is running as has priority set to 99. > 7. Stop VM1. > 8. Wait for 30+ minutes. > 9. Check R1 and R2, they will be stopped. > 10. Start VM1. > 11. R1 and R2 will be started and their priorities will now be set to 99 and > 98 resp. > 12. If you repeat steps #7 through #10, you will observe that after 40 tries > priorities of R1 and R2 would be 20 and 19. You will observe that the RVR > won't start. It will complain about the priority being too low. > The only workaround now is to restart network with cleanup=true, basically > destroy old routers and create new ones. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-2792) Redundant router: Password is reset again after fail-over happened
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang updated CLOUDSTACK-2792: --- Priority: Critical (was: Major) > Redundant router: Password is reset again after fail-over happened > -- > > Key: CLOUDSTACK-2792 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2792 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0 >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Critical > Fix For: 4.2.1 > > > Consider this scenario with RVR and "Password protected" VM: > > 1. Both Master and Backup is running. > 2. We reset the password on VM > 3. Both Master and Backup have password; for example say; "password1" > 4. VM boots up and requests for password; receives it from Master VR > 5. Master VR sets the password to Saved_Password and Backup VR continues to > keep "password1" > 6. Backup VR goes down; it had password as "password1" > 7. Maste VR is running > 8. We reset the password; so the password is only changed to Master VR (as > Backup VR is down); for example "password2" > 9. VM boots up and requests the password; gets it as "password2" > 10. Master VR sets the password to be Saved_Password > 11. Now Master VR goes down > 12. Backup VR was brought online (it still has "password1") > 13. Now we reboot the VM > 14. It sends a password request > 15. Backup VR (which is only available now; so is Master) sends the password > as > "password1" > User tries to login as "password2" and he cannot; unless we reset the password > again. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-2792) Redundant router: Password is reset again after fail-over happened
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798753#comment-13798753 ] Sheng Yang commented on CLOUDSTACK-2792: And it would affect the basic functionality of password enabled VM, so QA must test this. > Redundant router: Password is reset again after fail-over happened > -- > > Key: CLOUDSTACK-2792 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2792 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0 >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.2.1 > > > Consider this scenario with RVR and "Password protected" VM: > > 1. Both Master and Backup is running. > 2. We reset the password on VM > 3. Both Master and Backup have password; for example say; "password1" > 4. VM boots up and requests for password; receives it from Master VR > 5. Master VR sets the password to Saved_Password and Backup VR continues to > keep "password1" > 6. Backup VR goes down; it had password as "password1" > 7. Maste VR is running > 8. We reset the password; so the password is only changed to Master VR (as > Backup VR is down); for example "password2" > 9. VM boots up and requests the password; gets it as "password2" > 10. Master VR sets the password to be Saved_Password > 11. Now Master VR goes down > 12. Backup VR was brought online (it still has "password1") > 13. Now we reboot the VM > 14. It sends a password request > 15. Backup VR (which is only available now; so is Master) sends the password > as > "password1" > User tries to login as "password2" and he cannot; unless we reset the password > again. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4786) Redundant router: the priority limitation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang resolved CLOUDSTACK-4786. Resolution: Fixed > Redundant router: the priority limitation > - > > Key: CLOUDSTACK-4786 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4786 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.2.0 >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.2.1 > > > The limitation states that when using RVR, Network GC can run only 40 times > or RVR can only be restarted 40 times or Guest VM can only be restart 40 > times before having the need to restart the network with cleanup=true > (downtime). > Example: > 1. Let us say there is one VM in an account/network, VM1. > 2. It is using 1 network, say N1 and it's created from a network offering that > has redundant router enabled. > 3. When VM1 was launched, two RVRs were created, say R1 and R2. > 4. At that time R1 has priority set to 100 and R2 99. This is the default > behavior. > 5. Network GC is set to run every 30 minutes. > 6. Let us draw a base line here, VM1 is running, R1 is running and has > priority set to 100, R2 is running as has priority set to 99. > 7. Stop VM1. > 8. Wait for 30+ minutes. > 9. Check R1 and R2, they will be stopped. > 10. Start VM1. > 11. R1 and R2 will be started and their priorities will now be set to 99 and > 98 resp. > 12. If you repeat steps #7 through #10, you will observe that after 40 tries > priorities of R1 and R2 would be 20 and 19. You will observe that the RVR > won't start. It will complain about the priority being too low. > The only workaround now is to restart network with cleanup=true, basically > destroy old routers and create new ones. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-2792) Redundant router: Password is reset again after fail-over happened
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798752#comment-13798752 ] ASF subversion and git services commented on CLOUDSTACK-2792: - Commit 484d6c4eb741c882e1cc512ab35918d694e855c7 in branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=484d6c4 ] CLOUDSTACK-2792: Call savepassword.sh inside VR Also only set password when password service is running, thus avoid setting for redundant router BACKUP router. > Redundant router: Password is reset again after fail-over happened > -- > > Key: CLOUDSTACK-2792 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2792 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0 >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.2.1 > > > Consider this scenario with RVR and "Password protected" VM: > > 1. Both Master and Backup is running. > 2. We reset the password on VM > 3. Both Master and Backup have password; for example say; "password1" > 4. VM boots up and requests for password; receives it from Master VR > 5. Master VR sets the password to Saved_Password and Backup VR continues to > keep "password1" > 6. Backup VR goes down; it had password as "password1" > 7. Maste VR is running > 8. We reset the password; so the password is only changed to Master VR (as > Backup VR is down); for example "password2" > 9. VM boots up and requests the password; gets it as "password2" > 10. Master VR sets the password to be Saved_Password > 11. Now Master VR goes down > 12. Backup VR was brought online (it still has "password1") > 13. Now we reboot the VM > 14. It sends a password request > 15. Backup VR (which is only available now; so is Master) sends the password > as > "password1" > User tries to login as "password2" and he cannot; unless we reset the password > again. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-2792) Redundant router: Password is reset again after fail-over happened
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798745#comment-13798745 ] Sheng Yang commented on CLOUDSTACK-2792: VMware and KVM are also fixed, but not tested. QA please test the VMware and KVM. > Redundant router: Password is reset again after fail-over happened > -- > > Key: CLOUDSTACK-2792 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2792 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0 >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.2.1 > > > Consider this scenario with RVR and "Password protected" VM: > > 1. Both Master and Backup is running. > 2. We reset the password on VM > 3. Both Master and Backup have password; for example say; "password1" > 4. VM boots up and requests for password; receives it from Master VR > 5. Master VR sets the password to Saved_Password and Backup VR continues to > keep "password1" > 6. Backup VR goes down; it had password as "password1" > 7. Maste VR is running > 8. We reset the password; so the password is only changed to Master VR (as > Backup VR is down); for example "password2" > 9. VM boots up and requests the password; gets it as "password2" > 10. Master VR sets the password to be Saved_Password > 11. Now Master VR goes down > 12. Backup VR was brought online (it still has "password1") > 13. Now we reboot the VM > 14. It sends a password request > 15. Backup VR (which is only available now; so is Master) sends the password > as > "password1" > User tries to login as "password2" and he cannot; unless we reset the password > again. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-2792) Redundant router: Password is reset again after fail-over happened
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang resolved CLOUDSTACK-2792. Resolution: Fixed > Redundant router: Password is reset again after fail-over happened > -- > > Key: CLOUDSTACK-2792 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2792 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0 >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.2.1 > > > Consider this scenario with RVR and "Password protected" VM: > > 1. Both Master and Backup is running. > 2. We reset the password on VM > 3. Both Master and Backup have password; for example say; "password1" > 4. VM boots up and requests for password; receives it from Master VR > 5. Master VR sets the password to Saved_Password and Backup VR continues to > keep "password1" > 6. Backup VR goes down; it had password as "password1" > 7. Maste VR is running > 8. We reset the password; so the password is only changed to Master VR (as > Backup VR is down); for example "password2" > 9. VM boots up and requests the password; gets it as "password2" > 10. Master VR sets the password to be Saved_Password > 11. Now Master VR goes down > 12. Backup VR was brought online (it still has "password1") > 13. Now we reboot the VM > 14. It sends a password request > 15. Backup VR (which is only available now; so is Master) sends the password > as > "password1" > User tries to login as "password2" and he cannot; unless we reset the password > again. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-2792) Redundant router: Password is reset again after fail-over happened
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798743#comment-13798743 ] ASF subversion and git services commented on CLOUDSTACK-2792: - Commit 3c8be550f0dbde0e2cc8ca2d8c190e9e8d6daf9c in branch refs/heads/4.2 from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3c8be55 ] CLOUDSTACK-2792: Call savepassword.sh inside VR for Xen Also only set password when password service is running, thus avoid setting for redundant router BACKUP router. > Redundant router: Password is reset again after fail-over happened > -- > > Key: CLOUDSTACK-2792 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2792 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0 >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.2.1 > > > Consider this scenario with RVR and "Password protected" VM: > > 1. Both Master and Backup is running. > 2. We reset the password on VM > 3. Both Master and Backup have password; for example say; "password1" > 4. VM boots up and requests for password; receives it from Master VR > 5. Master VR sets the password to Saved_Password and Backup VR continues to > keep "password1" > 6. Backup VR goes down; it had password as "password1" > 7. Maste VR is running > 8. We reset the password; so the password is only changed to Master VR (as > Backup VR is down); for example "password2" > 9. VM boots up and requests the password; gets it as "password2" > 10. Master VR sets the password to be Saved_Password > 11. Now Master VR goes down > 12. Backup VR was brought online (it still has "password1") > 13. Now we reboot the VM > 14. It sends a password request > 15. Backup VR (which is only available now; so is Master) sends the password > as > "password1" > User tries to login as "password2" and he cannot; unless we reset the password > again. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4786) Redundant router: the priority limitation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798742#comment-13798742 ] ASF subversion and git services commented on CLOUDSTACK-4786: - Commit 93188b449c177481cecafb35fc14f40da88ece07 in branch refs/heads/4.2 from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=93188b4 ] CLOUDSTACK-4786: Reset Redundant Router priority after all the routers are stopped This patch would reset the priority in such condition: 1. All redundant routers are stopped, e.g. due to network GC 2. User start one VM in the network 3. The routers would be brought up with reseted priority(100 & 99). This would resolve the issue of network GC result in lower limit of redundant router priority reached. > Redundant router: the priority limitation > - > > Key: CLOUDSTACK-4786 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4786 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.2.0 >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.3.0 > > > The limitation states that when using RVR, Network GC can run only 40 times > or RVR can only be restarted 40 times or Guest VM can only be restart 40 > times before having the need to restart the network with cleanup=true > (downtime). > Example: > 1. Let us say there is one VM in an account/network, VM1. > 2. It is using 1 network, say N1 and it's created from a network offering that > has redundant router enabled. > 3. When VM1 was launched, two RVRs were created, say R1 and R2. > 4. At that time R1 has priority set to 100 and R2 99. This is the default > behavior. > 5. Network GC is set to run every 30 minutes. > 6. Let us draw a base line here, VM1 is running, R1 is running and has > priority set to 100, R2 is running as has priority set to 99. > 7. Stop VM1. > 8. Wait for 30+ minutes. > 9. Check R1 and R2, they will be stopped. > 10. Start VM1. > 11. R1 and R2 will be started and their priorities will now be set to 99 and > 98 resp. > 12. If you repeat steps #7 through #10, you will observe that after 40 tries > priorities of R1 and R2 would be 20 and 19. You will observe that the RVR > won't start. It will complain about the priority being too low. > The only workaround now is to restart network with cleanup=true, basically > destroy old routers and create new ones. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4752) Can't delete a network that lacks a DHCP in network offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798692#comment-13798692 ] Jijun commented on CLOUDSTACK-4752: --- i have the same issue, i create a QuickCloudNoServices Zone , and create new VMsuccessful, but when delete the VM , throw the same exception. 2013-10-16 12:53:44,601 WARN [cloud.vm.UserVmManagerImpl] (UserVm-Scavenger-1:null) Unable to expunge VM[User|ztest01] com.cloud.exception.UnsupportedServiceException: Service Dhcp is not supported in the network id=204 at com.cloud.network.dao.NetworkServiceMapDaoImpl.getProviderForServiceInNetwork(NetworkServiceMapDaoImpl.java:127) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.network.NetworkManagerImpl.getDhcpServiceProvider(NetworkManagerImpl.java:3681) at com.cloud.network.NetworkManagerImpl.isDhcpAccrossMultipleSubnetsSupported(NetworkManagerImpl.java:2522) at com.cloud.network.NetworkManagerImpl.removeNic(NetworkManagerImpl.java:2507) at com.cloud.network.NetworkManagerImpl.cleanupNics(NetworkManagerImpl.java:2463) at com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:475) at com.cloud.vm.UserVmManagerImpl.expunge(UserVmManagerImpl.java:1600) at com.cloud.vm.UserVmManagerImpl$ExpungeTask.run(UserVmManagerImpl.java:1769) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) 2013-10-16 12:53:44,616 DEBUG [storage.image.BaseImageStoreDriverImpl] (RemoteHostEndPoint-2:null) Performing image store createTemplate async callback 2013-10-16 12:53:46,402 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-2:null) Ping from 4 2013-10-16 12:53:46,487 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-3:null) Ping from 1 2013-10-16 12:53:46,492 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-4:null) Ping from 3 2013-10-16 12:53:46,504 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-5:null) Ping from 2 2013-10-16 12:53:47,788 DEBUG [storage.download.DownloadListener] (Timer-9:null) Scheduling timeout at 3 ms, TEMPLATE: 202 at host 1 > Can't delete a network that lacks a DHCP in network offering > > > Key: CLOUDSTACK-4752 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4752 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: John Beredimas > > Trying to delete a network that lacks DHCP in its network offering seems to > fail. > Relevant output from Cloudmonkey follows: > cloudmonkey> remove nicfromvirtualmachine > virtualmachineid=a8d35e16-cb65-46c5-aa8d-d07e533326ee > nicid=a95e9112-07f0-4b94-b6be-5aa58bd360b3 > Async job 76cbd3e7-e97f-49b7-b177-176ff76a5927 failed > Error 530, Service Dhcp is not supported in the network id=249 > accountid = 2e64c73f-a173-419a-8dc8-6739aa4e4f9d -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4836) Restart network with cleanup=true won't reprogram remote access VPN users in the VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang resolved CLOUDSTACK-4836. Resolution: Fixed > Restart network with cleanup=true won't reprogram remote access VPN users in > the VR > --- > > Key: CLOUDSTACK-4836 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4836 > 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 >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Critical > Fix For: 4.2.1 > > > After restart network with cleanup=true, there is no programming of VPN users > of the new user, thus remote access VPN function is broken. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4836) Restart network with cleanup=true won't reprogram remote access VPN users in the VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798688#comment-13798688 ] ASF subversion and git services commented on CLOUDSTACK-4836: - Commit 7d7bd2afdf4fcf9ddf06080f041ec0bbebf5d2f0 in branch refs/heads/4.2 from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7d7bd2a ] CLOUDSTACK-4836: Fix VPN user are not programmed after restart network > Restart network with cleanup=true won't reprogram remote access VPN users in > the VR > --- > > Key: CLOUDSTACK-4836 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4836 > 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 >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Critical > Fix For: 4.2.1 > > > After restart network with cleanup=true, there is no programming of VPN users > of the new user, thus remote access VPN function is broken. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4836) Restart network with cleanup=true won't reprogram remote access VPN users in the VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798682#comment-13798682 ] ASF subversion and git services commented on CLOUDSTACK-4836: - Commit c3df34826413067d0a1ff90fbb2ab89f2a6a6416 in branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c3df348 ] CLOUDSTACK-4836: Fix VPN user are not programmed after restart network Also refactor VPN code. > Restart network with cleanup=true won't reprogram remote access VPN users in > the VR > --- > > Key: CLOUDSTACK-4836 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4836 > 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 >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Critical > Fix For: 4.2.1 > > > After restart network with cleanup=true, there is no programming of VPN users > of the new user, thus remote access VPN function is broken. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4890) [VM snapshot] Do not delete VM snapshots until VM is expunged. Currently after VM is restored, unable to recover VM snapshots as these are destroyed
angeline shen created CLOUDSTACK-4890: - Summary: [VM snapshot] Do not delete VM snapshots until VM is expunged. Currently after VM is restored, unable to recover VM snapshots as these are destroyed Key: CLOUDSTACK-4890 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4890 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.1 Environment: MSCloudPlatform-4.2.1-732-rhel6.3.tar.gz Hosts XS 6.2 Reporter: angeline shen Priority: Minor Fix For: 4.2.1 1. Create multiple VM snapshots for the same VM - say 3 snapshots - S1,S2,S3. 2. Destroy the Vm. 3. Restore VM. All VM snapshots are removed. It would be nice to be able to recover VM snapshots when VM is restored . -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4637) [Automation] test_egress_fw_rules.py fails with Script result is ['send: spawn id exp3 not open' ....'] is not matching with ['100'] in KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798627#comment-13798627 ] ASF subversion and git services commented on CLOUDSTACK-4637: - Commit 833229c416cfee3e3dec3762d2e9c8e734696f90 in branch refs/heads/4.2 from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=833229c ] CLOUDSTACK-4637: Fix failures in test_egress_fw_rules.py Removed log_test_exceptions which did not add any value. Skipped few tests which are incomplete. Added timeout logic and to wait for router to boot. (cherry picked from commit a65f1ebefca7b22512762faf1832291153782f58) Signed-off-by: Sangeetha > [Automation] test_egress_fw_rules.py fails with Script result is ['send: > spawn id exp3 not open' '] is not matching with ['100'] in KVM > --- > > Key: CLOUDSTACK-4637 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4637 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Girish Shilamkar >Assignee: Girish Shilamkar >Priority: Critical > > Still fails > Script result is ['send: spawn id exp3 not open', ' while executing', '"send > "ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o > LogLevel=quiet root@10.1.1.183 ping -c 1 www.google.com; exit $?', '""', ' > (file "/tmp/expect_script.exp" line 4)'] is not matching with ['100'] > >> begin captured logging << > testclient.testcase.TestEgressFWRules: DEBUG: Creating network with network > offering: 05d985b1-ee1c-4b04-9cee-d6c97e43032d > testclient.testcase.TestEgressFWRules: DEBUG: Created network with ID: > 02187a7a-9afe-45ff-b9c3-069b00c731fc > testclient.testcase.TestEgressFWRules: DEBUG: Deploying instance in the > account: test-B0F0Z8 > testclient.testcase.TestEgressFWRules: DEBUG: Deployed instance in account: > test-B0F0Z8 > testclient.testcase.TestEgressFWRules: DEBUG: Creating Egress FW rule for > networkid=02187a7a-9afe-45ff-b9c3-069b00c731fc networkname=Test Network > testclient.testcase.TestEgressFWRules: DEBUG: Created > rule=fe84b110-8042-47d3-8b72-917607ab8811 > testclient.testcase.TestEgressFWRules: DEBUG: expect_script>> > #!/usr/bin/expect > spawn ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o > LogLevel=quiet -i /root/.ssh/id_rsa.cloud -p 3922 root@169.254.2.102 > expect "root@r-588-QA:~#" > send "ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o > LogLevel=quiet root@10.1.1.183 ping -c 1 www.google.com; exit $? > " > expect "root@10.1.1.183's password: " > send "password > " > interact > < paramiko.transport: DEBUG: starting thread (client mode): 0x204143d0L > paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_5.3) > paramiko.transport: DEBUG: kex algos:['diffie-hellman-group-exchange-sha256', > 'diffie-hellman-group-exchange-sha1', 'diffie-hellman-group14-sha1', > 'diffie-hellman-group1-sha1'] server key:['ssh-rsa', 'ssh-dss'] client > encrypt:['aes128-ctr', 'aes192-ctr', 'aes256-ctr', 'arcfour256', > 'arcfour128', 'aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', > 'aes192-cbc', 'aes256-cbc', 'arcfour', 'rijndael-...@lysator.liu.se'] server > encrypt:['aes128-ctr', 'aes192-ctr', 'aes256-ctr', 'arcfour256', > 'arcfour128', 'aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', > 'aes192-cbc', 'aes256-cbc', 'arcfour', 'rijndael-...@lysator.liu.se'] client > mac:['hmac-md5', 'hmac-sha1', 'umac...@openssh.com', 'hmac-ripemd160', > 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] server > mac:['hmac-md5', 'hmac-sha1', 'umac...@openssh.com', 'hmac-ripemd160', > 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client > compress:['none', 'z...@openssh.com'] server compress:['none', > 'z...@openssh.com'] client lang:[''] server lang:[''] kex follows?False > paramiko.transport: DEBUG: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr > paramiko.transport: DEBUG: using kex diffie-hellman-group1-sha1; server key > type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local > hmac-sha1, remote hmac-sha1; compression: local none, remote none > paramiko.transport: DEBUG: Switch to new keys ... > paramiko.transport: DEBUG: Adding ssh-rsa host key for 10.223.50.66: > 41aef5f507e1ddd99077b11f4bf26553 > paramiko.transport: DEBUG: Trying discovered key > 76be480fa6b8ad3b78082d6d19e4ee44 in /root/.ssh/id_rsa > paramiko.transport: DEBUG: userauth is OK > paramiko.transport: INFO: Authentication (publickey) failed. > paramiko.transport: DEBUG: userauth is OK > para
[jira] [Commented] (CLOUDSTACK-4637) [Automation] test_egress_fw_rules.py fails with Script result is ['send: spawn id exp3 not open' ....'] is not matching with ['100'] in KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798625#comment-13798625 ] ASF subversion and git services commented on CLOUDSTACK-4637: - Commit a65f1ebefca7b22512762faf1832291153782f58 in branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a65f1eb ] CLOUDSTACK-4637: Fix failures in test_egress_fw_rules.py Removed log_test_exceptions which did not add any value. Skipped few tests which are incomplete. Added timeout logic and to wait for router to boot. > [Automation] test_egress_fw_rules.py fails with Script result is ['send: > spawn id exp3 not open' '] is not matching with ['100'] in KVM > --- > > Key: CLOUDSTACK-4637 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4637 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Girish Shilamkar >Assignee: Girish Shilamkar >Priority: Critical > > Still fails > Script result is ['send: spawn id exp3 not open', ' while executing', '"send > "ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o > LogLevel=quiet root@10.1.1.183 ping -c 1 www.google.com; exit $?', '""', ' > (file "/tmp/expect_script.exp" line 4)'] is not matching with ['100'] > >> begin captured logging << > testclient.testcase.TestEgressFWRules: DEBUG: Creating network with network > offering: 05d985b1-ee1c-4b04-9cee-d6c97e43032d > testclient.testcase.TestEgressFWRules: DEBUG: Created network with ID: > 02187a7a-9afe-45ff-b9c3-069b00c731fc > testclient.testcase.TestEgressFWRules: DEBUG: Deploying instance in the > account: test-B0F0Z8 > testclient.testcase.TestEgressFWRules: DEBUG: Deployed instance in account: > test-B0F0Z8 > testclient.testcase.TestEgressFWRules: DEBUG: Creating Egress FW rule for > networkid=02187a7a-9afe-45ff-b9c3-069b00c731fc networkname=Test Network > testclient.testcase.TestEgressFWRules: DEBUG: Created > rule=fe84b110-8042-47d3-8b72-917607ab8811 > testclient.testcase.TestEgressFWRules: DEBUG: expect_script>> > #!/usr/bin/expect > spawn ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o > LogLevel=quiet -i /root/.ssh/id_rsa.cloud -p 3922 root@169.254.2.102 > expect "root@r-588-QA:~#" > send "ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o > LogLevel=quiet root@10.1.1.183 ping -c 1 www.google.com; exit $? > " > expect "root@10.1.1.183's password: " > send "password > " > interact > < paramiko.transport: DEBUG: starting thread (client mode): 0x204143d0L > paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_5.3) > paramiko.transport: DEBUG: kex algos:['diffie-hellman-group-exchange-sha256', > 'diffie-hellman-group-exchange-sha1', 'diffie-hellman-group14-sha1', > 'diffie-hellman-group1-sha1'] server key:['ssh-rsa', 'ssh-dss'] client > encrypt:['aes128-ctr', 'aes192-ctr', 'aes256-ctr', 'arcfour256', > 'arcfour128', 'aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', > 'aes192-cbc', 'aes256-cbc', 'arcfour', 'rijndael-...@lysator.liu.se'] server > encrypt:['aes128-ctr', 'aes192-ctr', 'aes256-ctr', 'arcfour256', > 'arcfour128', 'aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', > 'aes192-cbc', 'aes256-cbc', 'arcfour', 'rijndael-...@lysator.liu.se'] client > mac:['hmac-md5', 'hmac-sha1', 'umac...@openssh.com', 'hmac-ripemd160', > 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] server > mac:['hmac-md5', 'hmac-sha1', 'umac...@openssh.com', 'hmac-ripemd160', > 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client > compress:['none', 'z...@openssh.com'] server compress:['none', > 'z...@openssh.com'] client lang:[''] server lang:[''] kex follows?False > paramiko.transport: DEBUG: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr > paramiko.transport: DEBUG: using kex diffie-hellman-group1-sha1; server key > type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local > hmac-sha1, remote hmac-sha1; compression: local none, remote none > paramiko.transport: DEBUG: Switch to new keys ... > paramiko.transport: DEBUG: Adding ssh-rsa host key for 10.223.50.66: > 41aef5f507e1ddd99077b11f4bf26553 > paramiko.transport: DEBUG: Trying discovered key > 76be480fa6b8ad3b78082d6d19e4ee44 in /root/.ssh/id_rsa > paramiko.transport: DEBUG: userauth is OK > paramiko.transport: INFO: Authentication (publickey) failed. > paramiko.transport: DEBUG: userauth is OK > paramiko.transport: INFO: Authentication (password) successful! > sshClient: DEBUG: SSH connect:
[jira] [Commented] (CLOUDSTACK-4887) CLVM broken
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798622#comment-13798622
]
ASF subversion and git services commented on CLOUDSTACK-4887:
-
Commit a504c004bf10555e5ea67ec89fe7bf6f00fe4622 in branch refs/heads/master
from [~mlsorensen]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a504c00 ]
CLOUDSTACK-4887: Fix CLVM template download from storage refactoring work
> CLVM broken
> ---
>
> Key: CLOUDSTACK-4887
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4887
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: Future
>Reporter: Marcus Sorensen
>Assignee: Chris Suich
>Priority: Blocker
> Fix For: Future
>
>
> Chris,
>I think commit 180cfa19 broke CLVM primary storage for KVM. I'm failing VM
> deploy from template. I've been building a 'sanity check' test that focuses
> on the KVM specific suff (tests storage types and supported host OS for now),
> and this bubbled up.
> I reverted this one part in my local code and am testing (seems to fix it),
> but since I'm not clear on the refactor efforts I'm not sure what it should
> really be changed to in order to meet your requirements and keep CLVM working.
> @@ -65,7 +68,7 @@ public class StorageSubsystemCommandHandlerBase implements
> StorageSubsystemComma
> DataStoreTO srcDataStore = srcData.getDataStore();
> DataStoreTO destDataStore = destData.getDataStore();
> -if ((srcData.getObjectType() == DataObjectType.TEMPLATE) &&
> (srcDataStore instanceof NfsTO) && (destData.getDataStore().getRole() ==
> DataStoreRole.Primary)) {
> +if ((srcData.getObjectType() == DataObjectType.TEMPLATE) &&
> (destData.getObjectType() == DataObjectType.TEMPLATE &&
> destData.getDataStore().getRole() == DataStoreRole.Primary)) {
> //copy template to primary storage
> return processor.copyTemplateToPrimaryStorage(cmd);
> } else if (srcData.getObjectType() == DataObjectType.TEMPLATE &&
> srcDataStore.getRole() == DataStoreRole.Primary && destDataStore.getRole() ==
> DataStoreRole.Primary) {
> 4.2 command:
> { Cmd , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/201/fe75caa3-78fd-38ba-b34c-101d0502df2e.qcow2","origUrl":"http://marcus.mlsorensen.com/cloudstack-extras/tiny-centos-63.qcow2","uuid":"4795671b-dd72-4e62-9aac-c0e1d6732003","id":201,"format":"QCOW2","accountId":1,"checksum":"44cd0e6330a59f031460bc18a40c95a2","hvm":true,"displayText":"tiny","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://172.17.10.10:/nfs/secondary","_role":"Image"}},"name":"201-1-2b35186d-79a6-33dc-8b33-83eb650e5e1d","hypervisorType":"KVM"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"73f86d88-ccff-4dfb-ac86-2d76b7891117","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"08e8d399-b238-48f9-a497-1f7f5285d655","id":2,"poolType":"CLVM","host":"localhost","path":"vg0","port":0}},"name":"ROOT-6","size":1073741824,"volumeId":6,"vmName":"i-1-6-VM","accountId":1,"format":"QCOW2","id":6,"hypervisorType":"KVM"}},"executeInSequence":true,"wait":10800}}]
> }
> 4.2 response:
> { Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"newData":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"path":"f69879c0-ae3b-433a-841f-f1f5afc04fc7","accountId":0,"format":"RAW","id":0}},"result":true,"wait":0}}]
> }
> master command:
> { Cmd , MgmtId: 52241639751, via: 1(devcloud-kvm-u), Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/4/02170718-210a-3d8c-91a2-2793ed52f1d8.qcow2","origUrl":"http://download.cloud.com/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2","uuid":"07088e98-1fda-11e3-a1ff-000c29d82947","id":4,"format":"QCOW2","accountId":1,"checksum":"ed0e788280ff2912ea40f7f91ca7a249","hvm":false,"displayText":"CentOS
> 5.5(64-bit) no GUI
> (KVM)","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://172.17.10.10:/nfs/secondary","_role":"Image"}},"name":"centos55-x86_64","hypervisorType":"KVM"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"e08f2a84-0d8b-4c6e-9593-a7554fd57b78","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"0f77072d-c76f-449c-bc6d-e2504644c0ca","id":2,"poolType":"CLVM","host":"localhost","path":"vg0","p
[jira] [Closed] (CLOUDSTACK-4887) CLVM broken
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Sorensen closed CLOUDSTACK-4887.
---
> CLVM broken
> ---
>
> Key: CLOUDSTACK-4887
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4887
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: Future
>Reporter: Marcus Sorensen
>Assignee: Marcus Sorensen
>Priority: Blocker
> Fix For: Future
>
>
> Chris,
>I think commit 180cfa19 broke CLVM primary storage for KVM. I'm failing VM
> deploy from template. I've been building a 'sanity check' test that focuses
> on the KVM specific suff (tests storage types and supported host OS for now),
> and this bubbled up.
> I reverted this one part in my local code and am testing (seems to fix it),
> but since I'm not clear on the refactor efforts I'm not sure what it should
> really be changed to in order to meet your requirements and keep CLVM working.
> @@ -65,7 +68,7 @@ public class StorageSubsystemCommandHandlerBase implements
> StorageSubsystemComma
> DataStoreTO srcDataStore = srcData.getDataStore();
> DataStoreTO destDataStore = destData.getDataStore();
> -if ((srcData.getObjectType() == DataObjectType.TEMPLATE) &&
> (srcDataStore instanceof NfsTO) && (destData.getDataStore().getRole() ==
> DataStoreRole.Primary)) {
> +if ((srcData.getObjectType() == DataObjectType.TEMPLATE) &&
> (destData.getObjectType() == DataObjectType.TEMPLATE &&
> destData.getDataStore().getRole() == DataStoreRole.Primary)) {
> //copy template to primary storage
> return processor.copyTemplateToPrimaryStorage(cmd);
> } else if (srcData.getObjectType() == DataObjectType.TEMPLATE &&
> srcDataStore.getRole() == DataStoreRole.Primary && destDataStore.getRole() ==
> DataStoreRole.Primary) {
> 4.2 command:
> { Cmd , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/201/fe75caa3-78fd-38ba-b34c-101d0502df2e.qcow2","origUrl":"http://marcus.mlsorensen.com/cloudstack-extras/tiny-centos-63.qcow2","uuid":"4795671b-dd72-4e62-9aac-c0e1d6732003","id":201,"format":"QCOW2","accountId":1,"checksum":"44cd0e6330a59f031460bc18a40c95a2","hvm":true,"displayText":"tiny","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://172.17.10.10:/nfs/secondary","_role":"Image"}},"name":"201-1-2b35186d-79a6-33dc-8b33-83eb650e5e1d","hypervisorType":"KVM"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"73f86d88-ccff-4dfb-ac86-2d76b7891117","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"08e8d399-b238-48f9-a497-1f7f5285d655","id":2,"poolType":"CLVM","host":"localhost","path":"vg0","port":0}},"name":"ROOT-6","size":1073741824,"volumeId":6,"vmName":"i-1-6-VM","accountId":1,"format":"QCOW2","id":6,"hypervisorType":"KVM"}},"executeInSequence":true,"wait":10800}}]
> }
> 4.2 response:
> { Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"newData":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"path":"f69879c0-ae3b-433a-841f-f1f5afc04fc7","accountId":0,"format":"RAW","id":0}},"result":true,"wait":0}}]
> }
> master command:
> { Cmd , MgmtId: 52241639751, via: 1(devcloud-kvm-u), Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/4/02170718-210a-3d8c-91a2-2793ed52f1d8.qcow2","origUrl":"http://download.cloud.com/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2","uuid":"07088e98-1fda-11e3-a1ff-000c29d82947","id":4,"format":"QCOW2","accountId":1,"checksum":"ed0e788280ff2912ea40f7f91ca7a249","hvm":false,"displayText":"CentOS
> 5.5(64-bit) no GUI
> (KVM)","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://172.17.10.10:/nfs/secondary","_role":"Image"}},"name":"centos55-x86_64","hypervisorType":"KVM"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"e08f2a84-0d8b-4c6e-9593-a7554fd57b78","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"0f77072d-c76f-449c-bc6d-e2504644c0ca","id":2,"poolType":"CLVM","host":"localhost","path":"vg0","port":0}},"name":"ROOT-7","size":8589934592,"volumeId":7,"vmName":"i-1-7-VM","accountId":1,"format":"QCOW2","id":7,"hypervisorType":"KVM"}},"executeInSequence":true,"wait":10800}}]
> }
> master response:
> { Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"not
[jira] [Assigned] (CLOUDSTACK-4887) CLVM broken
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Sorensen reassigned CLOUDSTACK-4887:
---
Assignee: Marcus Sorensen (was: Chris Suich)
> CLVM broken
> ---
>
> Key: CLOUDSTACK-4887
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4887
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: Future
>Reporter: Marcus Sorensen
>Assignee: Marcus Sorensen
>Priority: Blocker
> Fix For: Future
>
>
> Chris,
>I think commit 180cfa19 broke CLVM primary storage for KVM. I'm failing VM
> deploy from template. I've been building a 'sanity check' test that focuses
> on the KVM specific suff (tests storage types and supported host OS for now),
> and this bubbled up.
> I reverted this one part in my local code and am testing (seems to fix it),
> but since I'm not clear on the refactor efforts I'm not sure what it should
> really be changed to in order to meet your requirements and keep CLVM working.
> @@ -65,7 +68,7 @@ public class StorageSubsystemCommandHandlerBase implements
> StorageSubsystemComma
> DataStoreTO srcDataStore = srcData.getDataStore();
> DataStoreTO destDataStore = destData.getDataStore();
> -if ((srcData.getObjectType() == DataObjectType.TEMPLATE) &&
> (srcDataStore instanceof NfsTO) && (destData.getDataStore().getRole() ==
> DataStoreRole.Primary)) {
> +if ((srcData.getObjectType() == DataObjectType.TEMPLATE) &&
> (destData.getObjectType() == DataObjectType.TEMPLATE &&
> destData.getDataStore().getRole() == DataStoreRole.Primary)) {
> //copy template to primary storage
> return processor.copyTemplateToPrimaryStorage(cmd);
> } else if (srcData.getObjectType() == DataObjectType.TEMPLATE &&
> srcDataStore.getRole() == DataStoreRole.Primary && destDataStore.getRole() ==
> DataStoreRole.Primary) {
> 4.2 command:
> { Cmd , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/201/fe75caa3-78fd-38ba-b34c-101d0502df2e.qcow2","origUrl":"http://marcus.mlsorensen.com/cloudstack-extras/tiny-centos-63.qcow2","uuid":"4795671b-dd72-4e62-9aac-c0e1d6732003","id":201,"format":"QCOW2","accountId":1,"checksum":"44cd0e6330a59f031460bc18a40c95a2","hvm":true,"displayText":"tiny","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://172.17.10.10:/nfs/secondary","_role":"Image"}},"name":"201-1-2b35186d-79a6-33dc-8b33-83eb650e5e1d","hypervisorType":"KVM"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"73f86d88-ccff-4dfb-ac86-2d76b7891117","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"08e8d399-b238-48f9-a497-1f7f5285d655","id":2,"poolType":"CLVM","host":"localhost","path":"vg0","port":0}},"name":"ROOT-6","size":1073741824,"volumeId":6,"vmName":"i-1-6-VM","accountId":1,"format":"QCOW2","id":6,"hypervisorType":"KVM"}},"executeInSequence":true,"wait":10800}}]
> }
> 4.2 response:
> { Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"newData":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"path":"f69879c0-ae3b-433a-841f-f1f5afc04fc7","accountId":0,"format":"RAW","id":0}},"result":true,"wait":0}}]
> }
> master command:
> { Cmd , MgmtId: 52241639751, via: 1(devcloud-kvm-u), Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/4/02170718-210a-3d8c-91a2-2793ed52f1d8.qcow2","origUrl":"http://download.cloud.com/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2","uuid":"07088e98-1fda-11e3-a1ff-000c29d82947","id":4,"format":"QCOW2","accountId":1,"checksum":"ed0e788280ff2912ea40f7f91ca7a249","hvm":false,"displayText":"CentOS
> 5.5(64-bit) no GUI
> (KVM)","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://172.17.10.10:/nfs/secondary","_role":"Image"}},"name":"centos55-x86_64","hypervisorType":"KVM"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"e08f2a84-0d8b-4c6e-9593-a7554fd57b78","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"0f77072d-c76f-449c-bc6d-e2504644c0ca","id":2,"poolType":"CLVM","host":"localhost","path":"vg0","port":0}},"name":"ROOT-7","size":8589934592,"volumeId":7,"vmName":"i-1-7-VM","accountId":1,"format":"QCOW2","id":7,"hypervisorType":"KVM"}},"executeInSequence":true,"wait":10800}}]
> }
> master response:
> { Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
> [{"
[jira] [Resolved] (CLOUDSTACK-4887) CLVM broken
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Sorensen resolved CLOUDSTACK-4887.
-
Resolution: Fixed
> CLVM broken
> ---
>
> Key: CLOUDSTACK-4887
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4887
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: Future
>Reporter: Marcus Sorensen
>Assignee: Marcus Sorensen
>Priority: Blocker
> Fix For: Future
>
>
> Chris,
>I think commit 180cfa19 broke CLVM primary storage for KVM. I'm failing VM
> deploy from template. I've been building a 'sanity check' test that focuses
> on the KVM specific suff (tests storage types and supported host OS for now),
> and this bubbled up.
> I reverted this one part in my local code and am testing (seems to fix it),
> but since I'm not clear on the refactor efforts I'm not sure what it should
> really be changed to in order to meet your requirements and keep CLVM working.
> @@ -65,7 +68,7 @@ public class StorageSubsystemCommandHandlerBase implements
> StorageSubsystemComma
> DataStoreTO srcDataStore = srcData.getDataStore();
> DataStoreTO destDataStore = destData.getDataStore();
> -if ((srcData.getObjectType() == DataObjectType.TEMPLATE) &&
> (srcDataStore instanceof NfsTO) && (destData.getDataStore().getRole() ==
> DataStoreRole.Primary)) {
> +if ((srcData.getObjectType() == DataObjectType.TEMPLATE) &&
> (destData.getObjectType() == DataObjectType.TEMPLATE &&
> destData.getDataStore().getRole() == DataStoreRole.Primary)) {
> //copy template to primary storage
> return processor.copyTemplateToPrimaryStorage(cmd);
> } else if (srcData.getObjectType() == DataObjectType.TEMPLATE &&
> srcDataStore.getRole() == DataStoreRole.Primary && destDataStore.getRole() ==
> DataStoreRole.Primary) {
> 4.2 command:
> { Cmd , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/201/fe75caa3-78fd-38ba-b34c-101d0502df2e.qcow2","origUrl":"http://marcus.mlsorensen.com/cloudstack-extras/tiny-centos-63.qcow2","uuid":"4795671b-dd72-4e62-9aac-c0e1d6732003","id":201,"format":"QCOW2","accountId":1,"checksum":"44cd0e6330a59f031460bc18a40c95a2","hvm":true,"displayText":"tiny","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://172.17.10.10:/nfs/secondary","_role":"Image"}},"name":"201-1-2b35186d-79a6-33dc-8b33-83eb650e5e1d","hypervisorType":"KVM"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"73f86d88-ccff-4dfb-ac86-2d76b7891117","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"08e8d399-b238-48f9-a497-1f7f5285d655","id":2,"poolType":"CLVM","host":"localhost","path":"vg0","port":0}},"name":"ROOT-6","size":1073741824,"volumeId":6,"vmName":"i-1-6-VM","accountId":1,"format":"QCOW2","id":6,"hypervisorType":"KVM"}},"executeInSequence":true,"wait":10800}}]
> }
> 4.2 response:
> { Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"newData":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"path":"f69879c0-ae3b-433a-841f-f1f5afc04fc7","accountId":0,"format":"RAW","id":0}},"result":true,"wait":0}}]
> }
> master command:
> { Cmd , MgmtId: 52241639751, via: 1(devcloud-kvm-u), Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/4/02170718-210a-3d8c-91a2-2793ed52f1d8.qcow2","origUrl":"http://download.cloud.com/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2","uuid":"07088e98-1fda-11e3-a1ff-000c29d82947","id":4,"format":"QCOW2","accountId":1,"checksum":"ed0e788280ff2912ea40f7f91ca7a249","hvm":false,"displayText":"CentOS
> 5.5(64-bit) no GUI
> (KVM)","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://172.17.10.10:/nfs/secondary","_role":"Image"}},"name":"centos55-x86_64","hypervisorType":"KVM"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"e08f2a84-0d8b-4c6e-9593-a7554fd57b78","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"0f77072d-c76f-449c-bc6d-e2504644c0ca","id":2,"poolType":"CLVM","host":"localhost","path":"vg0","port":0}},"name":"ROOT-7","size":8589934592,"volumeId":7,"vmName":"i-1-7-VM","accountId":1,"format":"QCOW2","id":7,"hypervisorType":"KVM"}},"executeInSequence":true,"wait":10800}}]
> }
> master response:
> { Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"re
[jira] [Commented] (CLOUDSTACK-3472) [Object_Store_Refactor] System VMs are not coming up in initial attempt, but they are coming up after multiple attempts
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798561#comment-13798561
]
ASF subversion and git services commented on CLOUDSTACK-3472:
-
Commit ec3302afd6c1676f766b6e731c101eaf316cd7cf in branch refs/heads/master
from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ec3302a ]
CLOUDSTACK-3472: [Object_Store_Refactor] System VMs are not coming up in
initial attempt, but they are coming up after multiple attempts.
> [Object_Store_Refactor] System VMs are not coming up in initial attempt, but
> they are coming up after multiple attempts
> ---
>
> Key: CLOUDSTACK-3472
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3472
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Install and Setup
>Affects Versions: 4.2.0
> Environment: Latest build from ACS4.2 branch:
> Cluster:XenServer6.1
>Reporter: Sanjeev N
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.rar
>
>
> System VMs are not coming up in initial attempt, but they are coming up after
> multiple attempts.
> Failed to create VDI in SR initially but succeeding after several failed
> attempts.
> Copycommand is failing with Runtime exception:
> 2013-07-11 11:25:17,554 DEBUG [agent.transport.Request] (DirectAgent-73:null)
> Seq 1-557449293: Processing: { Ans: , MgmtId: 6615759585382, via: 1, Ver:
> v1, Flags: 110,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"Catch
> Exception com.cloud.utils.exception.CloudRuntimeException for template +
> due to com.cloud.utils.exception.CloudRuntimeException: can not create vdi in
> sr f3429124-745a-70d1-da86-ce97bfb2570d","wait":0}}] }
> sr-list on hypervisor:
>
> [root@Rack1Pod1Host13 ~]# xe sr-list type=nfs
> uuid ( RO): f3429124-745a-70d1-da86-ce97bfb2570d
> name-label ( RW): c65a038a-750c-3b4f-bf26-7ce3b74e1c85
> name-description ( RW): 1
> host ( RO): Rack1Pod1Host13
> type ( RO): nfs
> content-type ( RO): user
> Log snippet from management server log:
> 2013-07-11 11:25:15,239 DEBUG [agent.transport.Request] (DirectAgent-15:null)
> Seq 1-557449293: Executing: { Cmd , MgmtId: 6615759585382, via: 1, Ver: v1,
> Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/1/ddc39e82-13b4-4d30-9149-5ea6c1b801d5.vhd","origUrl":"http://10.147.28.7/templates/newsysvmtemp/systemvmtemplate-2013-06-23-master-xen.vhd.bz2","uuid":"39355f04-ea28-11e2-9610-06045a66","id":1,"format":"VHD","accountId":1,"checksum":"7d76f106e5a5f6b68d114291c5938b41","hvm":false,"displayText":"SystemVM
> Template
> (XenServer)","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.147.28.7/export/home/sanjeev/sec_xen_os","_role":"ImageCache"}},"name":"routing-1"}},"destTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"origUrl":"http://10.147.28.7/templates/newsysvmtemp/systemvmtemplate-2013-06-23-master-xen.vhd.bz2","uuid":"39355f04-ea28-11e2-9610-06045a66","id":1,"format":"VHD","accountId":1,"checksum":"7d76f106e5a5f6b68d114291c5938b41","hvm":false,"displayText":"SystemVM
> Template
> (XenServer)","imageDataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"c65a038a-750c-3b4f-bf26-7ce3b74e1c85","id":1,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/sanjeev/pri_xen_os","port":2049}},"name":"routing-1"}},"wait":10800}}]
> }
> 2013-07-11 11:25:15,241 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-73:null) Seq 1-557449293: Executing request
> 2013-07-11 11:25:16,175 DEBUG [agent.transport.Request] (secstorage-1:null)
> Seq 1-557449302: Waiting for Seq 557449293 Scheduling: { Cmd , MgmtId:
> 6615759585382, via: 1, Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"5b6d5297-e270-4d01-ad4c-f5a75d96134c","origUrl":"http://10.147.28.7/templates/newsysvmtemp/systemvmtemplate-2013-06-23-master-xen.vhd.bz2","uuid":"39355f04-ea28-11e2-9610-06045a66","id":1,"format":"VHD","accountId":1,"checksum":"7d76f106e5a5f6b68d114291c5938b41","hvm":false,"displayText":"SystemVM
> Template
> (XenServer)","imageDataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"c65a038a-750c-3b4f-bf26-7ce3b74e1c85","id":1,"poolType":"NetworkFilesystem","host":"10.147.28.7","p
[jira] [Resolved] (CLOUDSTACK-4889) Hide search box in UCS Blades tab since listUcsBlades API doesn't support search
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-4889. -- Resolution: Fixed > Hide search box in UCS Blades tab since listUcsBlades API doesn't support > search > > > Key: CLOUDSTACK-4889 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4889 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Jessica Wang >Assignee: Jessica Wang > Fix For: 4.2.1 > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4889) Hide search box in UCS Blades tab since listUcsBlades API doesn't support search
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798529#comment-13798529 ] ASF subversion and git services commented on CLOUDSTACK-4889: - Commit 12189074b2e39a99b7021fdb19286a45b6150d18 in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1218907 ] CLOUDSTACK-4889: UI > (1) extend listView widget to support option of hiding/showing search box. (2) Hide search box in UCS Blades tab. > Hide search box in UCS Blades tab since listUcsBlades API doesn't support > search > > > Key: CLOUDSTACK-4889 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4889 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Jessica Wang >Assignee: Jessica Wang > Fix For: 4.2.1 > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4889) Hide search box in UCS Blades tab since listUcsBlades API doesn't support search
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-4889: - Fix Version/s: 4.2.1 > Hide search box in UCS Blades tab since listUcsBlades API doesn't support > search > > > Key: CLOUDSTACK-4889 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4889 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Jessica Wang >Assignee: Jessica Wang > Fix For: 4.2.1 > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4889) Hide search box in UCS Blades tab since listUcsBlades API doesn't support search
Jessica Wang created CLOUDSTACK-4889: Summary: Hide search box in UCS Blades tab since listUcsBlades API doesn't support search Key: CLOUDSTACK-4889 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4889 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Jessica Wang -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4889) Hide search box in UCS Blades tab since listUcsBlades API doesn't support search
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798525#comment-13798525 ] ASF subversion and git services commented on CLOUDSTACK-4889: - Commit 7ef4c7e1a47fca9ac78e5391638782cd29a6188e in branch refs/heads/4.2 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7ef4c7e ] CLOUDSTACK-4889: UI > (1) extend listView widget to support option of hiding/showing search box. (2) Hide search box in UCS Blades tab. > Hide search box in UCS Blades tab since listUcsBlades API doesn't support > search > > > Key: CLOUDSTACK-4889 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4889 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Jessica Wang >Assignee: Jessica Wang > Fix For: 4.2.1 > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4889) Hide search box in UCS Blades tab since listUcsBlades API doesn't support search
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang reassigned CLOUDSTACK-4889: Assignee: Jessica Wang > Hide search box in UCS Blades tab since listUcsBlades API doesn't support > search > > > Key: CLOUDSTACK-4889 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4889 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Jessica Wang >Assignee: Jessica Wang > Fix For: 4.2.1 > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4888) API:UCS:NPE Refresh blades on a decommissioned chassis results in NPE
Parth Jagirdar created CLOUDSTACK-4888: -- Summary: API:UCS:NPE Refresh blades on a decommissioned chassis results in NPE Key: CLOUDSTACK-4888 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4888 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API, UCS Affects Versions: 4.2.0 Environment: UCS Reporter: Parth Jagirdar Priority: Critical Fix For: 4.2.1 Expecting an appropriate error. When refresh blades is issues on a decommissioned chassis. 2013-10-17 13:52:26,432 DEBUG [cloud.api.ApiServlet] (catalina-exec-6:null) ===START=== 10.215.2.19 -- GET command=refreshUcsBlades&response=json&sessionkey=e0Kgb2hcBQPMXSe5O%2FDeRH8v2%2B8%3D&ucsmanagerid=f185ae78-08cb-4a06-a3c8-47c3d2afa896&_=1382043146927 2013-10-17 13:52:26,451 DEBUG [ucs.manager.UcsHttpClient] (catalina-exec-6:null) UCS call: 2013-10-17 13:52:26,458 WARN [ucs.manager.UcsManagerImpl] (catalina-exec-6:null) null java.lang.NullPointerException at com.cloud.ucs.structure.ComputeBlade.fromXmlObject(ComputeBlade.java:62) at com.cloud.ucs.structure.ComputeBlade.fromXmString(ComputeBlade.java:55) at com.cloud.ucs.manager.UcsManagerImpl.listBlades(UcsManagerImpl.java:285) at com.cloud.ucs.manager.UcsManagerImpl.access$100(UcsManagerImpl.java:65) at com.cloud.ucs.manager.UcsManagerImpl$SyncBladesThread.syncBlades(UcsManagerImpl.java:141) at com.cloud.ucs.manager.UcsManagerImpl$SyncBladesThread.run(UcsManagerImpl.java:156) at com.cloud.ucs.manager.UcsManagerImpl.refreshBlades(UcsManagerImpl.java:624) at org.apache.cloudstack.api.RefreshUcsBladesCmd.execute(RefreshUcsBladesCmd.java:42) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:514) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2274) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) 2013-10-17 13:52:26,468 DEBUG [ucs.manager.UcsHttpClient] (catalina-exec-6:null) UCS call: 2013-10-17 13:52:26,471 WARN [cloudstack.api.RefreshUcsBladesCmd] (catalina-exec-6:null) unhandled exception: java.lang.NullPointerException at com.cloud.ucs.structure.ComputeBlade.fromXmlObject(ComputeBlade.java:62) at com.cloud.ucs.structure.ComputeBlade.fromXmString(ComputeBlade.java:55) at com.cloud.ucs.manager.UcsManagerImpl.listBlades(UcsManagerImpl.java:285) at com.cloud.ucs.manager.UcsManagerImpl.refreshBlades(UcsManagerImpl.java:627) at org.apache.cloudstack.api.RefreshUcsBladesCmd.execute(RefreshUcsBladesCmd.java:42) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:514) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.int
[jira] [Commented] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798316#comment-13798316
]
Milamber commented on CLOUDSTACK-4792:
--
Need to add some properties to javamail in the file
/cloud-server/src/com/cloud/alert/AlertManagerImpl.java
props.put("mail.smtp.connectiontimeout","2");
props.put("mail.smtp.timeout","2");
props.put("mail.smtps.connectiontimeout","2");
props.put("mail.smtps.timeout","2");
I will works to add these properties in CS Global Properties
> Invalid SMTP breaks HA
> --
>
> Key: CLOUDSTACK-4792
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792
> 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.2.1
>
>
> Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from
> working. If the smtp ip is listening but does not send a proper HELO HA hangs
> and will not proceed. It seems as if the code
> (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not
> proceed.
> I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe
> we need to make HA independent of smtp alerts or at least put in a timeout so
> HA proceeds.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber reassigned CLOUDSTACK-4792: Assignee: Milamber (was: Anshul Gangwar) > Invalid SMTP breaks HA > -- > > Key: CLOUDSTACK-4792 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Anshul Gangwar >Assignee: Milamber >Priority: Critical > Fix For: 4.2.1 > > > Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from > working. If the smtp ip is listening but does not send a proper HELO HA hangs > and will not proceed. It seems as if the code > (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not > proceed. > I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe > we need to make HA independent of smtp alerts or at least put in a timeout so > HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4887) CLVM broken
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Suich updated CLOUDSTACK-4887:
Status: Ready To Review (was: In Progress)
> CLVM broken
> ---
>
> Key: CLOUDSTACK-4887
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4887
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: Future
>Reporter: Marcus Sorensen
>Assignee: Chris Suich
>Priority: Blocker
> Fix For: Future
>
>
> Chris,
>I think commit 180cfa19 broke CLVM primary storage for KVM. I'm failing VM
> deploy from template. I've been building a 'sanity check' test that focuses
> on the KVM specific suff (tests storage types and supported host OS for now),
> and this bubbled up.
> I reverted this one part in my local code and am testing (seems to fix it),
> but since I'm not clear on the refactor efforts I'm not sure what it should
> really be changed to in order to meet your requirements and keep CLVM working.
> @@ -65,7 +68,7 @@ public class StorageSubsystemCommandHandlerBase implements
> StorageSubsystemComma
> DataStoreTO srcDataStore = srcData.getDataStore();
> DataStoreTO destDataStore = destData.getDataStore();
> -if ((srcData.getObjectType() == DataObjectType.TEMPLATE) &&
> (srcDataStore instanceof NfsTO) && (destData.getDataStore().getRole() ==
> DataStoreRole.Primary)) {
> +if ((srcData.getObjectType() == DataObjectType.TEMPLATE) &&
> (destData.getObjectType() == DataObjectType.TEMPLATE &&
> destData.getDataStore().getRole() == DataStoreRole.Primary)) {
> //copy template to primary storage
> return processor.copyTemplateToPrimaryStorage(cmd);
> } else if (srcData.getObjectType() == DataObjectType.TEMPLATE &&
> srcDataStore.getRole() == DataStoreRole.Primary && destDataStore.getRole() ==
> DataStoreRole.Primary) {
> 4.2 command:
> { Cmd , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/201/fe75caa3-78fd-38ba-b34c-101d0502df2e.qcow2","origUrl":"http://marcus.mlsorensen.com/cloudstack-extras/tiny-centos-63.qcow2","uuid":"4795671b-dd72-4e62-9aac-c0e1d6732003","id":201,"format":"QCOW2","accountId":1,"checksum":"44cd0e6330a59f031460bc18a40c95a2","hvm":true,"displayText":"tiny","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://172.17.10.10:/nfs/secondary","_role":"Image"}},"name":"201-1-2b35186d-79a6-33dc-8b33-83eb650e5e1d","hypervisorType":"KVM"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"73f86d88-ccff-4dfb-ac86-2d76b7891117","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"08e8d399-b238-48f9-a497-1f7f5285d655","id":2,"poolType":"CLVM","host":"localhost","path":"vg0","port":0}},"name":"ROOT-6","size":1073741824,"volumeId":6,"vmName":"i-1-6-VM","accountId":1,"format":"QCOW2","id":6,"hypervisorType":"KVM"}},"executeInSequence":true,"wait":10800}}]
> }
> 4.2 response:
> { Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"newData":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"path":"f69879c0-ae3b-433a-841f-f1f5afc04fc7","accountId":0,"format":"RAW","id":0}},"result":true,"wait":0}}]
> }
> master command:
> { Cmd , MgmtId: 52241639751, via: 1(devcloud-kvm-u), Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/4/02170718-210a-3d8c-91a2-2793ed52f1d8.qcow2","origUrl":"http://download.cloud.com/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2","uuid":"07088e98-1fda-11e3-a1ff-000c29d82947","id":4,"format":"QCOW2","accountId":1,"checksum":"ed0e788280ff2912ea40f7f91ca7a249","hvm":false,"displayText":"CentOS
> 5.5(64-bit) no GUI
> (KVM)","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://172.17.10.10:/nfs/secondary","_role":"Image"}},"name":"centos55-x86_64","hypervisorType":"KVM"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"e08f2a84-0d8b-4c6e-9593-a7554fd57b78","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"0f77072d-c76f-449c-bc6d-e2504644c0ca","id":2,"poolType":"CLVM","host":"localhost","path":"vg0","port":0}},"name":"ROOT-7","size":8589934592,"volumeId":7,"vmName":"i-1-7-VM","accountId":1,"format":"QCOW2","id":7,"hypervisorType":"KVM"}},"executeInSequence":true,"wait":10800}}]
> }
> master response:
> { Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.
[jira] [Commented] (CLOUDSTACK-4887) CLVM broken
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798275#comment-13798275
]
Chris Suich commented on CLOUDSTACK-4887:
-
This was introduced by a bug in the storage subsystem refactoring. The posted
review can be found here: https://reviews.apache.org/r/14715/
> CLVM broken
> ---
>
> Key: CLOUDSTACK-4887
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4887
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: Future
>Reporter: Marcus Sorensen
>Assignee: Chris Suich
>Priority: Blocker
> Fix For: Future
>
>
> Chris,
>I think commit 180cfa19 broke CLVM primary storage for KVM. I'm failing VM
> deploy from template. I've been building a 'sanity check' test that focuses
> on the KVM specific suff (tests storage types and supported host OS for now),
> and this bubbled up.
> I reverted this one part in my local code and am testing (seems to fix it),
> but since I'm not clear on the refactor efforts I'm not sure what it should
> really be changed to in order to meet your requirements and keep CLVM working.
> @@ -65,7 +68,7 @@ public class StorageSubsystemCommandHandlerBase implements
> StorageSubsystemComma
> DataStoreTO srcDataStore = srcData.getDataStore();
> DataStoreTO destDataStore = destData.getDataStore();
> -if ((srcData.getObjectType() == DataObjectType.TEMPLATE) &&
> (srcDataStore instanceof NfsTO) && (destData.getDataStore().getRole() ==
> DataStoreRole.Primary)) {
> +if ((srcData.getObjectType() == DataObjectType.TEMPLATE) &&
> (destData.getObjectType() == DataObjectType.TEMPLATE &&
> destData.getDataStore().getRole() == DataStoreRole.Primary)) {
> //copy template to primary storage
> return processor.copyTemplateToPrimaryStorage(cmd);
> } else if (srcData.getObjectType() == DataObjectType.TEMPLATE &&
> srcDataStore.getRole() == DataStoreRole.Primary && destDataStore.getRole() ==
> DataStoreRole.Primary) {
> 4.2 command:
> { Cmd , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/201/fe75caa3-78fd-38ba-b34c-101d0502df2e.qcow2","origUrl":"http://marcus.mlsorensen.com/cloudstack-extras/tiny-centos-63.qcow2","uuid":"4795671b-dd72-4e62-9aac-c0e1d6732003","id":201,"format":"QCOW2","accountId":1,"checksum":"44cd0e6330a59f031460bc18a40c95a2","hvm":true,"displayText":"tiny","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://172.17.10.10:/nfs/secondary","_role":"Image"}},"name":"201-1-2b35186d-79a6-33dc-8b33-83eb650e5e1d","hypervisorType":"KVM"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"73f86d88-ccff-4dfb-ac86-2d76b7891117","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"08e8d399-b238-48f9-a497-1f7f5285d655","id":2,"poolType":"CLVM","host":"localhost","path":"vg0","port":0}},"name":"ROOT-6","size":1073741824,"volumeId":6,"vmName":"i-1-6-VM","accountId":1,"format":"QCOW2","id":6,"hypervisorType":"KVM"}},"executeInSequence":true,"wait":10800}}]
> }
> 4.2 response:
> { Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"newData":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"path":"f69879c0-ae3b-433a-841f-f1f5afc04fc7","accountId":0,"format":"RAW","id":0}},"result":true,"wait":0}}]
> }
> master command:
> { Cmd , MgmtId: 52241639751, via: 1(devcloud-kvm-u), Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/4/02170718-210a-3d8c-91a2-2793ed52f1d8.qcow2","origUrl":"http://download.cloud.com/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2","uuid":"07088e98-1fda-11e3-a1ff-000c29d82947","id":4,"format":"QCOW2","accountId":1,"checksum":"ed0e788280ff2912ea40f7f91ca7a249","hvm":false,"displayText":"CentOS
> 5.5(64-bit) no GUI
> (KVM)","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://172.17.10.10:/nfs/secondary","_role":"Image"}},"name":"centos55-x86_64","hypervisorType":"KVM"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"e08f2a84-0d8b-4c6e-9593-a7554fd57b78","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"0f77072d-c76f-449c-bc6d-e2504644c0ca","id":2,"poolType":"CLVM","host":"localhost","path":"vg0","port":0}},"name":"ROOT-7","size":8589934592,"volumeId":7,"vmName":"i-1-7-VM","accountId":1,"format":"QCOW2","id":7,"hypervisorType":"KVM"}},"ex
[jira] [Created] (CLOUDSTACK-4887) CLVM broken
Marcus Sorensen created CLOUDSTACK-4887:
---
Summary: CLVM broken
Key: CLOUDSTACK-4887
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4887
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM
Affects Versions: Future
Reporter: Marcus Sorensen
Assignee: Chris Suich
Priority: Blocker
Fix For: Future
Chris,
I think commit 180cfa19 broke CLVM primary storage for KVM. I'm failing VM
deploy from template. I've been building a 'sanity check' test that focuses on
the KVM specific suff (tests storage types and supported host OS for now), and
this bubbled up.
I reverted this one part in my local code and am testing (seems to fix it), but
since I'm not clear on the refactor efforts I'm not sure what it should really
be changed to in order to meet your requirements and keep CLVM working.
@@ -65,7 +68,7 @@ public class StorageSubsystemCommandHandlerBase implements
StorageSubsystemComma
DataStoreTO srcDataStore = srcData.getDataStore();
DataStoreTO destDataStore = destData.getDataStore();
-if ((srcData.getObjectType() == DataObjectType.TEMPLATE) &&
(srcDataStore instanceof NfsTO) && (destData.getDataStore().getRole() ==
DataStoreRole.Primary)) {
+if ((srcData.getObjectType() == DataObjectType.TEMPLATE) &&
(destData.getObjectType() == DataObjectType.TEMPLATE &&
destData.getDataStore().getRole() == DataStoreRole.Primary)) {
//copy template to primary storage
return processor.copyTemplateToPrimaryStorage(cmd);
} else if (srcData.getObjectType() == DataObjectType.TEMPLATE &&
srcDataStore.getRole() == DataStoreRole.Primary && destDataStore.getRole() ==
DataStoreRole.Primary) {
4.2 command:
{ Cmd , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 100111,
[{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/201/fe75caa3-78fd-38ba-b34c-101d0502df2e.qcow2","origUrl":"http://marcus.mlsorensen.com/cloudstack-extras/tiny-centos-63.qcow2","uuid":"4795671b-dd72-4e62-9aac-c0e1d6732003","id":201,"format":"QCOW2","accountId":1,"checksum":"44cd0e6330a59f031460bc18a40c95a2","hvm":true,"displayText":"tiny","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://172.17.10.10:/nfs/secondary","_role":"Image"}},"name":"201-1-2b35186d-79a6-33dc-8b33-83eb650e5e1d","hypervisorType":"KVM"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"73f86d88-ccff-4dfb-ac86-2d76b7891117","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"08e8d399-b238-48f9-a497-1f7f5285d655","id":2,"poolType":"CLVM","host":"localhost","path":"vg0","port":0}},"name":"ROOT-6","size":1073741824,"volumeId":6,"vmName":"i-1-6-VM","accountId":1,"format":"QCOW2","id":6,"hypervisorType":"KVM"}},"executeInSequence":true,"wait":10800}}]
}
4.2 response:
{ Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
[{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"newData":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"path":"f69879c0-ae3b-433a-841f-f1f5afc04fc7","accountId":0,"format":"RAW","id":0}},"result":true,"wait":0}}]
}
master command:
{ Cmd , MgmtId: 52241639751, via: 1(devcloud-kvm-u), Ver: v1, Flags: 100111,
[{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/4/02170718-210a-3d8c-91a2-2793ed52f1d8.qcow2","origUrl":"http://download.cloud.com/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2","uuid":"07088e98-1fda-11e3-a1ff-000c29d82947","id":4,"format":"QCOW2","accountId":1,"checksum":"ed0e788280ff2912ea40f7f91ca7a249","hvm":false,"displayText":"CentOS
5.5(64-bit) no GUI
(KVM)","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://172.17.10.10:/nfs/secondary","_role":"Image"}},"name":"centos55-x86_64","hypervisorType":"KVM"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"e08f2a84-0d8b-4c6e-9593-a7554fd57b78","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"0f77072d-c76f-449c-bc6d-e2504644c0ca","id":2,"poolType":"CLVM","host":"localhost","path":"vg0","port":0}},"name":"ROOT-7","size":8589934592,"volumeId":7,"vmName":"i-1-7-VM","accountId":1,"format":"QCOW2","id":7,"hypervisorType":"KVM"}},"executeInSequence":true,"wait":10800}}]
}
master response:
{ Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
[{"com.cloud.agent.api.Answer":{"result":false,"details":"not implemented
yet","wait":0}}] }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4649) Windows Vms that were deployed in 6.0.2 Xenservers fail to start (after being stopped) after upgrading host to 6.2.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798234#comment-13798234 ] ASF subversion and git services commented on CLOUDSTACK-4649: - Commit fdd33fbb174b3279ab8ab6cde30e6185ac8da7e2 in branch refs/heads/4.2 from [~anthonyxu] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fdd33fb ] Revert "CLOUDSTACK-4649" This reverts commit 5950d37e9f57a41a945a11724f250aaeffa9b118. > Windows Vms that were deployed in 6.0.2 Xenservers fail to start (after being > stopped) after upgrading host to 6.2. > --- > > Key: CLOUDSTACK-4649 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4649 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.1 > Environment: Build from 4.2-forward >Reporter: Sangeetha Hariharan >Assignee: Anthony Xu >Priority: Critical > Fix For: 4.2.1 > > Attachments: XenUpgrade.rar > > > Windows Vms that were deployed in 6.0.2 Xenservers fail to start (after being > stopped) after upgrade to 6.2 > Steps to reproduce the problem: > 1. Advanced zone with XS 6.0.2 > 2. install windows 2008 VM > 3. install xs-tools(XS 6.0.2) in windows 2008 VM > 4. upgrade XS 6.0.2 to XS 6.2 > As part of upgrade procedure , we are able to see all the Vms successfully > live migrate from XS 6.0.2 host to an upgraded XS 6.2 host. > 6. Now stop and start this windows VM. > Vm start reportd success. > Vm does not boot successfully. > We see the following exception on the screen: > "System Recovery Option:" -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-754) nTier Apps 2.0 : Remote access VPN to VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798166#comment-13798166 ] ASF subversion and git services commented on CLOUDSTACK-754: Commit 73c7de70e971314a568ff748e6b1752a86ae1e21 in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=73c7de7 ] CLOUDSTACK-754: UI > add Remote Access VPN support for VPC sourceNAT IP. > nTier Apps 2.0 : Remote access VPN to VPC > - > > Key: CLOUDSTACK-754 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-754 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 >Reporter: Kishan Kavala >Assignee: Sheng Yang >Priority: Critical > Fix For: 4.3.0 > > > This item is a sub task (2.9) of > https://issues.apache.org/jira/browse/CLOUDSTACK-621 > This would enable remote-users to login to their VPC network -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4746) Allocation capacity of a cluster during HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-4746: Fix Version/s: (was: 4.3.0) 4.2.1 > Allocation capacity of a cluster during HA > -- > > Key: CLOUDSTACK-4746 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4746 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.2.1 > > > When the host goes down. Cloudstack will stop the VM's for which HA is not > enabled. Once cloudstack marks these VM's as stopped then the capacity of > these VM's is moved into the reserved capacity. > If the VM's are HA enabled then cloudstack will stop and start the VM's on > another host. During this time the capacity of the VM's will be moved to > reserved capacity once the VM's are stopped, But when the Vm's are being > started cloudstack will try to calculate what will be total allocated > capacity if the VM is started again ( even though the CPU for the VM is > already reserved). This is a bug in cloudstack where the CPU required for the > VM is considered twice when calculating the allocated capacity. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4746) Allocation capacity of a cluster during HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta reassigned CLOUDSTACK-4746: --- Assignee: Nitin Mehta (was: Prachi Damle) > Allocation capacity of a cluster during HA > -- > > Key: CLOUDSTACK-4746 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4746 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.2.1 > > > When the host goes down. Cloudstack will stop the VM's for which HA is not > enabled. Once cloudstack marks these VM's as stopped then the capacity of > these VM's is moved into the reserved capacity. > If the VM's are HA enabled then cloudstack will stop and start the VM's on > another host. During this time the capacity of the VM's will be moved to > reserved capacity once the VM's are stopped, But when the Vm's are being > started cloudstack will try to calculate what will be total allocated > capacity if the VM is started again ( even though the CPU for the VM is > already reserved). This is a bug in cloudstack where the CPU required for the > VM is considered twice when calculating the allocated capacity. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4816) provide configurable option to choose single vs multipart upload to S3 object storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798136#comment-13798136 ] ASF subversion and git services commented on CLOUDSTACK-4816: - Commit 25acfbad78d0adc4ccf798f31d685be9c068c254 in branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=25acfba ] CLOUDSTACK-4816:provide configurable option to choose single vs multipart upload to S3 object storage based on object size. > provide configurable option to choose single vs multipart upload to S3 object > storage > -- > > Key: CLOUDSTACK-4816 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4816 > 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: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.2.1 > > > In 4.2, we only supports multipart upload for registering templates and > uploading volumes to object storage in secondary storage. The value of > multi-part is for network failure and throughput when you are going to a > remote storage. But with local storage (local to the DC) customers may prefer > single upload. Also, for templates you know the full size of the object > upfront and don't really need a multipart upload. > Some object storage vendors may prefer that this can be configured. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4493) registerSSHKeyPair API doc contains wrong API response (private key)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-4493: --- Fix Version/s: (was: 4.2.1) 4.3.0 > registerSSHKeyPair API doc contains wrong API response (private key) > > > Key: CLOUDSTACK-4493 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4493 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Harikrishna Patnala >Assignee: Harikrishna Patnala >Priority: Critical > Fix For: 4.3.0 > > > registerSSHKeyPair API returns only name and fingerprint of the ssh keypair > (sets null to private key parameter). > Our API doc > http://cloudstack.apache.org/docs/api/apidocs-4.1/user/registerSSHKeyPair.html > has an extra parameter private key in response which anyway we return null. > Response Name : Description > - >fingerprint : Fingerprint of the public key >name : Name of the keypair >privatekey: Private key > This is because we use same response object for all ssh key pair related APIs. > In this case it is misleading and seems like CS API leaks implementation > details. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4834) [Automation] Failed to create volume; failed with error "Invalid parameter diskofferingid value"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797998#comment-13797998 ] Rayees Namathponnan commented on CLOUDSTACK-4834: - Please try with master build and test cases from master > [Automation] Failed to create volume; failed with error "Invalid parameter > diskofferingid value" > > > Key: CLOUDSTACK-4834 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4834 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes >Affects Versions: 4.3.0 > Environment: KVM > Branch Master >Reporter: Rayees Namathponnan >Assignee: Gaurav Aradhye >Priority: Blocker > Fix For: 4.3.0 > > Attachments: CLOUDSTACK-4834.rar > > > Volume test cases from BVT suite failed, test cases failed while adding new > volume; > i tried to new volume from UI, its failed with error > Unable to execute API command createvolume due to invalid value. Invalid > parameter diskofferingid value=7c5f301b-69b3-43f4-a5b8-8acb356c5e3f due to > incorrect long value format, or entity does not exist or due to incorrect > parameter annotation for the field in api cmd class > Test case creating with API, observed below error in log > Execute cmd: createvolume failed, due to: errorCode: 431, errorText:volume > size 1073741824, but the maximum size allowed is 0 Gb > Log from MS log > > 2013-10-07 12:34:58,564 DEBUG [c.c.a.ApiServlet] > (catalina-exec-5:ctx-6b44eb58) ===START=== 10.223.240.194 -- GET > account=test-resource_details-TestResourceDetail-IMWBHV&domainid=34f66d20-2f83-11e3-a447-1a6f7bb0d0a8&name=ndm&zoneid=79 > ed0a9e-469c-460d-b674-0a2944e5d557&apiKey=ylSEBq6mjjv1nOqm2lsFI-uBAbDbeUuX2mOIUslHLFH62Vmgl2E5scxr5lUaJ8lkZ4qJ24Mg7mY6tMgsDv6CTw&command=createVolume&signature=8ySmF7tiGjJaxpZwKs5iPXLo%2FtU%3D&diskofferingid=aeeb298c-4d10-4bab-ba13-ad67 > f2dc026c&response=json > 2013-10-07 12:34:58,629 INFO [c.c.a.ApiServer] (catalina-exec-5:ctx-6b44eb58 > ctx-3e806b15 ctx-60ef7e57) volume size 1073741824, but the maximum size > allowed is 0 Gb. > 2013-10-07 12:34:58,637 DEBUG [c.c.a.ApiServlet] > (catalina-exec-5:ctx-6b44eb58 ctx-3e806b15 ctx-60ef7e57) ===END=== > 10.223.240.194 -- GET > account=test-resource_details-TestResourceDetail-IMWBHV&domainid=34f66d20-2f83-11e3-a447-1a6f7bb0d0a8&name=ndm&zoneid=79ed0a9e-469c-460d-b674-0a2944e5d557&apiKey=ylSEBq6mjjv1nOqm2lsFI-uBAbDbeUuX2mOIUslHLFH62Vmgl2E5scxr5lUaJ8lkZ4qJ24Mg7mY6tMgsDv6CTw&command=createVolume&signature=8ySmF7tiGjJaxpZwKs5iPXLo%2FtU%3D&diskofferingid=aeeb298c-4d10-4bab-ba13-ad67f2dc026c&response=json > Attached MS log with defect -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4835) [Automation] [BVT] Update global configuration test cases failed in master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797994#comment-13797994 ] Rayees Namathponnan commented on CLOUDSTACK-4835: - Have you tried with master build ? > [Automation] [BVT] Update global configuration test cases failed in master > -- > > Key: CLOUDSTACK-4835 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4835 > 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: KVM > Branch - master >Reporter: Rayees Namathponnan >Assignee: Gaurav Aradhye >Priority: Blocker > Fix For: 4.3.0 > > > Below BVT test cases failed, > integration.smoke.test_global_settings.TestUpdateConfigWithScope.test_UpdateConfigParamWithScope > Unable to find the global property "use.external.dns" in master, is it > removed ? > you can see the result at > http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/lastCompletedBuild/suite=test_global_settings/#showFailuresLink > Error Message > Execute cmd: updateconfiguration failed, due to: errorCode: 431, > errorText:Config parameter with name use.external.dns doesn't exist > Stacktrace > Traceback (most recent call last): > File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run > testMethod() > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/test/integration/smoke/test_global_settings.py", > line 47, in test_UpdateConfigParamWithScope > updateConfigurationResponse = > self.apiClient.updateConfiguration(updateConfigurationCmd) > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py", > line 1188, in updateConfiguration > response = self.connection.marvin_request(command, > response_type=response, method=method) > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/cloudstackConnection.py", > line 222, in marvin_request > response = jsonHelper.getResultObj(response.json(), response_type) > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/jsonHelper.py", > line 148, in getResultObj > raise cloudstackException.cloudstackAPIException(respname, errMsg) > cloudstackAPIException: Execute cmd: updateconfiguration failed, due to: > errorCode: 431, errorText:Config parameter with name use.external.dns doesn't > exist -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4833) [Automation][BVT] Template and ISO test cases failing from BVT suite, during LIST api call
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797993#comment-13797993 ] Rayees Namathponnan commented on CLOUDSTACK-4833: - This issue is only with master not 4.2.1 Have you tried with master ? > [Automation][BVT] Template and ISO test cases failing from BVT suite, during > LIST api call > --- > > Key: CLOUDSTACK-4833 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4833 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.3.0 > Environment: KVM automation on master >Reporter: Rayees Namathponnan >Assignee: Gaurav Aradhye >Priority: Blocker > Fix For: 4.3.0 > > > ISO and Template test cases from master BVT suite > i) test_iso.py > 2) integration.smoke.test_templates.TestTemplates.test_03_delete_template > Both the test cases are failed during list API call, you can see the result > at > http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/suite=test_templates/lastCompletedBuild/testReport/integration.smoke.test_templates/TestTemplates/test_03_delete_template/ > Error Message > Execute cmd: listtemplates failed, due to: errorCode: 431, errorText:Unable > to execute API command listtemplates due to invalid value. Invalid parameter > id value=f3abe3e3-2712-476d-9d71-05207597e4f4 due to incorrect long value > format, or entity does not exist or due to incorrect parameter annotation for > the field in api cmd class. > >> begin captured logging << > test_03_delete_template (integration.smoke.test_templates.TestTemplates): > DEBUG: Deleting Template ID: f3abe3e3-2712-476d-9d71-05207597e4f4 > - >> end captured logging << - > Stacktrace > File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run > testMethod() > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/test/integration/smoke/test_templates.py", > line 543, in test_03_delete_template > domainid=self.account.domainid > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/integration/lib/common.py", > line 534, in list_templates > return(apiclient.listTemplates(cmd)) > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py", > line 713, in listTemplates > response = self.connection.marvin_request(command, > response_type=response, method=method) > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/cloudstackConnection.py", > line 222, in marvin_request > response = jsonHelper.getResultObj(response.json(), response_type) > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/jsonHelper.py", > line 148, in getResultObj > raise cloudstackException.cloudstackAPIException(respname, errMsg) > Execute cmd: listtemplates failed, due to: errorCode: 431, errorText:Unable > to execute API command listtemplates due to invalid value. Invalid parameter > id value=f3abe3e3-2712-476d-9d71-05207597e4f4 due to incorrect long value > format, or entity does not exist or due to incorrect parameter annotation for > the field in api cmd class. > >> begin captured logging << > test_03_delete_template (integration.smoke.test_templates.TestTemplates): > DEBUG: Deleting Template ID: f3abe3e3-2712-476d-9d71-05207597e4f4 > - >> end captured logging << - > and > http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/suite=test_iso/lastCompletedBuild/testReport/%3Cnose/suite/ContextSuite_context_TestISO__setup/ > Error Message > Exception while downloading ISO b2a39aff-95c9-447a-9318-a2702eaab1cc: Execute > cmd: listisos failed, due to: errorCode: 431, errorText:Unable to execute API > command listisos due to invalid value. Invalid parameter id > value=b2a39aff-95c9-447a-9318-a2702eaab1cc due to incorrect long value > format, or entity does not exist or due to incorrect parameter annotation for > the field in api cmd class. > Stacktrace > Traceback (most recent call last): > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_iso/887/lib/python2.7/site-packages/nose/suite.py", > line 208, in run > self.setUp() > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_iso/887/lib/python2.7/site-packages/nose
[jira] [Commented] (CLOUDSTACK-3305) TemplateSync Deletes the templates in creation state from Seconday storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797980#comment-13797980 ] Marcus Sorensen commented on CLOUDSTACK-3305: - Template sync should probably look at timestamp of templates, and maybe have a global config that only cleans up templates once they're X minutes old (default 1440 or something like that). > TemplateSync Deletes the templates in creation state from Seconday storage. > --- > > Key: CLOUDSTACK-3305 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3305 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta > Fix For: Future > > > this is what is happening. > 1. Template creation from snapshot triggered. Work going on, but there is no > update in DB that there is Work in Progress (//TODO Fix this Long term by > putting an intermediate state) > 2. Work gets complete and the agent returns back. We dont update the DB and > send a computechecksum command to SSVM. (//TODO Long term - The create > template itself should return the checksum - fix needed at ssvm for vmware > and at citrix/libvrt resourcebase for XS and KVM) > 3. Template sync gets triggered (because of unhealthy ssvm connecting back > and forth with MS) and reports this template to the MS being on secondary > storage, but we have no record that WIP in DB. So template sync deletes the > template on SS. (//TODO short term - Should we be aggressive to delete the > template or just sending an alert is fine ? Or if we can just relax and maybe > delete in the next run or do more checking ?) > 4. Compute checksum returns and DB is updated that a template is created and > put into Ready status, but underlying it go deleted. > For now I have changed the compute checksum logic after updating the DB that > template is created. See the commit above for more information. BUT, this > doesnt completely eliminate the race condition. There would still be a window > where before updating the DB sync mechanism deletes the template (I think > this should happen rarely), > I can also make the fix possible in #3 (//TODO short term - Should we be > aggressive to delete the template or just sending an alert is fine) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3994) Wrong error notification is generated when Primary storage (Cluster wide) is added with wrong path
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797906#comment-13797906
]
ASF subversion and git services commented on CLOUDSTACK-3994:
-
Commit 93172df5569cea02cecf1c4e57646910409ffb6d in branch refs/heads/master
from [~anshulg]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=93172df ]
CLOUDSTACK-3994: fix for Wrong error notification is generated when Primary
storage is added with wrong path
Signed-off-by: Sateesh Chodapuneedi
> Wrong error notification is generated when Primary storage (Cluster wide) is
> added with wrong path
> --
>
> Key: CLOUDSTACK-3994
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3994
> 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
>Priority: Minor
> Fix For: 4.3.0
>
> Attachments: apilog.log, management-server.log
>
>
> Steps:
> 1. Configure Adv Zone with VMWARE
> 2. Tried to add wrong cluster wide primary storage point
> It failed saying " Failed to delete storage pool on host"
> 2013-08-01 10:00:12,928 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-230:null) Seq 1-757532143: Executing request
> 2013-08-01 10:00:12,928 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-230:null) Seq 1-757532143: Response Received:
> 2013-08-01 10:00:12,929 DEBUG [agent.transport.Request]
> (DirectAgent-230:null) Seq 1-757532143: Processing: { Ans: , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"success","wait":0}}]
> }
> 2013-08-01 10:00:12,933 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-757532143: Received: { Ans: , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 10, { Answer } }
> 2013-08-01 10:00:12,933 DEBUG [agent.manager.AgentManagerImpl]
> (catalina-exec-23:null) Details from executing class
> com.cloud.agent.api.CreateStoragePoolCommand: success
> 2013-08-01 10:00:12,933 DEBUG
> [datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl]
> (catalina-exec-23:null) In createPool Adding the pool to each of the hosts
> 2013-08-01 10:00:12,935 DEBUG [cloud.storage.StorageManagerImpl]
> (catalina-exec-23:null) Adding pool null to host 1
> 2013-08-01 10:00:12,940 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-757532144: Sending { Cmd , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.ModifyStoragePoolCommand":{"add":true,"pool":{"id":5,"uuid":"86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","host":"10.102.192.100","path":"/cpg_vol/sailaja/ps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","wait":0}}]
> }
> 2013-08-01 10:00:12,941 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-757532144: Executing: { Cmd , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.ModifyStoragePoolCommand":{"add":true,"pool":{"id":5,"uuid":"86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","host":"10.102.192.100","path":"/cpg_vol/sailaja/ps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","wait":0}}]
> }
> 2013-08-01 10:00:12,941 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-230:null) Seq 1-757532144: Executing request
> 2013-08-01 10:00:12,942 INFO [vmware.resource.VmwareResource]
> (DirectAgent-230:10.102.192.18) Executing resource ModifyStoragePoolCommand:
> {"add":true,"pool":{"id":5,"uuid":"86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","host":"10.102.192.100","path":"/cpg_vol/sailaja/ps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","wait":0}
> 2013-08-01 10:00:13,144 INFO [vmware.mo.HostMO]
> (DirectAgent-230: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/ps1, poolUuid: 86ee525833e736f0b3c1f6029e5c8bdf. Exception
> mesg: An error occurred during host configuration.
> 2013-08-01 10:00:13,145 ERROR [vmware.resource.VmwareResource]
> (DirectAgent-230: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.exe
[jira] [Commented] (CLOUDSTACK-3994) Wrong error notification is generated when Primary storage (Cluster wide) is added with wrong path
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797906#comment-13797906
]
ASF subversion and git services commented on CLOUDSTACK-3994:
-
Commit 93172df5569cea02cecf1c4e57646910409ffb6d in branch refs/heads/master
from [~anshulg]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=93172df ]
CLOUDSTACK-3994: fix for Wrong error notification is generated when Primary
storage is added with wrong path
Signed-off-by: Sateesh Chodapuneedi
> Wrong error notification is generated when Primary storage (Cluster wide) is
> added with wrong path
> --
>
> Key: CLOUDSTACK-3994
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3994
> 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
>Priority: Minor
> Fix For: 4.3.0
>
> Attachments: apilog.log, management-server.log
>
>
> Steps:
> 1. Configure Adv Zone with VMWARE
> 2. Tried to add wrong cluster wide primary storage point
> It failed saying " Failed to delete storage pool on host"
> 2013-08-01 10:00:12,928 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-230:null) Seq 1-757532143: Executing request
> 2013-08-01 10:00:12,928 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-230:null) Seq 1-757532143: Response Received:
> 2013-08-01 10:00:12,929 DEBUG [agent.transport.Request]
> (DirectAgent-230:null) Seq 1-757532143: Processing: { Ans: , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"success","wait":0}}]
> }
> 2013-08-01 10:00:12,933 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-757532143: Received: { Ans: , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 10, { Answer } }
> 2013-08-01 10:00:12,933 DEBUG [agent.manager.AgentManagerImpl]
> (catalina-exec-23:null) Details from executing class
> com.cloud.agent.api.CreateStoragePoolCommand: success
> 2013-08-01 10:00:12,933 DEBUG
> [datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl]
> (catalina-exec-23:null) In createPool Adding the pool to each of the hosts
> 2013-08-01 10:00:12,935 DEBUG [cloud.storage.StorageManagerImpl]
> (catalina-exec-23:null) Adding pool null to host 1
> 2013-08-01 10:00:12,940 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-757532144: Sending { Cmd , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.ModifyStoragePoolCommand":{"add":true,"pool":{"id":5,"uuid":"86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","host":"10.102.192.100","path":"/cpg_vol/sailaja/ps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","wait":0}}]
> }
> 2013-08-01 10:00:12,941 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-757532144: Executing: { Cmd , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.ModifyStoragePoolCommand":{"add":true,"pool":{"id":5,"uuid":"86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","host":"10.102.192.100","path":"/cpg_vol/sailaja/ps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","wait":0}}]
> }
> 2013-08-01 10:00:12,941 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-230:null) Seq 1-757532144: Executing request
> 2013-08-01 10:00:12,942 INFO [vmware.resource.VmwareResource]
> (DirectAgent-230:10.102.192.18) Executing resource ModifyStoragePoolCommand:
> {"add":true,"pool":{"id":5,"uuid":"86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","host":"10.102.192.100","path":"/cpg_vol/sailaja/ps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","wait":0}
> 2013-08-01 10:00:13,144 INFO [vmware.mo.HostMO]
> (DirectAgent-230: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/ps1, poolUuid: 86ee525833e736f0b3c1f6029e5c8bdf. Exception
> mesg: An error occurred during host configuration.
> 2013-08-01 10:00:13,145 ERROR [vmware.resource.VmwareResource]
> (DirectAgent-230: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.exe
[jira] [Commented] (CLOUDSTACK-3994) Wrong error notification is generated when Primary storage (Cluster wide) is added with wrong path
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797889#comment-13797889
]
ASF subversion and git services commented on CLOUDSTACK-3994:
-
Commit f52533c819b46483cda6647e0a9ae30a7558acea in branch refs/heads/4.2 from
[~anshulg]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f52533c ]
CLOUDSTACK-3994: fix for Wrong error notification is generated when Primary
storage is added with wrong path
Signed-off-by: Sateesh Chodapuneedi
> Wrong error notification is generated when Primary storage (Cluster wide) is
> added with wrong path
> --
>
> Key: CLOUDSTACK-3994
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3994
> 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
>Priority: Minor
> Fix For: 4.3.0
>
> Attachments: apilog.log, management-server.log
>
>
> Steps:
> 1. Configure Adv Zone with VMWARE
> 2. Tried to add wrong cluster wide primary storage point
> It failed saying " Failed to delete storage pool on host"
> 2013-08-01 10:00:12,928 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-230:null) Seq 1-757532143: Executing request
> 2013-08-01 10:00:12,928 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-230:null) Seq 1-757532143: Response Received:
> 2013-08-01 10:00:12,929 DEBUG [agent.transport.Request]
> (DirectAgent-230:null) Seq 1-757532143: Processing: { Ans: , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"success","wait":0}}]
> }
> 2013-08-01 10:00:12,933 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-757532143: Received: { Ans: , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 10, { Answer } }
> 2013-08-01 10:00:12,933 DEBUG [agent.manager.AgentManagerImpl]
> (catalina-exec-23:null) Details from executing class
> com.cloud.agent.api.CreateStoragePoolCommand: success
> 2013-08-01 10:00:12,933 DEBUG
> [datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl]
> (catalina-exec-23:null) In createPool Adding the pool to each of the hosts
> 2013-08-01 10:00:12,935 DEBUG [cloud.storage.StorageManagerImpl]
> (catalina-exec-23:null) Adding pool null to host 1
> 2013-08-01 10:00:12,940 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-757532144: Sending { Cmd , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.ModifyStoragePoolCommand":{"add":true,"pool":{"id":5,"uuid":"86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","host":"10.102.192.100","path":"/cpg_vol/sailaja/ps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","wait":0}}]
> }
> 2013-08-01 10:00:12,941 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-757532144: Executing: { Cmd , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.ModifyStoragePoolCommand":{"add":true,"pool":{"id":5,"uuid":"86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","host":"10.102.192.100","path":"/cpg_vol/sailaja/ps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","wait":0}}]
> }
> 2013-08-01 10:00:12,941 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-230:null) Seq 1-757532144: Executing request
> 2013-08-01 10:00:12,942 INFO [vmware.resource.VmwareResource]
> (DirectAgent-230:10.102.192.18) Executing resource ModifyStoragePoolCommand:
> {"add":true,"pool":{"id":5,"uuid":"86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","host":"10.102.192.100","path":"/cpg_vol/sailaja/ps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf","wait":0}
> 2013-08-01 10:00:13,144 INFO [vmware.mo.HostMO]
> (DirectAgent-230: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/ps1, poolUuid: 86ee525833e736f0b3c1f6029e5c8bdf. Exception
> mesg: An error occurred during host configuration.
> 2013-08-01 10:00:13,145 ERROR [vmware.resource.VmwareResource]
> (DirectAgent-230: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.execut
[jira] [Assigned] (CLOUDSTACK-2232) Automation: Add automation for Persistent networks without running a VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye reassigned CLOUDSTACK-2232: -- Assignee: Gaurav Aradhye > Automation: Add automation for Persistent networks without running a VM > > > Key: CLOUDSTACK-2232 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2232 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Sudha Ponnaganti >Assignee: Gaurav Aradhye > Fix For: 4.3.0 > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3840) [Automation] test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters failed to raise expected Exception
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797833#comment-13797833
]
Jayapal Reddy commented on CLOUDSTACK-3840:
---
The CIDR validation issue got fixed, please check test case again.
ASF subversion and git services added a comment - 03/Sep/13 14:28
Commit 7aea599eb4f16fc919a7556d5800f105a99b708e in branch refs/heads/master
from Jayapal Reddy
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7aea599 ]
CLOUDSTACK-4586 Added CIDR validation for SG Egress rules
> [Automation]
> test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters
> failed to raise expected Exception
> -
>
> Key: CLOUDSTACK-3840
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3840
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Management Server
>Affects Versions: 4.2.0
> Environment: Automation
>Reporter: Rayees Namathponnan
>Assignee: Rayees Namathponnan
> Fix For: 4.3.0
>
>
> Test case
> integration.component.test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters
> failed in automation runs, observed below error
> Error Message
> Exception not raised
> >> begin captured logging <<
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Created security
> group with ID: 896d1c49-1c40-4090-97f9-922ff4060ed6
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
> rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid port
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
> rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid cidr
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_rules.py",
> line 2098, in test_invalid_parameters
> domainid=self.account.domainid
> File "/usr/local/lib/python2.7/unittest/case.py", line 112, in __exit__
> "{0} not raised".format(exc_name))
> Exception not raised
> >> begin captured logging <<
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Created security
> group with ID: 896d1c49-1c40-4090-97f9-922ff4060ed6
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
> rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid port
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
> rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid cidr
> - >> end captured logging << -
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4137) KVM: After unmanaging cluster, manage cluster will not bring KVM hosts to UP state. cloud-agent on KVM hosts has to be restarted manually
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinandan Prateek updated CLOUDSTACK-4137:
---
Labels: ReleaseNote (was: )
> KVM: After unmanaging cluster, manage cluster will not bring KVM hosts to UP
> state. cloud-agent on KVM hosts has to be restarted manually
> -
>
> Key: CLOUDSTACK-4137
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4137
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.2.0
> Environment: hypervisor : KVM
>Reporter: prashant kumar mishra
>Assignee: Kishan Kavala
>Priority: Critical
> Labels: ReleaseNote
> Fix For: 4.2.1
>
> Attachments: Logs_DB_Agent.rar
>
>
> Steps to reproduce
> ---
> 1-prepare a CS ->one cluster-->one kvm(rhel6.3)
> 2-unmanage cluster
> 3-manage cluster
> Expected
> --
> Host should come up , in running state
> Actual
> --
> Host remain in Disconnect state
> My observation
> ---
> 1-after host went in disconnect state i performed host maintenance mode
> then cancel maintenance mode and host came up
> 2-restart cloud-agent on the kvm hosts bring the hosts to UP state
> Logs:
> --
> 2013-08-07 20:14:16,999 DEBUG [cloud.api.ApiServlet] (catalina-exec-23:null)
> ===START=== 10.252.192.53 -- GET
> command=updateCluster&id=854b547a-fbee-4eed-895d-b8ea96d1cc23&managedstate=Unmanaged&response=json&sessionkey=vOfsgLOiksyXg%2B23XuFp6maNm1I%3D&_=1375867173396
> 2013-08-07 20:14:17,031 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-2042691611: Sending { Cmd , MgmtId:
> 6703101771911, via: 1, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.MaintainCommand":{"wait":0}}] }
> 2013-08-07 20:14:17,038 DEBUG [agent.transport.Request]
> (AgentManager-Handler-7:null) Seq 1-2042691611: Processing: { Ans: , MgmtId:
> 6703101771911, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.MaintainAnswer":{"willMigrate":true,"result":true,"wait":0}}]
> }
> 2013-08-07 20:14:17,038 DEBUG [agent.manager.AgentAttache]
> (AgentManager-Handler-7:null) Seq 1-2042691611: No more commands found
> 2013-08-07 20:14:17,038 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-2042691611: Received: { Ans: , MgmtId:
> 6703101771911, via: 1, Ver: v1, Flags: 110, { MaintainAnswer } }
> 2013-08-07 20:14:17,039 INFO [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Host 1 is disconnecting with event ShutdownRequested
> 2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) The next status of agent 1is Disconnected, current
> status is Up
> 2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Deregistering link for 1 with state Disconnected
> 2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Remove Agent : 1
> 2013-08-07 20:14:17,052 DEBUG [agent.manager.ConnectedAgentAttache]
> (AgentTaskPool-4:null) Processing Disconnect.
> 2013-08-07 20:14:17,052 DEBUG [agent.manager.AgentAttache]
> (AgentTaskPool-4:null) Seq 1-2042691586: Sending disconnect to class
> com.cloud.network.security.SecurityGroupListener
> 2013-08-07 20:14:17,052 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.hypervisor.xen.discoverer.XcpServerDiscoverer_EnhancerByCloudStack_eccb8bca
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.deploy.DeploymentPlanningManagerImpl_EnhancerByCloudStack_b3901640
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.network.NetworkManagerImpl_EnhancerByCloudStack_c52127d3
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.storage.secondary.SecondaryStorageListener
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.hypervisor.vmware.manager.VmwareManagerImpl_EnhancerByCloudStack_5c9626cd
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.network.security.SecurityGroupListener
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.storage.listener.StoragePoolMonitor
> 2013-08-07 20:14:17,0
[jira] [Resolved] (CLOUDSTACK-4137) KVM: After unmanaging cluster, manage cluster will not bring KVM hosts to UP state. cloud-agent on KVM hosts has to be restarted manually
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinandan Prateek resolved CLOUDSTACK-4137.
Resolution: Won't Fix
Masked as release noted.
> KVM: After unmanaging cluster, manage cluster will not bring KVM hosts to UP
> state. cloud-agent on KVM hosts has to be restarted manually
> -
>
> Key: CLOUDSTACK-4137
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4137
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.2.0
> Environment: hypervisor : KVM
>Reporter: prashant kumar mishra
>Assignee: Kishan Kavala
>Priority: Critical
> Labels: ReleaseNote
> Fix For: 4.2.1
>
> Attachments: Logs_DB_Agent.rar
>
>
> Steps to reproduce
> ---
> 1-prepare a CS ->one cluster-->one kvm(rhel6.3)
> 2-unmanage cluster
> 3-manage cluster
> Expected
> --
> Host should come up , in running state
> Actual
> --
> Host remain in Disconnect state
> My observation
> ---
> 1-after host went in disconnect state i performed host maintenance mode
> then cancel maintenance mode and host came up
> 2-restart cloud-agent on the kvm hosts bring the hosts to UP state
> Logs:
> --
> 2013-08-07 20:14:16,999 DEBUG [cloud.api.ApiServlet] (catalina-exec-23:null)
> ===START=== 10.252.192.53 -- GET
> command=updateCluster&id=854b547a-fbee-4eed-895d-b8ea96d1cc23&managedstate=Unmanaged&response=json&sessionkey=vOfsgLOiksyXg%2B23XuFp6maNm1I%3D&_=1375867173396
> 2013-08-07 20:14:17,031 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-2042691611: Sending { Cmd , MgmtId:
> 6703101771911, via: 1, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.MaintainCommand":{"wait":0}}] }
> 2013-08-07 20:14:17,038 DEBUG [agent.transport.Request]
> (AgentManager-Handler-7:null) Seq 1-2042691611: Processing: { Ans: , MgmtId:
> 6703101771911, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.MaintainAnswer":{"willMigrate":true,"result":true,"wait":0}}]
> }
> 2013-08-07 20:14:17,038 DEBUG [agent.manager.AgentAttache]
> (AgentManager-Handler-7:null) Seq 1-2042691611: No more commands found
> 2013-08-07 20:14:17,038 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-2042691611: Received: { Ans: , MgmtId:
> 6703101771911, via: 1, Ver: v1, Flags: 110, { MaintainAnswer } }
> 2013-08-07 20:14:17,039 INFO [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Host 1 is disconnecting with event ShutdownRequested
> 2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) The next status of agent 1is Disconnected, current
> status is Up
> 2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Deregistering link for 1 with state Disconnected
> 2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Remove Agent : 1
> 2013-08-07 20:14:17,052 DEBUG [agent.manager.ConnectedAgentAttache]
> (AgentTaskPool-4:null) Processing Disconnect.
> 2013-08-07 20:14:17,052 DEBUG [agent.manager.AgentAttache]
> (AgentTaskPool-4:null) Seq 1-2042691586: Sending disconnect to class
> com.cloud.network.security.SecurityGroupListener
> 2013-08-07 20:14:17,052 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.hypervisor.xen.discoverer.XcpServerDiscoverer_EnhancerByCloudStack_eccb8bca
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.deploy.DeploymentPlanningManagerImpl_EnhancerByCloudStack_b3901640
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.network.NetworkManagerImpl_EnhancerByCloudStack_c52127d3
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.storage.secondary.SecondaryStorageListener
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.hypervisor.vmware.manager.VmwareManagerImpl_EnhancerByCloudStack_5c9626cd
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.network.security.SecurityGroupListener
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.storage.listener.StoragePoolMonitor
>
[jira] [Commented] (CLOUDSTACK-4137) KVM: After unmanaging cluster, manage cluster will not bring KVM hosts to UP state. cloud-agent on KVM hosts has to be restarted manually
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797824#comment-13797824
]
Abhinandan Prateek commented on CLOUDSTACK-4137:
Release noted as per http://bugs-ccp.citrix.com/browse/CS-16386.
> KVM: After unmanaging cluster, manage cluster will not bring KVM hosts to UP
> state. cloud-agent on KVM hosts has to be restarted manually
> -
>
> Key: CLOUDSTACK-4137
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4137
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.2.0
> Environment: hypervisor : KVM
>Reporter: prashant kumar mishra
>Assignee: Kishan Kavala
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: Logs_DB_Agent.rar
>
>
> Steps to reproduce
> ---
> 1-prepare a CS ->one cluster-->one kvm(rhel6.3)
> 2-unmanage cluster
> 3-manage cluster
> Expected
> --
> Host should come up , in running state
> Actual
> --
> Host remain in Disconnect state
> My observation
> ---
> 1-after host went in disconnect state i performed host maintenance mode
> then cancel maintenance mode and host came up
> 2-restart cloud-agent on the kvm hosts bring the hosts to UP state
> Logs:
> --
> 2013-08-07 20:14:16,999 DEBUG [cloud.api.ApiServlet] (catalina-exec-23:null)
> ===START=== 10.252.192.53 -- GET
> command=updateCluster&id=854b547a-fbee-4eed-895d-b8ea96d1cc23&managedstate=Unmanaged&response=json&sessionkey=vOfsgLOiksyXg%2B23XuFp6maNm1I%3D&_=1375867173396
> 2013-08-07 20:14:17,031 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-2042691611: Sending { Cmd , MgmtId:
> 6703101771911, via: 1, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.MaintainCommand":{"wait":0}}] }
> 2013-08-07 20:14:17,038 DEBUG [agent.transport.Request]
> (AgentManager-Handler-7:null) Seq 1-2042691611: Processing: { Ans: , MgmtId:
> 6703101771911, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.MaintainAnswer":{"willMigrate":true,"result":true,"wait":0}}]
> }
> 2013-08-07 20:14:17,038 DEBUG [agent.manager.AgentAttache]
> (AgentManager-Handler-7:null) Seq 1-2042691611: No more commands found
> 2013-08-07 20:14:17,038 DEBUG [agent.transport.Request]
> (catalina-exec-23:null) Seq 1-2042691611: Received: { Ans: , MgmtId:
> 6703101771911, via: 1, Ver: v1, Flags: 110, { MaintainAnswer } }
> 2013-08-07 20:14:17,039 INFO [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Host 1 is disconnecting with event ShutdownRequested
> 2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) The next status of agent 1is Disconnected, current
> status is Up
> 2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Deregistering link for 1 with state Disconnected
> 2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Remove Agent : 1
> 2013-08-07 20:14:17,052 DEBUG [agent.manager.ConnectedAgentAttache]
> (AgentTaskPool-4:null) Processing Disconnect.
> 2013-08-07 20:14:17,052 DEBUG [agent.manager.AgentAttache]
> (AgentTaskPool-4:null) Seq 1-2042691586: Sending disconnect to class
> com.cloud.network.security.SecurityGroupListener
> 2013-08-07 20:14:17,052 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.hypervisor.xen.discoverer.XcpServerDiscoverer_EnhancerByCloudStack_eccb8bca
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.deploy.DeploymentPlanningManagerImpl_EnhancerByCloudStack_b3901640
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.network.NetworkManagerImpl_EnhancerByCloudStack_c52127d3
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.storage.secondary.SecondaryStorageListener
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.hypervisor.vmware.manager.VmwareManagerImpl_EnhancerByCloudStack_5c9626cd
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.network.security.SecurityGroupListener
> 2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-4:null) Sending Disconnect to listener:
> com.cloud.stora
[jira] [Assigned] (CLOUDSTACK-3840) [Automation] test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters failed to raise expected Exception
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayapal Reddy reassigned CLOUDSTACK-3840:
-
Assignee: Rayees Namathponnan (was: Jayapal Reddy)
> [Automation]
> test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters
> failed to raise expected Exception
> -
>
> Key: CLOUDSTACK-3840
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3840
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Management Server
>Affects Versions: 4.2.0
> Environment: Automation
>Reporter: Rayees Namathponnan
>Assignee: Rayees Namathponnan
> Fix For: 4.3.0
>
>
> Test case
> integration.component.test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters
> failed in automation runs, observed below error
> Error Message
> Exception not raised
> >> begin captured logging <<
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Created security
> group with ID: 896d1c49-1c40-4090-97f9-922ff4060ed6
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
> rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid port
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
> rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid cidr
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_rules.py",
> line 2098, in test_invalid_parameters
> domainid=self.account.domainid
> File "/usr/local/lib/python2.7/unittest/case.py", line 112, in __exit__
> "{0} not raised".format(exc_name))
> Exception not raised
> >> begin captured logging <<
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Created security
> group with ID: 896d1c49-1c40-4090-97f9-922ff4060ed6
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
> rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid port
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
> rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid cidr
> - >> end captured logging << -
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-3840) [Automation] test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters failed to raise expected Exception
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayapal Reddy reassigned CLOUDSTACK-3840:
-
Assignee: Jayapal Reddy (was: venkata swamybabu budumuru)
> [Automation]
> test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters
> failed to raise expected Exception
> -
>
> Key: CLOUDSTACK-3840
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3840
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Management Server
>Affects Versions: 4.2.0
> Environment: Automation
>Reporter: Rayees Namathponnan
>Assignee: Jayapal Reddy
> Fix For: 4.3.0
>
>
> Test case
> integration.component.test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters
> failed in automation runs, observed below error
> Error Message
> Exception not raised
> >> begin captured logging <<
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Created security
> group with ID: 896d1c49-1c40-4090-97f9-922ff4060ed6
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
> rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid port
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
> rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid cidr
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_rules.py",
> line 2098, in test_invalid_parameters
> domainid=self.account.domainid
> File "/usr/local/lib/python2.7/unittest/case.py", line 112, in __exit__
> "{0} not raised".format(exc_name))
> Exception not raised
> >> begin captured logging <<
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Created security
> group with ID: 896d1c49-1c40-4090-97f9-922ff4060ed6
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
> rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid port
> testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
> rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid cidr
> - >> end captured logging << -
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3840) [Automation] test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters failed to raise expected Exception
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797819#comment-13797819
]
Jayapal Reddy commented on CLOUDSTACK-3840:
---
Hi,
>From the UI it is working as expected. Please see the below MS logs.
Please check the test case.
2013-10-17 17:28:53,317 DEBUG [cloud.api.ApiServlet]
(1074250461@qtp-1443430503-11:null) ===START=== 10.252.192.106 -- GET
command=authorizeSecurityGroupEgress&response=json&sessionkey=CwR0dunRxGVTa5qyt1l%2B5IpwC4Y%3D&securitygroupid=b25e3468-36f5-11e3-a5d4-0a5aa429dedd&protocol=tcp&domainid=6b161f1c-36f5-11e3-a5d4-0a5aa429dedd&account=admin&startport=22&endport=22&cidrlist=0.0.0.10&_=1382011133303
2013-10-17 17:28:53,346 DEBUG [cloud.async.AsyncJobManagerImpl]
(1074250461@qtp-1443430503-11:null) submit async job-17 = [
c84d5f5c-7d6a-4242-b2d0-aaa60f83712e ], details: AsyncJobVO {id:17, userId: 2,
accountId: 2, sessionKey: null, instanceType: SecurityGroup, instanceId: 1,
cmd:
org.apache.cloudstack.api.command.user.securitygroup.AuthorizeSecurityGroupEgressCmd,
cmdOriginator: null, cmdInfo:
{"sessionkey":"CwR0dunRxGVTa5qyt1l+5IpwC4Y\u003d","protocol":"tcp","cmdEventType":"SG.AUTH.EGRESS","ctxUserId":"2","securitygroupid":"b25e3468-36f5-11e3-a5d4-0a5aa429dedd","httpmethod":"GET","startport":"22","domainid":"6b161f1c-36f5-11e3-a5d4-0a5aa429dedd","endport":"22","response":"json","cidrlist":"0.0.0.10","account":"admin","_":"1382011133303","ctxAccountId":"2","ctxStartEventId":"70"},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 1, completeMsid: null,
lastUpdated: null, lastPolled: null, created: null}
2013-10-17 17:28:53,347 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-4:job-17 = [ c84d5f5c-7d6a-4242-b2d0-aaa60f83712e ]) Executing
org.apache.cloudstack.api.command.user.securitygroup.AuthorizeSecurityGroupEgressCmd
for job-17 = [ c84d5f5c-7d6a-4242-b2d0-aaa60f83712e ]
2013-10-17 17:28:53,349 DEBUG [cloud.api.ApiServlet]
(1074250461@qtp-1443430503-11:null) ===END=== 10.252.192.106 -- GET
command=authorizeSecurityGroupEgress&response=json&sessionkey=CwR0dunRxGVTa5qyt1l%2B5IpwC4Y%3D&securitygroupid=b25e3468-36f5-11e3-a5d4-0a5aa429dedd&protocol=tcp&domainid=6b161f1c-36f5-11e3-a5d4-0a5aa429dedd&account=admin&startport=22&endport=22&cidrlist=0.0.0.10&_=1382011133303
2013-10-17 17:28:53,377 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-4:job-17 = [ c84d5f5c-7d6a-4242-b2d0-aaa60f83712e ]) Unexpected
exception while executing
org.apache.cloudstack.api.command.user.securitygroup.AuthorizeSecurityGroupEgressCmd
com.cloud.exception.InvalidParameterValueException: Invalid cidr 0.0.0.10
at
com.cloud.network.security.SecurityGroupManagerImpl.authorizeSecurityGroupRule(SecurityGroupManagerImpl.java:606)
249
2013-10-17 17:25:12,302 DEBUG [cloud.async.AsyncJobManagerImpl]
(1074250461@qtp-1443430503-11:null) submit async job-16 = [
0b1d5086-584f-41a5-bda6-85f81b07132b ], details: AsyncJobVO {id:16, userId: 2,
accountId: 2, sessionKey: null, instanceType: SecurityGroup, instanceId: 1,
cmd:
org.apache.cloudstack.api.command.user.securitygroup.AuthorizeSecurityGroupEgressCmd,
cmdOriginator: null, cmdInfo:
{"sessionkey":"CwR0dunRxGVTa5qyt1l+5IpwC4Y\u003d","protocol":"tcp","cmdEventType":"SG.AUTH.EGRESS","ctxUserId":"2","securitygroupid":"b25e3468-36f5-11e3-a5d4-0a5aa429dedd","httpmethod":"GET","startport":"22","domainid":"6b161f1c-36f5-11e3-a5d4-0a5aa429dedd","endport":"22","response":"json","cidrlist":"0.0.0.0/33","account":"admin","_":"1382010912249","ctxAccountId":"2","ctxStartEventId":"67"},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 1, completeMsid: null,
lastUpdated: null, lastPolled: null, created: null}
2013-10-17 17:25:12,304 DEBUG [cloud.api.ApiServlet]
(1074250461@qtp-1443430503-11:null) ===END=== 10.252.192.106 -- GET
command=authorizeSecurityGroupEgress&response=json&sessionkey=CwR0dunRxGVTa5qyt1l%2B5IpwC4Y%3D&securitygroupid=b25e3468-36f5-11e3-a5d4-0a5aa429dedd&protocol=tcp&domainid=6b161f1c-36f5-11e3-a5d4-0a5aa429dedd&account=admin&startport=22&endport=22&cidrlist=0.0.0.0%2F33&_=1382010912249
2013-10-17 17:25:12,321 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-3:job-16 = [ 0b1d5086-584f-41a5-bda6-85f81b07132b ]) Executing
org.apache.cloudstack.api.command.user.securitygroup.AuthorizeSecurityGroupEgressCmd
for job-16 = [ 0b1d5086-584f-41a5-bda6-85f81b07132b ]
2013-10-17 17:25:12,351 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-3:job-16 = [ 0b1d5086-584f-41a5-bda6-85f81b07132b ]) Unexpected
exception while executing
org.apache.cloudstack.api.command.user.securitygroup.AuthorizeSecurityGroupEgressCmd
com.cloud.exception.InvalidParameterValueException: Invalid cidr 0.0.0.0/33
at
com.cloud.network.security.Secu
[jira] [Updated] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-4792: --- Fix Version/s: 4.2.1 > Invalid SMTP breaks HA > -- > > Key: CLOUDSTACK-4792 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 > 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.2.1 > > > Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from > working. If the smtp ip is listening but does not send a proper HELO HA hangs > and will not proceed. It seems as if the code > (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not > proceed. > I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe > we need to make HA independent of smtp alerts or at least put in a timeout so > HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-702) Multiple IP Ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797813#comment-13797813 ] ASF subversion and git services commented on CLOUDSTACK-702: Commit 8b0894b27c45c3e89824ece3a6c47c8143d3ae76 in branch refs/heads/4.2 from [~sanjeevn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8b0894b ] CLOUDSTACK-702: Verify Userdata,password services 1.Added two tests to vefiy userdata and password services on alias ip on VR Conflicts: test/integration/component/maint/test_multiple_ip_ranges.py Signed-off-by: sanjeevneelarapu Signed-off-by: venkataswamybabu budumuru (cherry picked from commit 7a7fb61a17911987838a2b6744d594c840df7c2e) > Multiple IP Ranges > -- > > Key: CLOUDSTACK-702 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-702 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Manan Shah >Assignee: Bharat Kumar > Fix For: 4.2.0 > > > Requirements described at: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+Ranges > Requirements discussion email thread link: > http://markmail.org/search/?q=[ASFCS41]+Multiple+IP+Ranges+list%3Aorg.apache.incubator.cloudstack-dev -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-702) Multiple IP Ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797812#comment-13797812 ] ASF subversion and git services commented on CLOUDSTACK-702: Commit 7a7fb61a17911987838a2b6744d594c840df7c2e in branch refs/heads/master from [~sanjeevn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7a7fb61 ] CLOUDSTACK-702: Verify Userdata,password services 1.Added two tests to vefiy userdata and password services on alias ip on VR Conflicts: test/integration/component/maint/test_multiple_ip_ranges.py Signed-off-by: sanjeevneelarapu Signed-off-by: venkataswamybabu budumuru > Multiple IP Ranges > -- > > Key: CLOUDSTACK-702 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-702 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Manan Shah >Assignee: Bharat Kumar > Fix For: 4.2.0 > > > Requirements described at: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+Ranges > Requirements discussion email thread link: > http://markmail.org/search/?q=[ASFCS41]+Multiple+IP+Ranges+list%3Aorg.apache.incubator.cloudstack-dev -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4766) [Automation] test_reset_ssh_keypair executing in infinite loop and regression suite hang
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797810#comment-13797810
]
ASF subversion and git services commented on CLOUDSTACK-4766:
-
Commit 9cc557509265d8faacca134e8bfeb3a31ddbeb31 in branch refs/heads/master
from [~gpshilamkar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9cc5575 ]
CLOUDSTACK-4766: Add timeout if vm does not reach running state
The tests use to wait for ever for the vm to attain Running state.
Added a timeout so it does not get into infinite loop.
Signed-off-by: venkataswamybabu budumuru
(cherry picked from commit e3bcdc16a11d7452b5bf6ce5e5993dcd008526a6)
> [Automation] test_reset_ssh_keypair executing in infinite loop and regression
> suite hang
>
>
> Key: CLOUDSTACK-4766
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4766
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.2.1
> Environment: Automation advanced zone
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
>Priority: Blocker
> Fix For: 4.2.1
>
>
> Few test cases from test_reset_ssh_keypair.py suite executing infinite loop
> hang automation
> See the below code from test_reset_ssh_keypair.py, here test case checking
> VM's state in every 60 sec, due to some reason if this vm never comes to
> running; this code will execute in a loop
> 578 while True:
> 579 vms = VirtualMachine.list(
> 580 self.apiclient,
> 581 account=self.account.name,
> 582 domainid=self.account.domainid,
> 583 listall=True
> 584 )
> 585 if vms[0].state == "Running":
> 586 break
> 587 self.debug("Vm not in Running state sleep 60s")
> 588 time.sleep(60)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4766) [Automation] test_reset_ssh_keypair executing in infinite loop and regression suite hang
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797809#comment-13797809
]
ASF subversion and git services commented on CLOUDSTACK-4766:
-
Commit e3bcdc16a11d7452b5bf6ce5e5993dcd008526a6 in branch refs/heads/4.2 from
[~gpshilamkar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e3bcdc1 ]
CLOUDSTACK-4766: Add timeout if vm does not reach running state
The tests use to wait for ever for the vm to attain Running state.
Added a timeout so it does not get into infinite loop.
Signed-off-by: venkataswamybabu budumuru
> [Automation] test_reset_ssh_keypair executing in infinite loop and regression
> suite hang
>
>
> Key: CLOUDSTACK-4766
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4766
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.2.1
> Environment: Automation advanced zone
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
>Priority: Blocker
> Fix For: 4.2.1
>
>
> Few test cases from test_reset_ssh_keypair.py suite executing infinite loop
> hang automation
> See the below code from test_reset_ssh_keypair.py, here test case checking
> VM's state in every 60 sec, due to some reason if this vm never comes to
> running; this code will execute in a loop
> 578 while True:
> 579 vms = VirtualMachine.list(
> 580 self.apiclient,
> 581 account=self.account.name,
> 582 domainid=self.account.domainid,
> 583 listall=True
> 584 )
> 585 if vms[0].state == "Running":
> 586 break
> 587 self.debug("Vm not in Running state sleep 60s")
> 588 time.sleep(60)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4624) VM Migration fails in 'Security Group Enabled Advanced Zone' with CloudRuntimeException: callHostPlugin failed for cmd: network_rules
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797793#comment-13797793
]
Paul Angus commented on CLOUDSTACK-4624:
Yes, /var/run/cloud does exist, and it contains i-2-76-VM.log and r-32-VM.log.
i-2-76-VM.log contains:
i-2-76-VM,76,[IP_REDACTED],12,2602c3ba6866a7a5d48335c74c185df5,1,06:f8:32:00:05:32
> VM Migration fails in 'Security Group Enabled Advanced Zone' with
> CloudRuntimeException: callHostPlugin failed for cmd: network_rules
> -
>
> Key: CLOUDSTACK-4624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4624
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: XenServer
>Affects Versions: 4.2.0, Future
> Environment: CloudStack 4.2.0 with XenServer 6.1 or 6.2
>Reporter: Paul Angus
>Assignee: Jayapal Reddy
>Priority: Critical
> Fix For: 4.2.1
>
>
> VM Migration fails in a 'Security Group Enabled Advanced Zone' with
> CloudRuntimeException: callHostPlugin failed for cmd: network_rules
> 013-09-06 14:18:07,711 DEBUG [network.security.SecurityGroupManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Security
> Group Mgr v2: scheduling ruleset updates for 1 vms (unique=1), current queue
> size=0
> 2013-09-06 14:18:07,715 DEBUG [network.security.SecurityGroupManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Security
> Group Mgr v2: done scheduling ruleset updates for 1 vms: num new jobs=1 num
> rows insert or updated=1 time taken=4
> 2013-09-06 14:18:07,715 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) VM state
> transitted from :Migrating to Running with event: OperationSucceededvm's
> original host id: 7 new host id: 8 host id before state transition: 8
> 2013-09-06 14:18:07,721 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-244:null) Ping from 5
> 2013-09-06 14:18:07,728 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Hosts's
> actual total CPU: 63840 and CPU after applying overprovisioning: 127680
> 2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Hosts's
> actual total RAM: 267404820480 and RAM after applying overprovisioning:
> 267404820480
> 2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) release
> cpu from host: 7, old used: 1000,reserved: 0, actual total: 63840, total with
> overprovisioning: 127680; new used: 0,reserved:0; movedfromreserved:
> false,moveToReserveredfalse
> 2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) release
> mem from host: 7, old used: 1073741824,reserved: 0, total: 267404820480; new
> used: 0,reserved:0; movedfromreserved: false,moveToReserveredfalse
> 2013-09-06 14:18:07,731 DEBUG [cloud.api.ApiServlet] (catalina-exec-18:null)
> ===START=== 10.67.9.233 -- GET
> command=queryAsyncJobResult&jobId=16e9e8e3-460e-4a72-a455-d65b01f3b360&response=json&sessionkey=hLoqoRm93LQk67lSOtoBQZludFg%3D&_=1378473487668
> 2013-09-06 14:18:07,738 DEBUG [agent.transport.Request]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Seq
> 8-576979043: Sending { Cmd , MgmtId: 345052351047, via: 8, Ver: v1, Flags:
> 100011,
> [{"com.cloud.agent.api.CheckVirtualMachineCommand":{"vmName":"i-2-11-VM","wait":20}}]
> }
> 2013-09-06 14:18:07,738 DEBUG [agent.transport.Request]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Seq
> 8-576979043: Executing: { Cmd , MgmtId: 345052351047, via: 8, Ver: v1,
> Flags: 100011,
> [{"com.cloud.agent.api.CheckVirtualMachineCommand":{"vmName":"i-2-11-VM","wait":20}}]
> }
> 2013-09-06 14:18:07,739 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-436:null) Seq 8-576979043: Executing request
> 2013-09-06 14:18:07,747 DEBUG [network.security.SecurityGroupManagerImpl]
> (SecGrp-Worker-41:null) SecurityGroupManager v2: sending ruleset update for
> vm i-2-11-VM:ingress num rules=4:egress num rules=0 num cidrs=6
> sig=8ccd7a72119d5c8180377d3cd847c10f
> 2013-09-06 14:18:07,750 DEBUG [agent.transport.Request]
> (SecGrp-Worker-41:null) Seq 8-576979044: Sending { Cmd , MgmtId:
> 345052351047, via: 8, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SecurityGroupRulesCmd":{"guestIp":"10.79.129.49","vmName":"i-2-11-VM","guestMac":"06:b5:
[jira] [Comment Edited] (CLOUDSTACK-4624) VM Migration fails in 'Security Group Enabled Advanced Zone' with CloudRuntimeException: callHostPlugin failed for cmd: network_rules
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797789#comment-13797789
]
Wei Zhou edited comment on CLOUDSTACK-4624 at 10/17/13 11:03 AM:
-
Does /var/run/cloud/ directory exist on your host?
If not, create it and try again
was (Author: weizhou):
Does /var/run/cloud/ directory exist on your host?
> VM Migration fails in 'Security Group Enabled Advanced Zone' with
> CloudRuntimeException: callHostPlugin failed for cmd: network_rules
> -
>
> Key: CLOUDSTACK-4624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4624
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: XenServer
>Affects Versions: 4.2.0, Future
> Environment: CloudStack 4.2.0 with XenServer 6.1 or 6.2
>Reporter: Paul Angus
>Assignee: Jayapal Reddy
>Priority: Critical
> Fix For: 4.2.1
>
>
> VM Migration fails in a 'Security Group Enabled Advanced Zone' with
> CloudRuntimeException: callHostPlugin failed for cmd: network_rules
> 013-09-06 14:18:07,711 DEBUG [network.security.SecurityGroupManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Security
> Group Mgr v2: scheduling ruleset updates for 1 vms (unique=1), current queue
> size=0
> 2013-09-06 14:18:07,715 DEBUG [network.security.SecurityGroupManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Security
> Group Mgr v2: done scheduling ruleset updates for 1 vms: num new jobs=1 num
> rows insert or updated=1 time taken=4
> 2013-09-06 14:18:07,715 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) VM state
> transitted from :Migrating to Running with event: OperationSucceededvm's
> original host id: 7 new host id: 8 host id before state transition: 8
> 2013-09-06 14:18:07,721 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-244:null) Ping from 5
> 2013-09-06 14:18:07,728 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Hosts's
> actual total CPU: 63840 and CPU after applying overprovisioning: 127680
> 2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Hosts's
> actual total RAM: 267404820480 and RAM after applying overprovisioning:
> 267404820480
> 2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) release
> cpu from host: 7, old used: 1000,reserved: 0, actual total: 63840, total with
> overprovisioning: 127680; new used: 0,reserved:0; movedfromreserved:
> false,moveToReserveredfalse
> 2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) release
> mem from host: 7, old used: 1073741824,reserved: 0, total: 267404820480; new
> used: 0,reserved:0; movedfromreserved: false,moveToReserveredfalse
> 2013-09-06 14:18:07,731 DEBUG [cloud.api.ApiServlet] (catalina-exec-18:null)
> ===START=== 10.67.9.233 -- GET
> command=queryAsyncJobResult&jobId=16e9e8e3-460e-4a72-a455-d65b01f3b360&response=json&sessionkey=hLoqoRm93LQk67lSOtoBQZludFg%3D&_=1378473487668
> 2013-09-06 14:18:07,738 DEBUG [agent.transport.Request]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Seq
> 8-576979043: Sending { Cmd , MgmtId: 345052351047, via: 8, Ver: v1, Flags:
> 100011,
> [{"com.cloud.agent.api.CheckVirtualMachineCommand":{"vmName":"i-2-11-VM","wait":20}}]
> }
> 2013-09-06 14:18:07,738 DEBUG [agent.transport.Request]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Seq
> 8-576979043: Executing: { Cmd , MgmtId: 345052351047, via: 8, Ver: v1,
> Flags: 100011,
> [{"com.cloud.agent.api.CheckVirtualMachineCommand":{"vmName":"i-2-11-VM","wait":20}}]
> }
> 2013-09-06 14:18:07,739 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-436:null) Seq 8-576979043: Executing request
> 2013-09-06 14:18:07,747 DEBUG [network.security.SecurityGroupManagerImpl]
> (SecGrp-Worker-41:null) SecurityGroupManager v2: sending ruleset update for
> vm i-2-11-VM:ingress num rules=4:egress num rules=0 num cidrs=6
> sig=8ccd7a72119d5c8180377d3cd847c10f
> 2013-09-06 14:18:07,750 DEBUG [agent.transport.Request]
> (SecGrp-Worker-41:null) Seq 8-576979044: Sending { Cmd , MgmtId:
> 345052351047, via: 8, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SecurityGroupRulesCmd":{"guestIp":"10.79.129.49","vmName":"i-2-11-VM
[jira] [Commented] (CLOUDSTACK-4624) VM Migration fails in 'Security Group Enabled Advanced Zone' with CloudRuntimeException: callHostPlugin failed for cmd: network_rules
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797789#comment-13797789
]
Wei Zhou commented on CLOUDSTACK-4624:
--
Does /var/run/cloud/ directory exist on your host?
> VM Migration fails in 'Security Group Enabled Advanced Zone' with
> CloudRuntimeException: callHostPlugin failed for cmd: network_rules
> -
>
> Key: CLOUDSTACK-4624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4624
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: XenServer
>Affects Versions: 4.2.0, Future
> Environment: CloudStack 4.2.0 with XenServer 6.1 or 6.2
>Reporter: Paul Angus
>Assignee: Jayapal Reddy
>Priority: Critical
> Fix For: 4.2.1
>
>
> VM Migration fails in a 'Security Group Enabled Advanced Zone' with
> CloudRuntimeException: callHostPlugin failed for cmd: network_rules
> 013-09-06 14:18:07,711 DEBUG [network.security.SecurityGroupManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Security
> Group Mgr v2: scheduling ruleset updates for 1 vms (unique=1), current queue
> size=0
> 2013-09-06 14:18:07,715 DEBUG [network.security.SecurityGroupManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Security
> Group Mgr v2: done scheduling ruleset updates for 1 vms: num new jobs=1 num
> rows insert or updated=1 time taken=4
> 2013-09-06 14:18:07,715 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) VM state
> transitted from :Migrating to Running with event: OperationSucceededvm's
> original host id: 7 new host id: 8 host id before state transition: 8
> 2013-09-06 14:18:07,721 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-244:null) Ping from 5
> 2013-09-06 14:18:07,728 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Hosts's
> actual total CPU: 63840 and CPU after applying overprovisioning: 127680
> 2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Hosts's
> actual total RAM: 267404820480 and RAM after applying overprovisioning:
> 267404820480
> 2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) release
> cpu from host: 7, old used: 1000,reserved: 0, actual total: 63840, total with
> overprovisioning: 127680; new used: 0,reserved:0; movedfromreserved:
> false,moveToReserveredfalse
> 2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) release
> mem from host: 7, old used: 1073741824,reserved: 0, total: 267404820480; new
> used: 0,reserved:0; movedfromreserved: false,moveToReserveredfalse
> 2013-09-06 14:18:07,731 DEBUG [cloud.api.ApiServlet] (catalina-exec-18:null)
> ===START=== 10.67.9.233 -- GET
> command=queryAsyncJobResult&jobId=16e9e8e3-460e-4a72-a455-d65b01f3b360&response=json&sessionkey=hLoqoRm93LQk67lSOtoBQZludFg%3D&_=1378473487668
> 2013-09-06 14:18:07,738 DEBUG [agent.transport.Request]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Seq
> 8-576979043: Sending { Cmd , MgmtId: 345052351047, via: 8, Ver: v1, Flags:
> 100011,
> [{"com.cloud.agent.api.CheckVirtualMachineCommand":{"vmName":"i-2-11-VM","wait":20}}]
> }
> 2013-09-06 14:18:07,738 DEBUG [agent.transport.Request]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Seq
> 8-576979043: Executing: { Cmd , MgmtId: 345052351047, via: 8, Ver: v1,
> Flags: 100011,
> [{"com.cloud.agent.api.CheckVirtualMachineCommand":{"vmName":"i-2-11-VM","wait":20}}]
> }
> 2013-09-06 14:18:07,739 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-436:null) Seq 8-576979043: Executing request
> 2013-09-06 14:18:07,747 DEBUG [network.security.SecurityGroupManagerImpl]
> (SecGrp-Worker-41:null) SecurityGroupManager v2: sending ruleset update for
> vm i-2-11-VM:ingress num rules=4:egress num rules=0 num cidrs=6
> sig=8ccd7a72119d5c8180377d3cd847c10f
> 2013-09-06 14:18:07,750 DEBUG [agent.transport.Request]
> (SecGrp-Worker-41:null) Seq 8-576979044: Sending { Cmd , MgmtId:
> 345052351047, via: 8, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SecurityGroupRulesCmd":{"guestIp":"10.79.129.49","vmName":"i-2-11-VM","guestMac":"06:b5:fa:00:07:25","signature":"8ccd7a72119d5c8180377d3cd847c10f","seqNum":11,"vmId":11,"msId":345052351047,"ingressRuleSet":[{"proto":"icmp","star
[jira] [Commented] (CLOUDSTACK-4551) Migrating the data volume from NFS to local storage ,underlying disk offering is not changed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797765#comment-13797765 ] ASF subversion and git services commented on CLOUDSTACK-4551: - Commit 9fc47148983919392f6a238b45fac824c50b in branch refs/heads/master from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9fc471d ] CLOUDSTACK-4551: Migrating the data volume from NFS to local storage ,underlying disk offering is not changed. Even though the volume may get migrated from shared to local storage, it is not possible to update the disk offering. The fix is to disallow migration from shared to local store. > Migrating the data volume from NFS to local storage ,underlying disk offering > is not changed. > - > > Key: CLOUDSTACK-4551 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4551 > 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: manasaveloori >Assignee: Koushik Das >Priority: Critical > Fix For: 4.2.1 > > > .Steps: > 1.Have CS with 4.2 build. > 2.Have 2 primary storages NFS and local,NFS secondary. > 3.Create disk offering using local storage. > 4.Create a data volume using NFS. > 5.Now migrate the volume to local primary storage. > Observation: > Volume is getting migrated ad storage is changed from NFS to local but the > underlying disk offering is not changed. > >Disk offering with which NFS volume is created >id: 3 > domain_id: NULL > name: Small > uuid: d5b03402-9136-476f-9333-7db89def7b12 > display_text: Small Disk, 5 GB > disk_size: 5368709120 > type: Disk > tags: NULL > recreatable: 0 > use_local_storage: 0 > unique_name: Cloud.Com-Small >system_use: 0 >customized: 0 > removed: NULL > created: 2013-08-29 11:23:41 > sort_key: 0 > display_offering: 1 > customized_iops: NULL > min_iops: NULL > max_iops: NULL > bytes_read_rate: NULL > bytes_write_rate: NULL >iops_read_rate: NULL > iops_write_rate: NULL > > volume created using NFS > mysql> select * from volumes where name = "sharedBU"\G; > *** 1. row *** > id: 7 > account_id: 2 > domain_id: 1 >pool_id: 201 > last_pool_id: NULL >instance_id: NULL > device_id: NULL > name: sharedBU > uuid: 945073f2-1680-4e22-af35-9d7c0bb12486 > size: 5368709120 > folder: /export/home/manasa/primaryVMw > path: d52a77ff39c54c499441661ca0af789a > pod_id: 1 > data_center_id: 1 > iscsi_name: NULL >host_ip: NULL >volume_type: DATADISK > pool_type: NetworkFilesystem > disk_offering_id: 3 >template_id: NULL > iso_id: NULL > first_snapshot_backup_uuid: NULL >recreatable: 0 >created: 2013-08-29 12:02:08 > attached: NULL >updated: 2013-08-29 13:59:42 >removed: NULL > state: Ready > chain_info: NULL > update_count: 2 > disk_type: NULL > vm_snapshot_chain_size: NULL > display_volume: 1 > format: OVA > min_iops: NULL > max_iops: NULL > 1 row in set (0.00 sec) > Volume after migrating to local primary storage. >id: 20 > account_id: 2 > domain_id: 1 >pool_id: 200 > last_pool_id: 201 >instance_id: NULL > device_id: NULL > name: sharedBU > uuid: 0074a14a-ee89-425a-a745-cef7bef6425b > size: 5368709120 > folder: datastore-14964 > path: 9389f319093c4ef9907e16538fe21779 > pod_id: 1 > data_center_id: 1 > iscsi_name: NULL >host_ip: NULL >volume_type: DATADISK > pool_type: NULL > disk_offering_id: 3 >template_id: NULL > iso_id: 0 > first_snapshot_backup_uuid: NULL >
[jira] [Updated] (CLOUDSTACK-2413) The dialog box Change Compute Offering for a instance, display the Description (instead of the Name) of compute offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-2413: - Fix Version/s: (was: 4.2.0) 4.2.1 > The dialog box Change Compute Offering for a instance, display the > Description (instead of the Name) of compute offering > > > Key: CLOUDSTACK-2413 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2413 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.1.0, 4.2.0 >Reporter: Milamber >Assignee: Milamber > Fix For: 4.1.0, 4.2.1 > > > The dialog box Change Compute Offering for a instance, display the > Description (instead of the Name) of compute offering. > I think would be better to display the Name. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4624) VM Migration fails in 'Security Group Enabled Advanced Zone' with CloudRuntimeException: callHostPlugin failed for cmd: network_rules
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797748#comment-13797748
]
Jayapal Reddy commented on CLOUDSTACK-4624:
---
Rules config failed for the VM in below logs.
Oct 17 08:41:36 hdkvm02c SM: [11509] VMOPS enter network_rules
Oct 17 08:41:36 hdkvm02c SM: [11509] ['ifconfig', 'tap13.0']
Oct 17 08:41:36 hdkvm02c SM: [11509] FAILED in util.pread: (rc 1) stdout: '',
stderr: 'tap13.0: error fetching interface information: Device not found
Oct 17 08:41:36 hdkvm02c SM: [11509] '
Oct 17 08:41:36 hdkvm02c SM: [11509] VMOPS enter check_rule_log_for_vm
Oct 17 08:41:36 hdkvm02c SM: [11509] Failed to find logfile
/var/run/cloud/i-2-60-VM.log
Oct 17 08:41:36 hdkvm02c SM: [11509] VMOPS exit check_rule_log_for_vm
Oct 17 08:41:36 hdkvm02c SM: [11509] Change detected in vmId or vmIp or domId,
resetting default rules
Oct 17 08:41:36 hdkvm02c SM: [11509] VMOPS enter default_network_rules
Oct 17 08:41:36 hdkvm02c SM: [11509] Failed to network rule !
Oct 17 08:41:36 hdkvm02c SM: [11509] VMOPS exit network_rules
> VM Migration fails in 'Security Group Enabled Advanced Zone' with
> CloudRuntimeException: callHostPlugin failed for cmd: network_rules
> -
>
> Key: CLOUDSTACK-4624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4624
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: XenServer
>Affects Versions: 4.2.0, Future
> Environment: CloudStack 4.2.0 with XenServer 6.1 or 6.2
>Reporter: Paul Angus
>Assignee: Jayapal Reddy
>Priority: Critical
> Fix For: 4.2.1
>
>
> VM Migration fails in a 'Security Group Enabled Advanced Zone' with
> CloudRuntimeException: callHostPlugin failed for cmd: network_rules
> 013-09-06 14:18:07,711 DEBUG [network.security.SecurityGroupManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Security
> Group Mgr v2: scheduling ruleset updates for 1 vms (unique=1), current queue
> size=0
> 2013-09-06 14:18:07,715 DEBUG [network.security.SecurityGroupManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Security
> Group Mgr v2: done scheduling ruleset updates for 1 vms: num new jobs=1 num
> rows insert or updated=1 time taken=4
> 2013-09-06 14:18:07,715 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) VM state
> transitted from :Migrating to Running with event: OperationSucceededvm's
> original host id: 7 new host id: 8 host id before state transition: 8
> 2013-09-06 14:18:07,721 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-244:null) Ping from 5
> 2013-09-06 14:18:07,728 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Hosts's
> actual total CPU: 63840 and CPU after applying overprovisioning: 127680
> 2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Hosts's
> actual total RAM: 267404820480 and RAM after applying overprovisioning:
> 267404820480
> 2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) release
> cpu from host: 7, old used: 1000,reserved: 0, actual total: 63840, total with
> overprovisioning: 127680; new used: 0,reserved:0; movedfromreserved:
> false,moveToReserveredfalse
> 2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) release
> mem from host: 7, old used: 1073741824,reserved: 0, total: 267404820480; new
> used: 0,reserved:0; movedfromreserved: false,moveToReserveredfalse
> 2013-09-06 14:18:07,731 DEBUG [cloud.api.ApiServlet] (catalina-exec-18:null)
> ===START=== 10.67.9.233 -- GET
> command=queryAsyncJobResult&jobId=16e9e8e3-460e-4a72-a455-d65b01f3b360&response=json&sessionkey=hLoqoRm93LQk67lSOtoBQZludFg%3D&_=1378473487668
> 2013-09-06 14:18:07,738 DEBUG [agent.transport.Request]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Seq
> 8-576979043: Sending { Cmd , MgmtId: 345052351047, via: 8, Ver: v1, Flags:
> 100011,
> [{"com.cloud.agent.api.CheckVirtualMachineCommand":{"vmName":"i-2-11-VM","wait":20}}]
> }
> 2013-09-06 14:18:07,738 DEBUG [agent.transport.Request]
> (Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Seq
> 8-576979043: Executing: { Cmd , MgmtId: 345052351047, via: 8, Ver: v1,
> Flags: 100011,
> [{"c
[jira] [Commented] (CLOUDSTACK-4747) [Automation] Test cases creating account with more 100 character; account creation failing due to this
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797744#comment-13797744 ] ASF subversion and git services commented on CLOUDSTACK-4747: - Commit 08e69f130f142b0b034b6f42715ae0d1ca390c12 in branch refs/heads/4.2 from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=08e69f1 ] CLOUDSTACK-4747: Rename testcase name to use lesser characters Renamed testcase name and also initialised _cleanup so that it does not break on non-NS Cloudstack setup. Signed-off-by: venkataswamybabu budumuru (cherry picked from commit c5e1c4725c3658cae967c63cbae0ffe598f227ef) > [Automation] Test cases creating account with more 100 character; account > creation failing due to this > > > Key: CLOUDSTACK-4747 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4747 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, marvin, Test >Affects Versions: 4.2.1 > Environment: Automation >Reporter: Rayees Namathponnan >Assignee: Girish Shilamkar >Priority: Blocker > Fix For: 4.2.1 > > > You cannot create account more than 100 characters; > We added test case's name in account; but should trim the account name > maximum to 99 characters to avoid these kind of failures > integration.component.test_netscaler_nw_off.TestNOWithNetscaler.test_02_network_off_with_conserve_mode_netscaler > Execute cmd: createaccount failed, due to: errorCode: 530, errorText:DB > Exception on: com.mysql.jdbc.PreparedStatement@4d345362: INSERT INTO account > (account.account_name, account.type, account.domain_id, account.state, > account.cleanup_needed, account.network_domain, account.uuid, > account.default_zone_id, account.default) VALUES > (_binary'test-test_netscaler_nw_off-TestNwOffSToDUpgrade-test_02_network_off_with_conserve_mode_netscaler-AZBFBO', > 2, 1, 'enabled', 0, null, _binary'0c361f17-c605-456f-ad0b-b1952bce575a', > null, 0) > Stacktrace > Traceback (most recent call last): > File "/usr/local/lib/python2.7/unittest/case.py", line 311, in run > self.setUp() > File > "/Repo_30X/ipcl/cloudstack/test/integration/component/test_netscaler_nw_off.py", > line 2428, in setUp > domainid=self.domain.id > File > "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py", line > 116, in create > account = apiclient.createAccount(cmd) > File > "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py", > line 495, in createAccount > response = self.connection.marvin_request(command, > response_type=response, method=method) > File > "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line > 222, in marvin_request > response = jsonHelper.getResultObj(response.json(), response_type) > File "/usr/local/lib/python2.7/site-packages/marvin/jsonHelper.py", line > 148, in getResultObj > raise cloudstackException.cloudstackAPIException(respname, errMsg) > cloudstackAPIException: Execute cmd: createaccount failed, due to: errorCode: > 530, errorText:DB Exception on: com.mysql.jdbc.PreparedStatement@4d345362: > INSERT INTO account (account.account_name, account.type, account.domain_id, > account.state, account.cleanup_needed, account.network_domain, account.uuid, > account.default_zone_id, account.default) VALUES > (_binary'test-test_netscaler_nw_off-TestNwOffSToDUpgrade-test_02_network_off_with_conserve_mode_netscaler-AZBFBO', > 2, 1, 'enabled', 0, null, _binary'0c361f17-c605-456f-ad0b-b1952bce575a', > null, 0) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4682) VMs are getting deployed with shared service offering and local compute offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797743#comment-13797743 ] ASF subversion and git services commented on CLOUDSTACK-4682: - Commit e58bef22c161a939b52b7748c17238476bac923b in branch refs/heads/master from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e58bef2 ] CLOUDSTACK-4682: VMs are getting deployed with shared service offering and local compute offering VM deployment is fine, issue is in attach volume where all possible scenarios are not handled. The following needs to be logic of attached volume: 1. if data volume scope is zone then allow attach (this is already there) 2. if data volume scope is cluster a. if root volume scope is host, allow if both are in same cluster (already there) b. if root volume scope is zone, allow if vm and data volume in same cluster (fixed as part of this commit) 3. if data volume scope is host allow if vm and data volume in same host (fixed as part of this commit) > VMs are getting deployed with shared service offering and local compute > offering > -- > > Key: CLOUDSTACK-4682 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4682 > 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, 4.2.1 > Environment: hyp:KVM >Reporter: prashant kumar mishra >Assignee: Koushik Das >Priority: Critical > Fix For: 4.2.1 > > Attachments: Logs_DB.rar > > > Steps to reproduce > --- > 1-prepare a CS setup with kvm host+zone wide primary storage > 2-mark Local storage enabled to true at zone level and restart MS > 3-create a local disk offering > 4-deploy a vm with shared service offering and local compute offering > expected > --- > vm deployment should fail because CS can't move volume between scope: HOST > and ZONE > Actual > -- > vm deployment went successful with root disk on shared and data disk on > local storage storage > My observation > -- > once i detach the data disk(created in step 4) ,was not able to attach data > disk to vm(deployed in step 4) > with error > --- > 2013-09-16 13:01:53,697 ERROR [cloud.async.AsyncJobManagerImpl] > (Job-Executor-9:job-35 = [ ad075b33-d308-4056-bc8a-f3a7d71ad60f ]) Unexpected > exception while executing > org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd > com.cloud.utils.exception.CloudRuntimeException: Can't move volume between > scope: HOST and ZONE > at > com.cloud.storage.VolumeManagerImpl.needMoveVolume(VolumeManagerImpl.java:1605) > at > com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1880) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:122) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) > at > com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) > 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.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) > 2013-09-16 13:01:53,702 DEBUG [cloud.async.AsyncJobManagerImpl] > (Job-Executor-9:job-35 = [ ad075b33-d308-4056-bc8a-f3a7d71ad60f ]) Complete > async job-35 = [ ad075b33-d308-4056-bc8a-f3a7d71ad60f ], jobStatus: 2, > resultCode: 530, result: Error Code: 530 Error text: Can't move volume > between scope: HOST and ZONE -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4747) [Automation] Test cases creating account with more 100 character; account creation failing due to this
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797741#comment-13797741 ] ASF subversion and git services commented on CLOUDSTACK-4747: - Commit c5e1c4725c3658cae967c63cbae0ffe598f227ef in branch refs/heads/master from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c5e1c47 ] CLOUDSTACK-4747: Rename testcase name to use lesser characters Renamed testcase name and also initialised _cleanup so that it does not break on non-NS Cloudstack setup. Signed-off-by: venkataswamybabu budumuru > [Automation] Test cases creating account with more 100 character; account > creation failing due to this > > > Key: CLOUDSTACK-4747 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4747 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, marvin, Test >Affects Versions: 4.2.1 > Environment: Automation >Reporter: Rayees Namathponnan >Assignee: Girish Shilamkar >Priority: Blocker > Fix For: 4.2.1 > > > You cannot create account more than 100 characters; > We added test case's name in account; but should trim the account name > maximum to 99 characters to avoid these kind of failures > integration.component.test_netscaler_nw_off.TestNOWithNetscaler.test_02_network_off_with_conserve_mode_netscaler > Execute cmd: createaccount failed, due to: errorCode: 530, errorText:DB > Exception on: com.mysql.jdbc.PreparedStatement@4d345362: INSERT INTO account > (account.account_name, account.type, account.domain_id, account.state, > account.cleanup_needed, account.network_domain, account.uuid, > account.default_zone_id, account.default) VALUES > (_binary'test-test_netscaler_nw_off-TestNwOffSToDUpgrade-test_02_network_off_with_conserve_mode_netscaler-AZBFBO', > 2, 1, 'enabled', 0, null, _binary'0c361f17-c605-456f-ad0b-b1952bce575a', > null, 0) > Stacktrace > Traceback (most recent call last): > File "/usr/local/lib/python2.7/unittest/case.py", line 311, in run > self.setUp() > File > "/Repo_30X/ipcl/cloudstack/test/integration/component/test_netscaler_nw_off.py", > line 2428, in setUp > domainid=self.domain.id > File > "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py", line > 116, in create > account = apiclient.createAccount(cmd) > File > "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py", > line 495, in createAccount > response = self.connection.marvin_request(command, > response_type=response, method=method) > File > "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line > 222, in marvin_request > response = jsonHelper.getResultObj(response.json(), response_type) > File "/usr/local/lib/python2.7/site-packages/marvin/jsonHelper.py", line > 148, in getResultObj > raise cloudstackException.cloudstackAPIException(respname, errMsg) > cloudstackAPIException: Execute cmd: createaccount failed, due to: errorCode: > 530, errorText:DB Exception on: com.mysql.jdbc.PreparedStatement@4d345362: > INSERT INTO account (account.account_name, account.type, account.domain_id, > account.state, account.cleanup_needed, account.network_domain, account.uuid, > account.default_zone_id, account.default) VALUES > (_binary'test-test_netscaler_nw_off-TestNwOffSToDUpgrade-test_02_network_off_with_conserve_mode_netscaler-AZBFBO', > 2, 1, 'enabled', 0, null, _binary'0c361f17-c605-456f-ad0b-b1952bce575a', > null, 0) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4834) [Automation] Failed to create volume; failed with error "Invalid parameter diskofferingid value"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797736#comment-13797736 ] Gaurav Aradhye commented on CLOUDSTACK-4834: Could not reproduce. I also tried adding volume from UI. Operation succeeded. Log: test_01_create_volume (test_volumes.TestCreateVolume) Test Volume creation for all Disk Offerings (incl. custom) ... ok test_02_attach_volume (test_volumes.TestVolumes) Attach a created Volume to a Running VM ... ok test_03_download_attached_volume (test_volumes.TestVolumes) Download a Volume attached to a VM ... ok test_04_delete_attached_volume (test_volumes.TestVolumes) Delete a Volume attached to a VM ... ok test_05_detach_volume (test_volumes.TestVolumes) Detach a Volume attached to a VM ... ok test_06_download_detached_volume (test_volumes.TestVolumes) Download a Volume unattached to an VM ... ok test_07_resize_fail (test_volumes.TestVolumes) Test resize (negative) non-existent volume ... ok test_08_resize_volume (test_volumes.TestVolumes) Test resize a volume ... ok test_09_delete_detached_volume (test_volumes.TestVolumes) Delete a Volume unattached to an VM ... ok -- Ran 9 tests in 1196.089s OK > [Automation] Failed to create volume; failed with error "Invalid parameter > diskofferingid value" > > > Key: CLOUDSTACK-4834 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4834 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes >Affects Versions: 4.3.0 > Environment: KVM > Branch Master >Reporter: Rayees Namathponnan >Assignee: Gaurav Aradhye >Priority: Blocker > Fix For: 4.3.0 > > Attachments: CLOUDSTACK-4834.rar > > > Volume test cases from BVT suite failed, test cases failed while adding new > volume; > i tried to new volume from UI, its failed with error > Unable to execute API command createvolume due to invalid value. Invalid > parameter diskofferingid value=7c5f301b-69b3-43f4-a5b8-8acb356c5e3f due to > incorrect long value format, or entity does not exist or due to incorrect > parameter annotation for the field in api cmd class > Test case creating with API, observed below error in log > Execute cmd: createvolume failed, due to: errorCode: 431, errorText:volume > size 1073741824, but the maximum size allowed is 0 Gb > Log from MS log > > 2013-10-07 12:34:58,564 DEBUG [c.c.a.ApiServlet] > (catalina-exec-5:ctx-6b44eb58) ===START=== 10.223.240.194 -- GET > account=test-resource_details-TestResourceDetail-IMWBHV&domainid=34f66d20-2f83-11e3-a447-1a6f7bb0d0a8&name=ndm&zoneid=79 > ed0a9e-469c-460d-b674-0a2944e5d557&apiKey=ylSEBq6mjjv1nOqm2lsFI-uBAbDbeUuX2mOIUslHLFH62Vmgl2E5scxr5lUaJ8lkZ4qJ24Mg7mY6tMgsDv6CTw&command=createVolume&signature=8ySmF7tiGjJaxpZwKs5iPXLo%2FtU%3D&diskofferingid=aeeb298c-4d10-4bab-ba13-ad67 > f2dc026c&response=json > 2013-10-07 12:34:58,629 INFO [c.c.a.ApiServer] (catalina-exec-5:ctx-6b44eb58 > ctx-3e806b15 ctx-60ef7e57) volume size 1073741824, but the maximum size > allowed is 0 Gb. > 2013-10-07 12:34:58,637 DEBUG [c.c.a.ApiServlet] > (catalina-exec-5:ctx-6b44eb58 ctx-3e806b15 ctx-60ef7e57) ===END=== > 10.223.240.194 -- GET > account=test-resource_details-TestResourceDetail-IMWBHV&domainid=34f66d20-2f83-11e3-a447-1a6f7bb0d0a8&name=ndm&zoneid=79ed0a9e-469c-460d-b674-0a2944e5d557&apiKey=ylSEBq6mjjv1nOqm2lsFI-uBAbDbeUuX2mOIUslHLFH62Vmgl2E5scxr5lUaJ8lkZ4qJ24Mg7mY6tMgsDv6CTw&command=createVolume&signature=8ySmF7tiGjJaxpZwKs5iPXLo%2FtU%3D&diskofferingid=aeeb298c-4d10-4bab-ba13-ad67f2dc026c&response=json > Attached MS log with defect -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4835) [Automation] [BVT] Update global configuration test cases failed in master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye reassigned CLOUDSTACK-4835: -- Assignee: Gaurav Aradhye > [Automation] [BVT] Update global configuration test cases failed in master > -- > > Key: CLOUDSTACK-4835 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4835 > 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: KVM > Branch - master >Reporter: Rayees Namathponnan >Assignee: Gaurav Aradhye >Priority: Blocker > Fix For: 4.3.0 > > > Below BVT test cases failed, > integration.smoke.test_global_settings.TestUpdateConfigWithScope.test_UpdateConfigParamWithScope > Unable to find the global property "use.external.dns" in master, is it > removed ? > you can see the result at > http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/lastCompletedBuild/suite=test_global_settings/#showFailuresLink > Error Message > Execute cmd: updateconfiguration failed, due to: errorCode: 431, > errorText:Config parameter with name use.external.dns doesn't exist > Stacktrace > Traceback (most recent call last): > File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run > testMethod() > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/test/integration/smoke/test_global_settings.py", > line 47, in test_UpdateConfigParamWithScope > updateConfigurationResponse = > self.apiClient.updateConfiguration(updateConfigurationCmd) > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py", > line 1188, in updateConfiguration > response = self.connection.marvin_request(command, > response_type=response, method=method) > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/cloudstackConnection.py", > line 222, in marvin_request > response = jsonHelper.getResultObj(response.json(), response_type) > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/jsonHelper.py", > line 148, in getResultObj > raise cloudstackException.cloudstackAPIException(respname, errMsg) > cloudstackAPIException: Execute cmd: updateconfiguration failed, due to: > errorCode: 431, errorText:Config parameter with name use.external.dns doesn't > exist -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4834) [Automation] Failed to create volume; failed with error "Invalid parameter diskofferingid value"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye reassigned CLOUDSTACK-4834: -- Assignee: Gaurav Aradhye > [Automation] Failed to create volume; failed with error "Invalid parameter > diskofferingid value" > > > Key: CLOUDSTACK-4834 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4834 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes >Affects Versions: 4.3.0 > Environment: KVM > Branch Master >Reporter: Rayees Namathponnan >Assignee: Gaurav Aradhye >Priority: Blocker > Fix For: 4.3.0 > > Attachments: CLOUDSTACK-4834.rar > > > Volume test cases from BVT suite failed, test cases failed while adding new > volume; > i tried to new volume from UI, its failed with error > Unable to execute API command createvolume due to invalid value. Invalid > parameter diskofferingid value=7c5f301b-69b3-43f4-a5b8-8acb356c5e3f due to > incorrect long value format, or entity does not exist or due to incorrect > parameter annotation for the field in api cmd class > Test case creating with API, observed below error in log > Execute cmd: createvolume failed, due to: errorCode: 431, errorText:volume > size 1073741824, but the maximum size allowed is 0 Gb > Log from MS log > > 2013-10-07 12:34:58,564 DEBUG [c.c.a.ApiServlet] > (catalina-exec-5:ctx-6b44eb58) ===START=== 10.223.240.194 -- GET > account=test-resource_details-TestResourceDetail-IMWBHV&domainid=34f66d20-2f83-11e3-a447-1a6f7bb0d0a8&name=ndm&zoneid=79 > ed0a9e-469c-460d-b674-0a2944e5d557&apiKey=ylSEBq6mjjv1nOqm2lsFI-uBAbDbeUuX2mOIUslHLFH62Vmgl2E5scxr5lUaJ8lkZ4qJ24Mg7mY6tMgsDv6CTw&command=createVolume&signature=8ySmF7tiGjJaxpZwKs5iPXLo%2FtU%3D&diskofferingid=aeeb298c-4d10-4bab-ba13-ad67 > f2dc026c&response=json > 2013-10-07 12:34:58,629 INFO [c.c.a.ApiServer] (catalina-exec-5:ctx-6b44eb58 > ctx-3e806b15 ctx-60ef7e57) volume size 1073741824, but the maximum size > allowed is 0 Gb. > 2013-10-07 12:34:58,637 DEBUG [c.c.a.ApiServlet] > (catalina-exec-5:ctx-6b44eb58 ctx-3e806b15 ctx-60ef7e57) ===END=== > 10.223.240.194 -- GET > account=test-resource_details-TestResourceDetail-IMWBHV&domainid=34f66d20-2f83-11e3-a447-1a6f7bb0d0a8&name=ndm&zoneid=79ed0a9e-469c-460d-b674-0a2944e5d557&apiKey=ylSEBq6mjjv1nOqm2lsFI-uBAbDbeUuX2mOIUslHLFH62Vmgl2E5scxr5lUaJ8lkZ4qJ24Mg7mY6tMgsDv6CTw&command=createVolume&signature=8ySmF7tiGjJaxpZwKs5iPXLo%2FtU%3D&diskofferingid=aeeb298c-4d10-4bab-ba13-ad67f2dc026c&response=json > Attached MS log with defect -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4835) [Automation] [BVT] Update global configuration test cases failed in master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797717#comment-13797717 ] Gaurav Aradhye commented on CLOUDSTACK-4835: Could not reproduce. Log: ==> client.log <== 2013-10-16 21:56:36,048 - DEBUG - test_UpdateConfigParamWithScope (test_global_settings.TestUpdateConfigWithScope) - updated the parameter use.external.dns with value true ==> result.log <== test_UpdateConfigParamWithScope (test_global_settings.TestUpdateConfigWithScope) ... ok -- Ran 1 test in 2.720s OK > [Automation] [BVT] Update global configuration test cases failed in master > -- > > Key: CLOUDSTACK-4835 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4835 > 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: KVM > Branch - master >Reporter: Rayees Namathponnan >Assignee: Gaurav Aradhye >Priority: Blocker > Fix For: 4.3.0 > > > Below BVT test cases failed, > integration.smoke.test_global_settings.TestUpdateConfigWithScope.test_UpdateConfigParamWithScope > Unable to find the global property "use.external.dns" in master, is it > removed ? > you can see the result at > http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/lastCompletedBuild/suite=test_global_settings/#showFailuresLink > Error Message > Execute cmd: updateconfiguration failed, due to: errorCode: 431, > errorText:Config parameter with name use.external.dns doesn't exist > Stacktrace > Traceback (most recent call last): > File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run > testMethod() > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/test/integration/smoke/test_global_settings.py", > line 47, in test_UpdateConfigParamWithScope > updateConfigurationResponse = > self.apiClient.updateConfiguration(updateConfigurationCmd) > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py", > line 1188, in updateConfiguration > response = self.connection.marvin_request(command, > response_type=response, method=method) > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/cloudstackConnection.py", > line 222, in marvin_request > response = jsonHelper.getResultObj(response.json(), response_type) > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/jsonHelper.py", > line 148, in getResultObj > raise cloudstackException.cloudstackAPIException(respname, errMsg) > cloudstackAPIException: Execute cmd: updateconfiguration failed, due to: > errorCode: 431, errorText:Config parameter with name use.external.dns doesn't > exist -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4833) [Automation][BVT] Template and ISO test cases failing from BVT suite, during LIST api call
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797707#comment-13797707 ] Gaurav Aradhye commented on CLOUDSTACK-4833: Ran ISO and templates test cases, could not reproduce these issues. Test ran ok. Template delete test case log: ==> result.log <== test_01_create_template (test_templates_fixed.TestCreateTemplate) Test create public & private template ... ==> client.log <== 2013-10-16 20:24:06,878 - DEBUG - test_03_delete_template (test_templates_fixed.TestTemplates) - Deleting Template ID: d3d6d6ab-24e8-40fe-8b8c-e82dd1337ffa ==> result.log <== skipped 'Skip' test_02_edit_template (test_templates_fixed.TestTemplates) Test Edit template ... skipped 'Skip' test_03_delete_template (test_templates_fixed.TestTemplates) Test delete template ... ok test_04_extract_template (test_templates_fixed.TestTemplates) Test for extract template ... skipped 'Skip' test_05_template_permissions (test_templates_fixed.TestTemplates) Update & Test for template permissions ... skipped 'Skip' test_06_copy_template (test_templates_fixed.TestTemplates) Test for copy template from one zone to another ... skipped 'Skip' test_07_list_public_templates (test_templates_fixed.TestTemplates) Test only public templates are visible to normal user ... skipped 'Skip' test_08_list_system_templates (test_templates_fixed.TestTemplates) Test System templates are not visible to normal user ... skipped 'Skip' -- Ran 8 tests in 495.756s OK (skipped=7) ISO log: test_01_create_iso (test_iso.TestCreateIso) Test create public & private ISO ... ok test_02_edit_iso (test_iso.TestISO) Test Edit ISO ... ok test_03_delete_iso (test_iso.TestISO) Test delete ISO ... ok test_04_extract_Iso (test_iso.TestISO) Test for extract ISO ... ok test_05_iso_permissions (test_iso.TestISO) Update & Test for ISO permissions ... ok test_06_copy_iso (test_iso.TestISO) Test for copy ISO from one zone to another ... ok -- Ran 6 tests in 341.819s OK > [Automation][BVT] Template and ISO test cases failing from BVT suite, during > LIST api call > --- > > Key: CLOUDSTACK-4833 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4833 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.3.0 > Environment: KVM automation on master >Reporter: Rayees Namathponnan >Assignee: Gaurav Aradhye >Priority: Blocker > Fix For: 4.3.0 > > > ISO and Template test cases from master BVT suite > i) test_iso.py > 2) integration.smoke.test_templates.TestTemplates.test_03_delete_template > Both the test cases are failed during list API call, you can see the result > at > http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/suite=test_templates/lastCompletedBuild/testReport/integration.smoke.test_templates/TestTemplates/test_03_delete_template/ > Error Message > Execute cmd: listtemplates failed, due to: errorCode: 431, errorText:Unable > to execute API command listtemplates due to invalid value. Invalid parameter > id value=f3abe3e3-2712-476d-9d71-05207597e4f4 due to incorrect long value > format, or entity does not exist or due to incorrect parameter annotation for > the field in api cmd class. > >> begin captured logging << > test_03_delete_template (integration.smoke.test_templates.TestTemplates): > DEBUG: Deleting Template ID: f3abe3e3-2712-476d-9d71-05207597e4f4 > - >> end captured logging << - > Stacktrace > File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run > testMethod() > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/test/integration/smoke/test_templates.py", > line 543, in test_03_delete_template > domainid=self.account.domainid > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/integration/lib/common.py", > line 534, in list_templates > return(apiclient.listTemplates(cmd)) > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py", > line 713, in listTemplates > response = self.connection.marvin_request(command, > response_type=response, method=method) > File > "/var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/cloudstackConnection.py", > line 222, in marvin_request > response
[jira] [Commented] (CLOUDSTACK-4624) VM Migration fails in 'Security Group Enabled Advanced Zone' with CloudRuntimeException: callHostPlugin failed for cmd: network_rules
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797695#comment-13797695
]
Paul Angus commented on CLOUDSTACK-4624:
Hi Jayapal
/var/log/SMLog below...
Oct 17 08:41:02 hdkvm02c SM: [9226] lock: acquired
/var/lock/sm/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/sr
Oct 17 08:41:02 hdkvm02c SM: [9226] sr_scan {'sr_uuid':
'5609c1c0-03e4-8b58-1bf1-533f1ade34a1', 'subtask_of':
'DummyRef:|84d09d98-57d4-2c63-b97c-cf1da9c5f87a|SR.scan', 'args': [],
'host_ref': 'OpaqueRef:99e28465-5100-6b59-e9d7-ea48b5cdde49', 'session_ref':
'OpaqueRef:75f0e554-b926-847e-5730-ccd7591c08b1', 'device_config': {'device':
'/dev/md0', 'SRmaster': 'true'}, 'command': 'sr_scan', 'sr_ref':
'OpaqueRef:3155b7a0-1a0a-6dea-42d3-db95d84dbd82'}
Oct 17 08:41:02 hdkvm02c SM: [9226] ['/usr/bin/vhd-util', 'scan', '-f', '-c',
'-m', '/var/run/sr-mount/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/*.vhd']
Oct 17 08:41:02 hdkvm02c SM: [9226] pread SUCCESS
Oct 17 08:41:02 hdkvm02c SM: [9226] ['ls',
'/var/run/sr-mount/5609c1c0-03e4-8b58-1bf1-533f1ade34a1', '-1', '--color=never']
Oct 17 08:41:02 hdkvm02c SM: [9226] pread SUCCESS
Oct 17 08:41:02 hdkvm02c SM: [9226] lock: tried lock
/var/lock/sm/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/running, acquired: True
(exists: True)
Oct 17 08:41:02 hdkvm02c SM: [9226] lock: released
/var/lock/sm/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/running
Oct 17 08:41:02 hdkvm02c SM: [9226] Kicking GC
Oct 17 08:41:02 hdkvm02c SMGC: [9226] === SR
5609c1c0-03e4-8b58-1bf1-533f1ade34a1: gc ===
Oct 17 08:41:02 hdkvm02c SMGC: [9230] Will finish as PID [9231]
Oct 17 08:41:02 hdkvm02c SMGC: [9226] New PID [9230]
Oct 17 08:41:02 hdkvm02c SM: [9226] lock: closed
/var/lock/sm/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/running
Oct 17 08:41:02 hdkvm02c SM: [9226] lock: released
/var/lock/sm/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/sr
Oct 17 08:41:02 hdkvm02c SM: [9226] lock: closed
/var/lock/sm/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/sr
Oct 17 08:41:03 hdkvm02c SMGC: [9231] Found 0 cache files
Oct 17 08:41:03 hdkvm02c SM: [9231] lock: tried lock
/var/lock/sm/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/sr, acquired: True (exists:
True)
Oct 17 08:41:03 hdkvm02c SM: [9231] ['/usr/bin/vhd-util', 'scan', '-f', '-c',
'-m', '/var/run/sr-mount/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/*.vhd']
Oct 17 08:41:03 hdkvm02c SM: [9231] pread SUCCESS
Oct 17 08:41:03 hdkvm02c SMGC: [9231] SR 5609
('5609c1c0-03e4-8b58-1bf1-533f1ade34a1') (0 VDIs in 0 VHD trees): no changes
Oct 17 08:41:03 hdkvm02c SM: [9231] lock: released
/var/lock/sm/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/sr
Oct 17 08:41:03 hdkvm02c SMGC: [9231] No work, exiting
Oct 17 08:41:03 hdkvm02c SMGC: [9231] In cleanup
Oct 17 08:41:03 hdkvm02c SMGC: [9231] SR 5609
('5609c1c0-03e4-8b58-1bf1-533f1ade34a1') (0 VDIs in 0 VHD trees): no changes
Oct 17 08:41:08 hdkvm02c SM: [9365] VMOPS enter gethostvmstats
Oct 17 08:41:08 hdkvm02c SM: [9365] VMOPS exit gethostvmstats
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS enter get_rule_logs_for_vms
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS enter
network_rules_for_rebooted_vm
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS enter check_domid_changed
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS exit check_domid_changed
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS exit
network_rules_for_rebooted_vm
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS enter
network_rules_for_rebooted_vm
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS enter check_domid_changed
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS exit check_domid_changed
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS exit
network_rules_for_rebooted_vm
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS exit get_rule_logs_for_vms
Oct 17 08:41:29 hdkvm02c SM: [11083] lock: acquired
/var/lock/sm/081b1189-0b81-d55c-b230-b914ce8a9030/sr
Oct 17 08:41:29 hdkvm02c SM: [11083] ['/usr/sbin/td-util', 'query', 'vhd',
'-vpf',
'/var/run/sr-mount/081b1189-0b81-d55c-b230-b914ce8a9030/f5e5ffae-0c95-4db8-a3d1-c17c8879f839.vhd']
Oct 17 08:41:29 hdkvm02c SM: [11083] pread SUCCESS
Oct 17 08:41:29 hdkvm02c SM: [11083] vdi_attach {'sr_uuid':
'081b1189-0b81-d55c-b230-b914ce8a9030', 'subtask_of':
'DummyRef:|684284be-93d1-5813-083b-98d6632b3a54|VDI.attach', 'vdi_ref':
'OpaqueRef:524343bd-1a86-ac9a-b9e9-9bba88bb66a3', 'vdi_on_boot': 'persist',
'args': ['true'], 'vdi_location': 'f5e5ffae-0c95-4db8-a3d1-c17c8879f839',
'host_ref': 'OpaqueRef:99e28465-5100-6b59-e9d7-ea48b5cdde49', 'session_ref':
'OpaqueRef:c5a97db8-6732-5bcd-4bad-6cf083d8a6be', 'device_config': {'SRmaster':
'false', 'serverpath': '/vol/test_p2_c1_pri2/RootQtree', 'server':
'10.28.231.2'}, 'command': 'vdi_attach', 'vdi_allow_caching': 'false',
'sr_ref': 'OpaqueRef:e0b08b24-46c2-f945-36b3-f9feadb3aa93', 'vdi_uuid':
'f5e5ffae-0c95-4db8-a3d1-c17c8879f839'}
Oct
