[jira] [Commented] (CLOUDSTACK-8666) Put host in Alert state only after alert.wait timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640020#comment-14640020 ] ASF subversion and git services commented on CLOUDSTACK-8666: - Commit 090db05821a100ead24dee90658d5b0a863a8682 in cloudstack's branch refs/heads/master from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=090db05 ] CLOUDSTACK-8666: Put host in Alert state only after alert.wait timeout Instead of putting the host to Alert state immediately, the investigators should be allowed to run for some time based on alert.wait global config. At the end of this interval if the host state still cannot be determined then put the host in Alert. Also updated some of the log messages. This closes #621 Put host in Alert state only after alert.wait timeout - Key: CLOUDSTACK-8666 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8666 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0, 4.6.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 When there is a ping timeout on a host, investigators try to determine the state of a host. If none of the investigators are able to determine the host state then the process is repeated after some time. This works most of the time except some boundary scenarios. For e.g. if last host or all host in a XS cluster are brought down then the investigators are not able to determine the host state and the investigation process never completes. In such scenarios host state always remain as Up. In order to fix these boundary scenarios, a fix was made (refer to commit 4a13f81485c0f0664c60acafe534946e7428f080) to immediately put the host in Alert state if investigators are not able to determine the state after ping timeout. The fix solved the boundary scenarios but introduced a new issue. Suppose there is a XS cluster with 2 hosts and the master host is brought down. In this case XS elects a new master for the cluster. Since master is down, investigators won't able to determine host state until a new master is elected. If this master election takes more than ping timeout to complete then the host is put to Alert based on the above fix. Once this happens, the host continues to remain in Alert state and no actions are taken on the VMs on this host. In this case if the investigators were allowed to run for 1 or 2 more times, possibly the new master election would have completed and host state correctly determined. In order to fix both these issues, instead of putting the host to Alert state immediately, the investigators should be allowed to run for some time based on alert.wait global config. At the end of this interval if the host state still cannot be determined then put the host in Alert. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8666) Put host in Alert state only after alert.wait timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640021#comment-14640021 ] ASF GitHub Bot commented on CLOUDSTACK-8666: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/621 Put host in Alert state only after alert.wait timeout - Key: CLOUDSTACK-8666 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8666 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0, 4.6.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 When there is a ping timeout on a host, investigators try to determine the state of a host. If none of the investigators are able to determine the host state then the process is repeated after some time. This works most of the time except some boundary scenarios. For e.g. if last host or all host in a XS cluster are brought down then the investigators are not able to determine the host state and the investigation process never completes. In such scenarios host state always remain as Up. In order to fix these boundary scenarios, a fix was made (refer to commit 4a13f81485c0f0664c60acafe534946e7428f080) to immediately put the host in Alert state if investigators are not able to determine the state after ping timeout. The fix solved the boundary scenarios but introduced a new issue. Suppose there is a XS cluster with 2 hosts and the master host is brought down. In this case XS elects a new master for the cluster. Since master is down, investigators won't able to determine host state until a new master is elected. If this master election takes more than ping timeout to complete then the host is put to Alert based on the above fix. Once this happens, the host continues to remain in Alert state and no actions are taken on the VMs on this host. In this case if the investigators were allowed to run for 1 or 2 more times, possibly the new master election would have completed and host state correctly determined. In order to fix both these issues, instead of putting the host to Alert state immediately, the investigators should be allowed to run for some time based on alert.wait global config. At the end of this interval if the host state still cannot be determined then put the host in Alert. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8328) NPE while deleteing instance which has custom compute offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640037#comment-14640037 ] Sonali Jadhav commented on CLOUDSTACK-8328: --- can anyone verify this xenserver? NPE while deleteing instance which has custom compute offering -- Key: CLOUDSTACK-8328 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8328 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.2 Reporter: Sonali Jadhav Assignee: Abhinandan Prateek Priority: Critical I was trying to remove nic of a instance, which had two nics. I was unable to delete one nic, and i got this NPE. Here are logs http://pastebin.com/j1rfEq5s mysql select service_offering_id, id from vm_instance where instance_name=i-9-24-VM \G id: 24 service_offering_id: 14 mysql select * from nics where instance_id=24 \G *** 1. row *** id: 60 uuid: 99378e9f-ba64-4c76-ac16-d9ac977d979f instance_id: 24 mac_address: 06:by:bg:00:01:33 ip4_address: 1.1.1.1 netmask: 255.255.0.0 gateway: 1.1.1.1 ip_type: Ip4 broadcast_uri: vlan://201 network_id: 207 mode: Dhcp state: Allocated strategy: Create reserver_name: DirectNetworkGuru reservation_id: NULL device_id: 1 update_time: 2015-02-23 07:25:40 isolation_uri: vlan://201 ip6_address: NULL default_nic: 0 vm_type: User created: 2015-02-20 11:24:26 removed: NULL ip6_gateway: NULL ip6_cidr: NULL secondary_ip: 0 display_nic: 1 *** 2. row *** id: 61 uuid: 42178ae9-1c4c-43be-8a05-5d6259ee9ee4 instance_id: 24 mac_address: 02:00:3f:a4:00:01 ip4_address: 10.1.1.14 netmask: 255.255.255.0 gateway: 10.1.1.1 ip_type: Ip4 broadcast_uri: NULL network_id: 211 mode: Dhcp state: Allocated strategy: Start reserver_name: ExternalGuestNetworkGuru reservation_id: c59c1ead-fd98-4822-b7bb-71124fbf0018 device_id: 0 update_time: 2015-02-23 07:25:41 isolation_uri: NULL ip6_address: NULL default_nic: 1 vm_type: User created: 2015-02-20 13:21:07 removed: NULL ip6_gateway: NULL ip6_cidr: NULL secondary_ip: 0 display_nic: 1 2 rows in set (0.00 sec) mysql So as per NPE this is causing problem, mysql select ram_size from service_offering where id=14; +--+ | ram_size | +--+ | NULL | +--+ 1 row in set (0.00 sec) But I checked that, service_offering where id=14, is nothing but Custom compute offering I created. That’s why ram_size value is set to NULL. So basically I cant/don’t want to change value of ram_size service offering, Is this bug? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it
Sanjeev N created CLOUDSTACK-8668: - Summary: VR does not start in basic zone since ip address are not being configured on it Key: CLOUDSTACK-8668 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.6.0 Environment: Latest build from ACS master Reporter: Sanjeev N Priority: Blocker VR does not start in basic zone since ip address are not being configured on it Steps to reproduce: 1.Bring up CS in basic zone with xen server cluster 2.Try to deploy one guest vm using default cent os template Expected Result: == VR should come up as part of vm deployment and vm deployment should be successfull Actual Result: VR creation failed since the IP addresses not are getting assigned to VR's guest and link local interfaces. Observations: === 1.During vr boot time, cloud-early-config ran successfully and VR console output showed that ping to gateway was successful. However, after VR boot we don't see any ip addresses on the VRs guest and link local ip address. 2. If we run cloud-early-config manually from VR , ip addresses will be assigned and persistent. Impact: = VM deployments will fail since VR remains in stopped state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8666) Put host in Alert state only after alert.wait timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640014#comment-14640014 ] ASF GitHub Bot commented on CLOUDSTACK-8666: Github user koushik-das commented on the pull request: https://github.com/apache/cloudstack/pull/621#issuecomment-124357139 Merging it as 2 LGTMs Put host in Alert state only after alert.wait timeout - Key: CLOUDSTACK-8666 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8666 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0, 4.6.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 When there is a ping timeout on a host, investigators try to determine the state of a host. If none of the investigators are able to determine the host state then the process is repeated after some time. This works most of the time except some boundary scenarios. For e.g. if last host or all host in a XS cluster are brought down then the investigators are not able to determine the host state and the investigation process never completes. In such scenarios host state always remain as Up. In order to fix these boundary scenarios, a fix was made (refer to commit 4a13f81485c0f0664c60acafe534946e7428f080) to immediately put the host in Alert state if investigators are not able to determine the state after ping timeout. The fix solved the boundary scenarios but introduced a new issue. Suppose there is a XS cluster with 2 hosts and the master host is brought down. In this case XS elects a new master for the cluster. Since master is down, investigators won't able to determine host state until a new master is elected. If this master election takes more than ping timeout to complete then the host is put to Alert based on the above fix. Once this happens, the host continues to remain in Alert state and no actions are taken on the VMs on this host. In this case if the investigators were allowed to run for 1 or 2 more times, possibly the new master election would have completed and host state correctly determined. In order to fix both these issues, instead of putting the host to Alert state immediately, the investigators should be allowed to run for some time based on alert.wait global config. At the end of this interval if the host state still cannot be determined then put the host in Alert. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-8328) NPE while deleteing instance which has custom compute offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640037#comment-14640037 ] Sonali Jadhav edited comment on CLOUDSTACK-8328 at 7/24/15 6:59 AM: can anyone verify this with xenserver? was (Author: sonalij): can anyone verify this xenserver? NPE while deleteing instance which has custom compute offering -- Key: CLOUDSTACK-8328 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8328 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.2 Reporter: Sonali Jadhav Assignee: Abhinandan Prateek Priority: Critical I was trying to remove nic of a instance, which had two nics. I was unable to delete one nic, and i got this NPE. Here are logs http://pastebin.com/j1rfEq5s mysql select service_offering_id, id from vm_instance where instance_name=i-9-24-VM \G id: 24 service_offering_id: 14 mysql select * from nics where instance_id=24 \G *** 1. row *** id: 60 uuid: 99378e9f-ba64-4c76-ac16-d9ac977d979f instance_id: 24 mac_address: 06:by:bg:00:01:33 ip4_address: 1.1.1.1 netmask: 255.255.0.0 gateway: 1.1.1.1 ip_type: Ip4 broadcast_uri: vlan://201 network_id: 207 mode: Dhcp state: Allocated strategy: Create reserver_name: DirectNetworkGuru reservation_id: NULL device_id: 1 update_time: 2015-02-23 07:25:40 isolation_uri: vlan://201 ip6_address: NULL default_nic: 0 vm_type: User created: 2015-02-20 11:24:26 removed: NULL ip6_gateway: NULL ip6_cidr: NULL secondary_ip: 0 display_nic: 1 *** 2. row *** id: 61 uuid: 42178ae9-1c4c-43be-8a05-5d6259ee9ee4 instance_id: 24 mac_address: 02:00:3f:a4:00:01 ip4_address: 10.1.1.14 netmask: 255.255.255.0 gateway: 10.1.1.1 ip_type: Ip4 broadcast_uri: NULL network_id: 211 mode: Dhcp state: Allocated strategy: Start reserver_name: ExternalGuestNetworkGuru reservation_id: c59c1ead-fd98-4822-b7bb-71124fbf0018 device_id: 0 update_time: 2015-02-23 07:25:41 isolation_uri: NULL ip6_address: NULL default_nic: 1 vm_type: User created: 2015-02-20 13:21:07 removed: NULL ip6_gateway: NULL ip6_cidr: NULL secondary_ip: 0 display_nic: 1 2 rows in set (0.00 sec) mysql So as per NPE this is causing problem, mysql select ram_size from service_offering where id=14; +--+ | ram_size | +--+ | NULL | +--+ 1 row in set (0.00 sec) But I checked that, service_offering where id=14, is nothing but Custom compute offering I created. That’s why ram_size value is set to NULL. So basically I cant/don’t want to change value of ram_size service offering, Is this bug? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8669) [VMWare] create volume failed due to Exception: java.lang.NullPointerException Message: charsetName
Sanjeev N created CLOUDSTACK-8669:
-
Summary: [VMWare] create volume failed due to Exception:
java.lang.NullPointerException Message: charsetName
Key: CLOUDSTACK-8669
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8669
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Volumes
Affects Versions: 4.6.0
Environment: Latest build from ACS master with commit
2984acca83fff03c2ad8bdd28c097e797d4ce087
Hypervisor: VMWares
Reporter: Sanjeev N
Priority: Critical
[VMWare] create volume failed due to Exception: java.lang.NullPointerException
Message: charsetName
Steps to reproduce:
1.Bring up CS in advanced zone with vmware cluster
2.Deploy one guest vm using default cent os template
3.Create one data disk with shared disk offering
4.Attach the data disk to the vm created in step 2
Result:
=
Attach volume failed with NPE:
2015-07-23 16:06:58,103 ERROR [c.c.s.r.VmwareStorageProcessor]
(DirectAgent-64:ctx-6becb596 10.81.28.111, job-48/job-49, cmd:
CreateObjectCommand) create volume failed due to Exception:
java.lang.NullPointerException
Message: charsetName
java.lang.NullPointerException: charsetName
at java.io.InputStreamReader.lt;initgt;(InputStreamReader.java:99)
at
com.cloud.hypervisor.vmware.util.VmwareContext.uploadResourceContent(VmwareContext.java:486)
at
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.detachDisk(VirtualMachineMO.java:1217)
at
com.cloud.storage.resource.VmwareStorageProcessor.createVolume(VmwareStorageProcessor.java:1545)
at
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:113)
at
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:56)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:470)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:302)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
2015-07-23 16:06:58,104 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-64:ctx-6becb596) Seq 2-8089027880710832216: Response Received:
2015-07-23 16:06:58,104 DEBUG [c.c.a.t.Request] (DirectAgent-64:ctx-6becb596)
Seq 2-8089027880710832216: Processing: { Ans: , MgmtId: 187822473365406, via:
2, Ver: v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CreateObjectAnswer:{result:false,details:java.lang.NullPointerException:
charsetName,wait:0}}] }
2015-07-23 16:06:58,105 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-10:ctx-d0586dc9 job-48/job-49 ctx-7737cd68) Seq
2-8089027880710832216: Received: { Ans: , MgmtId: 187822473365406, via: 2,
Ver: v1, Flags: 10, { CreateObjectAnswer } }
2015-07-23 16:06:58,112 WARN [o.a.c.s.d.ObjectInDataStoreManagerImpl]
(Work-Job-Executor-10:ctx-d0586dc9 job-48/job-49 ctx-7737cd68) Unsupported data
object (VOLUME,
org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@58dd2323), no need
to delete from object in store ref table
Please look for job-48 in the attached Management server log file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8666) Put host in Alert state only after alert.wait timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koushik Das resolved CLOUDSTACK-8666. - Resolution: Fixed Put host in Alert state only after alert.wait timeout - Key: CLOUDSTACK-8666 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8666 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0, 4.6.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 When there is a ping timeout on a host, investigators try to determine the state of a host. If none of the investigators are able to determine the host state then the process is repeated after some time. This works most of the time except some boundary scenarios. For e.g. if last host or all host in a XS cluster are brought down then the investigators are not able to determine the host state and the investigation process never completes. In such scenarios host state always remain as Up. In order to fix these boundary scenarios, a fix was made (refer to commit 4a13f81485c0f0664c60acafe534946e7428f080) to immediately put the host in Alert state if investigators are not able to determine the state after ping timeout. The fix solved the boundary scenarios but introduced a new issue. Suppose there is a XS cluster with 2 hosts and the master host is brought down. In this case XS elects a new master for the cluster. Since master is down, investigators won't able to determine host state until a new master is elected. If this master election takes more than ping timeout to complete then the host is put to Alert based on the above fix. Once this happens, the host continues to remain in Alert state and no actions are taken on the VMs on this host. In this case if the investigators were allowed to run for 1 or 2 more times, possibly the new master election would have completed and host state correctly determined. In order to fix both these issues, instead of putting the host to Alert state immediately, the investigators should be allowed to run for some time based on alert.wait global config. At the end of this interval if the host state still cannot be determined then put the host in Alert. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8669) [VMWare] create volume failed due to Exception: java.lang.NullPointerException Message: charsetName
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjeev N updated CLOUDSTACK-8669:
--
Attachment: management-server.zip
Attached management server log file. Please look for job-48 for the sequence of
events in case of attach volume.
[VMWare] create volume failed due to Exception:
java.lang.NullPointerException Message: charsetName
---
Key: CLOUDSTACK-8669
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8669
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.6.0
Environment: Latest build from ACS master with commit
2984acca83fff03c2ad8bdd28c097e797d4ce087
Hypervisor: VMWares
Reporter: Sanjeev N
Priority: Critical
Attachments: management-server.zip
[VMWare] create volume failed due to Exception:
java.lang.NullPointerException Message: charsetName
Steps to reproduce:
1.Bring up CS in advanced zone with vmware cluster
2.Deploy one guest vm using default cent os template
3.Create one data disk with shared disk offering
4.Attach the data disk to the vm created in step 2
Result:
=
Attach volume failed with NPE:
2015-07-23 16:06:58,103 ERROR [c.c.s.r.VmwareStorageProcessor]
(DirectAgent-64:ctx-6becb596 10.81.28.111, job-48/job-49, cmd:
CreateObjectCommand) create volume failed due to Exception:
java.lang.NullPointerException
Message: charsetName
java.lang.NullPointerException: charsetName
at java.io.InputStreamReader.lt;initgt;(InputStreamReader.java:99)
at
com.cloud.hypervisor.vmware.util.VmwareContext.uploadResourceContent(VmwareContext.java:486)
at
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.detachDisk(VirtualMachineMO.java:1217)
at
com.cloud.storage.resource.VmwareStorageProcessor.createVolume(VmwareStorageProcessor.java:1545)
at
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:113)
at
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:56)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:470)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:302)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
2015-07-23 16:06:58,104 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-64:ctx-6becb596) Seq 2-8089027880710832216: Response Received:
2015-07-23 16:06:58,104 DEBUG [c.c.a.t.Request] (DirectAgent-64:ctx-6becb596)
Seq 2-8089027880710832216: Processing: { Ans: , MgmtId: 187822473365406,
via: 2, Ver: v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CreateObjectAnswer:{result:false,details:java.lang.NullPointerException:
charsetName,wait:0}}] }
2015-07-23 16:06:58,105 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-10:ctx-d0586dc9 job-48/job-49 ctx-7737cd68) Seq
2-8089027880710832216: Received: { Ans: , MgmtId: 187822473365406, via: 2,
Ver: v1, Flags: 10, { CreateObjectAnswer } }
2015-07-23 16:06:58,112 WARN [o.a.c.s.d.ObjectInDataStoreManagerImpl]
(Work-Job-Executor-10:ctx-d0586dc9 job-48/job-49 ctx-7737cd68) Unsupported
data object (VOLUME,
org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@58dd2323), no
need to delete from object in store ref
[jira] [Created] (CLOUDSTACK-8672) NCC Integration with CloudStack
Rajesh Battala created CLOUDSTACK-8672: -- Summary: NCC Integration with CloudStack Key: CLOUDSTACK-8672 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8672 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Network Devices Affects Versions: 4.6.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8649) Register SSH keypair is broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander resolved CLOUDSTACK-8649. Resolution: Fixed Merged into master and 4.5 Register SSH keypair is broken -- Key: CLOUDSTACK-8649 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8649 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0, 4.5.1 Reporter: Lennert den Teuling Fix For: Future, 4.6.0, 4.5.2 It seems that when we upgraded form CS 4.3 to 4.5 the register SSH keypair functionality broke. Registering keypairs work, but deployments with these newly registered keypair fails because they are not correctly put into the database. It seems that at least half of the public key data is missing in the database. We have tried this with multiple keys, even with keys that worked before. Keys that were registered before the upgrade still work. It is simple to reproduce, just register a SSH key and you will see the key will to be correctly put into the ssh_keypairs table and encrypting the VM password with the key will fail on deployment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8649) Register SSH keypair is broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander updated CLOUDSTACK-8649: --- Fix Version/s: 4.5.2 4.6.0 Future Register SSH keypair is broken -- Key: CLOUDSTACK-8649 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8649 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0, 4.5.1 Reporter: Lennert den Teuling Fix For: Future, 4.6.0, 4.5.2 It seems that when we upgraded form CS 4.3 to 4.5 the register SSH keypair functionality broke. Registering keypairs work, but deployments with these newly registered keypair fails because they are not correctly put into the database. It seems that at least half of the public key data is missing in the database. We have tried this with multiple keys, even with keys that worked before. Keys that were registered before the upgrade still work. It is simple to reproduce, just register a SSH key and you will see the key will to be correctly put into the ssh_keypairs table and encrypting the VM password with the key will fail on deployment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640192#comment-14640192 ] Jayapal Reddy commented on CLOUDSTACK-8668: --- [~wilder.rodrigues] On VR start ping from MS is success. On running VR aggregate command, in the VR interfaces ips are lost. If we run manually '/opt/cloud/bin/update_config.py monitor_service.json' it is removing interface ips. VR does not start in basic zone since ip address are not being configured on it --- Key: CLOUDSTACK-8668 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.6.0 Environment: Latest build from ACS master Reporter: Sanjeev N Priority: Blocker VR does not start in basic zone since ip address are not being configured on it Steps to reproduce: 1.Bring up CS in basic zone with xen server cluster 2.Try to deploy one guest vm using default cent os template Expected Result: == VR should come up as part of vm deployment and vm deployment should be successfull Actual Result: VR creation failed since the IP addresses not are getting assigned to VR's guest and link local interfaces. Observations: === 1.During vr boot time, cloud-early-config ran successfully and VR console output showed that ping to gateway was successful. However, after VR boot we don't see any ip addresses on the VRs guest and link local ip address. 2. If we run cloud-early-config manually from VR , ip addresses will be assigned and persistent. Impact: = VM deployments will fail since VR remains in stopped state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8671) [VMWare] VM deployment from iso fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjeev N updated CLOUDSTACK-8671:
--
Attachment: management-server.zip
Please look for job-322 in the attached MS log file for vm deployment failure.
[VMWare] VM deployment from iso fails
-
Key: CLOUDSTACK-8671
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8671
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: ISO, VMware
Affects Versions: 4.6.0
Environment: Latest build from ACS master with commit
2984acca83fff03c2ad8bdd28c097e797d4ce087
Hypervisor: VMWare
Reporter: Sanjeev N
Priority: Critical
Attachments: management-server.zip
Failed to deploy vm from ISO
Steps to reproduce:
1.Bring up CS in advanced zone with vmware cluster
2.Register one bootable iso
3.Try to deploy vm using that iso
Result:
==
VM Deployment failed due to failure in creating volume:
2015-07-23 16:48:29,712 ERROR [c.c.s.r.VmwareStorageProcessor]
(DirectAgent-196:ctx-18de08d8 10.81.28.111, job-322/job-323, cmd:
CreateObjectCommand) create volume failed due to Exception:
java.lang.NullPointerException
Message: charsetName
java.lang.NullPointerException: charsetName
at java.io.InputStreamReader.lt;initgt;(InputStreamReader.java:99)
at
com.cloud.hypervisor.vmware.util.VmwareContext.uploadResourceContent(VmwareContext.java:486)
at
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.detachDisk(VirtualMachineMO.java:1217)
at
com.cloud.storage.resource.VmwareStorageProcessor.createVolume(VmwareStorageProcessor.java:1545)
at
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:113)
at
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:56)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:470)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:302)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
2015-07-23 16:48:29,713 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-196:ctx-18de08d8) Seq 2-8089027880710832600: Response Received:
2015-07-23 16:48:29,713 DEBUG [c.c.a.t.Request]
(DirectAgent-196:ctx-18de08d8) Seq 2-8089027880710832600: Processing: { Ans:
, MgmtId: 187822473365406, via: 2, Ver: v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CreateObjectAnswer:{result:false,details:java.lang.NullPointerException:
charsetName,wait:0}}] }
2015-07-23 16:48:29,713 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Seq
2-8089027880710832600: Received: { Ans: , MgmtId: 187822473365406, via: 2,
Ver: v1, Flags: 10, { CreateObjectAnswer } }
2015-07-23 16:48:29,720 WARN [o.a.c.s.d.ObjectInDataStoreManagerImpl]
(Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Unsupported
data object (VOLUME,
org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@392f6f34), no
need to delete from object in store ref table
2015-07-23 16:48:29,720 DEBUG [o.a.c.e.o.VolumeOrchestrator]
(Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Unable to
create Vol[55|vm=50|ROOT]:java.lang.NullPointerException: charsetName
2015-07-23 16:48:29,720 INFO [c.c.v.VirtualMachineManagerImpl]
[jira] [Created] (CLOUDSTACK-8673) NS-Vpx LifeCycle with CloudStack
Rajesh Battala created CLOUDSTACK-8673: -- Summary: NS-Vpx LifeCycle with CloudStack Key: CLOUDSTACK-8673 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8673 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller, Network Devices Affects Versions: 4.6.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8670) Delay in VM's console
Lior created CLOUDSTACK-8670: Summary: Delay in VM's console Key: CLOUDSTACK-8670 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8670 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: VNC Proxy Affects Versions: 4.5.1 Environment: POC environment with one management server that hosts the DB too. Running on top of vSphere 5.5 hypervisor. Reporter: Lior I'm experiencing about 1 second delay between my actions and the response from the VM's console. This is an issue for me since the VM's are going to be accessed only by the console window and not by remote desktop or SSH. Wondering if this behavior is normal or is there any configuration I need to implement in order to fix it. I'm experiencing this delay both in Windows and Linux VM's with VMware Tools installed and updated. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8671) [VMWare] VM deployment from iso fails
Sanjeev N created CLOUDSTACK-8671:
-
Summary: [VMWare] VM deployment from iso fails
Key: CLOUDSTACK-8671
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8671
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: ISO, VMware
Affects Versions: 4.6.0
Environment: Latest build from ACS master with commit
2984acca83fff03c2ad8bdd28c097e797d4ce087
Hypervisor: VMWare
Reporter: Sanjeev N
Priority: Critical
Failed to deploy vm from ISO
Steps to reproduce:
1.Bring up CS in advanced zone with vmware cluster
2.Register one bootable iso
3.Try to deploy vm using that iso
Result:
==
VM Deployment failed due to failure in creating volume:
2015-07-23 16:48:29,712 ERROR [c.c.s.r.VmwareStorageProcessor]
(DirectAgent-196:ctx-18de08d8 10.81.28.111, job-322/job-323, cmd:
CreateObjectCommand) create volume failed due to Exception:
java.lang.NullPointerException
Message: charsetName
java.lang.NullPointerException: charsetName
at java.io.InputStreamReader.lt;initgt;(InputStreamReader.java:99)
at
com.cloud.hypervisor.vmware.util.VmwareContext.uploadResourceContent(VmwareContext.java:486)
at
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.detachDisk(VirtualMachineMO.java:1217)
at
com.cloud.storage.resource.VmwareStorageProcessor.createVolume(VmwareStorageProcessor.java:1545)
at
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:113)
at
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:56)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:470)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:302)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
2015-07-23 16:48:29,713 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-196:ctx-18de08d8) Seq 2-8089027880710832600: Response Received:
2015-07-23 16:48:29,713 DEBUG [c.c.a.t.Request] (DirectAgent-196:ctx-18de08d8)
Seq 2-8089027880710832600: Processing: { Ans: , MgmtId: 187822473365406, via:
2, Ver: v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CreateObjectAnswer:{result:false,details:java.lang.NullPointerException:
charsetName,wait:0}}] }
2015-07-23 16:48:29,713 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Seq
2-8089027880710832600: Received: { Ans: , MgmtId: 187822473365406, via: 2,
Ver: v1, Flags: 10, { CreateObjectAnswer } }
2015-07-23 16:48:29,720 WARN [o.a.c.s.d.ObjectInDataStoreManagerImpl]
(Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Unsupported
data object (VOLUME,
org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@392f6f34), no need
to delete from object in store ref table
2015-07-23 16:48:29,720 DEBUG [o.a.c.e.o.VolumeOrchestrator]
(Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Unable to
create Vol[55|vm=50|ROOT]:java.lang.NullPointerException: charsetName
2015-07-23 16:48:29,720 INFO [c.c.v.VirtualMachineManagerImpl]
(Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Unable to
contact resource.
com.cloud.exception.StorageUnavailableException: Resource [StoragePool:1] is
unreachable: Unable to create
Vol[55|vm=50|ROOT]:java.lang.NullPointerException: charsetName
at
org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:1278)
[jira] [Commented] (CLOUDSTACK-8649) Register SSH keypair is broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640203#comment-14640203 ] ASF subversion and git services commented on CLOUDSTACK-8649: - Commit 8dc8e9b8f31ef249a553cb20fb5be617a74cfbba in cloudstack's branch refs/heads/4.5 from [~bo...@pcextreme.nl] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8dc8e9b ] CLOUDSTACK-8649: Fixed unnecessary double url decoding in registerSSHKeyPair. Signed-off-by: wilderrodrigues wrodrig...@schubergphilis.com This closes #615 (cherry picked from commit 2e79c628e052ebdaf782458cfe4c4ef6e95545c6) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: server/src/com/cloud/server/ManagementServerImpl.java Register SSH keypair is broken -- Key: CLOUDSTACK-8649 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8649 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0, 4.5.1 Reporter: Lennert den Teuling It seems that when we upgraded form CS 4.3 to 4.5 the register SSH keypair functionality broke. Registering keypairs work, but deployments with these newly registered keypair fails because they are not correctly put into the database. It seems that at least half of the public key data is missing in the database. We have tried this with multiple keys, even with keys that worked before. Keys that were registered before the upgrade still work. It is simple to reproduce, just register a SSH key and you will see the key will to be correctly put into the ssh_keypairs table and encrypting the VM password with the key will fail on deployment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8674) Custom ISO with reboot --eject in kickstart does not get detached at reboot
Luca Gioppo created CLOUDSTACK-8674: --- Summary: Custom ISO with reboot --eject in kickstart does not get detached at reboot Key: CLOUDSTACK-8674 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8674 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Hypervisor Controller, ISO Affects Versions: 4.4.2 Environment: KVM Reporter: Luca Gioppo I have a custom ISO of a CentOS 7 with a kickstart that does some automatic installation and at the end it reboot the machine with the reboot --eject command. In previous versions of CloudStack the behaviour of the platform was to remove the ISO from the VM even if the console was considering it still attached. Now the machine loops endlessly since the --eject is not honored and the ISO keep to be attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8610) [VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640271#comment-14640271
]
ASF GitHub Bot commented on CLOUDSTACK-8610:
Github user sureshanaparti commented on the pull request:
https://github.com/apache/cloudstack/pull/554#issuecomment-124468346
Looks good to me.
[VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance
--
Key: CLOUDSTACK-8610
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8610
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Fix For: 4.6.0
+Steps to reproduce+
1. Set global config vmware.root.disk.controller to 'osdefault'.
2. Deploy a VM and attach 6 disks to the VM.
3. Try to attach a 7th disk to the VM.
Step 3 will fail with the below error
{noformat}
2015-06-22 11:03:22,673 ERROR [c.c.s.r.VmwareStorageProcessor]
(DirectAgent-636:ctx-8e72c2d9 s1p-z1-esxic-001.es.local, job-9286/job-9287,
cmd: AttachCommand) (logid:6372e940) Failed to attach volume: Failed to add
disk scsi0:7.
java.lang.RuntimeException: Failed to add disk scsi0:7.
at
com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:336)
at
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.attachDisk(VirtualMachineMO.java:1206)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8610) [VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640305#comment-14640305
]
ASF GitHub Bot commented on CLOUDSTACK-8610:
Github user sateesh-chodapuneedi commented on the pull request:
https://github.com/apache/cloudstack/pull/554#issuecomment-124474599
Looks like all checks are good and there are 2 LGTM too.
Should we merge this branch?
[VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance
--
Key: CLOUDSTACK-8610
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8610
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Fix For: 4.6.0
+Steps to reproduce+
1. Set global config vmware.root.disk.controller to 'osdefault'.
2. Deploy a VM and attach 6 disks to the VM.
3. Try to attach a 7th disk to the VM.
Step 3 will fail with the below error
{noformat}
2015-06-22 11:03:22,673 ERROR [c.c.s.r.VmwareStorageProcessor]
(DirectAgent-636:ctx-8e72c2d9 s1p-z1-esxic-001.es.local, job-9286/job-9287,
cmd: AttachCommand) (logid:6372e940) Failed to attach volume: Failed to add
disk scsi0:7.
java.lang.RuntimeException: Failed to add disk scsi0:7.
at
com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:336)
at
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.attachDisk(VirtualMachineMO.java:1206)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8602) MigrateVirtualMachineWithVolume leaves old chain data for volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640312#comment-14640312 ] ASF GitHub Bot commented on CLOUDSTACK-8602: Github user sureshanaparti commented on the pull request: https://github.com/apache/cloudstack/pull/548#issuecomment-124476270 Code changes to update the volume chain info are perfect. MigrateVirtualMachineWithVolume leaves old chain data for volume Key: CLOUDSTACK-8602 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8602 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.6.0 CS maintains chain info of every volume in DB, where chain info is the complete volume path. When the volumes associated with a VM are migrated to different storage pool, their chain info changes, but this information is not reflected in the DB. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8648) Unable to get storage implementation when copying template from NFS to S3
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640514#comment-14640514
]
ASF GitHub Bot commented on CLOUDSTACK-8648:
Github user DaanHoogland commented on the pull request:
https://github.com/apache/cloudstack/pull/606#issuecomment-124544128
LGTM
Unable to get storage implementation when copying template from NFS to S3
---
Key: CLOUDSTACK-8648
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8648
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Secondary Storage
Affects Versions: Future, 4.5.2
Reporter: Wido den Hollander
Labels: qcow2, s3, secondary_storage
Fix For: Future
In the SSVM this can be observed:
2015-07-17 12:12:56,675 WARN [storage.resource.NfsSecondaryStorageResource]
(agentRequest-Handler-11:null) Failed to get virtual size, returning file
size instead:
javax.naming.ConfigurationException: Unable to get storage implementation
at
com.cloud.storage.template.QCOW2Processor.configure(QCOW2Processor.java:95)
at
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.getVirtualSize(NfsSecondaryStorageResource.java:828)
at
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.copyFromNfsToS3(NfsSecondaryStorageResource.java:886)
at
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.copyFromNfsToImage(NfsSecondaryStorageResource.java:618)
at
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:645)
at
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:233)
at com.cloud.agent.Agent.processRequest(Agent.java:503)
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808)
at com.cloud.utils.nio.Task.run(Task.java:84)
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:745)
The problem is this:
processor.configure(template processor, new HashMapString, Object());
return processor.getVirtualSize(file);
It confitures the processor with a empty HashMap, but the check in the
processor is:
public boolean configure(String name, MapString, Object params) throws
ConfigurationException {
_storage = (StorageLayer)params.get(StorageLayer.InstanceConfigKey);
if (_storage == null) {
throw new ConfigurationException(Unable to get storage
implementation);
}
Since the HashMap is empty null is returned and this exception is thrown.
No need to configure the Processor as far as I can see.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8666) Put host in Alert state only after alert.wait timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640765#comment-14640765 ] ASF GitHub Bot commented on CLOUDSTACK-8666: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/621#issuecomment-124584731 wasn't this needing (unit)-tests? Put host in Alert state only after alert.wait timeout - Key: CLOUDSTACK-8666 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8666 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0, 4.6.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 When there is a ping timeout on a host, investigators try to determine the state of a host. If none of the investigators are able to determine the host state then the process is repeated after some time. This works most of the time except some boundary scenarios. For e.g. if last host or all host in a XS cluster are brought down then the investigators are not able to determine the host state and the investigation process never completes. In such scenarios host state always remain as Up. In order to fix these boundary scenarios, a fix was made (refer to commit 4a13f81485c0f0664c60acafe534946e7428f080) to immediately put the host in Alert state if investigators are not able to determine the state after ping timeout. The fix solved the boundary scenarios but introduced a new issue. Suppose there is a XS cluster with 2 hosts and the master host is brought down. In this case XS elects a new master for the cluster. Since master is down, investigators won't able to determine host state until a new master is elected. If this master election takes more than ping timeout to complete then the host is put to Alert based on the above fix. Once this happens, the host continues to remain in Alert state and no actions are taken on the VMs on this host. In this case if the investigators were allowed to run for 1 or 2 more times, possibly the new master election would have completed and host state correctly determined. In order to fix both these issues, instead of putting the host to Alert state immediately, the investigators should be allowed to run for some time based on alert.wait global config. At the end of this interval if the host state still cannot be determined then put the host in Alert. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6059) Restarting a VPC that has a Private Gateway fails due to a NPE, but message is not clear
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640385#comment-14640385 ] Pierre-Luc Dion commented on CLOUDSTACK-6059: - [~wilder.rodrigues]: Tested on 4.4.4, it seams to be resolved, but not commit about this issue. Are you able to confirmed on your side? look like this issue can be close. Thanks Restarting a VPC that has a Private Gateway fails due to a NPE, but message is not clear Key: CLOUDSTACK-6059 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6059 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.1, 4.4.2 Environment: Cloudstack 4.2.1-SNAPSHOT, Linux Reporter: Wilder Rodrigues Priority: Minor When trying to restart a VPC that has a Private Gateway configured, it fails with a message Failed to restart VPC. However, in the logs, we have observed that there is a NullPointerException when calling createPrivateNicProfileForGateway(VpcVirtualNetworkApplianceManagerImpl.java:1295). We know that's not possible to restart a VPC that has a Private Gateway, but we are opening this issue just to have in mind that the method is currently returning null and the message on the UI is not clear at all. 2014-02-07 10:53:22,639 DEBUG [db.Transaction.Transaction] (Job-Executor-75:job-224729 = [ bb0b666a-ef03-4712-bc62-f3e27c82282c ]) Rolling back the transaction: Time = 3 Name = -AsyncJobManagerImp l$1.run:494-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679; called by -Transac tion.rollback:897-PrivateIpDaoImpl.allocateIpAddress:85-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-VpcVirtualNetworkApplianceManagerImpl.createPrivateNicProfileForGatew ay:1294-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-VpcVirtualNetworkApplianceManagerImpl.createVpcRouterNetworks:1250-VpcVirtualNetworkApplianceManagerImpl.deployVpcRou ter:329-VpcVirtualNetworkApplianceManagerImpl.findOrDeployVirtualRouterInVpc:227-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-VpcVirtualNetworkApplianceManagerImpl.deploy VirtualRouterInVpc:176-VpcVirtualRouterElement.implementVpc:126-VpcManagerImpl.startVpc:992 2014-02-07 10:53:22,642 WARN [network.vpc.VpcManagerImpl] (Job-Executor-75:job-224729 = [ bb0b666a-ef03-4712-bc62-f3e27c82282c ]) Failed to start vpc [VPC [237-SBP_VPC_AJENKINS1] due to java.lang.NullPointerException at com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.createPrivateNicProfileForGateway(VpcVirtualNetworkApplianceManagerImpl.java:1295) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.createVpcRouterNetworks(VpcVirtualNetworkApplianceManagerImpl.java:1250) at com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.deployVpcRouter(VpcVirtualNetworkApplianceManagerImpl.java:329) at com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.findOrDeployVirtualRouterInVpc(VpcVirtualNetworkApplianceManagerImpl.java:227) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.deployVirtualRouterInVpc(VpcVirtualNetworkApplianceManagerImpl.java:176) at com.cloud.network.element.VpcVirtualRouterElement.implementVpc(VpcVirtualRouterElement.java:126) at com.cloud.network.vpc.VpcManagerImpl.startVpc(VpcManagerImpl.java:992) at com.cloud.network.vpc.VpcManagerImpl.startVpc(VpcManagerImpl.java:964) at com.cloud.network.vpc.VpcManagerImpl.restartVpc(VpcManagerImpl.java:1304) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.vpc.RestartVPCCmd.execute(RestartVPCCmd.java:80) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at
[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640389#comment-14640389
]
Kishan Kavala commented on CLOUDSTACK-8668:
---
VR Config file:
#Apache CloudStack Virtual Router Config File version
1.0
/version
file
/var/cache/cloud/monitor_service.json
{config:[dhcp]:processname=dnsmasq:servicename=dnsmasq:pidfile=/var/run/dnsmasq/dnsmasq.pid:,[ssh]:processname=sshd:servicename=ssh:pidfile=/var/run/sshd.pid:,[webserver]:processname=apache2:servicename=apache2:pidfile=/var/run/apache2.pid:,,type:monitorservice}
/file
script
/opt/cloud/bin/update_config.py monitor_service.json /script
/var/log/cloud.log:
2015-07-24 09:29:28,997 Loading data bag type monitorservice
2015-07-24 09:29:28,998 Command of type monitorservice received
2015-07-24 09:29:28,999 Writing data bag type monitorservice
2015-07-24 09:29:28,999 Creating data bag type ips
2015-07-24 09:29:28,999 Loading data bag type cmdline
2015-07-24 09:29:29,000 Executing ip addr show dev eth1
2015-07-24 09:29:29,019 Will remove all configured addresses on device eth1
2015-07-24 09:29:29,019 Removing addresses from device eth1
2015-07-24 09:29:29,036 Removed address 169.254.2.130/16 from device eth1
2015-07-24 09:29:29,056 Removed address 169.254.2.130/16 from device eth1
2015-07-24 09:29:29,057 Executing ip addr show dev eth0
2015-07-24 09:29:29,075 Will remove all configured addresses on device eth0
2015-07-24 09:29:29,076 Removing addresses from device eth0
2015-07-24 09:29:29,093 Removed address 10.220.39.131/19 from device eth0
2015-07-24 09:29:29,112 Removed address 10.220.39.131/19 from device eth
VR does not start in basic zone since ip address are not being configured on
it
---
Key: CLOUDSTACK-8668
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.6.0
Environment: Latest build from ACS master
Reporter: Sanjeev N
Priority: Blocker
VR does not start in basic zone since ip address are not being configured on
it
Steps to reproduce:
1.Bring up CS in basic zone with xen server cluster
2.Try to deploy one guest vm using default cent os template
Expected Result:
==
VR should come up as part of vm deployment and vm deployment should be
successfull
Actual Result:
VR creation failed since the IP addresses not are getting assigned to VR's
guest and link local interfaces.
Observations:
===
1.During vr boot time, cloud-early-config ran successfully and VR console
output showed that ping to gateway was successful. However, after VR boot we
don't see any ip addresses on the VRs guest and link local ip address.
2. If we run cloud-early-config manually from VR , ip addresses will be
assigned and persistent.
Impact:
=
VM deployments will fail since VR remains in stopped state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
