[jira] [Reopened] (CLOUDSTACK-7645) Many instances of "???label.*???"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi reopened CLOUDSTACK-7645: - > Many instances of "???label.*???" > - > > Key: CLOUDSTACK-7645 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7645 > 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: Stephen Turner >Assignee: Mihaela Stoica > Fix For: 4.5.0 > > Attachments: label.app.name.png > > > We have many instances of "\?\?\?label.*\?\?\?" in the UI, including strings > I know were correct recently. (For example, I saw it on the certificate > upload UI, which was recently rewritten). > I think something is wrong with the mechanism rather than individual > translations, so rather than creating a bug for each one, I have bundled them > together in this ticket. Individual tickets are linked from here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7645) Many instances of "???label.*???"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14177966#comment-14177966 ] Rajani Karuturi edited comment on CLOUDSTACK-7645 at 10/21/14 5:30 AM: --- Even after the fix, I am seeing some labels instead of text on welcome page. Attached screenshot. [^label.app.name.png] was (Author: rajanik): I am seeing some labels instead of text on welcome page. Attached screenshot. [^label.app.name.png] > Many instances of "???label.*???" > - > > Key: CLOUDSTACK-7645 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7645 > 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: Stephen Turner >Assignee: Mihaela Stoica > Fix For: 4.5.0 > > Attachments: label.app.name.png > > > We have many instances of "\?\?\?label.*\?\?\?" in the UI, including strings > I know were correct recently. (For example, I saw it on the certificate > upload UI, which was recently rewritten). > I think something is wrong with the mechanism rather than individual > translations, so rather than creating a bug for each one, I have bundled them > together in this ticket. Individual tickets are linked from here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7645) Many instances of "???label.*???"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14177968#comment-14177968 ] Stephen Turner commented on CLOUDSTACK-7645: Thank you for your email. I am on sick leave at the moment. For urgent questions, please contact my manager, andrew.hal...@citrix.com. Thank you very much, -- Stephen Turner Sr Manager, XenServer Citrix > Many instances of "???label.*???" > - > > Key: CLOUDSTACK-7645 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7645 > 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: Stephen Turner >Assignee: Mihaela Stoica > Fix For: 4.5.0 > > Attachments: label.app.name.png > > > We have many instances of "\?\?\?label.*\?\?\?" in the UI, including strings > I know were correct recently. (For example, I saw it on the certificate > upload UI, which was recently rewritten). > I think something is wrong with the mechanism rather than individual > translations, so rather than creating a bug for each one, I have bundled them > together in this ticket. Individual tickets are linked from here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7645) Many instances of "???label.*???"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14177966#comment-14177966 ] Rajani Karuturi edited comment on CLOUDSTACK-7645 at 10/21/14 5:28 AM: --- I am seeing some labels instead of text on welcome page. Attached screenshot. [^label.app.name.png] was (Author: rajanik): I am seeing some labels instead of text on welcome page. Attached screenshot. !label.app.name.png! > Many instances of "???label.*???" > - > > Key: CLOUDSTACK-7645 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7645 > 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: Stephen Turner >Assignee: Mihaela Stoica > Fix For: 4.5.0 > > Attachments: label.app.name.png > > > We have many instances of "\?\?\?label.*\?\?\?" in the UI, including strings > I know were correct recently. (For example, I saw it on the certificate > upload UI, which was recently rewritten). > I think something is wrong with the mechanism rather than individual > translations, so rather than creating a bug for each one, I have bundled them > together in this ticket. Individual tickets are linked from here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7645) Many instances of "???label.*???"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-7645: Attachment: label.app.name.png I am seeing some labels instead of text on welcome page. Attached screenshot. !label.app.name.png! > Many instances of "???label.*???" > - > > Key: CLOUDSTACK-7645 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7645 > 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: Stephen Turner >Assignee: Mihaela Stoica > Fix For: 4.5.0 > > Attachments: label.app.name.png > > > We have many instances of "\?\?\?label.*\?\?\?" in the UI, including strings > I know were correct recently. (For example, I saw it on the certificate > upload UI, which was recently rewritten). > I think something is wrong with the mechanism rather than individual > translations, so rather than creating a bug for each one, I have bundled them > together in this ticket. Individual tickets are linked from here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7754) 'vm_template.source_template_id' of Template created from Snapshot was NULL
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta resolved CLOUDSTACK-7754. - Resolution: Fixed > 'vm_template.source_template_id' of Template created from Snapshot was NULL > > > Key: CLOUDSTACK-7754 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7754 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.5.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.5.0 > > > Here is the procedure to reproduce the issue. This is consistent on my > environment. > Steps: > i) Create instance A > ii) Take snapshot A from instance A > iii) Create template 1 from snapshot A > iv) Delete instance A > v) Create template 2 from snapshot A > Test result: > The issue occurred to template 2 which was created after instance A was > deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7754) 'vm_template.source_template_id' of Template created from Snapshot was NULL
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14177666#comment-14177666 ] ASF subversion and git services commented on CLOUDSTACK-7754: - Commit a72580def0b555f479fbaa093cf4f8d95a8ea756 in cloudstack's branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a72580d ] CLOUDSTACK-7754: Templates source_template_id is null when it is created from Snapshot with its corresponding volume removed. Fix it by searching for volumes including removed. (cherry picked from commit 287ff83552081cd91c68af6214016ca4cc4cc040) > 'vm_template.source_template_id' of Template created from Snapshot was NULL > > > Key: CLOUDSTACK-7754 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7754 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.5.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.5.0 > > > Here is the procedure to reproduce the issue. This is consistent on my > environment. > Steps: > i) Create instance A > ii) Take snapshot A from instance A > iii) Create template 1 from snapshot A > iv) Delete instance A > v) Create template 2 from snapshot A > Test result: > The issue occurred to template 2 which was created after instance A was > deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7754) 'vm_template.source_template_id' of Template created from Snapshot was NULL
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14177665#comment-14177665 ] ASF subversion and git services commented on CLOUDSTACK-7754: - Commit 287ff83552081cd91c68af6214016ca4cc4cc040 in cloudstack's branch refs/heads/4.5 from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=287ff83 ] CLOUDSTACK-7754: Templates source_template_id is null when it is created from Snapshot with its corresponding volume removed. Fix it by searching for volumes including removed. > 'vm_template.source_template_id' of Template created from Snapshot was NULL > > > Key: CLOUDSTACK-7754 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7754 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.5.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.5.0 > > > Here is the procedure to reproduce the issue. This is consistent on my > environment. > Steps: > i) Create instance A > ii) Take snapshot A from instance A > iii) Create template 1 from snapshot A > iv) Delete instance A > v) Create template 2 from snapshot A > Test result: > The issue occurred to template 2 which was created after instance A was > deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7754) 'vm_template.source_template_id' of Template created from Snapshot was NULL
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-7754: Description: Here is the procedure to reproduce the issue. This is consistent on my environment. Steps: i) Create instance A ii) Take snapshot A from instance A iii) Create template 1 from snapshot A iv) Delete instance A v) Create template 2 from snapshot A Test result: The issue occurred to template 2 which was created after instance A was deleted. > 'vm_template.source_template_id' of Template created from Snapshot was NULL > > > Key: CLOUDSTACK-7754 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7754 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.5.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.5.0 > > > Here is the procedure to reproduce the issue. This is consistent on my > environment. > Steps: > i) Create instance A > ii) Take snapshot A from instance A > iii) Create template 1 from snapshot A > iv) Delete instance A > v) Create template 2 from snapshot A > Test result: > The issue occurred to template 2 which was created after instance A was > deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7754) 'vm_template.source_template_id' of Template created from Snapshot was NULL
Nitin Mehta created CLOUDSTACK-7754: --- Summary: 'vm_template.source_template_id' of Template created from Snapshot was NULL Key: CLOUDSTACK-7754 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7754 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Template Affects Versions: 4.5.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.5.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7725) [Automation][HyperV] After sometime System VM 'agents' get disconnected due to Ping Issues and get shut down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-7725: --- Assignee: Devdeep Singh > [Automation][HyperV] After sometime System VM 'agents' get disconnected due > to Ping Issues and get shut down > > > Key: CLOUDSTACK-7725 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7725 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Devdeep Singh >Priority: Blocker > Fix For: 4.5.0 > > Attachments: management-server.zip > > > There is something still wrong with the Agents in System VMs on HyperV Setup. > The System VM agents got disconnected due to Ping Issues and VMs got shut > down. I found this observation when I noticed that all the SSVM Test cases > failed. > Someone has to look at what is happening between management server and agents > communication. I don’t think it is anything wrong with the Setup based on the > success of other test suites. > === > Disconnection Information Log is as shown below: > === > 2014-10-14 19:21:50,378 INFO [c.c.a.m.AgentManagerImpl] > (AgentMonitor-1:ctx-72fa526b) Found the following agents behind on ping: [3, > 4] > 2014-10-14 19:21:50,380 WARN [c.c.a.m.AgentManagerImpl] > (AgentMonitor-1:ctx-72fa526b) Disconnect agent for CPVM/SSVM due to physical > connection close. host: 3 > 2014-10-14 19:21:50,381 INFO [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-5:ctx-693d2497) Host 3 is disconnecting with event PingTimeout > 2014-10-14 19:21:50,382 WARN [c.c.a.m.AgentManagerImpl] > (AgentMonitor-1:ctx-72fa526b) Disconnect agent for CPVM/SSVM due to physical > connection close. host: 4 > 2014-10-14 19:21:50,383 INFO [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-6:ctx-f560f275) Host 4 is disconnecting with event PingTimeout > 2014-10-14 19:21:50,384 DEBUG [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-5:ctx-693d2497) The next status of agent 3 is Alert, current > status is Up > 2014-10-14 19:21:50,384 DEBUG [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-5:ctx-693d2497) Deregistering link for 3 with state Alert > 2014-10-14 19:21:50,384 DEBUG [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-5:ctx-693d2497) Remove Agent : 3 > 2014-10-14 19:21:50,384 DEBUG [c.c.a.m.ConnectedAgentAttache] > (AgentTaskPool-5:ctx-693d2497) Processing Disconnect. > 2014-10-14 19:21:50,384 DEBUG [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-5:ctx-693d2497) Sending Disconnect to listener: > com.cloud.hypervisor.xenserver.discoverer.XcpServerDiscoverer > 2014-10-14 19:21:50,384 DEBUG [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-5:ctx-693d2497) Sending Disconnect to listener: > com.cloud.hypervisor.hyperv.discoverer.HypervServerDiscoverer > 2014-10-14 19:21:50,384 DEBUG [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-5:ctx-693d2497) Sending Disconnect to listener: > com.cloud.storage.secondary.SecondaryStorageListener > 2014-10-14 19:21:50,385 DEBUG [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-6:ctx-f560f275) The next status of agent 4 is Alert, current > status is Up > 2014-10-14 19:21:50,385 DEBUG [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-6:ctx-f560f275) Deregistering link for 4 with state Alert > 2014-10-14 19:21:50,385 DEBUG [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-6:ctx-f560f275) Remove Agent : 4 > 2014-10-14 19:21:50,385 DEBUG [c.c.a.m.ConnectedAgentAttache] > (AgentTaskPool-6:ctx-f560f275) Processing Disconnect. > 2014-10-14 19:21:50,385 DEBUG [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-5:ctx-693d2497) Sending Disconnect to listener: > com.cloud.vm.ClusteredVirtualMachineManagerImpl > 2014-10-14 19:21:50,385 DEBUG [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-5:ctx-693d2497) Sending Disconnect to listener: > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator > 2014-10-14 19:21:50,385 DEBUG [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-5:ctx-693d2497) Sending Disconnect to listener: > com.cloud.storage.listener.StoragePoolMonitor > 2014-10-14 19:21:50,385 DEBUG [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-5:ctx-693d2497) Sending Disconnect to listener: > com.cloud.hypervisor.vmware.manager.VmwareManagerImpl > 2014-10-14 19:21:50,385 DEBUG [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-5:ctx-693d2497) Sending Disconnect to listener: > com.cloud.deploy.DeploymentPlanningManagerImpl > 2014-10-14 19:21:50,385 DEBUG [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-6:ctx-f560f275) Sending Disconnect to listener: > com.cloud.hypervisor.xenserver.discoverer
[jira] [Assigned] (CLOUDSTACK-7753) [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small detecting memory incorrectly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett reassigned CLOUDSTACK-7753: -- Assignee: Chandan Purushothama (was: Alex Brett) [~chandanp] are you able to look at this, if not I might have some time in the next couple of weeks? > [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small > detecting memory incorrectly > - > > Key: CLOUDSTACK-7753 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7753 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Alex Brett >Assignee: Chandan Purushothama >Priority: Critical > Fix For: 4.5.0 > > > Deployed VM has the following memory configuration on the VM: > [root@Atoms-VM-2 ~]# cat /proc/meminfo | grep Mem > MemTotal: 363416 kB > MemFree: 81864 kB > [root@Atoms-VM-2 ~]# > Which is around 354.8984375 MB > But the Service Offering specified specifies 512 MB as shown below: > mysql> select id,name,instance_name,state,service_offering_id from > vm_instance where id=59 \G > id: 59 >name: Atoms-VM-2 > instance_name: i-36-59-VM > state: Running > service_offering_id: 1 > 1 row in set (0.00 sec) > mysql> select * from service_offering where id=1 \G > id: 1 >cpu: 1 > speed: 500 > ram_size: 512 >nw_rate: NULL >mc_rate: NULL > ha_enabled: 0 > limit_cpu_use: 0 > host_tag: NULL >default_use: 0 >vm_type: NULL > sort_key: 0 >is_volatile: 0 > deployment_planner: NULL > 1 row in set (0.00 sec) > mysql> -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7753) [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small detecting memory incorrectly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14176984#comment-14176984 ] Alex Brett commented on CLOUDSTACK-7753: integration.smoke.test_service_offerings.TestServiceOfferings.test_04_change_offering_small is currently failing on HyperV, the bug CLOUDSTACK-7737 was raised from this, however it was determined that cloudstack is doing the right thing, as such we need to fix the Marvin test instead... > [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small > detecting memory incorrectly > - > > Key: CLOUDSTACK-7753 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7753 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Alex Brett >Assignee: Alex Brett >Priority: Critical > Fix For: 4.5.0 > > > Deployed VM has the following memory configuration on the VM: > [root@Atoms-VM-2 ~]# cat /proc/meminfo | grep Mem > MemTotal: 363416 kB > MemFree: 81864 kB > [root@Atoms-VM-2 ~]# > Which is around 354.8984375 MB > But the Service Offering specified specifies 512 MB as shown below: > mysql> select id,name,instance_name,state,service_offering_id from > vm_instance where id=59 \G > id: 59 >name: Atoms-VM-2 > instance_name: i-36-59-VM > state: Running > service_offering_id: 1 > 1 row in set (0.00 sec) > mysql> select * from service_offering where id=1 \G > id: 1 >cpu: 1 > speed: 500 > ram_size: 512 >nw_rate: NULL >mc_rate: NULL > ha_enabled: 0 > limit_cpu_use: 0 > host_tag: NULL >default_use: 0 >vm_type: NULL > sort_key: 0 >is_volatile: 0 > deployment_planner: NULL > 1 row in set (0.00 sec) > mysql> -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7753) [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small detecting memory incorrectly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett reassigned CLOUDSTACK-7753: -- Assignee: Alex Brett (was: Devdeep Singh) > [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small > detecting memory incorrectly > - > > Key: CLOUDSTACK-7753 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7753 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Alex Brett >Assignee: Alex Brett >Priority: Critical > Fix For: 4.5.0 > > > Deployed VM has the following memory configuration on the VM: > [root@Atoms-VM-2 ~]# cat /proc/meminfo | grep Mem > MemTotal: 363416 kB > MemFree: 81864 kB > [root@Atoms-VM-2 ~]# > Which is around 354.8984375 MB > But the Service Offering specified specifies 512 MB as shown below: > mysql> select id,name,instance_name,state,service_offering_id from > vm_instance where id=59 \G > id: 59 >name: Atoms-VM-2 > instance_name: i-36-59-VM > state: Running > service_offering_id: 1 > 1 row in set (0.00 sec) > mysql> select * from service_offering where id=1 \G > id: 1 >cpu: 1 > speed: 500 > ram_size: 512 >nw_rate: NULL >mc_rate: NULL > ha_enabled: 0 > limit_cpu_use: 0 > host_tag: NULL >default_use: 0 >vm_type: NULL > sort_key: 0 >is_volatile: 0 > deployment_planner: NULL > 1 row in set (0.00 sec) > mysql> -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7753) [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small detecting memory incorrectly
Alex Brett created CLOUDSTACK-7753: -- Summary: [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small detecting memory incorrectly Key: CLOUDSTACK-7753 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7753 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Alex Brett Assignee: Devdeep Singh Priority: Critical Fix For: 4.5.0 Deployed VM has the following memory configuration on the VM: [root@Atoms-VM-2 ~]# cat /proc/meminfo | grep Mem MemTotal: 363416 kB MemFree: 81864 kB [root@Atoms-VM-2 ~]# Which is around 354.8984375 MB But the Service Offering specified specifies 512 MB as shown below: mysql> select id,name,instance_name,state,service_offering_id from vm_instance where id=59 \G id: 59 name: Atoms-VM-2 instance_name: i-36-59-VM state: Running service_offering_id: 1 1 row in set (0.00 sec) mysql> select * from service_offering where id=1 \G id: 1 cpu: 1 speed: 500 ram_size: 512 nw_rate: NULL mc_rate: NULL ha_enabled: 0 limit_cpu_use: 0 host_tag: NULL default_use: 0 vm_type: NULL sort_key: 0 is_volatile: 0 deployment_planner: NULL 1 row in set (0.00 sec) mysql> -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6915) Deleting dynamically added OS results in NPE for existing instances using that os type
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar Bandarupally updated CLOUDSTACK-6915: - Environment: XenServer host Cloudstack 4.4 , VmWare host , CloudStack 4.5 was: XenServer host Cloudstack 4.4 > Deleting dynamically added OS results in NPE for existing instances using > that os type > -- > > Key: CLOUDSTACK-6915 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6915 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.4.0, 4.5.0 > Environment: XenServer host > Cloudstack 4.4 , VmWare host , CloudStack 4.5 >Reporter: Pavan Kumar Bandarupally >Assignee: Amogh Vasekar >Priority: Critical > Fix For: 4.4.0, 4.5.0 > > Attachments: VmWareMSLog.log, management-server.log > > > A guest OS is dynamically added and an instance is deployed successfully > using that os type (ISO used to deploy instance was of that OS type). The > custom os added was deleted using removeGuestOS. After this the instance is > stopped and started again. > This start operation resulted in Null Pointer Exception. > 2014-06-16 06:50:33,350 ERROR [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-35:ctx-dd77fc16 job-86/job-87 ctx-331dc1d9) Failed to > start instance VM[User|i-2-12-VM] > java.lang.NullPointerException > at com.cloud.hypervisor.XenServerGuru.implement(XenServerGuru.java:93) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:995) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5180) > 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:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5325) > at > com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > 2014-06-16 06:50:33,359 DEBUG [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-35:ctx-dd77fc16 job-86/job-87 ctx-331dc1d9) Cleaning up > resources for the vm VM[User|i-2-12-VM] in Starting state > PFA MS log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6915) Deleting dynamically added OS results in NPE for existing instances using that os type
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar Bandarupally updated CLOUDSTACK-6915: - Attachment: VmWareMSLog.log > Deleting dynamically added OS results in NPE for existing instances using > that os type > -- > > Key: CLOUDSTACK-6915 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6915 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.4.0, 4.5.0 > Environment: XenServer host > Cloudstack 4.4 >Reporter: Pavan Kumar Bandarupally >Assignee: Amogh Vasekar >Priority: Critical > Fix For: 4.4.0, 4.5.0 > > Attachments: VmWareMSLog.log, management-server.log > > > A guest OS is dynamically added and an instance is deployed successfully > using that os type (ISO used to deploy instance was of that OS type). The > custom os added was deleted using removeGuestOS. After this the instance is > stopped and started again. > This start operation resulted in Null Pointer Exception. > 2014-06-16 06:50:33,350 ERROR [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-35:ctx-dd77fc16 job-86/job-87 ctx-331dc1d9) Failed to > start instance VM[User|i-2-12-VM] > java.lang.NullPointerException > at com.cloud.hypervisor.XenServerGuru.implement(XenServerGuru.java:93) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:995) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5180) > 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:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5325) > at > com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > 2014-06-16 06:50:33,359 DEBUG [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-35:ctx-dd77fc16 job-86/job-87 ctx-331dc1d9) Cleaning up > resources for the vm VM[User|i-2-12-VM] in Starting state > PFA MS log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6915) Deleting dynamically added OS results in NPE for existing instances using that os type
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar Bandarupally updated CLOUDSTACK-6915: - Fix Version/s: 4.5.0 > Deleting dynamically added OS results in NPE for existing instances using > that os type > -- > > Key: CLOUDSTACK-6915 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6915 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.4.0, 4.5.0 > Environment: XenServer host > Cloudstack 4.4 >Reporter: Pavan Kumar Bandarupally >Assignee: Amogh Vasekar >Priority: Critical > Fix For: 4.4.0, 4.5.0 > > Attachments: management-server.log > > > A guest OS is dynamically added and an instance is deployed successfully > using that os type (ISO used to deploy instance was of that OS type). The > custom os added was deleted using removeGuestOS. After this the instance is > stopped and started again. > This start operation resulted in Null Pointer Exception. > 2014-06-16 06:50:33,350 ERROR [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-35:ctx-dd77fc16 job-86/job-87 ctx-331dc1d9) Failed to > start instance VM[User|i-2-12-VM] > java.lang.NullPointerException > at com.cloud.hypervisor.XenServerGuru.implement(XenServerGuru.java:93) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:995) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5180) > 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:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5325) > at > com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > 2014-06-16 06:50:33,359 DEBUG [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-35:ctx-dd77fc16 job-86/job-87 ctx-331dc1d9) Cleaning up > resources for the vm VM[User|i-2-12-VM] in Starting state > PFA MS log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-6915) Deleting dynamically added OS results in NPE for existing instances using that os type
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar Bandarupally reopened CLOUDSTACK-6915: -- I can reproduce the issue on VmWare on 4.5 build. Hence re-opening the issue. > Deleting dynamically added OS results in NPE for existing instances using > that os type > -- > > Key: CLOUDSTACK-6915 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6915 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.4.0, 4.5.0 > Environment: XenServer host > Cloudstack 4.4 >Reporter: Pavan Kumar Bandarupally >Assignee: Amogh Vasekar >Priority: Critical > Fix For: 4.4.0, 4.5.0 > > Attachments: management-server.log > > > A guest OS is dynamically added and an instance is deployed successfully > using that os type (ISO used to deploy instance was of that OS type). The > custom os added was deleted using removeGuestOS. After this the instance is > stopped and started again. > This start operation resulted in Null Pointer Exception. > 2014-06-16 06:50:33,350 ERROR [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-35:ctx-dd77fc16 job-86/job-87 ctx-331dc1d9) Failed to > start instance VM[User|i-2-12-VM] > java.lang.NullPointerException > at com.cloud.hypervisor.XenServerGuru.implement(XenServerGuru.java:93) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:995) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5180) > 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:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5325) > at > com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > 2014-06-16 06:50:33,359 DEBUG [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-35:ctx-dd77fc16 job-86/job-87 ctx-331dc1d9) Cleaning up > resources for the vm VM[User|i-2-12-VM] in Starting state > PFA MS log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6915) Deleting dynamically added OS results in NPE for existing instances using that os type
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar Bandarupally updated CLOUDSTACK-6915: - Affects Version/s: 4.5.0 > Deleting dynamically added OS results in NPE for existing instances using > that os type > -- > > Key: CLOUDSTACK-6915 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6915 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.4.0, 4.5.0 > Environment: XenServer host > Cloudstack 4.4 >Reporter: Pavan Kumar Bandarupally >Assignee: Amogh Vasekar >Priority: Critical > Fix For: 4.4.0, 4.5.0 > > Attachments: management-server.log > > > A guest OS is dynamically added and an instance is deployed successfully > using that os type (ISO used to deploy instance was of that OS type). The > custom os added was deleted using removeGuestOS. After this the instance is > stopped and started again. > This start operation resulted in Null Pointer Exception. > 2014-06-16 06:50:33,350 ERROR [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-35:ctx-dd77fc16 job-86/job-87 ctx-331dc1d9) Failed to > start instance VM[User|i-2-12-VM] > java.lang.NullPointerException > at com.cloud.hypervisor.XenServerGuru.implement(XenServerGuru.java:93) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:995) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5180) > 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:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5325) > at > com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > 2014-06-16 06:50:33,359 DEBUG [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-35:ctx-dd77fc16 job-86/job-87 ctx-331dc1d9) Cleaning up > resources for the vm VM[User|i-2-12-VM] in Starting state > PFA MS log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6578) DeleteRemoteAccessVpnCmd failed block enable Remote VPN access again on the IP address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14176866#comment-14176866 ] Jayapal Reddy commented on CLOUDSTACK-6578: --- Problem: --- When enable the Remote VPN access on a particular IP address, report error "A Remote Access VPN already exists for this public Ip address" Root Cause Analysis: --- Configured remote access vpn on public ip and it is failed in the backend due to resource unreachable. The state entry in db 'remote_access_vpn' is marked as 'Running' (previous state). Due to this on the same public ip UI shows option to enable. Proposed solution: --- On remote access vpn failure state should be set to previous state that is Running . Verification steps: -- 1. configure the remote access vpn on public ip. 2. enable vpn is failed on public ip due to resource unreachable. (You can tweak router script to return error or put host in alert state) The status entry in db is marked as 'Removed'. Due to this on the same public ip UI shows option to enable. But in back end remote access vpn is not stopped. 3. Now in UI it should show status as enabled. If you try to enable it show the error message got from back end. Second way: 1. Enable remote access gateway on on public ip 2. Set up the state to 'Removed' in DB 3. Go to UI, it allow you enable.If you enable then it should shows error in UI. > DeleteRemoteAccessVpnCmd failed block enable Remote VPN access again on the > IP address > -- > > Key: CLOUDSTACK-6578 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6578 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Fix For: 4.4.0 > > > 1. configure the remote access vpn on public ip. > 2. enable vpn is failed on public ip due to resource unreachable. The status > entry in db is marked as 'Removed'. Due to this on the same public ip UI > shows option to enable. > On remote access vpn failure db should be cleaned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7703) Cloudstack server endless loop when trying to create a volume while storage pool is full
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14176846#comment-14176846 ] Anshul Gangwar commented on CLOUDSTACK-7703: This sounds similar to issue https://issues.apache.org/jira/browse/CLOUDSTACK-7752. I have fixed that for master and created the patch https://reviews.apache.org/r/26923/. As a workaround create a VM first and then attach data disk later after VM creation. > Cloudstack server endless loop when trying to create a volume while storage > pool is full > > > Key: CLOUDSTACK-7703 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7703 > 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: Centos 6.5 >Reporter: JF Vincent >Priority: Critical > Fix For: 4.5.0 > > > When trying to create a VM, and thus a volume for it and the primary storage > is full (over 90%), the managament server enter in and endless loop (extract > below) and we have to restart it to exit this loop. > 2014-10-14 11:39:20,701 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found for > volume: Vol[5436|vm=5855|DATADISK] under cluster: 2 > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable storagePools found > under this Cluster: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Could not find suitable > Deployment Destination for this VM under any clusters, returning. > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Searching all possible resources > under this Zone: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Listing clusters in order of > aggregate capacity, that have (atleast one host with) enough CPU and RAM > capacity under this Zone: 2 > 2014-10-14 11:39:20,707 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Removing from the clusterId list > these clusters from avoid set: [] > 2014-10-14 11:39:20,714 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Checking resources in Cluster: 2 > under Pod: 2 > 2014-10-14 11:39:20,714 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for hosts in dc: 2 pod:2 cluster:2 > 2014-10-14 11:39:20,716 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) > FirstFitAllocator has 3 hosts to check for allocation: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Found 3 > hosts for allocation after prioritization: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for speed=500Mhz, Ram=500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host: 79 > has cpu capability (cpu:8, speed:2399) to support requested CPU: 1 and > requested speed: 500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Checking > if host: 79 has enough capacity for requested CPU: 500 and requested RAM: > 524288000 , cpuOverprovisioningFactor: 4.0 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Hosts's > actual total CPU: 19192 and CPU after applying overprovisioning: 76768 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > CPU: 57268 , Requested CPU: 500 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > RAM: 93916725248 , Requested RAM: 524288000 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ct
[jira] [Assigned] (CLOUDSTACK-7703) Cloudstack server endless loop when trying to create a volume while storage pool is full
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar reassigned CLOUDSTACK-7703: -- Assignee: Anshul Gangwar > Cloudstack server endless loop when trying to create a volume while storage > pool is full > > > Key: CLOUDSTACK-7703 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7703 > 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: Centos 6.5 >Reporter: JF Vincent >Assignee: Anshul Gangwar >Priority: Critical > Fix For: 4.5.0 > > > When trying to create a VM, and thus a volume for it and the primary storage > is full (over 90%), the managament server enter in and endless loop (extract > below) and we have to restart it to exit this loop. > 2014-10-14 11:39:20,701 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found for > volume: Vol[5436|vm=5855|DATADISK] under cluster: 2 > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable storagePools found > under this Cluster: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Could not find suitable > Deployment Destination for this VM under any clusters, returning. > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Searching all possible resources > under this Zone: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Listing clusters in order of > aggregate capacity, that have (atleast one host with) enough CPU and RAM > capacity under this Zone: 2 > 2014-10-14 11:39:20,707 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Removing from the clusterId list > these clusters from avoid set: [] > 2014-10-14 11:39:20,714 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Checking resources in Cluster: 2 > under Pod: 2 > 2014-10-14 11:39:20,714 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for hosts in dc: 2 pod:2 cluster:2 > 2014-10-14 11:39:20,716 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) > FirstFitAllocator has 3 hosts to check for allocation: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Found 3 > hosts for allocation after prioritization: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for speed=500Mhz, Ram=500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host: 79 > has cpu capability (cpu:8, speed:2399) to support requested CPU: 1 and > requested speed: 500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Checking > if host: 79 has enough capacity for requested CPU: 500 and requested RAM: > 524288000 , cpuOverprovisioningFactor: 4.0 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Hosts's > actual total CPU: 19192 and CPU after applying overprovisioning: 76768 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > CPU: 57268 , Requested CPU: 500 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > RAM: 93916725248 , Requested RAM: 524288000 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host has > enough CPU and RAM available > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) STATS: > Can
[jira] [Updated] (CLOUDSTACK-7703) Cloudstack server endless loop when trying to create a volume while storage pool is full
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar updated CLOUDSTACK-7703: --- Fix Version/s: 4.5.0 > Cloudstack server endless loop when trying to create a volume while storage > pool is full > > > Key: CLOUDSTACK-7703 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7703 > 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: Centos 6.5 >Reporter: JF Vincent >Assignee: Anshul Gangwar >Priority: Critical > Fix For: 4.5.0 > > > When trying to create a VM, and thus a volume for it and the primary storage > is full (over 90%), the managament server enter in and endless loop (extract > below) and we have to restart it to exit this loop. > 2014-10-14 11:39:20,701 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found for > volume: Vol[5436|vm=5855|DATADISK] under cluster: 2 > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable storagePools found > under this Cluster: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Could not find suitable > Deployment Destination for this VM under any clusters, returning. > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Searching all possible resources > under this Zone: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Listing clusters in order of > aggregate capacity, that have (atleast one host with) enough CPU and RAM > capacity under this Zone: 2 > 2014-10-14 11:39:20,707 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Removing from the clusterId list > these clusters from avoid set: [] > 2014-10-14 11:39:20,714 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Checking resources in Cluster: 2 > under Pod: 2 > 2014-10-14 11:39:20,714 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for hosts in dc: 2 pod:2 cluster:2 > 2014-10-14 11:39:20,716 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) > FirstFitAllocator has 3 hosts to check for allocation: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Found 3 > hosts for allocation after prioritization: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for speed=500Mhz, Ram=500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host: 79 > has cpu capability (cpu:8, speed:2399) to support requested CPU: 1 and > requested speed: 500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Checking > if host: 79 has enough capacity for requested CPU: 500 and requested RAM: > 524288000 , cpuOverprovisioningFactor: 4.0 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Hosts's > actual total CPU: 19192 and CPU after applying overprovisioning: 76768 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > CPU: 57268 , Requested CPU: 500 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > RAM: 93916725248 , Requested RAM: 524288000 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host has > enough CPU and RAM available > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) STATS: > Can alloc CPU
[jira] [Created] (CLOUDSTACK-7752) Management Server goes in infinite loop while creating a vm with tagged local data disk when the pool is not tagged
Anshul Gangwar created CLOUDSTACK-7752: -- Summary: Management Server goes in infinite loop while creating a vm with tagged local data disk when the pool is not tagged Key: CLOUDSTACK-7752 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7752 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Steps to reproduce: Setup must have a single cluster with both local and shared storage. 1) Create a local disk offering and tag it T1 2) Deploy vm with shared root disk and local data disk Management server goes in an infinite loop. The vm is never started/expunged. Also this causes vmops.log size to go very high. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7703) Cloudstack server endless loop when trying to create a volume while storage pool is full
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14176819#comment-14176819 ] JF Vincent commented on CLOUDSTACK-7703: two storage pools. One local and one NFS ROOT disks are always local. Add-on disks are from the NFS pool. Yes we create them with two disks. > Cloudstack server endless loop when trying to create a volume while storage > pool is full > > > Key: CLOUDSTACK-7703 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7703 > 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: Centos 6.5 >Reporter: JF Vincent >Priority: Critical > > When trying to create a VM, and thus a volume for it and the primary storage > is full (over 90%), the managament server enter in and endless loop (extract > below) and we have to restart it to exit this loop. > 2014-10-14 11:39:20,701 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found for > volume: Vol[5436|vm=5855|DATADISK] under cluster: 2 > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable storagePools found > under this Cluster: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Could not find suitable > Deployment Destination for this VM under any clusters, returning. > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Searching all possible resources > under this Zone: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Listing clusters in order of > aggregate capacity, that have (atleast one host with) enough CPU and RAM > capacity under this Zone: 2 > 2014-10-14 11:39:20,707 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Removing from the clusterId list > these clusters from avoid set: [] > 2014-10-14 11:39:20,714 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Checking resources in Cluster: 2 > under Pod: 2 > 2014-10-14 11:39:20,714 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for hosts in dc: 2 pod:2 cluster:2 > 2014-10-14 11:39:20,716 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) > FirstFitAllocator has 3 hosts to check for allocation: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Found 3 > hosts for allocation after prioritization: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for speed=500Mhz, Ram=500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host: 79 > has cpu capability (cpu:8, speed:2399) to support requested CPU: 1 and > requested speed: 500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Checking > if host: 79 has enough capacity for requested CPU: 500 and requested RAM: > 524288000 , cpuOverprovisioningFactor: 4.0 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Hosts's > actual total CPU: 19192 and CPU after applying overprovisioning: 76768 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > CPU: 57268 , Requested CPU: 500 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > RAM: 93916725248 , Requested RAM: 524288000 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host has > enough CPU and RAM available > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl]
[jira] [Comment Edited] (CLOUDSTACK-7703) Cloudstack server endless loop when trying to create a volume while storage pool is full
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14176812#comment-14176812 ] Anshul Gangwar edited comment on CLOUDSTACK-7703 at 10/20/14 11:17 AM: --- I didn't get you. How many storage pools do you have? What kind of are they (shared or local)? With what offerings are you creating the VM( service offering and/or disk offering)? What kind of storage do those offerings have (shared or local)? Are you creating VM with two disks(root disk and data disk)? was (Author: anshulg): I didn't get you. So are you creating VM with two disks(root disk and data disk)? Do they both have shared storage offering( root disk from service offering and data disk from disk offering) ? > Cloudstack server endless loop when trying to create a volume while storage > pool is full > > > Key: CLOUDSTACK-7703 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7703 > 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: Centos 6.5 >Reporter: JF Vincent >Priority: Critical > > When trying to create a VM, and thus a volume for it and the primary storage > is full (over 90%), the managament server enter in and endless loop (extract > below) and we have to restart it to exit this loop. > 2014-10-14 11:39:20,701 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found for > volume: Vol[5436|vm=5855|DATADISK] under cluster: 2 > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable storagePools found > under this Cluster: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Could not find suitable > Deployment Destination for this VM under any clusters, returning. > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Searching all possible resources > under this Zone: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Listing clusters in order of > aggregate capacity, that have (atleast one host with) enough CPU and RAM > capacity under this Zone: 2 > 2014-10-14 11:39:20,707 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Removing from the clusterId list > these clusters from avoid set: [] > 2014-10-14 11:39:20,714 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Checking resources in Cluster: 2 > under Pod: 2 > 2014-10-14 11:39:20,714 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for hosts in dc: 2 pod:2 cluster:2 > 2014-10-14 11:39:20,716 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) > FirstFitAllocator has 3 hosts to check for allocation: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Found 3 > hosts for allocation after prioritization: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for speed=500Mhz, Ram=500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host: 79 > has cpu capability (cpu:8, speed:2399) to support requested CPU: 1 and > requested speed: 500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Checking > if host: 79 has enough capacity for requested CPU: 500 and requested RAM: > 524288000 , cpuOverprovisioningFactor: 4.0 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Hosts's > actual total CPU: 19192 and CPU after applying overprovisioning: 76768 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > CPU: 57268 , Req
[jira] [Commented] (CLOUDSTACK-7703) Cloudstack server endless loop when trying to create a volume while storage pool is full
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14176812#comment-14176812 ] Anshul Gangwar commented on CLOUDSTACK-7703: I didn't get you. So are you creating VM with two disks(root disk and data disk)? Do they both have shared storage offering( root disk from service offering and data disk from disk offering) ? > Cloudstack server endless loop when trying to create a volume while storage > pool is full > > > Key: CLOUDSTACK-7703 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7703 > 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: Centos 6.5 >Reporter: JF Vincent >Priority: Critical > > When trying to create a VM, and thus a volume for it and the primary storage > is full (over 90%), the managament server enter in and endless loop (extract > below) and we have to restart it to exit this loop. > 2014-10-14 11:39:20,701 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found for > volume: Vol[5436|vm=5855|DATADISK] under cluster: 2 > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable storagePools found > under this Cluster: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Could not find suitable > Deployment Destination for this VM under any clusters, returning. > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Searching all possible resources > under this Zone: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Listing clusters in order of > aggregate capacity, that have (atleast one host with) enough CPU and RAM > capacity under this Zone: 2 > 2014-10-14 11:39:20,707 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Removing from the clusterId list > these clusters from avoid set: [] > 2014-10-14 11:39:20,714 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Checking resources in Cluster: 2 > under Pod: 2 > 2014-10-14 11:39:20,714 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for hosts in dc: 2 pod:2 cluster:2 > 2014-10-14 11:39:20,716 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) > FirstFitAllocator has 3 hosts to check for allocation: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Found 3 > hosts for allocation after prioritization: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for speed=500Mhz, Ram=500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host: 79 > has cpu capability (cpu:8, speed:2399) to support requested CPU: 1 and > requested speed: 500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Checking > if host: 79 has enough capacity for requested CPU: 500 and requested RAM: > 524288000 , cpuOverprovisioningFactor: 4.0 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Hosts's > actual total CPU: 19192 and CPU after applying overprovisioning: 76768 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > CPU: 57268 , Requested CPU: 500 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > RAM: 93916725248 , Requested RAM: 524288000 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host has > enough CPU and RAM available >
[jira] [Commented] (CLOUDSTACK-7703) Cloudstack server endless loop when trying to create a volume while storage pool is full
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14176804#comment-14176804 ] JF Vincent commented on CLOUDSTACK-7703: The problem occurs once we add a NFS storage on a local root VOLUME. The NFS pool is almost full. Problem is the same with VM creation with local root / NFS volume. Problem occurs when the volume is implented. Regards > Cloudstack server endless loop when trying to create a volume while storage > pool is full > > > Key: CLOUDSTACK-7703 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7703 > 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: Centos 6.5 >Reporter: JF Vincent >Priority: Critical > > When trying to create a VM, and thus a volume for it and the primary storage > is full (over 90%), the managament server enter in and endless loop (extract > below) and we have to restart it to exit this loop. > 2014-10-14 11:39:20,701 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found for > volume: Vol[5436|vm=5855|DATADISK] under cluster: 2 > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable storagePools found > under this Cluster: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Could not find suitable > Deployment Destination for this VM under any clusters, returning. > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Searching all possible resources > under this Zone: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Listing clusters in order of > aggregate capacity, that have (atleast one host with) enough CPU and RAM > capacity under this Zone: 2 > 2014-10-14 11:39:20,707 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Removing from the clusterId list > these clusters from avoid set: [] > 2014-10-14 11:39:20,714 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Checking resources in Cluster: 2 > under Pod: 2 > 2014-10-14 11:39:20,714 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for hosts in dc: 2 pod:2 cluster:2 > 2014-10-14 11:39:20,716 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) > FirstFitAllocator has 3 hosts to check for allocation: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Found 3 > hosts for allocation after prioritization: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for speed=500Mhz, Ram=500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host: 79 > has cpu capability (cpu:8, speed:2399) to support requested CPU: 1 and > requested speed: 500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Checking > if host: 79 has enough capacity for requested CPU: 500 and requested RAM: > 524288000 , cpuOverprovisioningFactor: 4.0 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Hosts's > actual total CPU: 19192 and CPU after applying overprovisioning: 76768 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > CPU: 57268 , Requested CPU: 500 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > RAM: 93916725248 , Requested RAM: 524288000 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host has > enough CPU and RAM
[jira] [Created] (CLOUDSTACK-7751) Autoscaling without netscaler
lasantha jayasinghe created CLOUDSTACK-7751: --- Summary: Autoscaling without netscaler Key: CLOUDSTACK-7751 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7751 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.1 Reporter: lasantha jayasinghe Priority: Critical Auto scaling wizard not available apache cloudstack 4.4.1. no auto scale button available -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7703) Cloudstack server endless loop when trying to create a volume while storage pool is full
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14176763#comment-14176763 ] Anshul Gangwar edited comment on CLOUDSTACK-7703 at 10/20/14 10:29 AM: --- Vincent, What kind of storage pools are you using? Is it shared pool or local storage or both type of storage pools in clusters? Also have you tried to attach disk during VM creation? was (Author: anshulg): Vincent, What kind of storage pools are you using? Is it shared pool or local storage or both type of storage pools in clusters? > Cloudstack server endless loop when trying to create a volume while storage > pool is full > > > Key: CLOUDSTACK-7703 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7703 > 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: Centos 6.5 >Reporter: JF Vincent >Priority: Critical > > When trying to create a VM, and thus a volume for it and the primary storage > is full (over 90%), the managament server enter in and endless loop (extract > below) and we have to restart it to exit this loop. > 2014-10-14 11:39:20,701 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found for > volume: Vol[5436|vm=5855|DATADISK] under cluster: 2 > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable storagePools found > under this Cluster: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Could not find suitable > Deployment Destination for this VM under any clusters, returning. > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Searching all possible resources > under this Zone: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Listing clusters in order of > aggregate capacity, that have (atleast one host with) enough CPU and RAM > capacity under this Zone: 2 > 2014-10-14 11:39:20,707 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Removing from the clusterId list > these clusters from avoid set: [] > 2014-10-14 11:39:20,714 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Checking resources in Cluster: 2 > under Pod: 2 > 2014-10-14 11:39:20,714 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for hosts in dc: 2 pod:2 cluster:2 > 2014-10-14 11:39:20,716 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) > FirstFitAllocator has 3 hosts to check for allocation: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Found 3 > hosts for allocation after prioritization: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for speed=500Mhz, Ram=500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host: 79 > has cpu capability (cpu:8, speed:2399) to support requested CPU: 1 and > requested speed: 500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Checking > if host: 79 has enough capacity for requested CPU: 500 and requested RAM: > 524288000 , cpuOverprovisioningFactor: 4.0 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Hosts's > actual total CPU: 19192 and CPU after applying overprovisioning: 76768 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > CPU: 57268 , Requested CPU: 500 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > RAM: 93916725248 , Requested RAM:
[jira] [Commented] (CLOUDSTACK-7703) Cloudstack server endless loop when trying to create a volume while storage pool is full
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14176763#comment-14176763 ] Anshul Gangwar commented on CLOUDSTACK-7703: Vincent, What kind of storage pools are you using? Is it shared pool or local storage or both type of storage pools in clusters? > Cloudstack server endless loop when trying to create a volume while storage > pool is full > > > Key: CLOUDSTACK-7703 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7703 > 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: Centos 6.5 >Reporter: JF Vincent >Priority: Critical > > When trying to create a VM, and thus a volume for it and the primary storage > is full (over 90%), the managament server enter in and endless loop (extract > below) and we have to restart it to exit this loop. > 2014-10-14 11:39:20,701 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found for > volume: Vol[5436|vm=5855|DATADISK] under cluster: 2 > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found > 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable storagePools found > under this Cluster: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Could not find suitable > Deployment Destination for this VM under any clusters, returning. > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Searching all possible resources > under this Zone: 2 > 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Listing clusters in order of > aggregate capacity, that have (atleast one host with) enough CPU and RAM > capacity under this Zone: 2 > 2014-10-14 11:39:20,707 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Removing from the clusterId list > these clusters from avoid set: [] > 2014-10-14 11:39:20,714 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Checking resources in Cluster: 2 > under Pod: 2 > 2014-10-14 11:39:20,714 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for hosts in dc: 2 pod:2 cluster:2 > 2014-10-14 11:39:20,716 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) > FirstFitAllocator has 3 hosts to check for allocation: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Found 3 > hosts for allocation after prioritization: [Host[-79-Routing], > Host[-89-Routing], Host[-77-Routing]] > 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking > for speed=500Mhz, Ram=500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host: 79 > has cpu capability (cpu:8, speed:2399) to support requested CPU: 1 and > requested speed: 500 > 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Checking > if host: 79 has enough capacity for requested CPU: 500 and requested RAM: > 524288000 , cpuOverprovisioningFactor: 4.0 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Hosts's > actual total CPU: 19192 and CPU after applying overprovisioning: 76768 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > CPU: 57268 , Requested CPU: 500 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free > RAM: 93916725248 , Requested RAM: 524288000 > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host has > enough CPU and RAM available > 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] >
[jira] [Commented] (CLOUDSTACK-7737) [Automation] [HyperV] Deployed VM is not respecting the memory configuration specified in the service offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14176740#comment-14176740 ] Devdeep Singh commented on CLOUDSTACK-7737: --- I spoke to Chandan and had a look at his setup. Hyper-v agent is assigning the right memory to the vm. Even running a powershell command is reporting the expected memory PS C:\Users\Administrator.XSQA> Get-VMMemory i-36-59-VM VMName DynamicMemoryEnabled Minimum(M) Startup(M) Maximum(M) -- -- -- -- i-36-59-VM False512512512 PS C:\Users\Administrator.XSQA> Get-VMMemory i-2-60-VM VMNameDynamicMemoryEnabled Minimum(M) Startup(M) Maximum(M) -- -- -- -- i-2-60-VM False1024 1024 1024 Here the first VM is the one created by automation run and the second one is the one I created with a Medium service offering. The default CentOS template created for hyper-v is enabled with GUI. Maybe the memory is being used by video ram. On my local setup I created an instance with GUI and reported of 494 MB for a Small service offering when I checked in /proc/meminfo inside the VM. So I don’t think it is an issue here. > [Automation] [HyperV] Deployed VM is not respecting the memory configuration > specified in the service offering > -- > > Key: CLOUDSTACK-7737 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7737 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Devdeep Singh >Priority: Critical > Fix For: 4.5.0 > > > Deployed VM has the following memory configuration on the VM: > [root@Atoms-VM-2 ~]# cat /proc/meminfo | grep Mem > MemTotal: 363416 kB > MemFree: 81864 kB > [root@Atoms-VM-2 ~]# > Which is around 354.8984375 MB > But the Service Offering specified specifies 512 MB as shown below: > mysql> select id,name,instance_name,state,service_offering_id from > vm_instance where id=59 \G > id: 59 >name: Atoms-VM-2 > instance_name: i-36-59-VM > state: Running > service_offering_id: 1 > 1 row in set (0.00 sec) > mysql> select * from service_offering where id=1 \G > id: 1 >cpu: 1 > speed: 500 > ram_size: 512 >nw_rate: NULL >mc_rate: NULL > ha_enabled: 0 > limit_cpu_use: 0 > host_tag: NULL >default_use: 0 >vm_type: NULL > sort_key: 0 >is_volatile: 0 > deployment_planner: NULL > 1 row in set (0.00 sec) > mysql> -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7737) [Automation] [HyperV] Deployed VM is not respecting the memory configuration specified in the service offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devdeep Singh resolved CLOUDSTACK-7737. --- Resolution: Not a Problem > [Automation] [HyperV] Deployed VM is not respecting the memory configuration > specified in the service offering > -- > > Key: CLOUDSTACK-7737 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7737 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Devdeep Singh >Priority: Critical > Fix For: 4.5.0 > > > Deployed VM has the following memory configuration on the VM: > [root@Atoms-VM-2 ~]# cat /proc/meminfo | grep Mem > MemTotal: 363416 kB > MemFree: 81864 kB > [root@Atoms-VM-2 ~]# > Which is around 354.8984375 MB > But the Service Offering specified specifies 512 MB as shown below: > mysql> select id,name,instance_name,state,service_offering_id from > vm_instance where id=59 \G > id: 59 >name: Atoms-VM-2 > instance_name: i-36-59-VM > state: Running > service_offering_id: 1 > 1 row in set (0.00 sec) > mysql> select * from service_offering where id=1 \G > id: 1 >cpu: 1 > speed: 500 > ram_size: 512 >nw_rate: NULL >mc_rate: NULL > ha_enabled: 0 > limit_cpu_use: 0 > host_tag: NULL >default_use: 0 >vm_type: NULL > sort_key: 0 >is_volatile: 0 > deployment_planner: NULL > 1 row in set (0.00 sec) > mysql> -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7719) [UI] Notification shows wrong error message after Scalling up failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihaela Stoica resolved CLOUDSTACK-7719. Resolution: Duplicate Duplicates CLOUDSTACK-7744 > [UI] Notification shows wrong error message after Scalling up failed > > > Key: CLOUDSTACK-7719 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7719 > 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: Mihaela Stoica >Assignee: Mihaela Stoica >Priority: Minor > Fix For: 4.5.0 > > Attachments: screenshot-1.png > > > Try to scale up vm by changing the service offering to a custom offering and > provide invalid values like Memory = 1 > Expected: > > scaling up fails and the notification shows correct message > Actual: > === > scaling up fails but notification shows "instance scaled up". > See attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7724) [Automation][HyperV] Unable to migrate VM due to JsonParseException: The JsonDeserializer EnumTypeAdapter failed to deserialize json object "Running"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Devdeep Singh resolved CLOUDSTACK-7724.
---
Resolution: Duplicate
> [Automation][HyperV] Unable to migrate VM due to JsonParseException: The
> JsonDeserializer EnumTypeAdapter failed to deserialize json object "Running"
> -
>
> Key: CLOUDSTACK-7724
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7724
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Devdeep Singh
>Priority: Critical
> Fix For: 4.5.0
>
>
> =
> JsonParseException: The JsonDeserializer EnumTypeAdapter failed to
> deserialize json object "Running"
> =
> 2014-10-14 19:34:47,983 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-65:ctx-81e9b15c job-191/job-192 ctx-b908f714) Seq
> 1-5051068457072722114: Sending { Cmd , MgmtId: 192182403311206, via:
> 1(10.81.56.124), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CheckVirtualMachineCommand":{"vmName":"i-16-36-VM","wait":20}}]
> }
> 2014-10-14 19:34:47,983 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-65:ctx-81e9b15c job-191/job-192 ctx-b908f714) Seq
> 1-5051068457072722114: Executing: { Cmd , MgmtId: 192182403311206, via:
> 1(10.81.56.124), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CheckVirtualMachineCommand":{"vmName":"i-16-36-VM","wait":20}}]
> }
> 2014-10-14 19:34:47,983 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-110:ctx-409b4476) Seq 1-5051068457072722114: Executing request
> 2014-10-14 19:34:47,984 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-110:ctx-409b4476) POST request to
> https://10.81.56.124:8250/api/HypervResource/com.cloud.agent.api.CheckVirtualMachineCommand
> with contents
> {"vmName":"i-16-36-VM","contextMap":{"job":"job-191/job-192"},"wait":20}
> 2014-10-14 19:34:47,990 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-110:ctx-409b4476) Sending cmd to
> https://10.81.56.124:8250/api/HypervResource/com.cloud.agent.api.CheckVirtualMachineCommand
> cmd
> data:{"vmName":"i-16-36-VM","contextMap":{"job":"job-191/job-192"},"wait":20}
> 2014-10-14 19:34:48,099 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-110:ctx-409b4476) POST response is
> [{"com.cloud.agent.api.CheckVirtualMachineAnswer":{"result":true,"details":null,"state":"Running","contextMap":{}}}]
> 2014-10-14 19:34:48,148 WARN [c.c.a.m.DirectAgentAttache]
> (DirectAgent-110:ctx-409b4476) Seq 1-5051068457072722114: Throwable caught
> while executing command
> com.google.gson.JsonParseException: The JsonDeserializer EnumTypeAdapter
> failed to deserialize json object "Running" given the type class
> com.cloud.vm.VirtualMachine$PowerState
> at
> com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDeserializerExceptionWrapper.java:64)
> at
> com.google.gson.JsonDeserializationVisitor.invokeCustomDeserializer(JsonDeserializationVisitor.java:92)
> at
> com.google.gson.JsonObjectDeserializationVisitor.visitFieldUsingCustomHandler(JsonObjectDeserializationVisitor.java:117)
> at
> com.google.gson.ReflectingFieldNavigator.visitFieldsReflectively(ReflectingFieldNavigator.java:63)
> at com.google.gson.ObjectNavigator.accept(ObjectNavigator.java:120)
> at
> com.google.gson.JsonDeserializationContextDefault.fromJsonObject(JsonDeserializationContextDefault.java:76)
> at
> com.google.gson.JsonDeserializationContextDefault.deserialize(JsonDeserializationContextDefault.java:54)
> at com.google.gson.Gson.fromJson(Gson.java:551)
> at com.google.gson.Gson.fromJson(Gson.java:521)
> at
> com.cloud.agent.transport.ArrayTypeAdaptor.deserialize(ArrayTypeAdaptor.java:80)
> at
> com.cloud.agent.transport.ArrayTypeAdaptor.deserialize(ArrayTypeAdaptor.java:40)
> at
> com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDeserializerExceptionWrapper.java:51)
> at
> com.google.gson.JsonDeserializationVisitor.invokeCustomDeserializer(JsonDeserializationVisitor.java:92)
> at
> com.google.gson.JsonDeserializationVisitor.visitUsingCustomHandler(JsonDeserializationVisitor.java:80)
> at com.google.gson.ObjectNavigator.accept(ObjectNavigator.java:101)
> at
> com.google.gson.JsonDeserializationContextDefault.fromJsonArray(JsonDeserializationContextDefault.java:67)
> at
> com.google.gson.JsonDeserializationContextDefault.deserialize(JsonDes
[jira] [Commented] (CLOUDSTACK-7724) [Automation][HyperV] Unable to migrate VM due to JsonParseException: The JsonDeserializer EnumTypeAdapter failed to deserialize json object "Running"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14176732#comment-14176732
]
Devdeep Singh commented on CLOUDSTACK-7724:
---
I had already fixed this issue in commit
5350e61187d5b2f9fdc997dcc9fea34ff68148f7 on 19th September. The issue was fixed
against bug CLOUDSTACK-7494. The fix was in hyper-v agent. Hyper-v hosts are
probably running an older agent. This is the reason they are returning the
wrong state of the VM instead of the power state.
If you build and install the latest hyper-v agent, migration should be
successful. I tried it on a fresh setup and it was successful.
> [Automation][HyperV] Unable to migrate VM due to JsonParseException: The
> JsonDeserializer EnumTypeAdapter failed to deserialize json object "Running"
> -
>
> Key: CLOUDSTACK-7724
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7724
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Devdeep Singh
>Priority: Critical
> Fix For: 4.5.0
>
>
> =
> JsonParseException: The JsonDeserializer EnumTypeAdapter failed to
> deserialize json object "Running"
> =
> 2014-10-14 19:34:47,983 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-65:ctx-81e9b15c job-191/job-192 ctx-b908f714) Seq
> 1-5051068457072722114: Sending { Cmd , MgmtId: 192182403311206, via:
> 1(10.81.56.124), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CheckVirtualMachineCommand":{"vmName":"i-16-36-VM","wait":20}}]
> }
> 2014-10-14 19:34:47,983 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-65:ctx-81e9b15c job-191/job-192 ctx-b908f714) Seq
> 1-5051068457072722114: Executing: { Cmd , MgmtId: 192182403311206, via:
> 1(10.81.56.124), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CheckVirtualMachineCommand":{"vmName":"i-16-36-VM","wait":20}}]
> }
> 2014-10-14 19:34:47,983 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-110:ctx-409b4476) Seq 1-5051068457072722114: Executing request
> 2014-10-14 19:34:47,984 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-110:ctx-409b4476) POST request to
> https://10.81.56.124:8250/api/HypervResource/com.cloud.agent.api.CheckVirtualMachineCommand
> with contents
> {"vmName":"i-16-36-VM","contextMap":{"job":"job-191/job-192"},"wait":20}
> 2014-10-14 19:34:47,990 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-110:ctx-409b4476) Sending cmd to
> https://10.81.56.124:8250/api/HypervResource/com.cloud.agent.api.CheckVirtualMachineCommand
> cmd
> data:{"vmName":"i-16-36-VM","contextMap":{"job":"job-191/job-192"},"wait":20}
> 2014-10-14 19:34:48,099 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-110:ctx-409b4476) POST response is
> [{"com.cloud.agent.api.CheckVirtualMachineAnswer":{"result":true,"details":null,"state":"Running","contextMap":{}}}]
> 2014-10-14 19:34:48,148 WARN [c.c.a.m.DirectAgentAttache]
> (DirectAgent-110:ctx-409b4476) Seq 1-5051068457072722114: Throwable caught
> while executing command
> com.google.gson.JsonParseException: The JsonDeserializer EnumTypeAdapter
> failed to deserialize json object "Running" given the type class
> com.cloud.vm.VirtualMachine$PowerState
> at
> com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDeserializerExceptionWrapper.java:64)
> at
> com.google.gson.JsonDeserializationVisitor.invokeCustomDeserializer(JsonDeserializationVisitor.java:92)
> at
> com.google.gson.JsonObjectDeserializationVisitor.visitFieldUsingCustomHandler(JsonObjectDeserializationVisitor.java:117)
> at
> com.google.gson.ReflectingFieldNavigator.visitFieldsReflectively(ReflectingFieldNavigator.java:63)
> at com.google.gson.ObjectNavigator.accept(ObjectNavigator.java:120)
> at
> com.google.gson.JsonDeserializationContextDefault.fromJsonObject(JsonDeserializationContextDefault.java:76)
> at
> com.google.gson.JsonDeserializationContextDefault.deserialize(JsonDeserializationContextDefault.java:54)
> at com.google.gson.Gson.fromJson(Gson.java:551)
> at com.google.gson.Gson.fromJson(Gson.java:521)
> at
> com.cloud.agent.transport.ArrayTypeAdaptor.deserialize(ArrayTypeAdaptor.java:80)
> at
> com.cloud.agent.transport.ArrayTypeAdaptor.deserialize(ArrayTypeAdaptor.java:40)
> at
> com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDeserializerExceptionWrapper.java:51)
> at
> com.goog
[jira] [Updated] (CLOUDSTACK-5673) [Hyper-V] Default IP address never configured on eth0 with default CentOS template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-5673: --- Priority: Minor (was: Major) > [Hyper-V] Default IP address never configured on eth0 with default CentOS > template > -- > > Key: CLOUDSTACK-5673 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5673 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup, Template >Affects Versions: 4.3.0 > Environment: Hyper-V >Reporter: Sowmya Krishnan >Assignee: Rajesh Battala >Priority: Minor > Labels: hyper-v > Fix For: 4.4.0 > > > Deploy VM with the default CentOS 6.4 template that comes for Hyper-V. > Observe that default IP never gets configured on eth0. > While this doesn't seem to impact anything directly, it may have issues while > configuring multiple IPs for a VM. There may some workarounds needed to get > multiple IPs to work on the non-default interface. > It is instead desirable to have the default IP configured on eth0 itself like > the default templates for other hypervisors. > here's a sample of ifconfig from the deployed VM: > [root@VM1 ~]# ifconfig > eth2 Link encap:Ethernet HWaddr 02:00:74:88:00:01 > inet addr:10.0.17.2 Bcast:10.0.31.255 Mask:255.255.240.0 > inet6 addr: fe80::74ff:fe88:1/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:13925 errors:0 dropped:0 overruns:0 frame:0 > TX packets:14043 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:838100 (818.4 KiB) TX bytes:851899 (831.9 KiB) > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:4 errors:0 dropped:0 overruns:0 frame:0 > TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:240 (240.0 b) TX bytes:240 (240.0 b) > [root@VM1 ~]# ls /etc/sysconfig/network-scripts/ > ifcfg-eth0 ifdown-isdnifup-aliases ifup-plusb init.ipv6-global > ifcfg-lo ifdown-postifup-bnep ifup-post net.hotplug > ifdown ifdown-ppp ifup-eth ifup-ppp network-functions > ifdown-bnep ifdown-routes ifup-ippp ifup-routes > network-functions-ipv6 > ifdown-eth ifdown-sit ifup-ipv6 ifup-sit > ifdown-ippp ifdown-tunnel ifup-isdn ifup-tunnel > ifdown-ipv6 ifup ifup-plip ifup-wireless -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5673) [Hyper-V] Default IP address never configured on eth0 with default CentOS template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14176679#comment-14176679 ] Rajesh Battala commented on CLOUDSTACK-5673: from my above #1 comments it by design. > [Hyper-V] Default IP address never configured on eth0 with default CentOS > template > -- > > Key: CLOUDSTACK-5673 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5673 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup, Template >Affects Versions: 4.3.0 > Environment: Hyper-V >Reporter: Sowmya Krishnan >Assignee: Rajesh Battala >Priority: Minor > Labels: hyper-v > Fix For: 4.4.0 > > > Deploy VM with the default CentOS 6.4 template that comes for Hyper-V. > Observe that default IP never gets configured on eth0. > While this doesn't seem to impact anything directly, it may have issues while > configuring multiple IPs for a VM. There may some workarounds needed to get > multiple IPs to work on the non-default interface. > It is instead desirable to have the default IP configured on eth0 itself like > the default templates for other hypervisors. > here's a sample of ifconfig from the deployed VM: > [root@VM1 ~]# ifconfig > eth2 Link encap:Ethernet HWaddr 02:00:74:88:00:01 > inet addr:10.0.17.2 Bcast:10.0.31.255 Mask:255.255.240.0 > inet6 addr: fe80::74ff:fe88:1/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:13925 errors:0 dropped:0 overruns:0 frame:0 > TX packets:14043 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:838100 (818.4 KiB) TX bytes:851899 (831.9 KiB) > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:4 errors:0 dropped:0 overruns:0 frame:0 > TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:240 (240.0 b) TX bytes:240 (240.0 b) > [root@VM1 ~]# ls /etc/sysconfig/network-scripts/ > ifcfg-eth0 ifdown-isdnifup-aliases ifup-plusb init.ipv6-global > ifcfg-lo ifdown-postifup-bnep ifup-post net.hotplug > ifdown ifdown-ppp ifup-eth ifup-ppp network-functions > ifdown-bnep ifdown-routes ifup-ippp ifup-routes > network-functions-ipv6 > ifdown-eth ifdown-sit ifup-ipv6 ifup-sit > ifdown-ippp ifdown-tunnel ifup-isdn ifup-tunnel > ifdown-ipv6 ifup ifup-plip ifup-wireless -- This message was sent by Atlassian JIRA (v6.3.4#6332)
