[jira] [Created] (CLOUDSTACK-7969) SC: Win8.1: Key translation fails for some EN-US keyboard keys
Sanjay Tripathi created CLOUDSTACK-7969:
---
Summary: SC: Win8.1: Key translation fails for some EN-US
keyboard keys
Key: CLOUDSTACK-7969
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7969
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Environment:
Host KVM
Guest OS : SC win8.1
Reporter: Sanjay Tripathi
Assignee: Sanjay Tripathi
Repro Steps:
1. Setup CloudStack.
2. Bring Up SC- Windows 8.1 Guest VM on the Goleta
3. choose EN-US keyboard while bringing up the VM
4. Test the keys on the VM.
Browsers : Chrome, IE, Firefox
Below is the Expected result along with the actual results ( Red Colored are
incorrectly mapped inputs)
h6.Expected Result
1234567890-=
qwertyuiop[]
asdfghjkl;'
zxcvbnm,./
Shift Keys
!@#{color:red}${color}%{color:red}^{color}*(){color:red}_{color}+
QWERTYUIOP{}
ASDFGHJKL:
ZXCVBNM?
h6.Actual Result
1234567890-=
qwertyuiop[]
asdfghjkl;'
zxcvbnm,./
Shift Keys
!@#{color:red}¥{color}%{color:red}.{color}*(){color:red}__{color}+
QWERTYUIOP{}
ASDFGHJKL:
ZXCVBNM?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7969) SC: Win8.1: Key translation fails for some EN-US keyboard keys
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjay Tripathi updated CLOUDSTACK-7969:
Component/s: UI
KVM
SC: Win8.1: Key translation fails for some EN-US keyboard keys
Key: CLOUDSTACK-7969
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7969
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, UI
Environment: Host KVM
Guest OS : SC win8.1
Reporter: Sanjay Tripathi
Assignee: Sanjay Tripathi
Repro Steps:
1. Setup CloudStack.
2. Bring Up SC- Windows 8.1 Guest VM on the Goleta
3. choose EN-US keyboard while bringing up the VM
4. Test the keys on the VM.
Browsers : Chrome, IE, Firefox
Below is the Expected result along with the actual results ( Red Colored are
incorrectly mapped inputs)
h6.Expected Result
1234567890-=
qwertyuiop[]
asdfghjkl;'
zxcvbnm,./
Shift Keys
!@#{color:red}${color}%{color:red}^{color}*(){color:red}_{color}+
QWERTYUIOP{}
ASDFGHJKL:
ZXCVBNM?
h6.Actual Result
1234567890-=
qwertyuiop[]
asdfghjkl;'
zxcvbnm,./
Shift Keys
!@#{color:red}¥{color}%{color:red}.{color}*(){color:red}__{color}+
QWERTYUIOP{}
ASDFGHJKL:
ZXCVBNM?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7969) SC: Win8.1: Key translation fails for some EN-US keyboard keys
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225887#comment-14225887
]
ASF subversion and git services commented on CLOUDSTACK-7969:
-
Commit a45ddb514c13b0b72d47468fb2254e69520d37f6 in cloudstack's branch
refs/heads/master from [~sanjay.tripathi]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a45ddb5 ]
CLOUDSTACK-7969: SC: Win8.1: Key translation fails for some EN-US keyboard
keys.
SC: Win8.1: Key translation fails for some EN-US keyboard keys
Key: CLOUDSTACK-7969
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7969
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, UI
Environment: Host KVM
Guest OS : SC win8.1
Reporter: Sanjay Tripathi
Assignee: Sanjay Tripathi
Repro Steps:
1. Setup CloudStack.
2. Bring Up SC- Windows 8.1 Guest VM on the Goleta
3. choose EN-US keyboard while bringing up the VM
4. Test the keys on the VM.
Browsers : Chrome, IE, Firefox
Below is the Expected result along with the actual results ( Red Colored are
incorrectly mapped inputs)
h6.Expected Result
1234567890-=
qwertyuiop[]
asdfghjkl;'
zxcvbnm,./
Shift Keys
!@#{color:red}${color}%{color:red}^{color}*(){color:red}_{color}+
QWERTYUIOP{}
ASDFGHJKL:
ZXCVBNM?
h6.Actual Result
1234567890-=
qwertyuiop[]
asdfghjkl;'
zxcvbnm,./
Shift Keys
!@#{color:red}¥{color}%{color:red}.{color}*(){color:red}__{color}+
QWERTYUIOP{}
ASDFGHJKL:
ZXCVBNM?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7969) SC: Win8.1: Key translation fails for some EN-US keyboard keys
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjay Tripathi updated CLOUDSTACK-7969:
Fix Version/s: 4.6.0
SC: Win8.1: Key translation fails for some EN-US keyboard keys
Key: CLOUDSTACK-7969
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7969
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, UI
Affects Versions: 4.5.0
Environment: Host KVM
Guest OS : SC win8.1
Reporter: Sanjay Tripathi
Assignee: Sanjay Tripathi
Fix For: 4.6.0
Repro Steps:
1. Setup CloudStack.
2. Bring Up SC- Windows 8.1 Guest VM on the Goleta
3. choose EN-US keyboard while bringing up the VM
4. Test the keys on the VM.
Browsers : Chrome, IE, Firefox
Below is the Expected result along with the actual results ( Red Colored are
incorrectly mapped inputs)
h6.Expected Result
1234567890-=
qwertyuiop[]
asdfghjkl;'
zxcvbnm,./
Shift Keys
!@#{color:red}${color}%{color:red}^{color}*(){color:red}_{color}+
QWERTYUIOP{}
ASDFGHJKL:
ZXCVBNM?
h6.Actual Result
1234567890-=
qwertyuiop[]
asdfghjkl;'
zxcvbnm,./
Shift Keys
!@#{color:red}¥{color}%{color:red}.{color}*(){color:red}__{color}+
QWERTYUIOP{}
ASDFGHJKL:
ZXCVBNM?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7969) SC: Win8.1: Key translation fails for some EN-US keyboard keys
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjay Tripathi resolved CLOUDSTACK-7969.
-
Resolution: Fixed
SC: Win8.1: Key translation fails for some EN-US keyboard keys
Key: CLOUDSTACK-7969
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7969
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, UI
Affects Versions: 4.5.0
Environment: Host KVM
Guest OS : SC win8.1
Reporter: Sanjay Tripathi
Assignee: Sanjay Tripathi
Fix For: 4.6.0
Repro Steps:
1. Setup CloudStack.
2. Bring Up SC- Windows 8.1 Guest VM on the Goleta
3. choose EN-US keyboard while bringing up the VM
4. Test the keys on the VM.
Browsers : Chrome, IE, Firefox
Below is the Expected result along with the actual results ( Red Colored are
incorrectly mapped inputs)
h6.Expected Result
1234567890-=
qwertyuiop[]
asdfghjkl;'
zxcvbnm,./
Shift Keys
!@#{color:red}${color}%{color:red}^{color}*(){color:red}_{color}+
QWERTYUIOP{}
ASDFGHJKL:
ZXCVBNM?
h6.Actual Result
1234567890-=
qwertyuiop[]
asdfghjkl;'
zxcvbnm,./
Shift Keys
!@#{color:red}¥{color}%{color:red}.{color}*(){color:red}__{color}+
QWERTYUIOP{}
ASDFGHJKL:
ZXCVBNM?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7963) test_dedicate_guest_vlan_ranges.TestDeleteVlanRange.test_05_release_range_vlan_in_use failing because network does not get vlan id
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashutosk Kelkar resolved CLOUDSTACK-7963. - Resolution: Fixed test_dedicate_guest_vlan_ranges.TestDeleteVlanRange.test_05_release_range_vlan_in_use failing because network does not get vlan id -- Key: CLOUDSTACK-7963 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7963 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.5.0 Here is the exception: int() argument must be a string or a number, not 'NoneType' It fails while checking if the vlan id of the network is from the dedicated range The network does not get vlan id in the first place because it is not in implemented state. Solution: Either deploy a VM in the network or implement the network with persistent network offering -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7963) test_dedicate_guest_vlan_ranges.TestDeleteVlanRange.test_05_release_range_vlan_in_use failing because network does not get vlan id
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashutosk Kelkar updated CLOUDSTACK-7963: Issue Type: Test (was: Bug) test_dedicate_guest_vlan_ranges.TestDeleteVlanRange.test_05_release_range_vlan_in_use failing because network does not get vlan id -- Key: CLOUDSTACK-7963 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7963 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.5.0 Here is the exception: int() argument must be a string or a number, not 'NoneType' It fails while checking if the vlan id of the network is from the dedicated range The network does not get vlan id in the first place because it is not in implemented state. Solution: Either deploy a VM in the network or implement the network with persistent network offering -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7949) test_base_image_updation.TestBaseImageUpdate.test_04_reoccuring_snapshot_rules fails while rebooting VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashutosk Kelkar resolved CLOUDSTACK-7949.
-
Resolution: Fixed
test_base_image_updation.TestBaseImageUpdate.test_04_reoccuring_snapshot_rules
fails while rebooting VM
---
Key: CLOUDSTACK-7949
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7949
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Ashutosk Kelkar
Assignee: Ashutosk Kelkar
Labels: automation
Fix For: 4.5.0
The test case fails with below error:
Failed to reboot the virtual machine. Error: Job failed: {jobprocstatus : 0,
created : u'2014-11-19T16:58:28+', jobresult : {errorcode : 431,
errortext : uCannot restore the vm as the template
be9df80c-a064-4056-a30e-01746a448513 isn't available in the zone}, cmd :
u'org.apache.cloudstack.api.command.admin.vm.RebootVMCmdByAdmin', userid :
u'8c733998-6fe7-11e4-adbc-aa7a894c001b', jobstatus : 2, jobid :
u'8cc1d543-ad32-4fcf-b85d-7a234edcd089', jobresultcode : 530, jobinstanceid :
u'21ad3213-7383-433a-9bd2-d998c383b920', jobresulttype : u'object',
jobinstancetype : u'VirtualMachine', accountid :
u'8c732caa-6fe7-11e4-adbc-aa7a894c001b'}
Reboot Vm fails because the template used by the VM is deleted in earlier
test case. Instead the template should be cleaned up after execution of all
the test cases
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7934) Cleanup issues in test_escalations_volumes.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashutosk Kelkar resolved CLOUDSTACK-7934. - Resolution: Fixed Cleanup issues in test_escalations_volumes.py - Key: CLOUDSTACK-7934 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7934 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.5.0 Following test cases are failing during the cleanup operation. test_05_volume_snapshot test_10_volume_snapshots_pagination test_13_volume_custom_disk_size -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7942) test_templates.TestTemplates.test_04_template_from_snapshot failing with account permission issue
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashutosk Kelkar resolved CLOUDSTACK-7942. - Resolution: Fixed test_templates.TestTemplates.test_04_template_from_snapshot failing with account permission issue - Key: CLOUDSTACK-7942 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7942 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.5.0 Execute cmd: deployvirtualmachine failed, due to: errorCode: 531, errorText:Acct[e5335eee-442a-4f5d-a00f-fc501b172073-test-TestTemplates-test_01_create_template-6FKH7G] does not have permission to operate with resource Acct[f95f972e-6e19-11e4-a8a4-f661c2db1170-admin] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7953) test_snapshot_limits.TestSnapshotLimit.test_04_snapshot_limit failed with Check list response returns a valid list
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashutosk Kelkar resolved CLOUDSTACK-7953. - Resolution: Fixed test_snapshot_limits.TestSnapshotLimit.test_04_snapshot_limit failed with Check list response returns a valid list Key: CLOUDSTACK-7953 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7953 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.5.0 The test case failed because of faulty wait period for checking snapshots created by snapshot policy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7970) Shared Storage
Ingo Jochim created CLOUDSTACK-7970: --- Summary: Shared Storage Key: CLOUDSTACK-7970 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7970 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller, Volumes Affects Versions: Future Reporter: Ingo Jochim I'm looking for a way to create shared storage (NFS,CIFS) for several virtual machines. It should be possible to create new volumes on the storage through CS and have this exported to several virtual machines. Right now I'm using a workaround. I create an additional virtual machines as an NFS server and export the storage (block device) to a couple of machines. This way is not CS controlled and all traffic goes through this additional virtual machine. Also additional resources get consumed by an additional machine. There is also no HA for this VM. Thx. Ingo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7912) Move hard coded test data for Netscaler device out of the test cases. Read it from config file.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye resolved CLOUDSTACK-7912. Resolution: Fixed Move hard coded test data for Netscaler device out of the test cases. Read it from config file. --- Key: CLOUDSTACK-7912 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7912 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 Many test cases have Netscaler info hard coded in the test case. Move this data out of the test cases and read it from the config file. Make this change across all the files applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7933) test_escalations_instances.py - test_13_vm_nics - Skip remove_nic step for vmware if vmware-tools are not installed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye resolved CLOUDSTACK-7933. Resolution: Fixed test_escalations_instances.py - test_13_vm_nics - Skip remove_nic step for vmware if vmware-tools are not installed --- Key: CLOUDSTACK-7933 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7933 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 Remove Nic should be skipped for vmware when vmware tools are not installed because it is not supported without vmware tools. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7912) Move hard coded test data for Netscaler device out of the test cases. Read it from config file.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-7912: --- Status: Reviewable (was: In Progress) Move hard coded test data for Netscaler device out of the test cases. Read it from config file. --- Key: CLOUDSTACK-7912 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7912 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 Many test cases have Netscaler info hard coded in the test case. Move this data out of the test cases and read it from the config file. Make this change across all the files applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7938) Automation: Create different section in test_data.py for configurable data and make changes in test cases accordingly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye resolved CLOUDSTACK-7938. Resolution: Fixed Automation: Create different section in test_data.py for configurable data and make changes in test cases accordingly - Key: CLOUDSTACK-7938 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7938 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 Automation: Create different section in test_data.py for configurable data and make changes in test cases accordingly Currently we have some value in config such as portable IP data and also netscaler data. Move this to new section so that we know which data needs to be changed according to the setup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-6465) vmware.reserve.mem is missing from cluster level settings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala resolved CLOUDSTACK-6465. - Resolution: Fixed vmware.reserve.mem is missing from cluster level settings -- Key: CLOUDSTACK-6465 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6465 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.5.0, 4.4.3 vmware.reserve.mem is missing from cluster level settings steps === infrastructure-cluster-select a cluster-setting you should vmware.reserver.mem DB: === mysql select name from configuration where scope =cluster; +--+ | name | +--+ | cluster.cpu.allocated.capacity.disablethreshold | | cluster.cpu.allocated.capacity.notificationthreshold | | cluster.memory.allocated.capacity.disablethreshold | | cluster.memory.allocated.capacity.notificationthreshold | | cluster.storage.allocated.capacity.notificationthreshold | | cluster.storage.capacity.notificationthreshold | | cpu.overprovisioning.factor | | mem.overprovisioning.factor | | vmware.reserve.cpu | | xen.vm.vcpu.max | +--+ 10 rows in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-6748) Creating an instance with user-data when network doesn't support user-data should error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225927#comment-14225927 ] Harikrishna Patnala edited comment on CLOUDSTACK-6748 at 11/26/14 9:04 AM: --- Hi Dave, Sorry for the delayed response. We don't completely error out, we have this check for default network. https://reviews.apache.org/r/21805/ was (Author: harikrishna.patnala): Hi Dave, Sorry for the delayed response. We don't completely error out, we have this check for default network. Creating an instance with user-data when network doesn't support user-data should error --- Key: CLOUDSTACK-6748 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6748 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.5.0, 4.4.3 While deploying a VM we provide user-data in order to configure appliance instances. Right now we do not throw error if user data is sent while deploying the vm and network does not support userdata. We should not allow sending userdata when network does not support UserData service since this may create eventual problems. We should fail fast or error the creation of the instance if user-data is supplied when the guest network doesn't support this capability The same applies for ssh key and password enabled templates. Say if a vm is deployed using password enabled template we cannot send password to router if network does not support userdata service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6748) Creating an instance with user-data when network doesn't support user-data should error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225927#comment-14225927 ] Harikrishna Patnala commented on CLOUDSTACK-6748: - Hi Dave, Sorry for the delayed response. We don't completely error out, we have this check for default network. Creating an instance with user-data when network doesn't support user-data should error --- Key: CLOUDSTACK-6748 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6748 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.5.0, 4.4.3 While deploying a VM we provide user-data in order to configure appliance instances. Right now we do not throw error if user data is sent while deploying the vm and network does not support userdata. We should not allow sending userdata when network does not support UserData service since this may create eventual problems. We should fail fast or error the creation of the instance if user-data is supplied when the guest network doesn't support this capability The same applies for ssh key and password enabled templates. Say if a vm is deployed using password enabled template we cannot send password to router if network does not support userdata service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6945) Null pointer exception when starting a VM that had its template deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-6945: Fix Version/s: 4.3.2 Null pointer exception when starting a VM that had its template deleted --- Key: CLOUDSTACK-6945 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6945 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: Hosts are Debian 7.4.0 with Xen hypervisor e Xen Cloud Platform packages installed and properly configured. Reporter: Rafael Weingartner Priority: Critical Fix For: 4.5.0, 4.4.3, 4.3.2 It seems that you have a bug in CS 4.3.0(and probably previous versions?) when starting a machine that was created from a template that has been deleted. There will happen a null pointer exception in com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart: “858 -if (volTemplateId != null volTemplateId.longValue() != template.getId())” The object, “template” is going to be null, because in: “811 - VirtualMachineTemplate template = _entityMgr.findById(VirtualMachineTemplate.class, vm.getTemplateId());” The findById, will add a where clause, looking for template that have the column removed that is null, therefore It will return a null object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7790) VXLAN interface MTU change from 1450 to 1500 and JUMBRO frames
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225954#comment-14225954 ] Andrija Panic commented on CLOUDSTACK-7790: --- Now I see the way to acually make this works, and that is to really increase MTU in the first place on the physical device (ethX or bridge). When vxlan driver creates new vxan interface and corresponding bridge - it will create MTU that is exactly 50bytes smaller than the MTU on the physical device ethX/bridge. This was never mentioned in the documentation in the first place. But at least there is a correct way to setup things. Will try to update docs. VXLAN interface MTU change from 1450 to 1500 and JUMBRO frames -- Key: CLOUDSTACK-7790 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7790 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.4.1 Environment: NOT important - CentOS 6.5, elrepo kernel 3.10 - Reporter: Andrija Panic Priority: Critical Labels: frames, jumbo, vxlan By default, when using vxlan as isolation method for Guest traffic - cloudstack created vxlan vbidge and interface, and set's MTU for those to 1450 bytes. Problem is that default OS MTU for any VM is 1500 and all packets get droped (except maybe DHCP and ping which uses smaller packets). 1) Current proposed solution is to change MTU inside VM/template to 1450 - which is absolutely NOT user friendly and degrades performance 2) Better approach - set MTU on vxlan interface and bridge to a default value of 1500, and ask ADMIN to increase MTU to 1600 bytes on physical interface ethX or cloudbrX and enable at least 1600 frames on physical network 3) Even better - add GUI component to CloudStack for a MTU value, so the ADMIN can deploy JUMBRO frames accross whole Guest network - this should be probably enabled per network offering, or similar. Current setup, require MTU change inside VM is not a good solution, and does not enable user to use JUMBRO frames at all... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7971) central key management for tags
Ingo Jochim created CLOUDSTACK-7971: --- Summary: central key management for tags Key: CLOUDSTACK-7971 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7971 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, UI Affects Versions: Future Reporter: Ingo Jochim In case you get to use the tags for virtual machines or storage volumes a lot then the key's might end up with any kind of spelling for the different objects. For example (Hostname, Host-Name, hostname, ...). On a search you will run into problems. It can be very helpful if the domain admin can create a list of keys which users can select from a drop down field. Regards, Ingo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6276) Affinity Groups within projects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225993#comment-14225993 ] Ingo Jochim commented on CLOUDSTACK-6276: - Is this fixed in newer versions than 4.2? Regards, Ingo Affinity Groups within projects --- Key: CLOUDSTACK-6276 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6276 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Reporter: Ingo Jochim Hello, I like to have the features Affinity Group and Project combined. As far as I know I cannot use Affinity Groups within Projects. Thanks and regards, Ingo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7972) DNS records for additional IP addresses
Ingo Jochim created CLOUDSTACK-7972: --- Summary: DNS records for additional IP addresses Key: CLOUDSTACK-7972 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7972 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller, UI Affects Versions: Future Reporter: Ingo Jochim For adaptive computing it's important to get use of additional application IP addresses which you can move between machines in case of a failure of one of the virtual machines or for upgrades. I can attach an additional IP to a VM using CS. But I cannot give that a separate name which does not belong to the actual hostname of the VM. It would be just another A-Record in DNS for this new application IP. Thanks and regards, Ingo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7973) Proper handler for FenceCommand in simulator
Koushik Das created CLOUDSTACK-7973: --- Summary: Proper handler for FenceCommand in simulator Key: CLOUDSTACK-7973 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7973 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Simulator Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.5.0 Proper handler for FenceCommand in simulator -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7973) Proper handler for FenceCommand in simulator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226033#comment-14226033 ] ASF subversion and git services commented on CLOUDSTACK-7973: - Commit d55059dd5d8b276c92733e6cceed644e08c199d0 in cloudstack's branch refs/heads/4.5 from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d55059d ] CLOUDSTACK-7973: Proper handler for FenceCommand in simulator Added a proper handler for FenceCommand in simulator Proper handler for FenceCommand in simulator Key: CLOUDSTACK-7973 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7973 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Simulator Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.5.0 Proper handler for FenceCommand in simulator -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7960) [Automation] Creation of Volume from Snapshot fails due to StringIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226034#comment-14226034
]
ASF subversion and git services commented on CLOUDSTACK-7960:
-
Commit 3fc392abf8a17d823d76805782d3ee01b54b5210 in cloudstack's branch
refs/heads/4.5 from [~koushikd]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3fc392a ]
CLOUDSTACK-7960: [Automation] Creation of Volume from Snapshot fails due to
StringIndexOutOfBoundsException
Fixed the appropriate CopyCommand handler in simulator plugin
[Automation] Creation of Volume from Snapshot fails due to
StringIndexOutOfBoundsException
--
Key: CLOUDSTACK-7960
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7960
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Koushik Das
Priority: Critical
Fix For: 4.5.0
Use Case:
Validate the following sequence
# Deploy VM with custom disk offering and check the primary storage
resource count
# Stop the VM and create Snapshot from VM's volume
# Create volume again from this snapshot
StringIndexOutOfBoundsException:
{noformat}
2014-11-21 01:04:06,153 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-4e287cc2 ctx-e68b28dc ctx-a00dd9d4) ===END===
10.220.135.118 -- GET
account=test-a-TestVolumeLimits-test_create_template_snapshot_1_root_domain_admin-9B6G87domainid=58f506ce-7108-11e4-bca3-7640e6bc0920name=Test+Volume-DGE7AVzoneid=7934f921-50e4-406b-b0dd-8c474907d8cfapiKey=rRJabsdLiEc7Wnp7V6yxoQWckT_5EBLxkm5Bz5JFImYh-CqbkPW8fL87x8Qp2QDJXAobZscfqwwaW9jm3mXUzgcommand=createVolumesignature=Kb4x7pXEbm2yfoNmKAVZ92bFu1Y%3Dsnapshotid=cd663163-8045-43d1-9a88-899d0c1e9182response=jsonsize=2
2014-11-21 01:04:06,158 DEBUG [c.c.a.ApiServlet]
(catalina-exec-5:ctx-662f483b) ===START=== 10.220.135.118 -- GET
jobid=5b446f9d-2056-43f2-9057-2d16b40e926fapiKey=rRJabsdLiEc7Wnp7V6yxoQWckT_5EBLxkm5Bz5JFImYh-CqbkPW8fL87x8Qp2QDJXAobZscfqwwaW9jm3mXUzgcommand=queryAsyncJobResultresponse=jsonsignature=dtw5FWz4%2FrigWTMJHLTB7vMCKS0%3D
2014-11-21 01:04:06,175 DEBUG [c.c.a.ApiServlet]
(catalina-exec-5:ctx-662f483b ctx-ad395747 ctx-b176f4c5) ===END===
10.220.135.118 -- GET
jobid=5b446f9d-2056-43f2-9057-2d16b40e926fapiKey=rRJabsdLiEc7Wnp7V6yxoQWckT_5EBLxkm5Bz5JFImYh-CqbkPW8fL87x8Qp2QDJXAobZscfqwwaW9jm3mXUzgcommand=queryAsyncJobResultresponse=jsonsignature=dtw5FWz4%2FrigWTMJHLTB7vMCKS0%3D
2014-11-21 01:04:06,185 DEBUG [o.a.c.s.a.LocalStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945)
LocalStoragePoolAllocator trying to find storage pool to fit the vm
2014-11-21 01:04:06,185 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945)
ClusterScopeStoragePoolAllocator looking for storage pool
2014-11-21 01:04:06,185 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Looking for pools
in dc: 1 pod:1 cluster:null
2014-11-21 01:04:06,187 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Found pools
matching tags: [Pool[1|NetworkFilesystem], Pool[2|NetworkFilesystem],
Pool[3|NetworkFilesystem]]
2014-11-21 01:04:06,189 DEBUG [o.a.c.s.a.AbstractStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Checking if storage
pool is suitable, name: null ,poolId: 1
2014-11-21 01:04:06,191 INFO [c.c.s.StorageManagerImpl]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Storage pool null
(1) does not supply IOPS capacity, assuming enough capacity
2014-11-21 01:04:06,193 DEBUG [c.c.s.StorageManagerImpl]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Checking pool 1 for
storage, totalSize: 1099511627776, usedBytes: 0, usedPct: 0.0, disable
threshold: 0.85
2014-11-21 01:04:06,197 DEBUG [c.c.s.StorageManagerImpl]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Checking pool: 1
for volume allocation [Vol[764|vm=null|DATADISK]], maxSize : 219902322,
totalAllocatedSize : 200, askingSize : 2147483648, allocated disable
threshold: 0.85
2014-11-21 01:04:06,197 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945)
ClusterScopeStoragePoolAllocator returning 1 suitable storage pools
2014-11-21 01:04:06,198 DEBUG [o.a.c.e.o.VolumeOrchestrator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Found a suitable
pool for create volume: 1
[jira] [Commented] (CLOUDSTACK-7973) Proper handler for FenceCommand in simulator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226108#comment-14226108 ] ASF subversion and git services commented on CLOUDSTACK-7973: - Commit bf565845285c2e47ef362a39a278eec9dd599680 in cloudstack's branch refs/heads/master from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bf56584 ] CLOUDSTACK-7973: Proper handler for FenceCommand in simulator Added a proper handler for FenceCommand in simulator Proper handler for FenceCommand in simulator Key: CLOUDSTACK-7973 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7973 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Simulator Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.5.0 Proper handler for FenceCommand in simulator -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7960) [Automation] Creation of Volume from Snapshot fails due to StringIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226109#comment-14226109
]
ASF subversion and git services commented on CLOUDSTACK-7960:
-
Commit 4798db0de1862bbdf7f2af67f7684f2f3430609e in cloudstack's branch
refs/heads/master from [~koushikd]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4798db0 ]
CLOUDSTACK-7960: [Automation] Creation of Volume from Snapshot fails due to
StringIndexOutOfBoundsException
Fixed the appropriate CopyCommand handler in simulator plugin
[Automation] Creation of Volume from Snapshot fails due to
StringIndexOutOfBoundsException
--
Key: CLOUDSTACK-7960
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7960
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Koushik Das
Priority: Critical
Fix For: 4.5.0
Use Case:
Validate the following sequence
# Deploy VM with custom disk offering and check the primary storage
resource count
# Stop the VM and create Snapshot from VM's volume
# Create volume again from this snapshot
StringIndexOutOfBoundsException:
{noformat}
2014-11-21 01:04:06,153 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-4e287cc2 ctx-e68b28dc ctx-a00dd9d4) ===END===
10.220.135.118 -- GET
account=test-a-TestVolumeLimits-test_create_template_snapshot_1_root_domain_admin-9B6G87domainid=58f506ce-7108-11e4-bca3-7640e6bc0920name=Test+Volume-DGE7AVzoneid=7934f921-50e4-406b-b0dd-8c474907d8cfapiKey=rRJabsdLiEc7Wnp7V6yxoQWckT_5EBLxkm5Bz5JFImYh-CqbkPW8fL87x8Qp2QDJXAobZscfqwwaW9jm3mXUzgcommand=createVolumesignature=Kb4x7pXEbm2yfoNmKAVZ92bFu1Y%3Dsnapshotid=cd663163-8045-43d1-9a88-899d0c1e9182response=jsonsize=2
2014-11-21 01:04:06,158 DEBUG [c.c.a.ApiServlet]
(catalina-exec-5:ctx-662f483b) ===START=== 10.220.135.118 -- GET
jobid=5b446f9d-2056-43f2-9057-2d16b40e926fapiKey=rRJabsdLiEc7Wnp7V6yxoQWckT_5EBLxkm5Bz5JFImYh-CqbkPW8fL87x8Qp2QDJXAobZscfqwwaW9jm3mXUzgcommand=queryAsyncJobResultresponse=jsonsignature=dtw5FWz4%2FrigWTMJHLTB7vMCKS0%3D
2014-11-21 01:04:06,175 DEBUG [c.c.a.ApiServlet]
(catalina-exec-5:ctx-662f483b ctx-ad395747 ctx-b176f4c5) ===END===
10.220.135.118 -- GET
jobid=5b446f9d-2056-43f2-9057-2d16b40e926fapiKey=rRJabsdLiEc7Wnp7V6yxoQWckT_5EBLxkm5Bz5JFImYh-CqbkPW8fL87x8Qp2QDJXAobZscfqwwaW9jm3mXUzgcommand=queryAsyncJobResultresponse=jsonsignature=dtw5FWz4%2FrigWTMJHLTB7vMCKS0%3D
2014-11-21 01:04:06,185 DEBUG [o.a.c.s.a.LocalStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945)
LocalStoragePoolAllocator trying to find storage pool to fit the vm
2014-11-21 01:04:06,185 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945)
ClusterScopeStoragePoolAllocator looking for storage pool
2014-11-21 01:04:06,185 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Looking for pools
in dc: 1 pod:1 cluster:null
2014-11-21 01:04:06,187 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Found pools
matching tags: [Pool[1|NetworkFilesystem], Pool[2|NetworkFilesystem],
Pool[3|NetworkFilesystem]]
2014-11-21 01:04:06,189 DEBUG [o.a.c.s.a.AbstractStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Checking if storage
pool is suitable, name: null ,poolId: 1
2014-11-21 01:04:06,191 INFO [c.c.s.StorageManagerImpl]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Storage pool null
(1) does not supply IOPS capacity, assuming enough capacity
2014-11-21 01:04:06,193 DEBUG [c.c.s.StorageManagerImpl]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Checking pool 1 for
storage, totalSize: 1099511627776, usedBytes: 0, usedPct: 0.0, disable
threshold: 0.85
2014-11-21 01:04:06,197 DEBUG [c.c.s.StorageManagerImpl]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Checking pool: 1
for volume allocation [Vol[764|vm=null|DATADISK]], maxSize : 219902322,
totalAllocatedSize : 200, askingSize : 2147483648, allocated disable
threshold: 0.85
2014-11-21 01:04:06,197 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945)
ClusterScopeStoragePoolAllocator returning 1 suitable storage pools
2014-11-21 01:04:06,198 DEBUG [o.a.c.e.o.VolumeOrchestrator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Found a suitable
pool for create volume: 1
[jira] [Resolved] (CLOUDSTACK-7973) Proper handler for FenceCommand in simulator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koushik Das resolved CLOUDSTACK-7973. - Resolution: Fixed Proper handler for FenceCommand in simulator Key: CLOUDSTACK-7973 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7973 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Simulator Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.5.0 Proper handler for FenceCommand in simulator -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7960) [Automation] Creation of Volume from Snapshot fails due to StringIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koushik Das resolved CLOUDSTACK-7960.
-
Resolution: Fixed
[Automation] Creation of Volume from Snapshot fails due to
StringIndexOutOfBoundsException
--
Key: CLOUDSTACK-7960
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7960
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Koushik Das
Priority: Critical
Fix For: 4.5.0
Use Case:
Validate the following sequence
# Deploy VM with custom disk offering and check the primary storage
resource count
# Stop the VM and create Snapshot from VM's volume
# Create volume again from this snapshot
StringIndexOutOfBoundsException:
{noformat}
2014-11-21 01:04:06,153 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-4e287cc2 ctx-e68b28dc ctx-a00dd9d4) ===END===
10.220.135.118 -- GET
account=test-a-TestVolumeLimits-test_create_template_snapshot_1_root_domain_admin-9B6G87domainid=58f506ce-7108-11e4-bca3-7640e6bc0920name=Test+Volume-DGE7AVzoneid=7934f921-50e4-406b-b0dd-8c474907d8cfapiKey=rRJabsdLiEc7Wnp7V6yxoQWckT_5EBLxkm5Bz5JFImYh-CqbkPW8fL87x8Qp2QDJXAobZscfqwwaW9jm3mXUzgcommand=createVolumesignature=Kb4x7pXEbm2yfoNmKAVZ92bFu1Y%3Dsnapshotid=cd663163-8045-43d1-9a88-899d0c1e9182response=jsonsize=2
2014-11-21 01:04:06,158 DEBUG [c.c.a.ApiServlet]
(catalina-exec-5:ctx-662f483b) ===START=== 10.220.135.118 -- GET
jobid=5b446f9d-2056-43f2-9057-2d16b40e926fapiKey=rRJabsdLiEc7Wnp7V6yxoQWckT_5EBLxkm5Bz5JFImYh-CqbkPW8fL87x8Qp2QDJXAobZscfqwwaW9jm3mXUzgcommand=queryAsyncJobResultresponse=jsonsignature=dtw5FWz4%2FrigWTMJHLTB7vMCKS0%3D
2014-11-21 01:04:06,175 DEBUG [c.c.a.ApiServlet]
(catalina-exec-5:ctx-662f483b ctx-ad395747 ctx-b176f4c5) ===END===
10.220.135.118 -- GET
jobid=5b446f9d-2056-43f2-9057-2d16b40e926fapiKey=rRJabsdLiEc7Wnp7V6yxoQWckT_5EBLxkm5Bz5JFImYh-CqbkPW8fL87x8Qp2QDJXAobZscfqwwaW9jm3mXUzgcommand=queryAsyncJobResultresponse=jsonsignature=dtw5FWz4%2FrigWTMJHLTB7vMCKS0%3D
2014-11-21 01:04:06,185 DEBUG [o.a.c.s.a.LocalStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945)
LocalStoragePoolAllocator trying to find storage pool to fit the vm
2014-11-21 01:04:06,185 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945)
ClusterScopeStoragePoolAllocator looking for storage pool
2014-11-21 01:04:06,185 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Looking for pools
in dc: 1 pod:1 cluster:null
2014-11-21 01:04:06,187 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Found pools
matching tags: [Pool[1|NetworkFilesystem], Pool[2|NetworkFilesystem],
Pool[3|NetworkFilesystem]]
2014-11-21 01:04:06,189 DEBUG [o.a.c.s.a.AbstractStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Checking if storage
pool is suitable, name: null ,poolId: 1
2014-11-21 01:04:06,191 INFO [c.c.s.StorageManagerImpl]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Storage pool null
(1) does not supply IOPS capacity, assuming enough capacity
2014-11-21 01:04:06,193 DEBUG [c.c.s.StorageManagerImpl]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Checking pool 1 for
storage, totalSize: 1099511627776, usedBytes: 0, usedPct: 0.0, disable
threshold: 0.85
2014-11-21 01:04:06,197 DEBUG [c.c.s.StorageManagerImpl]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Checking pool: 1
for volume allocation [Vol[764|vm=null|DATADISK]], maxSize : 219902322,
totalAllocatedSize : 200, askingSize : 2147483648, allocated disable
threshold: 0.85
2014-11-21 01:04:06,197 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945)
ClusterScopeStoragePoolAllocator returning 1 suitable storage pools
2014-11-21 01:04:06,198 DEBUG [o.a.c.e.o.VolumeOrchestrator]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Found a suitable
pool for create volume: 1
2014-11-21 01:04:06,214 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) copyAsync
inspecting src type SNAPSHOT copyAsync inspecting dest type VOLUME
2014-11-21 01:04:06,225 DEBUG [c.c.a.t.Request]
(API-Job-Executor-101:ctx-c66892e0 job-4276 ctx-db279945) Seq
2-8004303912720929589: Sending { Cmd , MgmtId: 130021121067296, via:
[jira] [Commented] (CLOUDSTACK-5997) Template state changes side affects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226154#comment-14226154 ] Rohit Yadav commented on CLOUDSTACK-5997: - [~nitinme], if this valid for 4.3.x? If so can you please backport this to 4.3? Template state changes side affects --- Key: CLOUDSTACK-5997 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5997 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Fix For: 4.4.0 Template state change functionality. A state has been introduced for vm_template. It reflects the user action for making template active/inactive for further use. When the template is marked inactive it becomes unusable for the entire cloud. If the user wants to make it as inactive for a particular zone, template_zone_ref would be accordingly reflected. Admin listing should still be able to see the inactive templates. The intent of the removed flag is to capture the system state meaning whether it has been physically removed from the cloud. The garbage collection thread checks the inactive state of the template and deletes it physically from sec. storage when no vm is referencing this template anymore. It also deletes it from PS. This is when the removed flag is set in the vm_template table. At the moment this functionality doesn't exist in CS so the removed flag is never set as of now. Things that need to be fixed Deleting the template by user for a particular zone should mark the removed flag in template zone ref only. It should mark the template as inactive if its there is no other zone carrying it. Deleting the template without any zone should mark it as inactive right away. Removed flag is not set and there shouldn't be any code setting it at the moment (Delete template shouldn't mark the removed flag.) Start showing the state in the api. Regular users should see only active templates but admins should be able to see active/inactive templates Template Sync. Should start using active/inactive state than the removed flag. Show removed functionality introduced for CPBM would be fixed automatically when admin sees the inactive state - Any template code referencing the removed flag from vm_template should use the active/inactive flag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5995) change service offering is not honouring host tags
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226156#comment-14226156 ] Rohit Yadav commented on CLOUDSTACK-5995: - [~prachidamle], is this applicable to 4.3.x? If so can you please backport this to 4.3 branch. Thanks. change service offering is not honouring host tags --- Key: CLOUDSTACK-5995 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5995 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 Reporter: Prachi Damle Assignee: Prachi Damle Fix For: 4.4.0 steps to reproduce --- 1-prepare CS setup with two host 2-deploy a vm 3-create a SO say TG with host tag(say h1) 4-stop vm created in step 2 and change service offering to TG 5-start vm Expected = vm deployment should fail since there is no host with tag h1 Actual == vm got deployed on last host my observation === vm always choosing last host, irrespective of tag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6172) Volume is not retaining same uuid when migrating from one storage to another.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226165#comment-14226165 ] ASF subversion and git services commented on CLOUDSTACK-6172: - Commit 77446d2716a4d174c4505123758310ba0fe48e2d in cloudstack's branch refs/heads/4.3 from [~sanjay.tripathi] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=77446d2 ] CLOUDSTACK-6172: Volume is not retaining same uuid when migrating from one storage to another. (cherry picked from commit 624139d8ef9ea9462ba81d2d3941ee5ac9467b20) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Volume is not retaining same uuid when migrating from one storage to another. - Key: CLOUDSTACK-6172 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6172 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.3.0 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Fix For: 4.4.0 Volume migration results in creating a new entry in DB with different uuid, because of this if the user are using the APIs and referring to the same uuid of the volume for there different operations, which is correct as its the same volume; then this error is coming: Error please specify a valid data volume. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6210) LDAP:listLdapUsers api throws exception when we click on Add LDAP Account
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226163#comment-14226163
]
ASF subversion and git services commented on CLOUDSTACK-6210:
-
Commit c2c6ecf828d85e3a5085ea28baed0ed9e1ba5d9e in cloudstack's branch
refs/heads/4.3 from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c2c6ecf ]
CLOUDSTACK-6210: LDAP:listLdapUsers api throws exception when we click on Add
LDAP Account This occurs when ldap basedn is not configured. Throwing an IAE
and a proper message is returned from the api call
Signed-off-by: Ian Duffy i...@ianduffy.ie
(cherry picked from commit 4552ec632201e7432afae7770f5854aaa244267c)
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
Conflicts:
plugins/user-authenticators/ldap/src/org/apache/cloudstack/ldap/LdapUserManager.java
LDAP:listLdapUsers api throws exception when we click on Add LDAP Account
Key: CLOUDSTACK-6210
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6210
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API, Management Server
Affects Versions: 4.3.0
Reporter: sadhu suresh
Assignee: Rajani Karuturi
Fix For: 4.4.0
listLdapUsers throws Nullpointer exception when we try to add new LDAP
account.
http://10.147.59.151:8080/client/api?command=listLdapUserslisttype=newresponse=jsonsessionkey=mmC8CloNaIGUrupkj85XT4k1%2Fz0%3D_=1394010828334
75
Content-Type text/javascript;charset=UTF-8
Date Wed, 05 Mar 2014 09:13:48 GMT
Server Apache-Coyote/1.1
Request Headersview source
Accept application/json, text/javascript, /; q=0.01
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Connection keep-alive
Cookie userfullname=j%20h; userid=b3174173-6916-45ec-bb65-fa9162bd8941;
capabilities=%5Bobject%20Object%5D; kvmsnapshotenabled=false;
regionsecondaryenabled=false; userpublictemplateenabled=true;
userProjectsEnabled=true; sessionKey=mmC8CloNaIGUrupkj85XT4k1%252Fz0%253D;
username=root; account=admin; domainid=4711cc24-a2b6-11e3-8cda-06a8f47f;
role=1; supportELB=false; JSESSIONID=6ABB50CC5B2376957649E5B7ADAF432B
Host 10.147.59.151:8080
Referer http://10.147.59.151:8080/client/
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101
Firefox/27.0
X-Requested-With XMLHttpRequest
http://10.147.59.151:8080/client/api?command=listLdapUserslisttype=newresponse=jsonsessionkey=mmC8CloNaIGUrupkj85XT4k1%2Fz0%3D_=1394010828334
t25), Ver: v1, Flags: 11,
[{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[
{id:4,srcIp:10.147.49.32,protocol:udp,srcPortRange:[500,500],revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Ingress,defaultEgressPolicy:false}
,
{id:6,srcIp:10.147.49.32,protocol:udp,srcPortRange:[1701,1701],revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Ingress,defaultEgressPolicy:false}
,
{id:8,srcIp:10.147.49.32,protocol:udp,srcPortRange:[4500,4500],revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Ingress,defaultEgressPolicy:false}
],accessDetails:
{router.guest.ip:10.1.1.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:169.254.0.19,router.name:r-18-VM}
,wait:0}}] }
2014-03-05 15:10:22,168 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-480:ctx-d7593b7d) Seq 1-1795823775: Executing request
^C
[root@RHEL62 ~]# vi mslog
java.lang.NullPointerException
at javax.naming.InitialContext.getURLScheme(InitialContext.java:286)
at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:335)
at
javax.naming.directory.InitialDirContext.getURLOrDefaultInitDirCtx(InitialDirContext.java:104)
at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:265)
at
org.apache.cloudstack.ldap.LdapUserManager.searchUsers(LdapUserManager.java:184)
at
org.apache.cloudstack.ldap.LdapUserManager.getUsers(LdapUserManager.java:122)
at
org.apache.cloudstack.ldap.LdapUserManager.getUsers(LdapUserManager.java:118)
at
org.apache.cloudstack.ldap.LdapManagerImpl.getUsers(LdapManagerImpl.java:175)
at
org.apache.cloudstack.api.command.LdapListUsersCmd.execute(LdapListUsersCmd.java:85)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:531)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:374)
at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322)
at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114)
at
[jira] [Commented] (CLOUDSTACK-6172) Volume is not retaining same uuid when migrating from one storage to another.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226167#comment-14226167 ] ASF subversion and git services commented on CLOUDSTACK-6172: - Commit 11eab3d285620b2a62078bd48f6b9e4089ef10e9 in cloudstack's branch refs/heads/4.3 from sanjeev [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=11eab3d ] CLOUDSTACK-6172: Adding new test case to verify this fix Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: test/integration/component/test_volumes.py Signed-off-by: sanjeev sanj...@apache.org CLOUDSTACK-6172: Fixed review comments provided in RR 25771 (cherry picked from commit 2d19bcb46ad7c78b4842c1f52f552998a33f8836) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Volume is not retaining same uuid when migrating from one storage to another. - Key: CLOUDSTACK-6172 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6172 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.3.0 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Fix For: 4.4.0 Volume migration results in creating a new entry in DB with different uuid, because of this if the user are using the APIs and referring to the same uuid of the volume for there different operations, which is correct as its the same volume; then this error is coming: Error please specify a valid data volume. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6192) KVM: StartCommand and PrepareForMigrationCommand don't fail if storage adaptor fails connectPhysicalDisk
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226164#comment-14226164 ] ASF subversion and git services commented on CLOUDSTACK-6192: - Commit a88c3dd8a4dd108aa434440c83d6ca5cc3985e83 in cloudstack's branch refs/heads/4.3 from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a88c3dd ] CLOUDSTACK-6192: Return failure on StartCommand and PrepareForMigrationCommand when connectPhysicalDisk fails, rather than continuing on (cherry picked from commit fb0b2eb26731a6db00c65dcd799653a213475387) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com KVM: StartCommand and PrepareForMigrationCommand don't fail if storage adaptor fails connectPhysicalDisk Key: CLOUDSTACK-6192 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6192 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.3.0, 4.4.0 Reporter: Marcus Sorensen Assignee: Marcus Sorensen Priority: Minor Fix For: 4.4.0 PrepareForMigrationCommand returns success even if the disks are not properly prepared (storage adaptor returns false to connectPhysicalDisk). Likewise, StartCommand continues on with trying to start the VM if connectPhysicalDisk fails. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6172) Volume is not retaining same uuid when migrating from one storage to another.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226166#comment-14226166 ] ASF subversion and git services commented on CLOUDSTACK-6172: - Commit 11eab3d285620b2a62078bd48f6b9e4089ef10e9 in cloudstack's branch refs/heads/4.3 from sanjeev [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=11eab3d ] CLOUDSTACK-6172: Adding new test case to verify this fix Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: test/integration/component/test_volumes.py Signed-off-by: sanjeev sanj...@apache.org CLOUDSTACK-6172: Fixed review comments provided in RR 25771 (cherry picked from commit 2d19bcb46ad7c78b4842c1f52f552998a33f8836) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Volume is not retaining same uuid when migrating from one storage to another. - Key: CLOUDSTACK-6172 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6172 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.3.0 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Fix For: 4.4.0 Volume migration results in creating a new entry in DB with different uuid, because of this if the user are using the APIs and referring to the same uuid of the volume for there different operations, which is correct as its the same volume; then this error is coming: Error please specify a valid data volume. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6020) createPortForwardingRule failes for vmguestip above 127.255.255.255
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226168#comment-14226168
]
ASF subversion and git services commented on CLOUDSTACK-6020:
-
Commit 2b264e6b57b90d6eb5d202c4fe72e64d867b3f9b in cloudstack's branch
refs/heads/4.3 from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2b264e6 ]
CLOUDSTACK-6020 ipv4 address can be a larger number then
Interger.MAX_VALUE
(cherry picked from commit b3829e54d6b7af426f797ffb9fa54b4cd2abffc0)
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
createPortForwardingRule failes for vmguestip above 127.255.255.255
---
Key: CLOUDSTACK-6020
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6020
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API
Affects Versions: pre-4.0.0, 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0,
Future, 4.2.1, 4.1.2, 4.3.0, 4.4.0
Reporter: Joris van Lieshout
Assignee: Daan Hoogland
Fix For: 4.4.0
command=createPortForwardingRuleresponse=jsonsessionkey=FmHQb9oGmgKlM4ihB%2Fb2ik7p35E%3Dipaddressid=d29bebfe-edc1-406f-b4ed-7a49c6e7ee1fprivateport=80privateendport=80publicport=80publicendport=80protocol=tcpvirtualmachineid=cc5c9dc4-3eeb-4533-994a-0e2636a48a60openfirewall=falsevmguestip=192.168.1.30networkid=5e56227c-83c0-4b85-8a27-53343e806d12_=1391510423905
vmguestip=192.168.1.30
api/src/org/apache/cloudstack/api/command/user/firewall/CreatePortForwardingRuleCmd.java
@Parameter(name = ApiConstants.VM_GUEST_IP, type = CommandType.STRING,
required = false,
description = VM guest nic Secondary ip address for the port forwarding
rule)
private String vmSecondaryIp;
@Override
public void create() {
// cidr list parameter is deprecated
if (cidrlist != null) {
throw new InvalidParameterValueException(Parameter cidrList is
deprecated; if you need to open firewall rule for the specific cidr, please
refer to createFirewallRule command);
}
Ip privateIp = getVmSecondaryIp();
if (privateIp != null) {
if ( !privateIp.isIp4()) {
throw new InvalidParameterValueException(Invalid vm ip
address);
}
}
try {
PortForwardingRule result =
_rulesService.createPortForwardingRule(this, virtualMachineId, privateIp,
getOpenFirewall());
setEntityId(result.getId());
setEntityUuid(result.getUuid());
} catch (NetworkRuleConflictException ex) {
s_logger.info(Network rule conflict: , ex);
s_logger.trace(Network Rule Conflict: , ex);
throw new
ServerApiException(ApiErrorCode.NETWORK_RULE_CONFLICT_ERROR, ex.getMessage());
}
}
utils/src/com/cloud/utils/net/Ip.java
public boolean isIp4() {
return ip Integer.MAX_VALUE;
}
public Ip(String ip) {
this.ip = NetUtils.ip2Long(ip);
}
=== ip2long for 192.168.1.30 = 3232235806
=== Integer.MAX_VALUE = 231-1 = 2147483647
3232235806 (192.168.1.30) is therefore bigger then MAX_VALUE making isIp4()
return FALSE and throwing a InvalidParameterValueException…
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5920) CloudStack IAM Plugin feature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226410#comment-14226410 ] Rohit Yadav commented on CLOUDSTACK-5920: - Is this going to end up on 4.5/master anytime soon? CloudStack IAM Plugin feature - Key: CLOUDSTACK-5920 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5920 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: API, Management Server Affects Versions: 4.3.0 Reporter: Prachi Damle Assignee: Prachi Damle Fix For: 4.5.0 Currently CloudStack provides very limited IAM services and there are several drawbacks within those services: - Offers few roles out of the box (user and admin) with prebaked access control for these roles. There is no way to create additional roles with customized permissions. - Some resources have access control baked into them. E.g., shared networks, projects etc. - We have to create special dedicate APIs to grant permissions to resources. - Also it should be based on a plugin model to be possible to integrate with other RBAC implementations say using AD/LDAP in future Goal for this feature would be to address these limitations and offer true IAM services in a phased manner. As a first phase, we need to separate out the current access control into a separate component and create a standard access check mechanism to be used by the API layer. Also the read/listing APIs need to be refactored accordingly to consider the role based access granting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5810) addIpToNic: the owner of the secondary ip should be derived from vmInstance object, not from the caller account
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226433#comment-14226433 ] Rohit Yadav commented on CLOUDSTACK-5810: - Can any of [~alena1108] or [~jayapal] help backport the fixes to 4.3 branch, thanks? addIpToNic: the owner of the secondary ip should be derived from vmInstance object, not from the caller account --- Key: CLOUDSTACK-5810 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5810 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 Reporter: Alena Prokharchyk Assignee: Jayapal Reddy Priority: Critical Fix For: 4.4.0 Steps to reproduce: 1) Deploy a vm as a regular user account. 2) Login as admin, add secondary ip to the user's vm's nic. Bug: the secondary ip account owner is set to Admin account. This is wrong, as in CS we never let link objects belonging to diff accounts, unless its a public resource (template, network). In cases like this one, the owner info should be derived from the vm instance object. Jayapal, I will fix the API, and you have to fix the DB upgrade part. The fix should be: compare the sec ips accounts with the account of corresponding vms, and update nic_secondary_ips if account info is different. Should be done as a part of 43-44 upgrade. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7974) deleted host entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
Yiping Zhang created CLOUDSTACK-7974: Summary: deleted host entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, noted down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exists in /etc/dhcphosts.txt and /etc/hosts files -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7974) deleted host entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yiping Zhang updated CLOUDSTACK-7974: - Description: We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. was: We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, noted down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exists in /etc/dhcphosts.txt and /etc/hosts files deleted host entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router -- Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4757) Support OVA files with multiple disks for templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226585#comment-14226585 ] Rohit Yadav commented on CLOUDSTACK-4757: - Any update on this? Support OVA files with multiple disks for templates --- Key: CLOUDSTACK-4757 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4757 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.3.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: Future CloudStack volumes and templates are one single virtual disk in case of XenServer/XCP and KVM hypervisors since the files used for templates and volumes are virtual disks (VHD, QCOW2). However, VMware volumes and templates are in OVA format, which are archives that can contain a complete VM including multiple VMDKs and other files such as ISOs. And currently, Cloudstack only supports Template creation based on OVA files containing a single disk. If a user creates a template from a OVA file containing more than 1 disk and launches an instance using this template, only the first disk is attached to the new instance and other disks are ignored. Similarly with uploaded volumes, attaching an uploaded volume that contains multiple disks to a VM will result in only one VMDK to being attached to the VM. This behavior needs to be improved in VMWare to support OVA files with multiple disks for both uploaded volumes and templates. i.e. If a user creates a template from a OVA file containing more than 1 disk and launches an instance using this template, the first disk should be attached to the new instance as the ROOT disk and volumes should be created based on other VMDK disks in the OVA file and should be attached to the instance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5501) Unable to create more than one vpnConnection per vpn customer gateway
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226601#comment-14226601 ] ASF subversion and git services commented on CLOUDSTACK-5501: - Commit e9c5a03fb0253261b466fd1e3b496cbd500a8049 in cloudstack's branch refs/heads/4.3 from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e9c5a03 ] CLOUDSTACK-5501: Allow one vpn customer gateway with multiple connections This restriction was purposely avoid confusion of VPN setup, but later found too strictly and cause troubles for deployment. Removed after testing one customer gateway with multiple connections. (cherry picked from commit 0a62eb8380390acc7b76a211ef802de0e19aaf13) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: server/src/com/cloud/network/vpn/Site2SiteVpnManagerImpl.java Unable to create more than one vpnConnection per vpn customer gateway - Key: CLOUDSTACK-5501 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5501 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 Reporter: Alena Prokharchyk Assignee: Sheng Yang Priority: Critical Fix For: 4.4.0 There is currently a limitation in the CS code when you can't create more than one vpn connection per customer gateway. There are no technical reasons for this kind of limitation, so we should remove it as the customers might want to use his customer gateway cross zones if he owns VPCs in diff zones. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5719) [UI] Not listing shared network offerings tagged on second physical network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226599#comment-14226599 ] ASF subversion and git services commented on CLOUDSTACK-5719: - Commit bce07b68b8c26f3b44d0e91d76295aaf1d9d15f6 in cloudstack's branch refs/heads/4.3 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bce07b6 ] CLOUDSTACK-5719: UI Network Add Guest Network when Physical Network dropdown is changed, refresh Network Offering dropdown (because each physical network has its own tags which maps to different network offerings) (cherry picked from commit 0af0c041e9b05d52d72936b6ecd194ee07be7421) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com [UI] Not listing shared network offerings tagged on second physical network --- Key: CLOUDSTACK-5719 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5719 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Environment: Advanced zone, multiple guest networks Reporter: Sowmya Krishnan Assignee: Jessica Wang Fix For: 4.4.0 Attachments: cloud.dmp.gz, createsharednw.png Create multiple physical networks with guest networks in both physical networks. Tag the guest networks and use those while creating shared network offerings Try to create shared network in both physical networks UI: Networks - Add guest network - Choose the second physical n/w Result: Lists shared network offering belonging to physical n/w 1 although I choose the second physical n/w Firebug logs shows that it always queries Network offering for the same tag (tag1) although we have 2 tags, one for each physical network: http://10.102.192.125:8080/client/api?command=listPhysicalNetworksresponse=jsonsessionkey=zFMtaefMr9NxN%2F0RjgCtbWLft%2FU%3Dzoneid=15ac37e8-635b-43f4-a53f-4a8c003c5912_=1388662102005 http://10.102.192.125:8080/client/api?command=listTrafficTypesresponse=jsonsessionkey=zFMtaefMr9NxN%2F0RjgCtbWLft%2FU%3Dphysicalnetworkid=c19f422a-55a4-4473-867e-2c9c0b64fc9a_=1388662102199 http://10.102.192.125:8080/client/api?command=listTrafficTypesresponse=jsonsessionkey=zFMtaefMr9NxN%2F0RjgCtbWLft%2FU%3Dphysicalnetworkid=5f9c1b69-325c-43ad-b05e-76470ddbe610_=1388662102387 http://10.102.192.125:8080/client/api?command=listNetworkOfferingsresponse=jsonsessionkey=zFMtaefMr9NxN%2F0RjgCtbWLft%2FU%3Dstate=Enabledzoneid=15ac37e8-635b-43f4-a53f-4a8c003c5912tags=tag1guestiptype=Shared_=1388662102490 http://10.102.192.125:8080/client/api?command=listNetworkOfferingsresponse=jsonsessionkey=zFMtaefMr9NxN%2F0RjgCtbWLft%2FU%3Dstate=Enabledzoneid=15ac37e8-635b-43f4-a53f-4a8c003c5912tags=tag1guestiptype=Shared_=1388662102841 Further, if we continue to create the shared network, it gets created in physical network 2 while the offering is actually tagged on physical n/w 1 Workaround is to go to that physical network and add guest network from there zone - physical network - guest - configure - Network - Add guest network -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5446) KVM-Secondary Store down-Even after secondary store is brought back up after being down for few hours,snapshot jobs do not get triggered with reason there is othe
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226602#comment-14226602 ] ASF subversion and git services commented on CLOUDSTACK-5446: - Commit ba7711b06685993bca5443ebdf6ccb76e87b9f6f in cloudstack's branch refs/heads/4.3 from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ba7711b ] CLOUDSTACK-5446: delete all the leftover snapshots on primary storage in case of snapshot errors, after a new backup snapshot is finished (cherry picked from commit 2667855ccb932f9a03ddf6639f6411c73fea1b2c) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com KVM-Secondary Store down-Even after secondary store is brought back up after being down for few hours,snapshot jobs do not get triggered with reason there is other active snapshot tasks on the instance to which the volume is attached --- Key: CLOUDSTACK-5446 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5446 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: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: edison su Fix For: 4.4.0, 4.5.0 Attachments: agentdown.rar, ssdown.rar KVM - Secondary Store down - Even after secondary store is brought back up after being down for few hours , snapshot jobs do not get triggered with reason here is other active snapshot tasks on the instance to which the volume is attached, please try again later Set up: Advanced Zone set up with 2 KVM (RHEL 6.3) hosts. Steps to reproduce the problem: 1. Deploy 5 Vms in each of the hosts with 10 GB ROOT volume size , so we start with 10 Vms. 2. Start concurrent snapshots for ROOT volumes of all the Vms. 3. Shutdown the Secondary storage server when the snapshots are in the progress. 4. Bring the Secondary storage server up after ~ 12 hours. When the secondary storage was down: The snapshot jobs that were in progress timed out after 6 hours. Even after this , I do not see the hourly snapshots being scheduled due to the following reason: 2013-12-10 13:07:49,285 WARN [c.c.s.s.SnapshotSchedulerImpl] (SnapshotPollTask:ctx-cf0775f7) Scheduling snapshot failed due to com.cloud.utils.exception.CloudRuntimeException: There is other active snapshot tasks on the instance to which the volume is attached, please try again later Even after the secondary storage was brought up , there is no hourly snapshots being scheduled due to the same reason - com.cloud.utils.exception.CloudRuntimeException: There is other active snapshot tasks on the instance to which the volume is attached, please try again later mysql select * FROM snapshots; ++++---+---+--+--+--+-+--+---+--+-+-+-++--++--+-+-+---+ | id | data_center_id | account_id | domain_id | volume_id | disk_offering_id | status | path | name| uuid | snapshot_type | type_description | size| created | removed | backup_snap_id | swift_id | sechost_id | prev_snap_id | hypervisor_type | version | s3_id | ++++---+---+--+--+--+-+--+---+--+-+-+-++--++--+-+-+---+ | 1 | 1 | 6 | 1 |45 | 18 | BackedUp | NULL | TestVM-tiny-host-0ps-0-0_ROOT-45_20131209234410 | ee2c46b7-7623-439a-9a30-63eec1d95c56 | 3 | HOURLY | 21474836480 | 2013-12-09 23:44:10 | NULL| NULL | NULL | NULL | NULL | KVM | 2.2 | NULL | | 2 | 1 | 6 | 1 |43 | 18 | BackedUp | NULL | TestVM-1_ROOT-43_20131209234410 | 62c01389-49df-475b-b225-617d3903d25a | 3 | HOURLY | 21474836480 | 2013-12-09 23:44:10 |
[jira] [Commented] (CLOUDSTACK-6945) Null pointer exception when starting a VM that had its template deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226605#comment-14226605 ] Rohit Yadav commented on CLOUDSTACK-6945: - Is this issue fixed already? Can anyone update on this? Null pointer exception when starting a VM that had its template deleted --- Key: CLOUDSTACK-6945 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6945 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: Hosts are Debian 7.4.0 with Xen hypervisor e Xen Cloud Platform packages installed and properly configured. Reporter: Rafael Weingartner Priority: Critical Fix For: 4.5.0, 4.4.3, 4.3.2 It seems that you have a bug in CS 4.3.0(and probably previous versions?) when starting a machine that was created from a template that has been deleted. There will happen a null pointer exception in com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart: “858 -if (volTemplateId != null volTemplateId.longValue() != template.getId())” The object, “template” is going to be null, because in: “811 - VirtualMachineTemplate template = _entityMgr.findById(VirtualMachineTemplate.class, vm.getTemplateId());” The findById, will add a where clause, looking for template that have the column removed that is null, therefore It will return a null object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5576) RemoteVPNonVPC : Label needs to be changed to Enable Remote Access VPN
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226600#comment-14226600 ] ASF subversion and git services commented on CLOUDSTACK-5576: - Commit 6cd4b289b2d73359152a4bf53b74edee8e725384 in cloudstack's branch refs/heads/4.3 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6cd4b28 ] CLOUDSTACK-5576: UI IP Address EnableVPN, DisableVPN: change label. (cherry picked from commit e796d418b4ff7d3644bcc962b796d929b3d7baf7) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: ui/scripts/network.js RemoteVPNonVPC : Label needs to be changed to Enable Remote Access VPN - Key: CLOUDSTACK-5576 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5576 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Chandan Purushothama Assignee: Jessica Wang Priority: Minor Labels: DEVREV Fix For: 4.5.0 Attachments: 2014-10-17-jessica1.jpg, 2014-10-17-jessica2.jpg, UICapture38.png The corresponding UI Screenshot has been attached to the bug report. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6850) Cpu cores, cpu speed and memory are not returned by listUsageRecords
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226608#comment-14226608 ] Rohit Yadav commented on CLOUDSTACK-6850: - Hi [~olemasle] can you help backport your fix to 4.3 branch as well, thanks. Cpu cores, cpu speed and memory are not returned by listUsageRecords Key: CLOUDSTACK-6850 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6850 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.3.0, 4.4.0 Reporter: Olivier Lemasle Assignee: Olivier Lemasle Priority: Critical Fix For: 4.4.0 When using dynamic custom offerings, cpu cores, cpu speed and ram values are recorded in usage_vm_instance table while parsing the usage events. But these details are not populated in cloud_usage table, and are not returned by the listUsageRecords command. Therefore, there is no way to know the historical values for cpu and memory using API. We should add cpu_cores, cpu_speed and memory in cloud_usage.cloud_usage and return them in listUsageRecords response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6177) CS does XS master switch, which may cause weird XS behavior
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226609#comment-14226609 ] Rohit Yadav commented on CLOUDSTACK-6177: - Hi [~xuefei...@citrix.com] Anthony, can you help backport this to 4.3 branch? Thanks. CS does XS master switch, which may cause weird XS behavior --- Key: CLOUDSTACK-6177 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6177 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.3.0 Environment: XS 6.2 with CS 4.3.0 Reporter: Anthony Xu Assignee: Anthony Xu Priority: Critical Fix For: 4.5.0 When XS master is down, CS uses pool-emergency-transition-to-master and pool-recover-slaves API to choose a new master, this API is not safe, and should be only used in emergent situation, this API may cause XS use a little bit old(5 minutes old) version of XS DB, some of object may be missing in the old XS DB, which may cause weird behavior, you may not be able to start VM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5997) Template state changes side affects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226612#comment-14226612 ] Rohit Yadav commented on CLOUDSTACK-5997: - [~nitinme] I think part of the fix are applicable for 4.3.x, if so can you help backport them to 4.3 branch? Thanks. Template state changes side affects --- Key: CLOUDSTACK-5997 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5997 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Fix For: 4.4.0 Template state change functionality. A state has been introduced for vm_template. It reflects the user action for making template active/inactive for further use. When the template is marked inactive it becomes unusable for the entire cloud. If the user wants to make it as inactive for a particular zone, template_zone_ref would be accordingly reflected. Admin listing should still be able to see the inactive templates. The intent of the removed flag is to capture the system state meaning whether it has been physically removed from the cloud. The garbage collection thread checks the inactive state of the template and deletes it physically from sec. storage when no vm is referencing this template anymore. It also deletes it from PS. This is when the removed flag is set in the vm_template table. At the moment this functionality doesn't exist in CS so the removed flag is never set as of now. Things that need to be fixed Deleting the template by user for a particular zone should mark the removed flag in template zone ref only. It should mark the template as inactive if its there is no other zone carrying it. Deleting the template without any zone should mark it as inactive right away. Removed flag is not set and there shouldn't be any code setting it at the moment (Delete template shouldn't mark the removed flag.) Start showing the state in the api. Regular users should see only active templates but admins should be able to see active/inactive templates Template Sync. Should start using active/inactive state than the removed flag. Show removed functionality introduced for CPBM would be fixed automatically when admin sees the inactive state - Any template code referencing the removed flag from vm_template should use the active/inactive flag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5834) [upgrade]Error while collecting disk stats from : You gave an invalid object reference. The object may have recently been deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226613#comment-14226613 ] Rohit Yadav commented on CLOUDSTACK-5834: - Hi [~anthonyxu], can you help backport this fix to 4.3 branch? I have seen such errors many times, it would be great if we can fix it for 4.3.2. [upgrade]Error while collecting disk stats from : You gave an invalid object reference. The object may have recently been deleted -- Key: CLOUDSTACK-5834 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5834 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, XenServer Affects Versions: 4.3.0 Reporter: prashant kumar mishra Assignee: Anthony Xu Fix For: 4.4.0, 4.5.0 Attachments: MS_XEN_log_DB.rar Steps == 1-prepare ACS 4.2 setup with xen6.2 host 2-upgrade CS to 4.3 and upgrade xen 6.2 to xen6.2sp1 After upgrade i am seeing error message in log whenever VmStatsCollector is running. Logs == 2014-01-08 13:15:08,182 DEBUG [c.c.s.StatsCollector] (StatsCollector-2:ctx-aa75b506) VmStatsCollector is running... 2014-01-08 13:15:08,207 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-141:ctx-74d0d04a) Seq 1-498139202: Executing request 2014-01-08 13:15:08,358 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-141:ctx-74d0d04a) Vm cpu utilization 0.0 2014-01-08 13:15:08,359 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-141:ctx-74d0d04a) Vm cpu utilization 0.00453125 2014-01-08 13:15:08,369 WARN [c.c.h.x.r.CitrixResourceBase] (DirectAgent-141:ctx-74d0d04a) Error while collecting disk stats from : You gave an invalid object reference. The object may have recently been deleted. The class parameter gives the type of reference given, and the handle parameter echoes the bad value given. at com.xensource.xenapi.Types.checkResponse(Types.java:209) at com.xensource.xenapi.Connection.dispatch(Connection.java:368) at com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909) at com.xensource.xenapi.VBDMetrics.getIoReadKbs(VBDMetrics.java:210) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.getVmStats(CitrixResourceBase.java:2784) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:2684) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:493) at com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59) at com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) 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) 2014-01-08 13:15:08,371 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-141:ctx-74d0d04a) Seq 1-498139202: Response Received: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5812) Secondary ip allocation in Basic zone - the pod is not respected
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226615#comment-14226615 ] Rohit Yadav commented on CLOUDSTACK-5812: - Hi [~alena1108], can you help backport this to 4.3 branch? Thanks. Secondary ip allocation in Basic zone - the pod is not respected Key: CLOUDSTACK-5812 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5812 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Critical Fix For: 4.4.0 After reviewing sec ip for nic code, found out that the pod information is not respected when do secondary ip Allocation in Basic zone. We should always pass pod info when request for the new ip, otherwise you might end up with the nic having ips from different pods, which is not acceptable in Basic zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5597) attachVolume shouldn't create the volume on the primary storage if the vm's root volume is not created yet
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226616#comment-14226616 ] Rohit Yadav commented on CLOUDSTACK-5597: - Hi [~alena1108], can you please help backport this to 4.3 branch? Thanks. attachVolume shouldn't create the volume on the primary storage if the vm's root volume is not created yet -- Key: CLOUDSTACK-5597 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5597 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 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Fix For: 4.4.0 In cloudStack you can deploy a vm w/o actually starting it on the backend (startVm=false parameter should be passed to deployVm call to trigger this behavior). When vm is not started during the original deployment, its ROOT volume is not created either. It stays in Allocated state in the DB. Bug: when try to attach data disk to such a vm, current CS code creates it on the primary storage. The fix should be: when check to see if the volume needs to be created on the primary storage, validate the Vm's Root volume state. And if its Allocated, don't create it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5324) error message not proper when start VM fails because router requires upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226622#comment-14226622 ] Rohit Yadav commented on CLOUDSTACK-5324: - Hi [~kishan], can you please help backport this to 4.3 branch? Thanks. error message not proper when start VM fails because router requires upgrade - Key: CLOUDSTACK-5324 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5324 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.3.0 Reporter: shweta agarwal Assignee: Kishan Kavala Fix For: 4.4.0, 4.5.0 Repro steps: Create a VM on 3.07 setup Upgrade to 4.3.0 but dont upgrade routers Stop user VM Start user VM Bug: Error message shows Unable to start a VM due to concurrent operation Expectation : Error message should show router requires upgrade MS log snippet : 2013-12-02 12:28:09,029 ERROR [c.c.v.VirtualMachineManagerImpl] (Job-Executor-9:ctx-1bf286cd ctx-4cabd091) Failed to start instance VM[User|f01ae0d5-23b3-44c4-9e8d-9df9245874be] com.cloud.utils.exception.CloudRuntimeException: Router requires upgrade. Unable to send command to router:4 at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.sendCommandsToRouter(VirtualNetworkApplianceManagerImpl.java:3437) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl$7.execute(VirtualNetworkApplianceManagerImpl.java:2873) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3722) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyDhcpEntry(VirtualNetworkApplianceManagerImpl.java:2865) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:622) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy239.applyDhcpEntry(Unknown Source) at com.cloud.network.element.VirtualRouterElement.addDhcpEntry(VirtualRouterElement.java:914) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1171) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1293) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1229) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:899) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:552) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:236) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3465) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:1921) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:622) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at
[jira] [Commented] (CLOUDSTACK-5685) [Vmsync] - When VR is rebooted outside of cloudstack , there is no change in state detected by cloudstack resulting in VR not bieng programmed with any rules.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226620#comment-14226620 ] Rohit Yadav commented on CLOUDSTACK-5685: - Hi [~nitinme], is this applicable to 4.3, if you have any idea around this component can you please help backport it to 4.3 branch? Thanks. [Vmsync] - When VR is rebooted outside of cloudstack , there is no change in state detected by cloudstack resulting in VR not bieng programmed with any rules. -- Key: CLOUDSTACK-5685 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5685 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: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Kelven Yang Fix For: 4.4.0 [Vmsync] - When VR is rebooted outside of cloudstack , there is no change in state detected by cloudstack resulting in VR not being programmed with any rules. PreReq: Have few Vms deployed using Cloudstack. Have PF,Static NAT,LB and Egress rules programmed for the Vms. Steps: Outside of Cloudstack, Reboot VR. After the successful reboot of VR , there are no rules being programmed in the VR for the Vms. Currently , VM sync does not detect any change of state in the router when router is rebooted. So there is no way for CS to know that the router needs to be reprogrammed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7974) deleted host entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-7974: Fix Version/s: 4.3.2 4.4.3 4.4.2 4.6.0 4.5.0 deleted host entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router -- Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang Fix For: 4.5.0, 4.6.0, 4.4.2, 4.4.3, 4.3.2 We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7951) cloudstack-agent jsvc gets too large virtual memory space.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rohit Yadav resolved CLOUDSTACK-7951.
-
Resolution: Fixed
Assignee: Rohit Yadav
Fixed on 4.3, 4.4, 4.5 and master branches.
cloudstack-agent jsvc gets too large virtual memory space.
--
Key: CLOUDSTACK-7951
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7951
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.3.0
Environment: - Builds up with 155 physical machines and a cloudstack
server.
- Each physical machine equips these.
+ Xeon E5-2680 (10 cores, 20 threads).
+ 128GB memory (and is not set swap space).
+ 600GB Solid State Drive.
- All physical machines are networked by InfiniBand and 10GBase-T.
- Using CentOS6.6 (64bit)
Reporter: Keiichi Yusa
Assignee: Rohit Yadav
Priority: Critical
Fix For: Future, 4.5.0, 4.6.0, 4.4.3, 4.3.2
cloudstack-agent jsvc gets too large virtual memory space on huge
memory equipped machine.
We have 155 physical machines that each is equipped 128GB RAM and
is installed CentOS6.6 (64bit). On these physical machines, I use
KVM as hypervisor.
I create Compute Offering with 120GB RAM and I deploy VM with this
Compute Offering on this environment.
Now, I have a problem that qemu-kvm process often fails deploying VM
in the above conditions. I confirm that the following message is
outputted in /var/log/libvirt/qemu/i-X-X-VM.log.
{noformat}
Cannot set up guest memory 'pc.ram': Cannot allocate memory
{noformat}
I find that cloudstack-agent jsvc gets virtual memory about 35GB.
{noformat}
$ top -a
(snip)
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
5787 root 20 0 34.9g 667m 18m S 0.0 0.5 8:45.20 jsvc
(snip)
{noformat}
I suspect that this failure is caused by what cloudstack-agent jsvc
gets too large virtual memory.
I try to patch /etc/init.d/cloudstack-agent as follows:
{noformat}
@@ -66,7 +66,7 @@
start() {
echo -n $Starting $PROGNAME:
if hostname --fqdn /dev/null 21 ; then
-$JSVC -cp $CLASSPATH -pidfile $PIDFILE \
+$JSVC -Xms1024m -Xmx2048m -cp $CLASSPATH -pidfile $PIDFILE \
-errfile $LOGDIR/cloudstack-agent.err -outfile
$LOGDIR/cloudstack-agent.out $CLASS
RETVAL=$?
echo
{noformat}
Then, I restart cloudstack-agent.
As a result, cloudstack agent jsvc reduces virtual memory about 6GB.
Also, qemu-kvm process does not fail deploying VM for now.
{noformat}
$ top -a
(snip)
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
141405 root 20 0 6290m 393m 18m S 0.0 0.3 1:11.44 jsvc
(snip)
{noformat}
If that helps, our CloudStack environment is as follows:
{noformat}
- Builds up with 155 physical machines and a cloudstack server.
- Each physical machine equips these.
+ Xeon E5-2680 (10 cores, 20 threads)
+ 128GB memory (and is not set swap space).
+ 600GB Solid State Drive.
- All physical machines are networked by InfiniBand and 10GBase-T.
- Using CentOS6.6 (64bit)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7291) LXC: Mgmt server/agent keeps killing systemvms
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-7291: Fix Version/s: (was: 4.3.2) LXC: Mgmt server/agent keeps killing systemvms -- Key: CLOUDSTACK-7291 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7291 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.3.1 Reporter: Rohit Yadav Followed installation and setup docs of 4.3, was unable to get LXC to work on Ubuntu 14.04/trusty. The systemvms kept coming up and result from ssvm_check.sh was good and it was able to reach mgmt server /host, even then mgmt server complained that it was unable to contact agent on the systemvm (ping), while the agent would gracefully shutdown the systemvm (by killing them). Relevant log: 2014-08-07 19:52:26,294 INFO [c.c.u.e.CSExceptionErrorCode] (secstorage-1:ctx-fc57ef43) Could not find exception: com.cloud.exception.OperationTimedoutException in error code list for exceptions 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host Host[-1-Routing] 2014-08-07 19:52:26,295 DEBUG [c.c.a.m.AgentAttache] (consoleproxy-1:ctx-e123fa9c) Seq 1-51249205: Cancelling. 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host Host[-1-Routing] 2014-08-07 19:52:26,303 DEBUG [c.c.h.Status] (AgentTaskPool-13:ctx-0b35e679) Transition:[Resource state = Enabled, Agent event = ShutdownRequested, Host id = 1, name = bluebox1.bhaisaab.org] 2014-08-07 19:52:26,311 DEBUG [c.c.h.HighAvailabilityManagerImpl] (secstorage-1:ctx-fc57ef43) Scheduled HAWork[12-CheckStop-2-Starting-Scheduled] 2014-08-07 19:52:26,314 WARN [c.c.s.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-fc57ef43) Exception while trying to start secondary storage vm com.cloud.exception.AgentUnavailableException: Resource [Host:1] is unreachable: Host 1: Unable to start s-2-VM ---at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1051) ---at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761) ---at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:745) ---at com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:261) ---at com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:694) ---at com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1278) ---at com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:123) ---at com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:50) ---at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111) ... ... ... Caused by: com.cloud.exception.OperationTimedoutException: Commands 51249206 to Host 1 timed out after 3600 ---at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:439) ---at com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:394) ---at com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:920) ---at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:989) ---... 24 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7291) LXC: Mgmt server/agent keeps killing systemvms
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav resolved CLOUDSTACK-7291. - Resolution: Won't Fix LXC is better supported in 4.5, 4.3's implementation is not production quality. LXC related issues are better fixed in 4.5 or above since 4.3/4.4 don't officially support LXC for production. LXC: Mgmt server/agent keeps killing systemvms -- Key: CLOUDSTACK-7291 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7291 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.3.1 Reporter: Rohit Yadav Followed installation and setup docs of 4.3, was unable to get LXC to work on Ubuntu 14.04/trusty. The systemvms kept coming up and result from ssvm_check.sh was good and it was able to reach mgmt server /host, even then mgmt server complained that it was unable to contact agent on the systemvm (ping), while the agent would gracefully shutdown the systemvm (by killing them). Relevant log: 2014-08-07 19:52:26,294 INFO [c.c.u.e.CSExceptionErrorCode] (secstorage-1:ctx-fc57ef43) Could not find exception: com.cloud.exception.OperationTimedoutException in error code list for exceptions 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host Host[-1-Routing] 2014-08-07 19:52:26,295 DEBUG [c.c.a.m.AgentAttache] (consoleproxy-1:ctx-e123fa9c) Seq 1-51249205: Cancelling. 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host Host[-1-Routing] 2014-08-07 19:52:26,303 DEBUG [c.c.h.Status] (AgentTaskPool-13:ctx-0b35e679) Transition:[Resource state = Enabled, Agent event = ShutdownRequested, Host id = 1, name = bluebox1.bhaisaab.org] 2014-08-07 19:52:26,311 DEBUG [c.c.h.HighAvailabilityManagerImpl] (secstorage-1:ctx-fc57ef43) Scheduled HAWork[12-CheckStop-2-Starting-Scheduled] 2014-08-07 19:52:26,314 WARN [c.c.s.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-fc57ef43) Exception while trying to start secondary storage vm com.cloud.exception.AgentUnavailableException: Resource [Host:1] is unreachable: Host 1: Unable to start s-2-VM ---at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1051) ---at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761) ---at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:745) ---at com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:261) ---at com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:694) ---at com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1278) ---at com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:123) ---at com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:50) ---at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111) ... ... ... Caused by: com.cloud.exception.OperationTimedoutException: Commands 51249206 to Host 1 timed out after 3600 ---at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:439) ---at com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:394) ---at com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:920) ---at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:989) ---... 24 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7974) deleted host entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yiping Zhang updated CLOUDSTACK-7974: - Description: We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. I did a bit more digging on virtual router, and immediately noticed the following: 1. /root/edithosts.sh script is only called when an instance is created, but not when an instance is destroyed. 2. After reading /root/edithosts.sh script, I am pretty certain that the function of this script is to add info about newly created instances into /etc/hosts and /etc/dhcphosts.txt files. So the script should really be renamed as /root/addhosts.sh to reflect its true function. 3. there is no script to properly delete entries from /etc/hosts and /etc/dhcphosts.txt file when instances are destroyed was: We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. deleted host entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router -- Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang Fix For: 4.5.0, 4.6.0, 4.4.2, 4.4.3, 4.3.2 We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. I did a bit more digging on virtual router, and immediately noticed the following: 1. /root/edithosts.sh script is only called when an instance is created, but not when an instance is destroyed. 2. After reading /root/edithosts.sh script, I am pretty certain that the function of this script is to add info about newly created instances into /etc/hosts and /etc/dhcphosts.txt files. So the script should really be renamed as /root/addhosts.sh to reflect its true function. 3. there is no script to properly delete entries from /etc/hosts and /etc/dhcphosts.txt file when instances are destroyed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5834) [upgrade]Error while collecting disk stats from : You gave an invalid object reference. The object may have recently been deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226670#comment-14226670 ] Vincent Vuong commented on CLOUDSTACK-5834: --- We also noticed when the above error is present, the statistic for each VM instance stops working. The statistics for each VM instance displays N/A. [upgrade]Error while collecting disk stats from : You gave an invalid object reference. The object may have recently been deleted -- Key: CLOUDSTACK-5834 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5834 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, XenServer Affects Versions: 4.3.0 Reporter: prashant kumar mishra Assignee: Anthony Xu Fix For: 4.4.0, 4.5.0 Attachments: MS_XEN_log_DB.rar Steps == 1-prepare ACS 4.2 setup with xen6.2 host 2-upgrade CS to 4.3 and upgrade xen 6.2 to xen6.2sp1 After upgrade i am seeing error message in log whenever VmStatsCollector is running. Logs == 2014-01-08 13:15:08,182 DEBUG [c.c.s.StatsCollector] (StatsCollector-2:ctx-aa75b506) VmStatsCollector is running... 2014-01-08 13:15:08,207 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-141:ctx-74d0d04a) Seq 1-498139202: Executing request 2014-01-08 13:15:08,358 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-141:ctx-74d0d04a) Vm cpu utilization 0.0 2014-01-08 13:15:08,359 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-141:ctx-74d0d04a) Vm cpu utilization 0.00453125 2014-01-08 13:15:08,369 WARN [c.c.h.x.r.CitrixResourceBase] (DirectAgent-141:ctx-74d0d04a) Error while collecting disk stats from : You gave an invalid object reference. The object may have recently been deleted. The class parameter gives the type of reference given, and the handle parameter echoes the bad value given. at com.xensource.xenapi.Types.checkResponse(Types.java:209) at com.xensource.xenapi.Connection.dispatch(Connection.java:368) at com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909) at com.xensource.xenapi.VBDMetrics.getIoReadKbs(VBDMetrics.java:210) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.getVmStats(CitrixResourceBase.java:2784) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:2684) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:493) at com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59) at com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) 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) 2014-01-08 13:15:08,371 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-141:ctx-74d0d04a) Seq 1-498139202: Response Received: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6850) Cpu cores, cpu speed and memory are not returned by listUsageRecords
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226780#comment-14226780 ] Olivier Lemasle commented on CLOUDSTACK-6850: - Hi [~bhaisaab], this fix requires a database model modification (3 additional columns in table `cloud_usage`.`cloud_usage`). Is it really possible to backport it to 4.3? Because if the db model for 4.3 is changed now, I guess that the update to 4.4 will not work anymore... Cpu cores, cpu speed and memory are not returned by listUsageRecords Key: CLOUDSTACK-6850 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6850 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.3.0, 4.4.0 Reporter: Olivier Lemasle Assignee: Olivier Lemasle Priority: Critical Fix For: 4.4.0 When using dynamic custom offerings, cpu cores, cpu speed and ram values are recorded in usage_vm_instance table while parsing the usage events. But these details are not populated in cloud_usage table, and are not returned by the listUsageRecords command. Therefore, there is no way to know the historical values for cpu and memory using API. We should add cpu_cores, cpu_speed and memory in cloud_usage.cloud_usage and return them in listUsageRecords response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4200) listSystemVMs API and listRouters API fail to return hypervisor property
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226887#comment-14226887 ] ASF subversion and git services commented on CLOUDSTACK-4200: - Commit 837a17b3da8e419143a9d6ee9ad67c69deebdb0b in cloudstack's branch refs/heads/master from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=837a17b ] Revert VM detail view: Disable 'change service offering' action per CLOUDSTACK-4200 This reverts commit 73087bc3ffed4200e4e0a298b9e5539e248449a1. listSystemVMs API and listRouters API fail to return hypervisor property - Key: CLOUDSTACK-4200 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4200 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.5.0 listSystemVMs API and listRouters API doesn't return hypervisor property and this is important for scalevm operation, since its not implemented for all the hypervisors -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7968) [Automation] ListVirtualMachines failed due to NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-7968:
---
Assignee: Min Chen
[Automation] ListVirtualMachines failed due to NPE
--
Key: CLOUDSTACK-7968
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7968
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
==
NullPointer Exception:
==
{noformat}
2014-11-25 07:02:04,577 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-3c4583df) ===START=== 10.220.135.158 -- GET
apiKey=cZnc5GpyJx80LGvhVhQMwdCSfoIyzyVRq1F4lRjI00w1xrAgCOTAZWpxgtARH_JNID8RSYjGnJalpQcy5u1Xfgcommand=listVirtualMachinessignature=5T4zh0Tv4tnLOFRwNn8DRghnJkA%3Dtags%5B0%5D.key=region111response=jsonlistall=Truetags%5B0%5D.value=India
2014-11-25 07:02:04,600 ERROR [c.c.a.ApiServer]
(catalina-exec-22:ctx-3c4583df ctx-8f125542 ctx-2cc1f4d0) unhandled exception
executing api command: [Ljava.lang.String;@7bf2b28
com.cloud.utils.exception.CloudRuntimeException: Caught:
com.mysql.jdbc.JDBC4PreparedStatement@235185cf: SELECT
DISTINCT(user_vm_view.id) FROM user_vm_view WHERE user_vm_view.account_type
!= 5 AND user_vm_view.display_vm = 1 AND ( ( AND ) ) AND
user_vm_view.removed IS NULL ORDER BY user_vm_view.id ASC LIMIT 0, 1
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:427)
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:361)
at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:345)
at
com.cloud.utils.db.GenericDaoBase.searchAndCount(GenericDaoBase.java:1296)
at sun.reflect.GeneratedMethodAccessor132.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy175.searchAndCount(Unknown Source)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMsInternal(QueryManagerImpl.java:996)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMs(QueryManagerImpl.java:756)
at
org.apache.cloudstack.api.command.user.vm.ListVMsCmd.execute(ListVMsCmd.java:227)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:691)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:514)
at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:276)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:120)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:117)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:79)
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
[jira] [Created] (CLOUDSTACK-7975) Add RHEL 6.5 support
Amogh Vasekar created CLOUDSTACK-7975: - Summary: Add RHEL 6.5 support Key: CLOUDSTACK-7975 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7975 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Amogh Vasekar Assignee: Amogh Vasekar Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7975) Add RHEL 6.5 support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226940#comment-14226940 ] Amogh Vasekar commented on CLOUDSTACK-7975: --- Fixed in commit 3d6635a537ca33e6d8d2643c768e31742c001f99 Add RHEL 6.5 support Key: CLOUDSTACK-7975 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7975 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Amogh Vasekar Assignee: Amogh Vasekar Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7975) Add RHEL 6.5 support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amogh Vasekar resolved CLOUDSTACK-7975. --- Resolution: Fixed Add RHEL 6.5 support Key: CLOUDSTACK-7975 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7975 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Amogh Vasekar Assignee: Amogh Vasekar Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7976) Add validation for global params consoleproxy.url.domain and secstorage.cert.domain
Amogh Vasekar created CLOUDSTACK-7976: - Summary: Add validation for global params consoleproxy.url.domain and secstorage.cert.domain Key: CLOUDSTACK-7976 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7976 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Amogh Vasekar Assignee: Amogh Vasekar Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7976) Add validation for global params consoleproxy.url.domain and secstorage.cert.domain
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226945#comment-14226945 ] ASF subversion and git services commented on CLOUDSTACK-7976: - Commit 95ea20390739a24dad92895b8db712282be31bbb in cloudstack's branch refs/heads/master from [~amogh.vasekar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=95ea203 ] CLOUDSTACK-7976 : Param validation for global params involving domain name Add validation for global params consoleproxy.url.domain and secstorage.cert.domain --- Key: CLOUDSTACK-7976 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7976 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Amogh Vasekar Assignee: Amogh Vasekar Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7976) Add validation for global params consoleproxy.url.domain and secstorage.cert.domain
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amogh Vasekar resolved CLOUDSTACK-7976. --- Resolution: Fixed Add validation for global params consoleproxy.url.domain and secstorage.cert.domain --- Key: CLOUDSTACK-7976 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7976 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Amogh Vasekar Assignee: Amogh Vasekar Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7976) Add validation for global params consoleproxy.url.domain and secstorage.cert.domain
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226948#comment-14226948 ] Amogh Vasekar commented on CLOUDSTACK-7976: --- Parent commit 86895ec13c11bdf4dc1feab0a3dfa003e02fde12 Add validation for global params consoleproxy.url.domain and secstorage.cert.domain --- Key: CLOUDSTACK-7976 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7976 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Amogh Vasekar Assignee: Amogh Vasekar Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7977) Password generator adds 3 characters to length. Should also have minimum length
Amogh Vasekar created CLOUDSTACK-7977: - Summary: Password generator adds 3 characters to length. Should also have minimum length Key: CLOUDSTACK-7977 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7977 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Amogh Vasekar Assignee: Amogh Vasekar Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7977) Password generator adds 3 characters to length. Should also have minimum length
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amogh Vasekar resolved CLOUDSTACK-7977. --- Resolution: Fixed Password generator adds 3 characters to length. Should also have minimum length --- Key: CLOUDSTACK-7977 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7977 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Amogh Vasekar Assignee: Amogh Vasekar Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7977) Password generator adds 3 characters to length. Should also have minimum length
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14226976#comment-14226976 ] ASF subversion and git services commented on CLOUDSTACK-7977: - Commit 960b7bbf742bbba62cd25bc62b700c6c829e35f2 in cloudstack's branch refs/heads/master from [~amogh.vasekar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=960b7bb ] CLOUDSTACK-7977 Fix password generator, add guards for minimum length Password generator adds 3 characters to length. Should also have minimum length --- Key: CLOUDSTACK-7977 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7977 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Amogh Vasekar Assignee: Amogh Vasekar Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7978) [Automation] Fix the script test_egress_rules.py - Zone Network Type Information should to be passed to VirtualMachine create method
Chandan Purushothama created CLOUDSTACK-7978: Summary: [Automation] Fix the script test_egress_rules.py - Zone Network Type Information should to be passed to VirtualMachine create method Key: CLOUDSTACK-7978 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7978 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 Currently, test cases in the test suite do not pass the Zone Network Type to the Virtual Machine class create method. This doesn't cause any problem with majority of the configurations except EIP-ELB Configuration. Hence Zone Network Type Information should be passed consciously to the create method to cover EIP-ELB Configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7979) [Automation] Fix the script test_security_groups.py - Zone Network Type Information should to be passed to VirtualMachine create method
Chandan Purushothama created CLOUDSTACK-7979: Summary: [Automation] Fix the script test_security_groups.py - Zone Network Type Information should to be passed to VirtualMachine create method Key: CLOUDSTACK-7979 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7979 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 Currently, test cases in the test suite do not pass the Zone Network Type to the Virtual Machine class create method. This doesn't cause any problem with majority of the configurations except EIP-ELB Configuration. Hence Zone Network Type Information should be passed consciously to the create method to cover EIP-ELB Configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7980) [Automation] Fix the script maint/test_egress_rules_host_maintenance.py - Zone Network Type Information should to be passed to VirtualMachine create method
Chandan Purushothama created CLOUDSTACK-7980: Summary: [Automation] Fix the script maint/test_egress_rules_host_maintenance.py - Zone Network Type Information should to be passed to VirtualMachine create method Key: CLOUDSTACK-7980 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7980 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 Currently, test cases in the test suite do not pass the Zone Network Type to the Virtual Machine class create method. This doesn't cause any problem with majority of the configurations except EIP-ELB Configuration. Hence Zone Network Type Information should be passed consciously to the create method to cover EIP-ELB Configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7978) [Automation] Fix the script test_egress_rules.py - Zone Network Type Information should to be passed to VirtualMachine create method
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227063#comment-14227063 ] ASF subversion and git services commented on CLOUDSTACK-7978: - Commit b81cf5eab19a00b12c2c39c105442f8c12d5cd82 in cloudstack's branch refs/heads/master from [~chandanp] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b81cf5e ] CLOUDSTACK-7978 : Fixed the script 'test_egress_rules.py' - Zone Network Type Information should to be passed to VirtualMachine create method [Automation] Fix the script test_egress_rules.py - Zone Network Type Information should to be passed to VirtualMachine create method -- Key: CLOUDSTACK-7978 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7978 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 Currently, test cases in the test suite do not pass the Zone Network Type to the Virtual Machine class create method. This doesn't cause any problem with majority of the configurations except EIP-ELB Configuration. Hence Zone Network Type Information should be passed consciously to the create method to cover EIP-ELB Configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7980) [Automation] Fix the script maint/test_egress_rules_host_maintenance.py - Zone Network Type Information should to be passed to VirtualMachine create method
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227065#comment-14227065 ] ASF subversion and git services commented on CLOUDSTACK-7980: - Commit d5761ea65ba6cffecc2f79af2b76cbce380a4547 in cloudstack's branch refs/heads/master from [~chandanp] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d5761ea ] CLOUDSTACK-7980 : Fixed the script '/maint/test_egress_rules_host_maintenance.py' - Zone Network Type Information should to be passed to VirtualMachine create method [Automation] Fix the script maint/test_egress_rules_host_maintenance.py - Zone Network Type Information should to be passed to VirtualMachine create method - Key: CLOUDSTACK-7980 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7980 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 Currently, test cases in the test suite do not pass the Zone Network Type to the Virtual Machine class create method. This doesn't cause any problem with majority of the configurations except EIP-ELB Configuration. Hence Zone Network Type Information should be passed consciously to the create method to cover EIP-ELB Configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7979) [Automation] Fix the script test_security_groups.py - Zone Network Type Information should to be passed to VirtualMachine create method
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227064#comment-14227064 ] ASF subversion and git services commented on CLOUDSTACK-7979: - Commit 4f8799315f71e30ce9edf1e10b39d1bb433ae36b in cloudstack's branch refs/heads/master from [~chandanp] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4f87993 ] CLOUDSTACK-7979 : Fixed the script 'test_security_groups.py' - Zone Network Type Information should to be passed to VirtualMachine create method [Automation] Fix the script test_security_groups.py - Zone Network Type Information should to be passed to VirtualMachine create method - Key: CLOUDSTACK-7979 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7979 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 Currently, test cases in the test suite do not pass the Zone Network Type to the Virtual Machine class create method. This doesn't cause any problem with majority of the configurations except EIP-ELB Configuration. Hence Zone Network Type Information should be passed consciously to the create method to cover EIP-ELB Configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7981) listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view
Min Chen created CLOUDSTACK-7981: Summary: listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view Key: CLOUDSTACK-7981 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7981 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.1 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Deploy 40 to 50 VMs, each one has 3-4 resource tags, and each one also add about 10 details, then do a listVMCmd, the performance is very slow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7981) listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227113#comment-14227113 ] ASF subversion and git services commented on CLOUDSTACK-7981: - Commit 4e7af26c9fcdb3914c577c743fd83c8f7b8ef424 in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4e7af26 ] CLOUDSTACK-7981: listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view. listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view Key: CLOUDSTACK-7981 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7981 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.1 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Deploy 40 to 50 VMs, each one has 3-4 resource tags, and each one also add about 10 details, then do a listVMCmd, the performance is very slow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7981) listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227122#comment-14227122 ] ASF subversion and git services commented on CLOUDSTACK-7981: - Commit bf8dd828f5c9f9ade42eb17e812d0579478c5467 in cloudstack's branch refs/heads/4.5 from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bf8dd82 ] CLOUDSTACK-7981: listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view. listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view Key: CLOUDSTACK-7981 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7981 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.1 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Deploy 40 to 50 VMs, each one has 3-4 resource tags, and each one also add about 10 details, then do a listVMCmd, the performance is very slow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7981) listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227123#comment-14227123 ] Min Chen commented on CLOUDSTACK-7981: -- we should not join user_vm_details table in user_vm_view at all since our code never used them, we always find details from user_vm_details table directly. Also, handle duplicate resource tag entry by avoiding retrieving duplicate tags. listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view Key: CLOUDSTACK-7981 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7981 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.1 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Deploy 40 to 50 VMs, each one has 3-4 resource tags, and each one also add about 10 details, then do a listVMCmd, the performance is very slow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7981) listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7981. -- Resolution: Fixed listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view Key: CLOUDSTACK-7981 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7981 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.1 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Deploy 40 to 50 VMs, each one has 3-4 resource tags, and each one also add about 10 details, then do a listVMCmd, the performance is very slow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5511) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227166#comment-14227166 ] Sebb commented on CLOUDSTACK-5511: -- Please can someone from the PMC take responsibilty for fixing this? Thanks. Please delete old releases from mirroring system Key: CLOUDSTACK-5511 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5511 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Environment: https://dist.apache.org/repos/dist/release/cloudstack/releases/ Reporter: Sebb To reduce the load on the ASF mirrors, projects are required to delete old releases [1] Please can you remove all non-current releases? Thanks! [Note that older releases are always available from the ASF archive server] Any links to older releases on download pages should first be adjusted to point to the archive server. [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7974) deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy updated CLOUDSTACK-7974: -- Summary: deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router (was: deleted host entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router) deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang Fix For: 4.5.0, 4.6.0, 4.4.2, 4.4.3, 4.3.2 We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. I did a bit more digging on virtual router, and immediately noticed the following: 1. /root/edithosts.sh script is only called when an instance is created, but not when an instance is destroyed. 2. After reading /root/edithosts.sh script, I am pretty certain that the function of this script is to add info about newly created instances into /etc/hosts and /etc/dhcphosts.txt files. So the script should really be renamed as /root/addhosts.sh to reflect its true function. 3. there is no script to properly delete entries from /etc/hosts and /etc/dhcphosts.txt file when instances are destroyed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7974) deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227252#comment-14227252 ] Jayapal Reddy commented on CLOUDSTACK-7974: --- Are there any issues seen with the entries for a deleted VM in the dhcphosts.txt file ? The edithosts.sh script deletes the matching entries before adding into dhcphosts.txt. There is no specific script to delete. -Jayapal deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang Fix For: 4.5.0, 4.6.0, 4.4.2, 4.4.3, 4.3.2 We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. I did a bit more digging on virtual router, and immediately noticed the following: 1. /root/edithosts.sh script is only called when an instance is created, but not when an instance is destroyed. 2. After reading /root/edithosts.sh script, I am pretty certain that the function of this script is to add info about newly created instances into /etc/hosts and /etc/dhcphosts.txt files. So the script should really be renamed as /root/addhosts.sh to reflect its true function. 3. there is no script to properly delete entries from /etc/hosts and /etc/dhcphosts.txt file when instances are destroyed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
