[jira] [Updated] (CLOUDSTACK-7460) [LXC][RHEl7] Agent installaion fails if Management server is already installed on the same machine
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damodar Reddy T updated CLOUDSTACK-7460: Fix Version/s: (was: 4.5.0) > [LXC][RHEl7] Agent installaion fails if Management server is already > installed on the same machine > -- > > Key: CLOUDSTACK-7460 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7460 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup, KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Damodar Reddy T > > Repro steps: > on rhel 7 Machine. First install MS and try installing Agent on the same > machine > Bug: > Agent installation will fail with following error : > Transaction check error: > file /var/log/cloudstack/agent from install of > cloudstack-agent-4.5.0-SNAPSHOT.el7.x86_64 conflicts with file from package > cloudstack-management-4.5.0-SNAPSHOT.el7.x86_64 > Error Summary > - > Done -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7249) Enable Password Strength check for all users
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damodar Reddy T updated CLOUDSTACK-7249: Fix Version/s: (was: 4.5.0) Future > Enable Password Strength check for all users > > > Key: CLOUDSTACK-7249 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7249 > 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: Damodar Reddy T >Assignee: Damodar Reddy T > Fix For: Future > > > Currently we do not show the password strength of a user for his chosen > password int he API response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6834) [Windows] Feedback Items
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damodar Reddy T updated CLOUDSTACK-6834: Fix Version/s: (was: 4.5.0) Future > [Windows] Feedback Items > > > Key: CLOUDSTACK-6834 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6834 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: Future >Reporter: Damodar Reddy T >Assignee: Damodar Reddy T > Fix For: Future > > > The feed back items received internally. > 1. Need to add more fields to the database creation wizard > 2. Remove Complete Option > 3. Some description changes words like CloudStack etc > 4. Change Default installation location if possible include version number > 5. Mysql Connector Installer along with other dependecies > 6. Add run Service Checkbox > 7. Add ReadMe checkbox > 8. If possible enable logs for Custom Actions that are executed as part of > installation -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7142) Coverity Issues fixes and better error messages
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damodar Reddy T updated CLOUDSTACK-7142: Fix Version/s: (was: 4.5.0) Future > Coverity Issues fixes and better error messages > --- > > Key: CLOUDSTACK-7142 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7142 > 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: Damodar Reddy T >Assignee: Damodar Reddy T >Priority: Minor > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6105) Windowsfication of CloudStack Management Server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damodar Reddy T updated CLOUDSTACK-6105: Fix Version/s: (was: 4.5.0) Future > Windowsfication of CloudStack Management Server > --- > > Key: CLOUDSTACK-6105 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6105 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Damodar Reddy T >Assignee: Damodar Reddy T > Labels: features > Fix For: Future > > > Currently Management Server runs on Linux based operating systems. Though it > runs on windows under cygwin terminal, there is a need to run it on windows > without dependency on cygwin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6703) [Windows] Try to install as a normal java service (Spawn a java thread)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damodar Reddy T updated CLOUDSTACK-6703: Fix Version/s: (was: 4.5.0) Future > [Windows] Try to install as a normal java service (Spawn a java thread) > --- > > Key: CLOUDSTACK-6703 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6703 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.5.0 >Reporter: Damodar Reddy T >Assignee: Damodar Reddy T > Fix For: Future > > > 1, Currently it is started as s tomcat service. Instead of that try to spawn > a java thread service > 2. Try to add Cloud stack Version some where in the service name or in the > registry keys -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6704) [Windows] Localization of the windows installer
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damodar Reddy T updated CLOUDSTACK-6704: Fix Version/s: (was: 4.5.0) Future > [Windows] Localization of the windows installer > --- > > Key: CLOUDSTACK-6704 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6704 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.0 >Reporter: Damodar Reddy T >Assignee: Damodar Reddy T > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5616) [DBHA]:There is no way to know to which DB is the CS writing in the case of DBHA.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damodar Reddy T updated CLOUDSTACK-5616: Fix Version/s: (was: 4.4.0) Future > [DBHA]:There is no way to know to which DB is the CS writing in the case of > DBHA. > - > > Key: CLOUDSTACK-5616 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5616 > 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: Kiran Koneti >Assignee: Damodar Reddy T > Fix For: Future > > > At any instance of time we never know to which database (either M1 or M2) is > the CS writing the db changes changes. > This creates some problems at the customer environment like > 1)The customer doesn't have chance to go for maintenance or manual do a > switch over from one db to other if he has some network maintenance to > perform. > 2)There is no chance to check whether the db switch over has happened from > the slave to master after the db.cloud.secondsBeforeRetryMaster interval if > the master comes back by this time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-6664) support Docker as a new hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197971#comment-14197971 ] Kambiz Darabi edited comment on CLOUDSTACK-6664 at 11/5/14 9:20 AM: I would also be interested to know the current status and whether there is anything I could contribute. was (Author: darabi): Linked to Wiki Design Document > support Docker as a new hypervisor > -- > > Key: CLOUDSTACK-6664 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6664 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: Future >Reporter: tuna >Assignee: tuna > Fix For: Future > > > Supporting Docker as a new hypervisor, which can spawn containers from > Dockerfile, Docker image or Docker tar file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7808) Typo in Zone Creation Wizard
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihaela Stoica resolved CLOUDSTACK-7808. Resolution: Fixed Fix Version/s: (was: 4.5.0) 4.6.0 > Typo in Zone Creation Wizard > > > Key: CLOUDSTACK-7808 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7808 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.1 >Reporter: Gabor Apati-Nagy >Assignee: Gabor Apati-Nagy >Priority: Minor > Fix For: 4.6.0 > > > Steps to reproduce: > 1. Go to the New Zone creation wizard > 2. In Step 3 (Setup Network, Pod) look at the reference text on the upper > part of the box. > There is a typo in the text: "CloudStack\'s" is shown instead of > "CloudStack's". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7840) UI control tip for 'Add Primary Storage' -> 'Provider' seems wrong
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihaela Stoica resolved CLOUDSTACK-7840. Resolution: Fixed Fix Version/s: (was: 4.5.0) 4.6.0 > UI control tip for 'Add Primary Storage' -> 'Provider' seems wrong > -- > > Key: CLOUDSTACK-7840 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7840 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Gabor Apati-Nagy >Assignee: Gabor Apati-Nagy >Priority: Minor > Fix For: 4.6.0 > > > The Control Tip that is displayed when the user opens the 'Add Primary > Storage' dialog and then clicks on 'Provider' doesn't seem to be correct - it > seems to be the text that is displayed when selecting a Zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7838) UI - Update category names on Resources tab of a Zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihaela Stoica resolved CLOUDSTACK-7838. Resolution: Fixed Fix Version/s: (was: 4.5.0) 4.6.0 > UI - Update category names on Resources tab of a Zone > - > > Key: CLOUDSTACK-7838 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7838 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: pre-4.0.0 >Reporter: Gabor Apati-Nagy >Assignee: Gabor Apati-Nagy > Fix For: 4.6.0 > > > Make the wordings better on the Resources tab of a Zone. > "Storage" -> "Primary Storage Used" > "CPU" -> "CPU allocated" > Memory -> "Memory Allocated" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7841) Existed connections are disconnected when update load balancer configuration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198178#comment-14198178 ] ASF subversion and git services commented on CLOUDSTACK-7841: - Commit c15ed74f63559dca7692cfcfe695e195c3401454 in cloudstack's branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c15ed74 ] CLOUDSTACK-7841: Gracefully reload haproxy config The old way would disconnect all the existing connections through haproxy when reload the config. This new way would ensure that all the existing connections would still alive after reload the config. > Existed connections are disconnected when update load balancer configuration > > > Key: CLOUDSTACK-7841 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7841 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.5.0 > > > Applying load balancer rules breaks existing connections and causes short > outage. > That's because our currently logic of handling haproxy reload configuration > is not graceful enough, and focused on how to recover from failed newly > configuration. > There would be a way to improve this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7242) adding a Secure config using the new ConfigDepot and ConfigKey breaks the build when encryption is enabled
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198179#comment-14198179
]
ASF subversion and git services commented on CLOUDSTACK-7242:
-
Commit c3e5964dcbbd3b3ff34562aeeb9f8daa154ee7d1 in cloudstack's branch
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c3e5964 ]
Fixed CLOUDSTACK-7242: Adding a securing config using configDepo doesnt work
In ConfigurationVo, changed the setter to do the encryption if required
like the getter. Called the setter in constructor as well.
Removed references of encryption check in different places.
Reviewed-by: Santhosh Edukulla
This closes #35
> adding a Secure config using the new ConfigDepot and ConfigKey breaks the
> build when encryption is enabled
> --
>
> Key: CLOUDSTACK-7242
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7242
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.5.0
>
>
> In the inner layers, when it get the value of the key it tries to do decrypt
> if its a secure or hidden field. But, it doesn’t encrypt while adding the
> config.
> Here is code snippet from ConfigurationVO
> {noformat}
>@Override
> public String getValue() {
> return (("Hidden".equals(getCategory()) ||
> "Secure".equals(getCategory())) ? DBEncryptionUtil.decrypt(value) : value);
> }
> public void setValue(String value) {
> this.value = value;
> }
> {noformat}
> we should make the getter and setter consistent. Otherwise, you won’t be able
> to introduce any new secure/hidden configs unless you put the encrypted value
> in the db before.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7800) integration.smoke.test_nic.TestNic.test_01_nic fails on VMware when vmware tools are not installed on VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198180#comment-14198180 ] ASF subversion and git services commented on CLOUDSTACK-7800: - Commit 2cd4ad201adbee3ad75dd57d8196b633cdd0494b in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2cd4ad2 ] CLOUDSTACK-7800: Correcting code related to unplug NIC on VMware Signed-off-by: SrikanteswaraRao Talluri > integration.smoke.test_nic.TestNic.test_01_nic fails on VMware when vmware > tools are not installed on VM > > > Key: CLOUDSTACK-7800 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7800 > 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 > > > Starting vCenter 5.5 it has been made strict that hot unplug requires vmware > tools installed on the guest os. > Our code base currently does not have a check for vmware tools installed on > the guest os, so we can go ahead and do hot plug/unplug. But VMware will > report error if the vmtools are not installed. > The tests that are trying hot plug and unplug of nic on vms running on > vmware, must check for vmware tools running on the vm. > if the vm does not have tools => assert true for the exception (assert for > exception is better option). > if vm has vm tools running => Then only try for plug/unplug of nic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7837) [UI] CIDR field not completely visible in multi-edit view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198190#comment-14198190 ] ASF subversion and git services commented on CLOUDSTACK-7837: - Commit 6490694231cb1184011b8504cb118ba73fe6cdc1 in cloudstack's branch refs/heads/4.5 from [~mihaelas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6490694 ] CLOUDSTACK-7837: [UI] Make the Source CIDR column wide enough to fit the CIDR value without ellipsizing Signed-off-by: Rajani Karuturi > [UI] CIDR field not completely visible in multi-edit view > - > > Key: CLOUDSTACK-7837 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7837 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0, 4.4.0, 4.5.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica >Priority: Minor > Attachments: IssueFixed.png, screenshot-1.png > > > Network - Guest networks > IP Addresses > Configuration > Firewall (available > for Advanced Networks only): > The Source CIDR field is not completely visible. > We should make the column wide enough to fit the CIDR value without > ellipsizing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-6224) VM Snapshot inconsistent size
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal reopened CLOUDSTACK-6224: I tried to verify the bug . Bug is still not fixed. I created a VM on vmware 5.1 with a template of size 2GB and data disk of size 5GB . Then i created a VM snapshot of this VM When usage is generated for the VM snapshot the usage for root disk is only 37KB , for data disk usage was fine. > VM Snapshot inconsistent size > - > > Key: CLOUDSTACK-6224 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6224 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server >Affects Versions: 4.2.1 > Environment: Cloudstack 4.2.1 > XenServer 6.2 > Vcenter 5.5 ESXi >Reporter: Artjoms Petrovs >Assignee: Mike Tutkowski > Labels: snapshot, vmware, xen > Fix For: 4.4.0 > > > During the creation of VM Snapshot [VMware], resulting size is written in > table „volumes”, column vm_snapshot_chain_size. It seems that size of a VM > Snapshot is calculated manually via the method getVMSnapshotChainSize(..) > and it gives overexpected result ( hundreds of terabytes ) and is much larger > than the filesize, that we can see in VMware itself. By calculating the vmdk > and vmsn file sizes manually. Xen VM snapshots [disks only] give similar > results. For me it seems that either the method works incorrectly, either it > loops between some simlinks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7837) [UI] CIDR field not completely visible in multi-edit view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198216#comment-14198216 ] ASF subversion and git services commented on CLOUDSTACK-7837: - Commit 6490694231cb1184011b8504cb118ba73fe6cdc1 in cloudstack's branch refs/heads/master from [~mihaelas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6490694 ] CLOUDSTACK-7837: [UI] Make the Source CIDR column wide enough to fit the CIDR value without ellipsizing Signed-off-by: Rajani Karuturi > [UI] CIDR field not completely visible in multi-edit view > - > > Key: CLOUDSTACK-7837 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7837 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0, 4.4.0, 4.5.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica >Priority: Minor > Attachments: IssueFixed.png, screenshot-1.png > > > Network - Guest networks > IP Addresses > Configuration > Firewall (available > for Advanced Networks only): > The Source CIDR field is not completely visible. > We should make the column wide enough to fit the CIDR value without > ellipsizing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7837) [UI] CIDR field not completely visible in multi-edit view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198217#comment-14198217 ] ASF subversion and git services commented on CLOUDSTACK-7837: - Commit 083feab7c0e680239328a0b38eb9d202bb44284a in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=083feab ] Merge branch '4.5' * 4.5: CLOUDSTACK-7837: [UI] Make the Source CIDR column wide enough to fit the CIDR value without ellipsizing > [UI] CIDR field not completely visible in multi-edit view > - > > Key: CLOUDSTACK-7837 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7837 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0, 4.4.0, 4.5.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica >Priority: Minor > Attachments: IssueFixed.png, screenshot-1.png > > > Network - Guest networks > IP Addresses > Configuration > Firewall (available > for Advanced Networks only): > The Source CIDR field is not completely visible. > We should make the column wide enough to fit the CIDR value without > ellipsizing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7837) [UI] CIDR field not completely visible in multi-edit view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-7837. - Resolution: Fixed > [UI] CIDR field not completely visible in multi-edit view > - > > Key: CLOUDSTACK-7837 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7837 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0, 4.4.0, 4.5.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica >Priority: Minor > Attachments: IssueFixed.png, screenshot-1.png > > > Network - Guest networks > IP Addresses > Configuration > Firewall (available > for Advanced Networks only): > The Source CIDR field is not completely visible. > We should make the column wide enough to fit the CIDR value without > ellipsizing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7842) wrong size column is getting updated with snapshot physical size in snapshot_store_ref table.
Sanjay Tripathi created CLOUDSTACK-7842: --- Summary: wrong size column is getting updated with snapshot physical size in snapshot_store_ref table. Key: CLOUDSTACK-7842 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7842 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Priority: Critical Fix For: 4.5.0 "size" column instead of "physical_size" is getting updated with physical size of snapshots. Also, update the "size" column with virtual size of snapshots. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7842) wrong size column is getting updated with snapshot physical size in snapshot_store_ref table.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198222#comment-14198222 ] ASF subversion and git services commented on CLOUDSTACK-7842: - Commit b8441552400e7372950ef2d64c4a73d7ccc27460 in cloudstack's branch refs/heads/master from [~sanjay.tripathi] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b844155 ] CLOUDSTACK-7842: Wrong size column is getting updated with snapshot physical size in snapshot_store_ref table. Also fixed the issue that snapshot size with hypervisor XS >= 6.2.5 is not getting updated in snapshot_store_ref table. > wrong size column is getting updated with snapshot physical size in > snapshot_store_ref table. > - > > Key: CLOUDSTACK-7842 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7842 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0 >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi >Priority: Critical > Fix For: 4.5.0 > > > "size" column instead of "physical_size" is getting updated with physical > size of snapshots. > Also, update the "size" column with virtual size of snapshots. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7842) wrong size column is getting updated with snapshot physical size in snapshot_store_ref table.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198225#comment-14198225 ] ASF subversion and git services commented on CLOUDSTACK-7842: - Commit 5a67fe73697be5254884294f151cf6e375bc00d6 in cloudstack's branch refs/heads/4.5 from [~sanjay.tripathi] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5a67fe7 ] CLOUDSTACK-7842: wrong size column is getting updated with snapshot physical size in snapshot_store_ref table. Also fixed the issue that snapshot size with hypervisor XS >= 6.2.5 is not getting updated in snapshot_store_ref table. > wrong size column is getting updated with snapshot physical size in > snapshot_store_ref table. > - > > Key: CLOUDSTACK-7842 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7842 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0 >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi >Priority: Critical > Fix For: 4.5.0 > > > "size" column instead of "physical_size" is getting updated with physical > size of snapshots. > Also, update the "size" column with virtual size of snapshots. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7842) wrong size column is getting updated with snapshot physical size in snapshot_store_ref table.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi resolved CLOUDSTACK-7842. - Resolution: Fixed > wrong size column is getting updated with snapshot physical size in > snapshot_store_ref table. > - > > Key: CLOUDSTACK-7842 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7842 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0 >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi >Priority: Critical > Fix For: 4.5.0 > > > "size" column instead of "physical_size" is getting updated with physical > size of snapshots. > Also, update the "size" column with virtual size of snapshots. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7837) [UI] CIDR field not completely visible in multi-edit view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihaela Stoica updated CLOUDSTACK-7837: --- Fix Version/s: 4.5.0 > [UI] CIDR field not completely visible in multi-edit view > - > > Key: CLOUDSTACK-7837 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7837 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0, 4.4.0, 4.5.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica >Priority: Minor > Fix For: 4.5.0 > > Attachments: IssueFixed.png, screenshot-1.png > > > Network - Guest networks > IP Addresses > Configuration > Firewall (available > for Advanced Networks only): > The Source CIDR field is not completely visible. > We should make the column wide enough to fit the CIDR value without > ellipsizing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7843) sync Job Failures always reported as success on Event Bus
Damodar Reddy T created CLOUDSTACK-7843:
---
Summary: sync Job Failures always reported as success on Event Bus
Key: CLOUDSTACK-7843
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7843
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.4.0
Reporter: Damodar Reddy T
Assignee: Damodar Reddy T
Fix For: 4.5.0
For example, addition of nic to a VM is failed. Management log files show this
as failed.
{ "queryasyncjobresultresponse" :
{"accountid":"eddeb7f4-dbc5-11e3-b9c8-9e300504069a","userid":"eddf0399-dbc5-11e3-b9c8-9e300504069a","cmd":"org.apache.cloudstack.api.command.user.vm.AddNicToVMCmd","jobstatus":2,"jobprocstatus":0,"jobresultcode":530,"jobresulttype":"object","jobresult":{"errorcode":530,"errortext":"A
NIC already exists for VM:i-615-879-VM in network:
fe60e938-c186-4dda-a37c-732ac66fd381"},"created":"2014-09-15T16:06:48-0400","jobid":"34dd7fb6-d350-430d-ae35-5f63d0986d4a"}
}
But in event bus it shows as the job is success.
"management-server.AsyncJobEvent.complete.None.*"
"
{\"instanceType\":\"None\",\"jobId\":\"34dd7fb6-d350-430d-ae35-5f63d0986d4a\",\"processStatus\":\"0\",\"commandEventType\":\"NIC.CREATE\",\"resultCode\":\"0\",\"command\":\"org.apache.cloudstack.api.command.user.vm.AddNicToVMCmd\",\"account\":\"eddeb7f4-dbc5-11e3-b9c8-9e300504069a\",\"user\":\"eddf0399-dbc5-11e3-b9c8-9e300504069a\"}"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7822) test SSL cert expired
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198541#comment-14198541
]
ASF subversion and git services commented on CLOUDSTACK-7822:
-
Commit ddb2d9c60ebf121109392f202a724920137256b7 in cloudstack's branch
refs/heads/4.5 from pdion891
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ddb2d9c ]
CLOUDSTACK-7822: merge, test sslcert ca
> test SSL cert expired
> -
>
> Key: CLOUDSTACK-7822
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7822
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Test
>Affects Versions: 4.4.0, 4.5.0, 4.4.1
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Minor
> Fix For: 4.5.0
>
>
> Building from source (apache-cloudstack-4.4.1-src.tar.bz2) fail to build
> using {{mvn install}} or package.sh due to test ssl cert that are expired.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-245) VPC ACLs are not stored and programmed consistently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-245: -- Fix Version/s: 4.5.0 > VPC ACLs are not stored and programmed consistently > --- > > Key: CLOUDSTACK-245 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-245 > 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 >Reporter: David Noland >Assignee: Kishan Kavala >Priority: Minor > Fix For: 4.4.0, 4.5.0 > > > If user specifies 1.2.3.4/24 as the CIDR for an ACL the firewall rule is > being programmed as 1.2.3.0/24. Both CIDRs are correct, but it's inconsistent > to store one thing in the database and program the firewall using another > rule. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-245) VPC ACLs are not stored and programmed consistently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-245: -- Assignee: Kishan Kavala > VPC ACLs are not stored and programmed consistently > --- > > Key: CLOUDSTACK-245 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-245 > 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 >Reporter: David Noland >Assignee: Kishan Kavala >Priority: Minor > Fix For: 4.4.0, 4.5.0 > > > If user specifies 1.2.3.4/24 as the CIDR for an ACL the firewall rule is > being programmed as 1.2.3.0/24. Both CIDRs are correct, but it's inconsistent > to store one thing in the database and program the firewall using another > rule. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3607) "guest_os_hypervisor" table has values that are not registered in "guest_os" table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-3607: --- Assignee: Chandan Purushothama > "guest_os_hypervisor" table has values that are not registered in "guest_os" > table > -- > > Key: CLOUDSTACK-3607 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3607 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: Chandan Purushothama >Assignee: Chandan Purushothama > Fix For: 4.4.0 > > > mysql> select * from guest_os_hypervisor where guest_os_id not in (select id > from guest_os); > +-+-++-+ > | id | hypervisor_type | guest_os_name | guest_os_id | > +-+-++-+ > | 128 | VmWare | Red Hat Enterprise Linux 6(32-bit) | 204 | > | 129 | VmWare | Red Hat Enterprise Linux 6(64-bit) | 205 | > +-+-++-+ > 2 rows in set (0.07 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-315) Infrastructure view does not show capacity values
[ https://issues.apache.org/jira/browse/CLOUDSTACK-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-315: -- Fix Version/s: 4.5.0 > Infrastructure view does not show capacity values > - > > Key: CLOUDSTACK-315 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-315 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.1.0, 4.2.0 > Environment: master branch >Reporter: Rohit Yadav >Assignee: Min Chen >Priority: Minor > Fix For: 4.4.0, 4.5.0 > > > Goto Infrastructure, it won't post a GET request to get list of capacities, > no. of hosts, zones, routers etc.; and fails to show any capacity values. > This was observed on master branch, > head=16fa74b7293039db75fdc6851c35e194b33f2135. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6320) Upgrade 4.1.1 -> 4.3.0 OVS provider should be inserted to the physical network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-6320: --- Assignee: Kishan Kavala > Upgrade 4.1.1 -> 4.3.0 OVS provider should be inserted to the physical network > -- > > Key: CLOUDSTACK-6320 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6320 > 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: Upgrading from CS 4.1.1 to CS 4.3.0, using Xenserver > 6.1.0 > Advanced zone with GRE isolation is configured before upgrade. >Reporter: Florin Dumitrascu >Assignee: Kishan Kavala > Fix For: 4.4.0, 4.5.0 > > > When you create an Advanced zone in 4.3 code, server-side will > automatically add OVS provider to its physical network. > However, since your zone was created in 4.1 code and upgraded to 4.3, > server-side won't automatically add OVS provider to its physical network. > Full message thread: > -Original Message- > From: Alena Prokharchyk > Sent: Friday, March 21, 2014 4:18 PM > To: Jessica Wang; Florin Dumitrascu; Murali Reddy > Cc: Nguyen Anh Tu (t...@apache.org); d...@cloudstack.apache.org > Subject: Re: GRE isolation - no in service upgrade (4.1.1 to 4.3.0) - Is your > zone an Advanced zone or Basic zone? (2) > Then its a DB upgrade bug. If the GRE isolation is supported on the network > in 4.1.1, DB upgrade should have inserted the provider to physical network. > On 3/21/14, 3:51 PM, "Jessica Wang" wrote: > >> [Alena] Not exactly like that. > >> [Alena] None of the providers are added to the physical network by > >>default if execute createPhysicalNetwork call via API. > >> [Alena] Our CS UI does this job - adding the providers to the network > >>- for you by calling addNetworkServiceProvider call. > > > >Actually, OVS provider is an exception. > >UI doesn't do the job because server-side already does the job. > >When you create an Advanced zone in 4.3 code, server-side will > >automatically add OVS provider to its physical network. > >However, since your zone was created in 4.1 code and upgraded to 4.3, > >server-side won't automatically add OVS provider to its physical network. > > > >Murali, please confirm. > > > > > > > >-Original Message- > >From: Alena Prokharchyk > >Sent: Friday, March 21, 2014 2:44 PM > >To: Florin Dumitrascu; Jessica Wang; Murali Reddy; Florin Dumitrascu > >Cc: Nguyen Anh Tu (t...@apache.org); d...@cloudstack.apache.org > >Subject: Re: GRE isolation - no in service upgrade (4.1.1 to 4.3.0) - > >Is your zone an Advanced zone or Basic zone? (2) > > > > > > > >On 3/21/14, 2:34 PM, "Florin Dumitrascu" > > wrote: > > > >>Hi, > >> > >>Alena, my assumption is that the Ovs provider is created when you > >>create the physical network with GRE isolation (if someone can confirm ...). > >>When I configured CS RC8 from scratch, I could see the provider and > >>enable it in the GUI. > > > >Not exactly like that. None of the providers are added to the physical > >network by default if execute createPhysicalNetwork call via API. Our > >CS UI does this job - adding the providers to the network - for you by > >calling addNetworkServiceProvider call. > > > > > > > >>But when I have upgraded from CS 4.1.1 to 4.3.0 RC9, I have preserved > >>the existing configuration with the existing physical network. > >>So my assumption is that the physical network was not updated with the > >>OVS provider (such a provider was not needed in CS 4.1.1). > > > >So while you were on 4.1.1, GRE isolation was disabled? Did you enable > >it on 4.3? If there is a way to enable new isolation on the physical > >network, on my opinion - the UI should perform the background call and > >add all the providers associated with this option, to the physical > >network. So it would be a UI issue. > > > >Or the case was the following - the GRE isolation was enabled on your > >network while on 4.1.1, but new provider - OVS - was added in 4.3. And > >this provider wasn't added to existing physical networks during the > >upgrade. Then its a database upgrade bug. > > > > > >Please confirm which one from the above is correct. > > > >> > >>Jessica, I am building CentOS RPM packages from the RC source, using > >>"package.sh" script in the source packaging folder. Not aware about > >>the difference between "oss" and "noredist". > >>Also, my setup is for an advanced zone. > >> > >>Kind Regards, > >>Florin > >> > >> > >> > >>-Original Message- > >>From: Jessica Wang [mailto:jessica.w...@citrix.com] > >>Sent: Friday, March 21, 2014 8:28 PM > >>To: Florin Dumitrascu; Murali Reddy > >>Cc: Nguyen Anh Tu (t...@apach
[jira] [Updated] (CLOUDSTACK-3607) "guest_os_hypervisor" table has values that are not registered in "guest_os" table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-3607: --- Fix Version/s: 4.5.0 > "guest_os_hypervisor" table has values that are not registered in "guest_os" > table > -- > > Key: CLOUDSTACK-3607 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3607 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: Chandan Purushothama >Assignee: Chandan Purushothama > Fix For: 4.4.0, 4.5.0 > > > mysql> select * from guest_os_hypervisor where guest_os_id not in (select id > from guest_os); > +-+-++-+ > | id | hypervisor_type | guest_os_name | guest_os_id | > +-+-++-+ > | 128 | VmWare | Red Hat Enterprise Linux 6(32-bit) | 204 | > | 129 | VmWare | Red Hat Enterprise Linux 6(64-bit) | 205 | > +-+-++-+ > 2 rows in set (0.07 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6320) Upgrade 4.1.1 -> 4.3.0 OVS provider should be inserted to the physical network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-6320: --- Fix Version/s: 4.5.0 > Upgrade 4.1.1 -> 4.3.0 OVS provider should be inserted to the physical network > -- > > Key: CLOUDSTACK-6320 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6320 > 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: Upgrading from CS 4.1.1 to CS 4.3.0, using Xenserver > 6.1.0 > Advanced zone with GRE isolation is configured before upgrade. >Reporter: Florin Dumitrascu >Assignee: Kishan Kavala > Fix For: 4.4.0, 4.5.0 > > > When you create an Advanced zone in 4.3 code, server-side will > automatically add OVS provider to its physical network. > However, since your zone was created in 4.1 code and upgraded to 4.3, > server-side won't automatically add OVS provider to its physical network. > Full message thread: > -Original Message- > From: Alena Prokharchyk > Sent: Friday, March 21, 2014 4:18 PM > To: Jessica Wang; Florin Dumitrascu; Murali Reddy > Cc: Nguyen Anh Tu (t...@apache.org); d...@cloudstack.apache.org > Subject: Re: GRE isolation - no in service upgrade (4.1.1 to 4.3.0) - Is your > zone an Advanced zone or Basic zone? (2) > Then its a DB upgrade bug. If the GRE isolation is supported on the network > in 4.1.1, DB upgrade should have inserted the provider to physical network. > On 3/21/14, 3:51 PM, "Jessica Wang" wrote: > >> [Alena] Not exactly like that. > >> [Alena] None of the providers are added to the physical network by > >>default if execute createPhysicalNetwork call via API. > >> [Alena] Our CS UI does this job - adding the providers to the network > >>- for you by calling addNetworkServiceProvider call. > > > >Actually, OVS provider is an exception. > >UI doesn't do the job because server-side already does the job. > >When you create an Advanced zone in 4.3 code, server-side will > >automatically add OVS provider to its physical network. > >However, since your zone was created in 4.1 code and upgraded to 4.3, > >server-side won't automatically add OVS provider to its physical network. > > > >Murali, please confirm. > > > > > > > >-Original Message- > >From: Alena Prokharchyk > >Sent: Friday, March 21, 2014 2:44 PM > >To: Florin Dumitrascu; Jessica Wang; Murali Reddy; Florin Dumitrascu > >Cc: Nguyen Anh Tu (t...@apache.org); d...@cloudstack.apache.org > >Subject: Re: GRE isolation - no in service upgrade (4.1.1 to 4.3.0) - > >Is your zone an Advanced zone or Basic zone? (2) > > > > > > > >On 3/21/14, 2:34 PM, "Florin Dumitrascu" > > wrote: > > > >>Hi, > >> > >>Alena, my assumption is that the Ovs provider is created when you > >>create the physical network with GRE isolation (if someone can confirm ...). > >>When I configured CS RC8 from scratch, I could see the provider and > >>enable it in the GUI. > > > >Not exactly like that. None of the providers are added to the physical > >network by default if execute createPhysicalNetwork call via API. Our > >CS UI does this job - adding the providers to the network - for you by > >calling addNetworkServiceProvider call. > > > > > > > >>But when I have upgraded from CS 4.1.1 to 4.3.0 RC9, I have preserved > >>the existing configuration with the existing physical network. > >>So my assumption is that the physical network was not updated with the > >>OVS provider (such a provider was not needed in CS 4.1.1). > > > >So while you were on 4.1.1, GRE isolation was disabled? Did you enable > >it on 4.3? If there is a way to enable new isolation on the physical > >network, on my opinion - the UI should perform the background call and > >add all the providers associated with this option, to the physical > >network. So it would be a UI issue. > > > >Or the case was the following - the GRE isolation was enabled on your > >network while on 4.1.1, but new provider - OVS - was added in 4.3. And > >this provider wasn't added to existing physical networks during the > >upgrade. Then its a database upgrade bug. > > > > > >Please confirm which one from the above is correct. > > > >> > >>Jessica, I am building CentOS RPM packages from the RC source, using > >>"package.sh" script in the source packaging folder. Not aware about > >>the difference between "oss" and "noredist". > >>Also, my setup is for an advanced zone. > >> > >>Kind Regards, > >>Florin > >> > >> > >> > >>-Original Message- > >>From: Jessica Wang [mailto:jessica.w...@citrix.com] > >>Sent: Friday, March 21, 2014 8:28 PM > >>To: Florin Dumitrascu; Murali Reddy > >>Cc: Nguyen Anh Tu (t...@apache.o
[jira] [Updated] (CLOUDSTACK-5836) When tried to reverting back to (disk attached)quiesced vm snapshot, got error at logs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ram Ganesh updated CLOUDSTACK-5836:
---
Fix Version/s: 4.5.0
> When tried to reverting back to (disk attached)quiesced vm snapshot, got
> error at logs
> --
>
> Key: CLOUDSTACK-5836
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5836
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, Snapshot
>Affects Versions: 4.3.0
> Environment: cloudstack 4.3,vm snapshot
>Reporter: rashid
>Assignee: edison su
> Fix For: 4.4.0, 4.5.0
>
>
> Environment: There is a vm with attached disk. When tried to revert back to
> older vm snapshot then I saw the below error message in log &
> • VM did not stop
> • At notification it says “successfull” & No GUI error message
> Manually powered off and powered on the vm and verified that Vm has been
> successfully reverted.
> But , why vm did not get powered off by itself?
> PLease check the below logs
> INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-41:ctx-5711a5dd) Add job-93
> into job monitoring INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-42:ctx-b7e47685) Add job-94 into job monitoring INFO
> [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-43:ctx-7c2d7cd2) Add job-93 into
> job monitoring INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-42:ctx-b7e47685) Remove job-94 from job monitoring WARN
> [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-43:ctx-7c2d7cd2) job-93 is
> scheduled for wakeup run, but there is no joining info anymore ERROR
> [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-43:ctx-7c2d7cd2) Unable to
> find a wakeup dispatcher from the joined job: AsyncJobVO {id:93, userId: 2,
> accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.vmsnapshot.RevertToVMSnapshotCmd,
> cmdInfo:
> {"response":"json","sessionkey":"LAwQEgGPTl8PlWexb67vz8P8SoU\u003d","cmdEventType":"VMSNAPSHOT.REVERTTO","ctxUserId":"2","httpmethod":"GET","vmsnapshotid":"4b1ea7b0-7274-4d35-bfd8-d1f151eabe3e","_":"1389095290252","ctxAccountId":"2","ctxStartEventId":"119"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 345052565034, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Tue Jan 07 06:48:10 EST 2014} INFO
> [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-43:ctx-7c2d7cd2) Remove job-93
> from job monitoring INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-41:ctx-5711a5dd) Remove job-93 from job monitoring INFO
> [c.c.h.HighAvailabilityManagerImpl] (HA-2:ctx-943a466a) checking health of
> usage server
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5800) While creating a VM from template (which is created based on existing newly created vm) getting error as Unable to deploy vm base on template due to of insufficient
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-5800: --- Assignee: edison su > While creating a VM from template (which is created based on existing newly > created vm) getting error as Unable to deploy vm base on template due to of > insufficient server capicity > - > > Key: CLOUDSTACK-5800 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5800 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, XenServer >Affects Versions: 4.3.0 > Environment: CENTOS 6.4,WIN2012,ACS 4.3.0, >Reporter: rashid >Assignee: edison su > Fix For: 4.4.0, 4.5.0 > > > While creating a vm from template > INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-5:ctx-c259052d) Add job-46 > into job monitoring > INFO [o.a.c.s.v.VolumeServiceImpl] (Job-Executor-5:ctx-c259052d > ctx-506ea49e) lock is acquired for VMTemplateStoragePool 7 > WARN [o.a.c.alerts] (CapacityChecker:ctx-374c70b5) alertType:: 24 // > dataCenterId:: 1 // podId:: null // clusterId:: null // message:: System > Alert: Number of unallocated shared network IPs is low in availability zone > NEWZONE > WARN [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-32c31ce6) Task (job-45) has > been pending for 104 seconds > WARN [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-32c31ce6) Task (job-46) has > been pending for 103 seconds > WARN [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-92c2ed53) Task (job-45) has > been pending for 164 seconds > WARN [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-92c2ed53) Task (job-46) has > been pending for 163 seconds > WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) > destoryVDIbyNameLabel failed due to there are 0 VDIs with name > cloud-377c12f4-a8e9-491a-8cba-34b9532455f8 > WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) > failed to set hidden to 0 > /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd > WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) > Catch Exception com.cloud.utils.exception.CloudRuntimeException for template > + due to com.cloud.utils.exception.CloudRuntimeException: failed to set > hidden to 0 > /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd > com.cloud.utils.exception.CloudRuntimeException: failed to set hidden to 0 > /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd > at > com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copy_vhd_from_secondarystorage(XenServerStorageProcessor.java:858) > at > com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copyTemplateToPrimaryStorage(XenServerStorageProcessor.java:928) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:75) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:50) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:609) > 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$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoo
[jira] [Updated] (CLOUDSTACK-5800) While creating a VM from template (which is created based on existing newly created vm) getting error as Unable to deploy vm base on template due to of insufficient
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-5800: --- Fix Version/s: 4.5.0 > While creating a VM from template (which is created based on existing newly > created vm) getting error as Unable to deploy vm base on template due to of > insufficient server capicity > - > > Key: CLOUDSTACK-5800 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5800 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, XenServer >Affects Versions: 4.3.0 > Environment: CENTOS 6.4,WIN2012,ACS 4.3.0, >Reporter: rashid >Assignee: edison su > Fix For: 4.4.0, 4.5.0 > > > While creating a vm from template > INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-5:ctx-c259052d) Add job-46 > into job monitoring > INFO [o.a.c.s.v.VolumeServiceImpl] (Job-Executor-5:ctx-c259052d > ctx-506ea49e) lock is acquired for VMTemplateStoragePool 7 > WARN [o.a.c.alerts] (CapacityChecker:ctx-374c70b5) alertType:: 24 // > dataCenterId:: 1 // podId:: null // clusterId:: null // message:: System > Alert: Number of unallocated shared network IPs is low in availability zone > NEWZONE > WARN [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-32c31ce6) Task (job-45) has > been pending for 104 seconds > WARN [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-32c31ce6) Task (job-46) has > been pending for 103 seconds > WARN [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-92c2ed53) Task (job-45) has > been pending for 164 seconds > WARN [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-92c2ed53) Task (job-46) has > been pending for 163 seconds > WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) > destoryVDIbyNameLabel failed due to there are 0 VDIs with name > cloud-377c12f4-a8e9-491a-8cba-34b9532455f8 > WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) > failed to set hidden to 0 > /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd > WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) > Catch Exception com.cloud.utils.exception.CloudRuntimeException for template > + due to com.cloud.utils.exception.CloudRuntimeException: failed to set > hidden to 0 > /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd > com.cloud.utils.exception.CloudRuntimeException: failed to set hidden to 0 > /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd > at > com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copy_vhd_from_secondarystorage(XenServerStorageProcessor.java:858) > at > com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copyTemplateToPrimaryStorage(XenServerStorageProcessor.java:928) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:75) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:50) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:609) > 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$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPo
[jira] [Updated] (CLOUDSTACK-5836) When tried to reverting back to (disk attached)quiesced vm snapshot, got error at logs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ram Ganesh updated CLOUDSTACK-5836:
---
Assignee: edison su
> When tried to reverting back to (disk attached)quiesced vm snapshot, got
> error at logs
> --
>
> Key: CLOUDSTACK-5836
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5836
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, Snapshot
>Affects Versions: 4.3.0
> Environment: cloudstack 4.3,vm snapshot
>Reporter: rashid
>Assignee: edison su
> Fix For: 4.4.0, 4.5.0
>
>
> Environment: There is a vm with attached disk. When tried to revert back to
> older vm snapshot then I saw the below error message in log &
> • VM did not stop
> • At notification it says “successfull” & No GUI error message
> Manually powered off and powered on the vm and verified that Vm has been
> successfully reverted.
> But , why vm did not get powered off by itself?
> PLease check the below logs
> INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-41:ctx-5711a5dd) Add job-93
> into job monitoring INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-42:ctx-b7e47685) Add job-94 into job monitoring INFO
> [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-43:ctx-7c2d7cd2) Add job-93 into
> job monitoring INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-42:ctx-b7e47685) Remove job-94 from job monitoring WARN
> [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-43:ctx-7c2d7cd2) job-93 is
> scheduled for wakeup run, but there is no joining info anymore ERROR
> [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-43:ctx-7c2d7cd2) Unable to
> find a wakeup dispatcher from the joined job: AsyncJobVO {id:93, userId: 2,
> accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.vmsnapshot.RevertToVMSnapshotCmd,
> cmdInfo:
> {"response":"json","sessionkey":"LAwQEgGPTl8PlWexb67vz8P8SoU\u003d","cmdEventType":"VMSNAPSHOT.REVERTTO","ctxUserId":"2","httpmethod":"GET","vmsnapshotid":"4b1ea7b0-7274-4d35-bfd8-d1f151eabe3e","_":"1389095290252","ctxAccountId":"2","ctxStartEventId":"119"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 345052565034, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Tue Jan 07 06:48:10 EST 2014} INFO
> [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-43:ctx-7c2d7cd2) Remove job-93
> from job monitoring INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-41:ctx-5711a5dd) Remove job-93 from job monitoring INFO
> [c.c.h.HighAvailabilityManagerImpl] (HA-2:ctx-943a466a) checking health of
> usage server
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5583) vmopsSnapshot plug-in (XenServer) does not return an error when it should
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-5583: --- Fix Version/s: 4.5.0 > vmopsSnapshot plug-in (XenServer) does not return an error when it should > - > > Key: CLOUDSTACK-5583 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5583 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot, Xen >Affects Versions: 4.3.0 > Environment: XenServer 6.1 >Reporter: Mike Tutkowski >Assignee: Anthony Xu > Fix For: 4.4.0, 4.5.0 > > > I tried to revert a VM snapshot and one of my storage repositories had an > insufficient amount of space. The plug-in did not return an error message (it > returned "0"). > From the XenServer vmopsSnapshot plug-in's revert_memory_snapshot method: > [root@XenServer-6 ~]# xe snapshot-revert > snapshot-uuid=82e33f6d-59f3-a26d-4171-d51cd58716d8 > Error code: SR_BACKEND_FAILURE_44 > Error parameters: , There is insufficient space, > An error should be returned from the plug-in instead of "0". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5583) vmopsSnapshot plug-in (XenServer) does not return an error when it should
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-5583: --- Assignee: Anthony Xu > vmopsSnapshot plug-in (XenServer) does not return an error when it should > - > > Key: CLOUDSTACK-5583 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5583 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot, Xen >Affects Versions: 4.3.0 > Environment: XenServer 6.1 >Reporter: Mike Tutkowski >Assignee: Anthony Xu > Fix For: 4.4.0, 4.5.0 > > > I tried to revert a VM snapshot and one of my storage repositories had an > insufficient amount of space. The plug-in did not return an error message (it > returned "0"). > From the XenServer vmopsSnapshot plug-in's revert_memory_snapshot method: > [root@XenServer-6 ~]# xe snapshot-revert > snapshot-uuid=82e33f6d-59f3-a26d-4171-d51cd58716d8 > Error code: SR_BACKEND_FAILURE_44 > Error parameters: , There is insufficient space, > An error should be returned from the plug-in instead of "0". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7822) test SSL cert expired
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198599#comment-14198599
]
ASF subversion and git services commented on CLOUDSTACK-7822:
-
Commit b532e4f52c967ff6ea1830520e1c7306cfcb96da in cloudstack's branch
refs/heads/master from pdion891
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b532e4f ]
CLOUDSTACK-7822: fix tests CA cert
> test SSL cert expired
> -
>
> Key: CLOUDSTACK-7822
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7822
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Test
>Affects Versions: 4.4.0, 4.5.0, 4.4.1
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Minor
> Fix For: 4.5.0
>
>
> Building from source (apache-cloudstack-4.4.1-src.tar.bz2) fail to build
> using {{mvn install}} or package.sh due to test ssl cert that are expired.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-315) Infrastructure view does not show capacity values
[ https://issues.apache.org/jira/browse/CLOUDSTACK-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-315: -- Assignee: Min Chen > Infrastructure view does not show capacity values > - > > Key: CLOUDSTACK-315 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-315 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.1.0, 4.2.0 > Environment: master branch >Reporter: Rohit Yadav >Assignee: Min Chen >Priority: Minor > Fix For: 4.4.0, 4.5.0 > > > Goto Infrastructure, it won't post a GET request to get list of capacities, > no. of hosts, zones, routers etc.; and fails to show any capacity values. > This was observed on master branch, > head=16fa74b7293039db75fdc6851c35e194b33f2135. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7822) test SSL cert expired
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre-Luc Dion updated CLOUDSTACK-7822:
Fix Version/s: Future
> test SSL cert expired
> -
>
> Key: CLOUDSTACK-7822
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7822
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Test
>Affects Versions: 4.4.0, 4.5.0, 4.4.1
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Minor
> Fix For: Future, 4.5.0
>
>
> Building from source (apache-cloudstack-4.4.1-src.tar.bz2) fail to build
> using {{mvn install}} or package.sh due to test ssl cert that are expired.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5836) When tried to reverting back to (disk attached)quiesced vm snapshot, got error at logs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198796#comment-14198796
]
edison su commented on CLOUDSTACK-5836:
---
the error in the log doesn't say anything. per my understanding, revert vm
snapshot won't power off vm.
> When tried to reverting back to (disk attached)quiesced vm snapshot, got
> error at logs
> --
>
> Key: CLOUDSTACK-5836
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5836
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, Snapshot
>Affects Versions: 4.3.0
> Environment: cloudstack 4.3,vm snapshot
>Reporter: rashid
>Assignee: edison su
> Fix For: 4.4.0, 4.5.0
>
>
> Environment: There is a vm with attached disk. When tried to revert back to
> older vm snapshot then I saw the below error message in log &
> • VM did not stop
> • At notification it says “successfull” & No GUI error message
> Manually powered off and powered on the vm and verified that Vm has been
> successfully reverted.
> But , why vm did not get powered off by itself?
> PLease check the below logs
> INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-41:ctx-5711a5dd) Add job-93
> into job monitoring INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-42:ctx-b7e47685) Add job-94 into job monitoring INFO
> [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-43:ctx-7c2d7cd2) Add job-93 into
> job monitoring INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-42:ctx-b7e47685) Remove job-94 from job monitoring WARN
> [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-43:ctx-7c2d7cd2) job-93 is
> scheduled for wakeup run, but there is no joining info anymore ERROR
> [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-43:ctx-7c2d7cd2) Unable to
> find a wakeup dispatcher from the joined job: AsyncJobVO {id:93, userId: 2,
> accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.vmsnapshot.RevertToVMSnapshotCmd,
> cmdInfo:
> {"response":"json","sessionkey":"LAwQEgGPTl8PlWexb67vz8P8SoU\u003d","cmdEventType":"VMSNAPSHOT.REVERTTO","ctxUserId":"2","httpmethod":"GET","vmsnapshotid":"4b1ea7b0-7274-4d35-bfd8-d1f151eabe3e","_":"1389095290252","ctxAccountId":"2","ctxStartEventId":"119"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 345052565034, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Tue Jan 07 06:48:10 EST 2014} INFO
> [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-43:ctx-7c2d7cd2) Remove job-93
> from job monitoring INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-41:ctx-5711a5dd) Remove job-93 from job monitoring INFO
> [c.c.h.HighAvailabilityManagerImpl] (HA-2:ctx-943a466a) checking health of
> usage server
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-5836) When tried to reverting back to (disk attached)quiesced vm snapshot, got error at logs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su resolved CLOUDSTACK-5836.
---
Resolution: Invalid
> When tried to reverting back to (disk attached)quiesced vm snapshot, got
> error at logs
> --
>
> Key: CLOUDSTACK-5836
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5836
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, Snapshot
>Affects Versions: 4.3.0
> Environment: cloudstack 4.3,vm snapshot
>Reporter: rashid
>Assignee: edison su
> Fix For: 4.4.0, 4.5.0
>
>
> Environment: There is a vm with attached disk. When tried to revert back to
> older vm snapshot then I saw the below error message in log &
> • VM did not stop
> • At notification it says “successfull” & No GUI error message
> Manually powered off and powered on the vm and verified that Vm has been
> successfully reverted.
> But , why vm did not get powered off by itself?
> PLease check the below logs
> INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-41:ctx-5711a5dd) Add job-93
> into job monitoring INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-42:ctx-b7e47685) Add job-94 into job monitoring INFO
> [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-43:ctx-7c2d7cd2) Add job-93 into
> job monitoring INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-42:ctx-b7e47685) Remove job-94 from job monitoring WARN
> [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-43:ctx-7c2d7cd2) job-93 is
> scheduled for wakeup run, but there is no joining info anymore ERROR
> [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-43:ctx-7c2d7cd2) Unable to
> find a wakeup dispatcher from the joined job: AsyncJobVO {id:93, userId: 2,
> accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.vmsnapshot.RevertToVMSnapshotCmd,
> cmdInfo:
> {"response":"json","sessionkey":"LAwQEgGPTl8PlWexb67vz8P8SoU\u003d","cmdEventType":"VMSNAPSHOT.REVERTTO","ctxUserId":"2","httpmethod":"GET","vmsnapshotid":"4b1ea7b0-7274-4d35-bfd8-d1f151eabe3e","_":"1389095290252","ctxAccountId":"2","ctxStartEventId":"119"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 345052565034, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Tue Jan 07 06:48:10 EST 2014} INFO
> [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-43:ctx-7c2d7cd2) Remove job-93
> from job monitoring INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-41:ctx-5711a5dd) Remove job-93 from job monitoring INFO
> [c.c.h.HighAvailabilityManagerImpl] (HA-2:ctx-943a466a) checking health of
> usage server
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7844) IP Reservation in Isolated Networks doesn't work as expected
Logan B created CLOUDSTACK-7844: --- Summary: IP Reservation in Isolated Networks doesn't work as expected Key: CLOUDSTACK-7844 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7844 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.4.0 Environment: CloudStack 4.4.0 w/ KVM Hypervisor on Ubuntu 14.04 LTS Reporter: Logan B Fix For: 4.5.0 When using the IP Reservation functionality on an Isolated Guest Network in an Advanced Zone it doesn't work as expected. Goal: Create Isolated Network with 10.1.1.0/24 subnet. Configure network with IP reservation to 10.1.1.0/25. Test: 1. Create Isolated Guest Network with VR/DHCP/Etc. (Using the default 'IsolatedNetworkOfferingWithSourceNAT' offering). Use default Guest CIDR (10.1.1.0/24). 2. Deploy VM on network to "Implement" it.* Make sure VM has a NIC in 10.1.1.0/25. (ex: 10.1.1.50). 3. Edit network and set "Guest CIDR" to 10.1.1.0/25. After saving the "Guest CIDR" field should display 10.1.1.0/25, and the "Network CIDR" field should be 10.1.1.0/24. 4. NOTE: At this point everything should be working as expected. Problems don't occur until the next step. 5. Restart the network you created (with "Cleanup" checked). 6. Reboot the VM you created earlier, or run dhclient on the primary interface. 7. The VM will now have a /25 (255.255.255.128) netmask, instead of the /24 it was initially deployed with. 8. Manually modify the VMs IP and netmask to be outside the Guest CIDR, but still within the network CIDR (e.g., 10.1.1.150/24), and create a default route for the VR IP (e.g. 10.1.1.1). Expected Result: - No VMs should be deployed in the reserved range. - IPs in the reserved range (10.1.1.127 - 10.1.1.254) should be able to ping VMs in the Guest CIDR range (10.1.1.2 - 10.1.1.125), and vice versa. - The virtual router should still have a 255.255.255.0 netmask, and provide routing/DHCP/etc for the entire subnet (10.1.1.0/24). - New VMs created on the guest network should get an IP in the Guest CIDR range (10.1.1.0/25) but have the Network CIDR netmask (255.255.255.0). Observed Result: - No VMs are deployed in the reserved range. - IPs in the reserved range (10.1.1.127 - 10.1.1.254) are NOT ABLE to ping VMs in the Guest CIDR range (10.1.1.2 - 10.1.1.125), and vice versa. - The virtual router has a /25 (255.255.255.128) netmask, and only provides routing/DHCP for addresses in that subnet. - New VMs created on the network are deployed in the Guest CIDR range (10.1.1.0/25) with a /25 (255.255.255.128) netmask, instead of a /24 (255.255.255.0) netmask. I'm assuming this is not the intended behavior. I posted these results on the dev list, but didn't get much traction. I would assume this can be resolved in one of two ways: - Option A) Ensure that the Virtual Router always pulls it's netmask/routing from the Network CIDR. As I understand it CloudStack manually creates static DHCP entries when provisioning VMs, so I don't think any networking changes should take effect on the VR when implementing IP reservation. (If anything we should just update the "dhcp-range" instead of the netmask/routing. - Option B) When IP reservation is in effect the virtual router should be updated with a route to the reserved range (10.1.1.128/25). That way it will still be reachable if we manually set a /24 netmask on hosts in the reserved range. This option seems like a workaround rather than a fix, so Option A would be preferred. Notice that this problem ONLY comes up when the Virtual Router is cleaned up or re-deployed. Because of this it may not be caught in standard testing, but it can cause problems when the router is restarted for HA/migrations/maintenance/etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7845) Strict Implicit Dedication should allow for deploying owned Virtual Routers on dedicated host
Logan B created CLOUDSTACK-7845: --- Summary: Strict Implicit Dedication should allow for deploying owned Virtual Routers on dedicated host Key: CLOUDSTACK-7845 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7845 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM, Virtual Router Affects Versions: 4.4.0 Environment: CloudStack 4.4.0 w/ KVM Hypervisor on Ubuntu 14.04 LTS Reporter: Logan B Fix For: 4.5.0 Currently the best method of isolation for domains or accounts is Strict Implicit Dedication. The reasoning is as follows: Goal: Dedicated a resource (host, cluster, or pod) to an account or domain. Problems: - Explicit Dedication: Account or domain's VMs are all deployed on it's dedicated resources. However, System VMs (Virtual Routers) belonging to OTHER accounts can also be deployed on those same resources (host, cluster, or pod). This is not desirable. - Preferred Implicit Dedication: Account or domain's VMs are deployed on it's dedicated resources. However, if those resources are near full utilization there is a chance that the account or domain's VMs will be deployed on resources that are not dedicated. This is less likely, but also undesirable. We are currently using both explicit and implicit dedication. The explicit dedication ensures that the first VM deployed is provisioned on the dedicated resources, while the implicit dedication ensures that other accounts can't deploy resources on the same dedicated resources (intentionally or not). Proposed changes: Currently Virtual Router's are considered to be owned by the "system" account, even though they are each tied to a specific user account. This probably doesn't need to change, but it makes a solution to the above issue easier since Virtual Router's are already tagged/associated with user accounts. I would suggest changing the Strict Implicit Dedication planner, and the Virtual Router deployment planner as follows: - Strict Implicit Dedication: When selecting a host for strict implicit dedication Virtual Router's belonging to the account that "owns" the resource should be ignored. Virtual Router's or other System VMs belonging to OTHER accounts should still be considered, and cause the deployment to fail. - Virtual Router deployment: Virtual Router's belonging to an account should prefer deployment on explicitly or implicitly dedicated resources belonging to that same account. In addition, deployment should not fail if the Strict Implicitly dedicated resource owner and the Virtual Router "owner" match. The end goal here is to provide absolute isolation for accounts or domains with dedicated resources. If someone pays for a 'private cloud' with dedicated hardware then all of their deployed services should end up on that hardware, and no other account/domain should be able to utilize the dedicated resources of another. This ensures that an outage or issue on a public resource doesn't affect the dedicated/private infrastructure, and "public" users can't consume private resources being paid for by someone else. Currently the only way this is possible is by dedicating an entire zone to an account, but that is far from ideal, and makes management of the overall deployment/networking/etc. much more of a hassle. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7846) deploydb fails when new version doesn't have any database upgrade
Derrick Schneider created CLOUDSTACK-7846:
-
Summary: deploydb fails when new version doesn't have any database
upgrade
Key: CLOUDSTACK-7846
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7846
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
Environment: Mac OS X 10.8.3
Reporter: Derrick Schneider
Having checked out branch 4.4, I followed along with the developer setup
documentation found here.
http://docs.cloudstack.apache.org/en/master/developer_guide.html
However, the deploydb failed with the error message:
```
Caused by: com.cloud.utils.exception.CloudRuntimeException: The end upgrade
version is actually at 4.4.1 but our management server code version is at
4.4.2-SNAPSHOT
at
com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:278)
at
com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:438)
at com.cloud.upgrade.DatabaseCreator.main(DatabaseCreator.java:217)
```
The relevant code is here:
```
if (Version.compare(trimmedCurrentVersion, upgrades[upgrades.length -
1].getUpgradedVersion()) != 0) {
s_logger.error("The end upgrade version is actually at " +
upgrades[upgrades.length - 1].getUpgradedVersion() +
" but our management server code version is at " +
currentVersion);
throw new CloudRuntimeException("The end upgrade version is
actually at " + upgrades[upgrades.length - 1].getUpgradedVersion() +
" but our management server code version is at " +
currentVersion);
}
```
The problem seems to be that there's no Upgrade441to442 object with appropriate
settings.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7847) API: listDomains should display the domain resources, similar to listAccounts
Logan B created CLOUDSTACK-7847: --- Summary: API: listDomains should display the domain resources, similar to listAccounts Key: CLOUDSTACK-7847 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7847 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Environment: CloudStack 4.4.0 w/ KVM Hypervisor on Ubuntu 14.04 LTS Reporter: Logan B Fix For: 4.5.0 Currently the "listDomains" call does not display any resource statistics. Since resources can be limited at the Domain level, it would make sense to have the "listDomains" call return the resource limit & usage details the same way "listAccounts" does. I would suggest having it return the following details for the domain: - Max/Used IPs - Max/Used Templates - Max/Used Snapshots - Max/Used VPC - Max/Used Networks - Max/Used Memory - Max/Used Projects - Max/Used vCPU Count - Max/Used CPU Mhz (This may not actually be tracked by CloudStack) - Max/Used Primary Storage - Max/Used Secondary Storage - I may have missed some. This would make it much easier to pull statistics information for a domain, instead of having to use multiple other calls. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7846) deploydb fails when new version doesn't have any database upgrade
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199007#comment-14199007
]
Derrick Schneider edited comment on CLOUDSTACK-7846 at 11/5/14 8:27 PM:
Note that as a temporary workaround if you're running into this, you can return
"4.4.2" in Upgrade440to441.java
Current:
public String getUpgradedVersion() {
return "4.4.1";
}
Works:
public String getUpgradedVersion() {
return "4.4.2";
}
was (Author: derrickschneider):
Note that as a temporary workaround if you're running into this, you can return
"4.4.2" in Upgrade440to441.java
Current:
```public String getUpgradedVersion() {
return "4.4.1";
}
```
Works:
```
public String getUpgradedVersion() {
return "4.4.2";
}
```
> deploydb fails when new version doesn't have any database upgrade
> -
>
> Key: CLOUDSTACK-7846
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7846
> 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
> Environment: Mac OS X 10.8.3
>Reporter: Derrick Schneider
>
> Having checked out branch 4.4, I followed along with the developer setup
> documentation found here.
> http://docs.cloudstack.apache.org/en/master/developer_guide.html
> However, the deploydb failed with the error message:
> ```
> Caused by: com.cloud.utils.exception.CloudRuntimeException: The end upgrade
> version is actually at 4.4.1 but our management server code version is at
> 4.4.2-SNAPSHOT
> at
> com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:278)
> at
> com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:438)
> at com.cloud.upgrade.DatabaseCreator.main(DatabaseCreator.java:217)
> ```
> The relevant code is here:
> ```
> if (Version.compare(trimmedCurrentVersion, upgrades[upgrades.length -
> 1].getUpgradedVersion()) != 0) {
> s_logger.error("The end upgrade version is actually at " +
> upgrades[upgrades.length - 1].getUpgradedVersion() +
> " but our management server code version is at " +
> currentVersion);
> throw new CloudRuntimeException("The end upgrade version is
> actually at " + upgrades[upgrades.length - 1].getUpgradedVersion() +
> " but our management server code version is at " +
> currentVersion);
> }
> ```
> The problem seems to be that there's no Upgrade441to442 object with
> appropriate settings.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7846) deploydb fails when new version doesn't have any database upgrade
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199007#comment-14199007
]
Derrick Schneider commented on CLOUDSTACK-7846:
---
Note that as a temporary workaround if you're running into this, you can return
"4.4.2" in Upgrade440to441.java
Current:
```public String getUpgradedVersion() {
return "4.4.1";
}
```
Works:
```
public String getUpgradedVersion() {
return "4.4.2";
}
```
> deploydb fails when new version doesn't have any database upgrade
> -
>
> Key: CLOUDSTACK-7846
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7846
> 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
> Environment: Mac OS X 10.8.3
>Reporter: Derrick Schneider
>
> Having checked out branch 4.4, I followed along with the developer setup
> documentation found here.
> http://docs.cloudstack.apache.org/en/master/developer_guide.html
> However, the deploydb failed with the error message:
> ```
> Caused by: com.cloud.utils.exception.CloudRuntimeException: The end upgrade
> version is actually at 4.4.1 but our management server code version is at
> 4.4.2-SNAPSHOT
> at
> com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:278)
> at
> com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:438)
> at com.cloud.upgrade.DatabaseCreator.main(DatabaseCreator.java:217)
> ```
> The relevant code is here:
> ```
> if (Version.compare(trimmedCurrentVersion, upgrades[upgrades.length -
> 1].getUpgradedVersion()) != 0) {
> s_logger.error("The end upgrade version is actually at " +
> upgrades[upgrades.length - 1].getUpgradedVersion() +
> " but our management server code version is at " +
> currentVersion);
> throw new CloudRuntimeException("The end upgrade version is
> actually at " + upgrades[upgrades.length - 1].getUpgradedVersion() +
> " but our management server code version is at " +
> currentVersion);
> }
> ```
> The problem seems to be that there's no Upgrade441to442 object with
> appropriate settings.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7848) API: updateResourceCount doesn't return all statistics
Logan B created CLOUDSTACK-7848:
---
Summary: API: updateResourceCount doesn't return all statistics
Key: CLOUDSTACK-7848
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7848
Project: CloudStack
Issue Type: Improvement
Security Level: Public (Anyone can view this level - this is the default.)
Components: API
Affects Versions: 4.4.0
Environment: CloudStack 4.4.0 w/ KVM Hypervisor on Ubuntu 14.04 LTS
Reporter: Logan B
Fix For: 4.5.0
Currently the "updateResourceCount" API call is not returning correct values
for all of the statistics. Specifically the "Memory Used" and "Secondary
Storage Used" are being returned as "0" even if those resources are being used.
As a workaround right now I'm having to go through other calls to pull this
data down.
I'm unsure if there are other values not being returned correctly, but I can
confirm that at least the "IPs Used", "Templates Used", and "Primary Storage
Used" values are being returned.
I have tested this with the "domainid" field specified. I haven't tested
without "domainid" since that is my use case.
Here is a var_dump of the call with unique information removed:
object(stdClass)#2 (1) {
["updateresourcecountresponse"]=>
object(stdClass)#3 (2) {
["count"]=>
int(12)
["resourcecount"]=>
array(12) {
[0]=>
object(stdClass)#4 (4) {
["domainid"]=>
string(36) "12345678-91234-56789-1234-567891234"
["domain"]=>
string(7) "Example"
["resourcetype"]=>
string(1) "0"
["resourcecount"]=>
int(2)
}
[1]=>
object(stdClass)#5 (4) {
["domainid"]=>
string(36) "12345678-91234-56789-1234-567891234"
["domain"]=>
string(7) "Example"
["resourcetype"]=>
string(1) "1"
["resourcecount"]=>
int(2)
}
[2]=>
object(stdClass)#6 (4) {
["domainid"]=>
string(36) "12345678-91234-56789-1234-567891234"
["domain"]=>
string(7) "Example"
["resourcetype"]=>
string(1) "2"
["resourcecount"]=>
int(2)
}
[3]=>
object(stdClass)#7 (4) {
["domainid"]=>
string(36) "12345678-91234-56789-1234-567891234"
["domain"]=>
string(7) "Example"
["resourcetype"]=>
string(1) "3"
["resourcecount"]=>
int(2)
}
[4]=>
object(stdClass)#8 (4) {
["domainid"]=>
string(36) "12345678-91234-56789-1234-567891234"
["domain"]=>
string(7) "Example"
["resourcetype"]=>
string(1) "4"
["resourcecount"]=>
int(0)
}
[5]=>
object(stdClass)#9 (4) {
["domainid"]=>
string(36) "12345678-91234-56789-1234-567891234"
["domain"]=>
string(7) "Example"
["resourcetype"]=>
string(1) "5"
["resourcecount"]=>
int(0)
}
[6]=>
object(stdClass)#10 (4) {
["domainid"]=>
string(36) "12345678-91234-56789-1234-567891234"
["domain"]=>
string(7) "Example"
["resourcetype"]=>
string(1) "6"
["resourcecount"]=>
int(1)
}
[7]=>
object(stdClass)#11 (4) {
["domainid"]=>
string(36) "12345678-91234-56789-1234-567891234"
["domain"]=>
string(7) "Example"
["resourcetype"]=>
string(1) "7"
["resourcecount"]=>
int(0)
}
[8]=>
object(stdClass)#12 (4) {
["domainid"]=>
string(36) "12345678-91234-56789-1234-567891234"
["domain"]=>
string(7) "Example"
["resourcetype"]=>
string(1) "8"
["resourcecount"]=>
int(0)
}
[9]=>
object(stdClass)#13 (4) {
["domainid"]=>
string(36) "12345678-91234-56789-1234-567891234"
["domain"]=>
string(7) "Example"
["resourcetype"]=>
string(1) "9"
["resourcecount"]=>
int(0)
}
[10]=>
object(stdClass)#14 (4) {
["domainid"]=>
string(36) "12345678-91234-56789-1234-567891234"
["domain"]=>
string(7) "Example"
["resourcetype"]=>
string(2) "10"
["resourcecount"]=>
float(11811160064)
}
[11]=>
object(stdClass)#15 (4) {
["domainid"]=>
string(36) "12345678-91234-56789-1234-567891234"
["domain"]=>
string(7) "Example"
["resourcetype"]=>
string(2) "11"
["resourcecount"]=>
int(0)
}
}
}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7849) sort the projects on drop down menu alphabetically
Luis Henrique Okama created CLOUDSTACK-7849: --- Summary: sort the projects on drop down menu alphabetically Key: CLOUDSTACK-7849 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7849 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Luis Henrique Okama It should have some kind of criteria to show the projects on drop down menu. We change the projectSelect.js to sort the projects alphabetically. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7850) UI > Instances > detailView > Attach ISO option > ISO dropdown > should list only ISOs belonging to the same zone.
Jessica Wang created CLOUDSTACK-7850: Summary: UI > Instances > detailView > Attach ISO option > ISO dropdown > should list only ISOs belonging to the same zone. Key: CLOUDSTACK-7850 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7850 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang Priority: Critical Fix For: 4.5.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7850) UI > Instances > detailView > Attach ISO option > ISO dropdown > should list only ISOs belonging to the same zone.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199121#comment-14199121 ] ASF subversion and git services commented on CLOUDSTACK-7850: - Commit 11808ae7fb73390c862e09ce0c7d01edf4e8ea62 in cloudstack's branch refs/heads/4.5 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=11808ae ] CLOUDSTACK-7850: UI > Instances > detailView > Attach ISO option > ISO dropdown > should list only ISOs belonging to the same zone. > UI > Instances > detailView > Attach ISO option > ISO dropdown > should list > only ISOs belonging to the same zone. > --- > > Key: CLOUDSTACK-7850 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7850 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7850) UI > Instances > detailView > Attach ISO option > ISO dropdown > should list only ISOs belonging to the same zone.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199125#comment-14199125 ] ASF subversion and git services commented on CLOUDSTACK-7850: - Commit dd326af83d1cee4b1072c793fe2876643a1dbc6b in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=dd326af ] CLOUDSTACK-7850: UI > Instances > detailView > Attach ISO option > ISO dropdown > should list only ISOs belonging to the same zone. > UI > Instances > detailView > Attach ISO option > ISO dropdown > should list > only ISOs belonging to the same zone. > --- > > Key: CLOUDSTACK-7850 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7850 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7850) UI > Instances > detailView > Attach ISO option > ISO dropdown > should list only ISOs belonging to the same zone.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang closed CLOUDSTACK-7850. > UI > Instances > detailView > Attach ISO option > ISO dropdown > should list > only ISOs belonging to the same zone. > --- > > Key: CLOUDSTACK-7850 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7850 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7850) UI > Instances > detailView > Attach ISO option > ISO dropdown > should list only ISOs belonging to the same zone.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-7850. -- Resolution: Fixed > UI > Instances > detailView > Attach ISO option > ISO dropdown > should list > only ISOs belonging to the same zone. > --- > > Key: CLOUDSTACK-7850 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7850 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-5469) Snapshot creation fails with following exception - "Failed to backup snapshot: qemu-img: Could not delete snapshot '89eced14-9121-44a7-bb97-26b567795726': -2 (No su
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su resolved CLOUDSTACK-5469. --- Resolution: Fixed It's because, mgt server sends snapshot related commands to wrong kvm host. > Snapshot creation fails with following exception - "Failed to backup > snapshot: qemu-img: Could not delete snapshot > '89eced14-9121-44a7-bb97-26b567795726': -2 (No such file or directory)" > -- > > Key: CLOUDSTACK-5469 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5469 > 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 >Priority: Critical > Fix For: 4.4.0, 4.5.0 > > Attachments: deletesnapshot.rar > > > Set up: > Advanced Zone with 2 KVM (RHEL 6.3) hosts. > 2 NFS secondary stores set up. > 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. > 1 of the secondary store -ss1- had the nfs server down for 1 and 1/2 hours. > The other secondary store -ss2 - was always reachable. > Snapshot tasks that went to the ss1 , succeeded after the nfs server was > brought up (It temporarily halted when the the nfs server was down and > resumed when the nsf server was made available). > First set of snapshot tasks that went to the ss2 all succeeded. > But the next hourly snapshot tasks, few of them failed with following > exception: 2013-12-11 16:33:22,427 DEBUG [c.c.s.s.SnapshotManagerImpl] > (Job-Executor-64:ctx-9c70ad77 ctx-3d959fa6) Failed t o create snapshot > com.cloud.utils.exception.CloudRuntimeException: Failed to backup snapshot: > qemu-img: Could not delete snapshot '89eced14-9121-44a7-bb97-26b567795726': > -2 (No such file or directory)Failed to delete snapshot 89eced14-9121-44 > a7-bb97-26b567795726 for path > /mnt/c20ea198-e8ca-33c3-9f11-e361ec9b5532/71a5dce2-da7c-4692-8f25-ba37e5296886 > at > org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:27 > 5) at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStra > tegy.java:135) at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrate > gy.java:294) at > com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:951) > 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:601) at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocati > on.java:183) at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java: > 150) at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.ja > va:91) at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java: > 172) at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at $Proxy161.takeSnapshot(Unknown Source) at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1341) > at > com.cloud.storage.VolumeApiServiceImpl.takeSnapshot(VolumeApiServiceImpl.java:1461) > 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:601) at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > Copy to the secondary has succeed. Failure happens after this. > [root@Rack3Host5 118]# ls -ltr > total 10002852 > -rw-r--r--. 1 root root 3637903360 Dec 11 20:33 > 89eced14-9121-44a7-bb97-26b567795726 > -rw-r--r--. 1 root root 3638755328 Dec 11 21:37 > b38d93db-4c14-45a7-9274-639ad95a3f29 > -rw-r--r--. 1 root root 2956619776 Dec 11 22:24 > 452c8841-2025-41da-b6ec-49cea2a49da8 > [root@Rack3Host5 118]#
[jira] [Commented] (CLOUDSTACK-7683) NPE while expunging the failed VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199313#comment-14199313 ] edison su commented on CLOUDSTACK-7683: --- Yes, there is a background vm GC thread which cleaned up the same vm at the same time, when expunged vm cmd is executing, which cause the conflict. > NPE while expunging the failed VM > - > > Key: CLOUDSTACK-7683 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7683 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, XenServer >Affects Versions: 4.5.0 >Reporter: Sailaja Mada >Assignee: edison su >Priority: Critical > Fix For: 4.5.0 > > Attachments: expungenpelogs.zip > > > Steps: > 1. Install and configure with XS 6.5 > 2. Tried to Deployed VM (Windows 7) . It failed to deploy VM due to > resources not being available > 3. Deleted this VM which is in Error state > Observation:NPE while expunging the failed VM > 2014-10-08 11:09:11,894 DEBUG [o.a.c.s.v.VolumeObject] > (API-Job-Executor-58:ctx-bdc8e992 job-4398 ctx-8115790b) Failed to update > state > java.lang.NullPointerException > at com.cloud.utils.fsm.StateMachine2.transitTo(StateMachine2.java:101) > at > org.apache.cloudstack.storage.volume.VolumeObject.stateTransit(VolumeObject.java:185) > at > org.apache.cloudstack.storage.volume.VolumeObject.processEvent(VolumeObject.java:325) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.deleteVolumeCallback(VolumeServiceImpl.java:339) > at sun.reflect.GeneratedMethodAccessor392.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.dispatch(AsyncCallbackDispatcher.java:148) > at > org.apache.cloudstack.framework.async.InplaceAsyncCallbackDriver.performCompletionCallback(InplaceAsyncCallbackDriver.java:25) > at > org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.complete(AsyncCallbackDispatcher.java:126) > at > org.apache.cloudstack.storage.datastore.driver.CloudStackPrimaryDataStoreDriverImpl.deleteAsync(CloudStackPrimaryDataStoreDriverImpl.java:222) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.expungeVolumeAsync(VolumeServiceImpl.java:323) > at > org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.cleanupVolumes(VolumeOrchestrator.java:862) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:522) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:454) > at com.cloud.vm.UserVmManagerImpl.expunge(UserVmManagerImpl.java:1709) > at sun.reflect.GeneratedMethodAccessor803.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > 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.$Proxy212.expunge(Unknown Source) > at > com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:738) > at > com.cloud.user.AccountManagerImpl.deleteAccount(AccountManagerImpl.java:665) > at > com.cloud.user.AccountManagerImpl.deleteUserAccount(AccountManagerImpl.java:1444) > at sun.reflect.GeneratedMethodAccessor816.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > 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.ReflectiveMethodInvocatio
[jira] [Closed] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chandan Purushothama closed CLOUDSTACK-7493.
Closing the bug based on Jayapal's comment.
> [Automation] Egress Firewall Rule fails to create on the Virtual Router in
> Hyper-V Setup - Reports Success instead of failure report
>
>
> Key: CLOUDSTACK-7493
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
> 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: Blocker
> Fix For: 4.5.0
>
> Attachments: client_managementLogs.zip
>
>
> ==
> Error in management Server log:
> ==
> {code}
> 2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===
> 10.220.135.217 -- GET
> jobid=561bbb6c-7931-493d-a778-525086befb96&apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3g&command=queryAsyncJobResult&response=json&signature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
> 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
> 1-4477422454536405316: Sending { Cmd , MgmtId: 174253150778429, via:
> 1(10.220.163.36), Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.routing.SetFirewallRulesCommand":{"rules":[{"id":36,"srcIp":"","protocol":"all","revoked":false,"alreadyAdded":false,"sourceCidrList":["0.0.0.0/0"],"purpose":"Firewall","trafficType":"Egress","defaultEgressPolicy":false}],"accessDetails":{"router.guest.ip":"192.168.200.1","firewall.egress.default":"false","zone.network.type":"Advanced","router.ip":"10.220.165.184","router.name":"r-45-VM"},"wait":0}}]
> }
> 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
> 1-4477422454536405316: Executing: { Cmd , MgmtId: 174253150778429, via:
> 1(10.220.163.36), Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.routing.SetFirewallRulesCommand":{"rules":[{"id":36,"srcIp":"","protocol":"all","revoked":false,"alreadyAdded":false,"sourceCidrList":["0.0.0.0/0"],"purpose":"Firewall","trafficType":"Egress","defaultEgressPolicy":false}],"accessDetails":{"router.guest.ip":"192.168.200.1","firewall.egress.default":"false","zone.network.type":"Advanced","router.ip":"10.220.165.184","router.name":"r-45-VM"},"wait":0}}]
> }
> 2014-09-03 18:04:36,702 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Executing request
> 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-316:ctx-c363d57a) Use router's private IP for SSH control. IP :
> 10.220.165.184
> 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-316:ctx-c363d57a) Run command on VR: 10.220.165.184, script:
> firewall_egress.sh with args: -F -E -P 0 -a :all:0:0:0.0.0.0/0:,
> 2014-09-03 18:04:37,394 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-14:null) SeqA 3-604: Processing Seq 3-604: { Cmd ,
> MgmtId: -1, via: 3, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-09-03 18:04:37,397 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-14:null) SeqA 3-604: Sending Seq 3-604: { Ans: ,
> MgmtId: 174253150778429, via: 3, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2014-09-03 18:04:37,826 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Storage pool garbage collector
> found 0 templates to clean up in storage pool:
> XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0
> 2014-09-03 18:04:37,829 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
> found 0 templates to cleanup on template_store_ref for store:
> cifs://10.220.163.36/storage/secondary
> 2014-09-03 18:04:37,831 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
> found 0 snapshots to cleanup on snapshot_store_ref for store:
> cifs://10.220.163.36/storage/secondary
> 2014-09-03 18:04:37,832 DEBUG [c.c.s.StorageManagerImpl]
> (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
> found 0 volumes to cleanup on volume_store_ref for store:
> cifs://10.220.163.36/storage/secondary
> 2014-09-03 18:04:37,940 DEBUG
[jira] [Commented] (CLOUDSTACK-3607) "guest_os_hypervisor" table has values that are not registered in "guest_os" table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199425#comment-14199425 ] Chandan Purushothama commented on CLOUDSTACK-3607: -- I still see the table in 4.5: mysql> show tables like "guest_os_hypervisor"; +---+ | Tables_in_cloud (guest_os_hypervisor) | +---+ | guest_os_hypervisor | +---+ 1 row in set (0.01 sec) mysql> select * from version; ++-+-+--+ | id | version | updated | step | ++-+-+--+ | 1 | 4.0.0 | 2014-11-04 22:31:30 | Complete | | 2 | 4.1.0 | 2014-11-04 22:32:01 | Complete | | 3 | 4.2.0 | 2014-11-04 22:32:01 | Complete | | 4 | 4.2.1 | 2014-11-04 22:32:01 | Complete | | 5 | 4.3.0 | 2014-11-04 22:32:01 | Complete | | 6 | 4.4.0 | 2014-11-04 22:32:01 | Complete | | 7 | 4.4.1 | 2014-11-04 22:32:01 | Complete | | 8 | 4.5.0 | 2014-11-04 22:32:01 | Complete | ++-+-+--+ 8 rows in set (0.01 sec) mysql> > "guest_os_hypervisor" table has values that are not registered in "guest_os" > table > -- > > Key: CLOUDSTACK-3607 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3607 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: Chandan Purushothama >Assignee: Chandan Purushothama > Fix For: 4.4.0, 4.5.0 > > > mysql> select * from guest_os_hypervisor where guest_os_id not in (select id > from guest_os); > +-+-++-+ > | id | hypervisor_type | guest_os_name | guest_os_id | > +-+-++-+ > | 128 | VmWare | Red Hat Enterprise Linux 6(32-bit) | 204 | > | 129 | VmWare | Red Hat Enterprise Linux 6(64-bit) | 205 | > +-+-++-+ > 2 rows in set (0.07 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7848) API: updateResourceCount doesn't return all statistics
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Logan B updated CLOUDSTACK-7848:
Issue Type: Bug (was: Improvement)
> API: updateResourceCount doesn't return all statistics
> --
>
> Key: CLOUDSTACK-7848
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7848
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.4.0
> Environment: CloudStack 4.4.0 w/ KVM Hypervisor on Ubuntu 14.04 LTS
>Reporter: Logan B
> Fix For: 4.5.0
>
>
> Currently the "updateResourceCount" API call is not returning correct values
> for all of the statistics. Specifically the "Memory Used" and "Secondary
> Storage Used" are being returned as "0" even if those resources are being
> used.
> As a workaround right now I'm having to go through other calls to pull this
> data down.
> I'm unsure if there are other values not being returned correctly, but I can
> confirm that at least the "IPs Used", "Templates Used", and "Primary Storage
> Used" values are being returned.
> I have tested this with the "domainid" field specified. I haven't tested
> without "domainid" since that is my use case.
> Here is a var_dump of the call with unique information removed:
> object(stdClass)#2 (1) {
> ["updateresourcecountresponse"]=>
> object(stdClass)#3 (2) {
> ["count"]=>
> int(12)
> ["resourcecount"]=>
> array(12) {
> [0]=>
> object(stdClass)#4 (4) {
> ["domainid"]=>
> string(36) "12345678-91234-56789-1234-567891234"
> ["domain"]=>
> string(7) "Example"
> ["resourcetype"]=>
> string(1) "0"
> ["resourcecount"]=>
> int(2)
> }
> [1]=>
> object(stdClass)#5 (4) {
> ["domainid"]=>
> string(36) "12345678-91234-56789-1234-567891234"
> ["domain"]=>
> string(7) "Example"
> ["resourcetype"]=>
> string(1) "1"
> ["resourcecount"]=>
> int(2)
> }
> [2]=>
> object(stdClass)#6 (4) {
> ["domainid"]=>
> string(36) "12345678-91234-56789-1234-567891234"
> ["domain"]=>
> string(7) "Example"
> ["resourcetype"]=>
> string(1) "2"
> ["resourcecount"]=>
> int(2)
> }
> [3]=>
> object(stdClass)#7 (4) {
> ["domainid"]=>
> string(36) "12345678-91234-56789-1234-567891234"
> ["domain"]=>
> string(7) "Example"
> ["resourcetype"]=>
> string(1) "3"
> ["resourcecount"]=>
> int(2)
> }
> [4]=>
> object(stdClass)#8 (4) {
> ["domainid"]=>
> string(36) "12345678-91234-56789-1234-567891234"
> ["domain"]=>
> string(7) "Example"
> ["resourcetype"]=>
> string(1) "4"
> ["resourcecount"]=>
> int(0)
> }
> [5]=>
> object(stdClass)#9 (4) {
> ["domainid"]=>
> string(36) "12345678-91234-56789-1234-567891234"
> ["domain"]=>
> string(7) "Example"
> ["resourcetype"]=>
> string(1) "5"
> ["resourcecount"]=>
> int(0)
> }
> [6]=>
> object(stdClass)#10 (4) {
> ["domainid"]=>
> string(36) "12345678-91234-56789-1234-567891234"
> ["domain"]=>
> string(7) "Example"
> ["resourcetype"]=>
> string(1) "6"
> ["resourcecount"]=>
> int(1)
> }
> [7]=>
> object(stdClass)#11 (4) {
> ["domainid"]=>
> string(36) "12345678-91234-56789-1234-567891234"
> ["domain"]=>
> string(7) "Example"
> ["resourcetype"]=>
> string(1) "7"
> ["resourcecount"]=>
> int(0)
> }
> [8]=>
> object(stdClass)#12 (4) {
> ["domainid"]=>
> string(36) "12345678-91234-56789-1234-567891234"
> ["domain"]=>
> string(7) "Example"
> ["resourcetype"]=>
> string(1) "8"
> ["resourcecount"]=>
> int(0)
> }
> [9]=>
> object(stdClass)#13 (4) {
> ["domainid"]=>
> string(36) "12345678-91234-56789-1234-567891234"
> ["domain"]=>
> string(7) "Example"
> ["resourcetype"]=>
> string(1) "9"
> ["resourcecount"]=>
> int(0)
> }
> [10]=>
> object(stdClass)#14 (4) {
> ["domainid"]=>
> string(36) "12345678-91234-56789-1234-567891234"
> ["domain"]=>
> string(7) "Example"
> ["resourcetype"]=>
> string(2) "10"
> ["resourcecount"]=>
> float(11811160064)
> }
> [11]=>
> object(stdClass)#
[jira] [Assigned] (CLOUDSTACK-5324) error message not proper when start VM fails because router reuires upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang reassigned CLOUDSTACK-5324: -- Assignee: Kishan Kavala (was: Sheng Yang) Assign to Kishan who wrote router version check feature. > error message not proper when start VM fails because router reuires 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 > org.springframework.a
[jira] [Commented] (CLOUDSTACK-7822) test SSL cert expired
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199772#comment-14199772
]
ASF subversion and git services commented on CLOUDSTACK-7822:
-
Commit ddb2d9c60ebf121109392f202a724920137256b7 in cloudstack's branch
refs/heads/master from pdion891
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ddb2d9c ]
CLOUDSTACK-7822: merge, test sslcert ca
> test SSL cert expired
> -
>
> Key: CLOUDSTACK-7822
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7822
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Test
>Affects Versions: 4.4.0, 4.5.0, 4.4.1
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Minor
> Fix For: Future, 4.5.0
>
>
> Building from source (apache-cloudstack-4.4.1-src.tar.bz2) fail to build
> using {{mvn install}} or package.sh due to test ssl cert that are expired.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7850) UI > Instances > detailView > Attach ISO option > ISO dropdown > should list only ISOs belonging to the same zone.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199773#comment-14199773 ] ASF subversion and git services commented on CLOUDSTACK-7850: - Commit 11808ae7fb73390c862e09ce0c7d01edf4e8ea62 in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=11808ae ] CLOUDSTACK-7850: UI > Instances > detailView > Attach ISO option > ISO dropdown > should list only ISOs belonging to the same zone. > UI > Instances > detailView > Attach ISO option > ISO dropdown > should list > only ISOs belonging to the same zone. > --- > > Key: CLOUDSTACK-7850 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7850 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7849) sort the projects on drop down menu alphabetically
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199793#comment-14199793 ] Rajani Karuturi commented on CLOUDSTACK-7849: - Review Request: https://reviews.apache.org/r/27641/ commit: e03a7e6feaae2d024f2a53afd71e0230309b1085 on 4.5 and master > sort the projects on drop down menu alphabetically > -- > > Key: CLOUDSTACK-7849 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7849 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Luis Henrique Okama > > It should have some kind of criteria to show the projects on drop down menu. > We change the projectSelect.js to sort the projects alphabetically. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7849) sort the projects on drop down menu alphabetically
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-7849: Fix Version/s: 4.5.0 > sort the projects on drop down menu alphabetically > -- > > Key: CLOUDSTACK-7849 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7849 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Luis Henrique Okama > Fix For: 4.5.0 > > > It should have some kind of criteria to show the projects on drop down menu. > We change the projectSelect.js to sort the projects alphabetically. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7704) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-7704. - Resolution: Fixed > Triage and fix Coverity defects > --- > > Key: CLOUDSTACK-7704 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7704 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Santhosh Kumar Edukulla >Assignee: Rajani Karuturi > Fix For: 4.5.0 > > > 1. We have Coverity setup available, running as scheduled and individual > owners are assigned with analyzed bugs. > 2. As part of this bug, please triage and fix the relevant Coverity bugs > assigned. It could be a count as small as 25 bugs. > 3. First start with high impact in order to others later. > 4. We can either triage them accordingly as fix required or false positive or > not a bug accordingly. But, triage and fix accordingly wherever relevant and > applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7733) Admin/Regular User is not allowed to stop/start Vms that are running on disabled hosts.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199833#comment-14199833
]
Sudhansu Sahu commented on CLOUDSTACK-7733:
---
This is by design.
Start VM on a disabled host and disable host feature are contradictory.
CS will not allow any deployment on a disabled host. As Start VM operation
tries to deploy the VM on a host, so deployment fails.
If deployment planner finds another host with same host tag(as that of SO) then
it will deploy the VM on that host.
Thanks
Sudhansu
> Admin/Regular User is not allowed to stop/start Vms that are running on
> disabled hosts.
> ---
>
> Key: CLOUDSTACK-7733
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7733
> 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
> Environment: Build from master
>Reporter: Sangeetha Hariharan
>Priority: Critical
>
> Steps to reproduce the problem:
> Deploy a Vm in a host say host1 using a service offering that has hosttags
> that matches with host1.
> Disable host.
> As admin , stop this VM.
> Now try to start the VM.
> This fails with "job failed due to exception Unable to create a deployment
> for VM[User|i-20-63-VM"
> {jobprocstatus : 0, created : u'2014-10-15T08:21:04-0400', jobresult :
> {errorcode : 530, errortext : u'Job failed due to exception Unable to create
> a deployment for VM[User|i-20-63-VM]'}, cmd :
> u'org.apache.cloudstack.api.command.admin.vm.StartVMCmdByAdmin', userid :
> u'f3d01d86-93bb-4ec7-a249-f1dc59ba33a1', jobstatus : 2, jobid :
> u'fbe3432d-f90c-49d7-a5ea-f1e65e88aae7', jobresultcode : 530, jobinstanceid :
> u'c9987836-8d76-4a55-bdce-6ef81c4cf51d', jobresulttype : u'object',
> jobinstancetype : u'VirtualMachine', accountid :
> u'54b7a442-2b1f-4df9-b3cc-14a4d8537a74'}
> Management server logs indicating that Vms cannot be started on the last host
> Id , when the host is disabled:
> 2014-10-15 09:37:24,480 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
> (Work-Job-Executor-79:ctx-746fc
> d6f job-558/job-559 ctx-246fb1a1) Trying to allocate a host and storage pools
> from dc:1, pod:1,clus
> ter:2, requested cpu: 100, requested ram: 134217728
> 2014-10-15 09:37:24,480 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
> (Work-Job-Executor-79:ctx-746fcd6f job-558/job-559 ctx-246fb1a1) Is ROOT
> volume READY (pool already allocated)?: Yes
> 2014-10-15 09:37:24,480 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
> (Work-Job-Executor-79:ctx-746fcd6f job-558/job-559 ctx-246fb1a1) This VM has
> last host_id specified, trying to choose the same host: 4
> 2014-10-15 09:37:24,484 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
> (Work-Job-Executor-79:ctx-746fcd6f job-558/job-559 ctx-246fb1a1) The last
> host of this VM is not UP or is not enabled, host status is: Up, host
> resource state is: Disabled
> 2014-10-15 09:37:24,484 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
> (Work-Job-Executor-79:ctx-746fcd6f job-558/job-559 ctx-246fb1a1) Cannot
> choose the last host to deploy this VM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7851) MS does not start after the VM it is running on is rebooted
Damodar Reddy T created CLOUDSTACK-7851: --- Summary: MS does not start after the VM it is running on is rebooted Key: CLOUDSTACK-7851 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7851 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Environment: Centos OS Reporter: Damodar Reddy T Assignee: Damodar Reddy T Priority: Critical Fix For: 4.5.0 After installing management server on centos and try to reboot the machine. It will not start the management server automatically. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7852) EN-US, SC: CentOS CLI & Windows OS: Key translation fails on the Numeric Del. key for US 101 keyboard
Sanjay Tripathi created CLOUDSTACK-7852: --- Summary: EN-US, SC: CentOS CLI & Windows OS: Key translation fails on the Numeric Del. key for US 101 keyboard Key: CLOUDSTACK-7852 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7852 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Environment: Host Server: XenServer6.2SP1 + Hotfix Deploy VMs: CentOS 6.5 CLI mode, EN-Win7x64, SC-Win8.1x64 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Repro Steps: 1. Setup with latest 4.5 code. 2. Bring a CentOS 6.5 CLI VM via Add Instance; Bring the other Windows OS VM via Add Instance. 3. Access both the VMs via Console Proxy from the a physical client machine connected to US 101 Keyboard. Choose “Standard (US) Keyboard” Layout in VNC Proxy. 4. Hit all the keys with US 101 keyboard on vi editor/Notepad Expected Result: All the keys should work fine. Actual Result: Both in CentOS CLI mode and in Win7/Win8.1 VMs, the Numeric Del. key has an unexpected double output. Browser Info: IE/Firefox/Chrome/Safari -> Fail -- This message was sent by Atlassian JIRA (v6.3.4#6332)
