[jira] [Updated] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-4787: - Fix Version/s: (was: Future) 4.6.0 Allow selection of scsi controller type in vSphere -- Key: CLOUDSTACK-4787 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI, VMware Affects Versions: 4.2.0, 4.3.0 Environment: vSphere 5.1 Reporter: Chris Sciarrino Assignee: Sateesh Chodapuneedi Priority: Critical Fix For: 4.6.0 When adding an OVA template for a vSphere environment allow the selection of the scsi controller type. Currently the instances are deployed with the the LSI Parallel controller type. This results in a blue screen on boot when attempting to deploy templates that use the LSI SAS controller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5578) KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-5578: -- Attachment: nfsUmount.jpg Reboot stuck while umounting primary KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary -- Key: CLOUDSTACK-5578 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5578 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.0 Attachments: DisconnectedHost.png, kvm-hostdisconnect.rar, nfsUmount.jpg KVM - Network down - When the host looses network connectivity , it is not able to fence itself. Steps to reproduce the problem: Set up - Advanced zone with 2 Rhel 6.3 hosts in cluster. Deploy ~10 Vms. Simulate network disconnect on the host ( ifdown em1) Host gets marked as Down and all the Vms gets HA-ed to the other host. On the KVM host which lost connectivity , attempt to shutdown itself fails. It was not able to umount the primary store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-5578) KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213467#comment-14213467 ] Kishan Kavala edited comment on CLOUDSTACK-5578 at 11/15/14 8:50 AM: - Reboot stuck while umounting primary: screenshot attached was (Author: kishan): Reboot stuck while umounting primary KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary -- Key: CLOUDSTACK-5578 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5578 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.0 Attachments: DisconnectedHost.png, kvm-hostdisconnect.rar, nfsUmount.jpg KVM - Network down - When the host looses network connectivity , it is not able to fence itself. Steps to reproduce the problem: Set up - Advanced zone with 2 Rhel 6.3 hosts in cluster. Deploy ~10 Vms. Simulate network disconnect on the host ( ifdown em1) Host gets marked as Down and all the Vms gets HA-ed to the other host. On the KVM host which lost connectivity , attempt to shutdown itself fails. It was not able to umount the primary store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5578) KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213468#comment-14213468 ] Kishan Kavala commented on CLOUDSTACK-5578: --- This is happening consistently. Force reboot reboot -f is an option. kvmheartbeat script should use -f option while rebooting. KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary -- Key: CLOUDSTACK-5578 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5578 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.0 Attachments: DisconnectedHost.png, kvm-hostdisconnect.rar, nfsUmount.jpg KVM - Network down - When the host looses network connectivity , it is not able to fence itself. Steps to reproduce the problem: Set up - Advanced zone with 2 Rhel 6.3 hosts in cluster. Deploy ~10 Vms. Simulate network disconnect on the host ( ifdown em1) Host gets marked as Down and all the Vms gets HA-ed to the other host. On the KVM host which lost connectivity , attempt to shutdown itself fails. It was not able to umount the primary store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213475#comment-14213475 ] Bharat Kumar commented on CLOUDSTACK-7501: -- if we do not mention any default hypervisor, Cloudstack tries to start a vm on different hypervisor after some retries. While creating a new system vm we select the hypervisor type. If there is more than one hypervisor available for deployment we shuffle the list and pick one. System VM fails to move from one cluster to another cluster when hypervisor type differs Key: CLOUDSTACK-7501 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Bharat Kumar Priority: Critical Fix For: 4.5.0 Attachments: Ms.tar.gz Repro steps: 1. Create a LXC advance zone setup with one LXC cluster 2. When system vms are up .add one more KVM cluster 3. Put LXC host to maintenance Bug: System VM is not coming up on KVM cluster Expected result: System VMs should come up on KVM cluster Ms log shows : Cluster: 2 has HyperVisorType that does not match the VM, skipping this cluster which should not be the case in case of SSVM and CPVM attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7501. -- Resolution: Fixed System VM fails to move from one cluster to another cluster when hypervisor type differs Key: CLOUDSTACK-7501 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Bharat Kumar Priority: Critical Fix For: 4.5.0 Attachments: Ms.tar.gz Repro steps: 1. Create a LXC advance zone setup with one LXC cluster 2. When system vms are up .add one more KVM cluster 3. Put LXC host to maintenance Bug: System VM is not coming up on KVM cluster Expected result: System VMs should come up on KVM cluster Ms log shows : Cluster: 2 has HyperVisorType that does not match the VM, skipping this cluster which should not be the case in case of SSVM and CPVM attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7697) HA - No alerts being generated when SSVM/CPVM is being HA-ed to a different hosts.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213477#comment-14213477 ] Koushik Das commented on CLOUDSTACK-7697: - When host is detected as 'Down', all VMs running on that are scheduled for investigation (using HA worker threads). Based on investigation if VM is detected as alive, HA process is marked as completed. If it cannot be conclusively determined as alive/dead then the VM is fenced. After this if the VM is not HA enabled then the process is marked as completed. In this case no alert is generated for individual VMs as this is expected behaviour. For SSVM/CPVM, there is a separate monitoring logic that will detect when there is no running SSVM/CPVM and spawn a new one. As part of this alerts will be generated. In case of non-HA user VMs there is no need for alerts as the VM is not critical since it is not HA enabled. For HA enabled VMs it will tried to be started on another host and if there are any failures alerts are generated. HA - No alerts being generated when SSVM/CPVM is being HA-ed to a different hosts. -- Key: CLOUDSTACK-7697 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7697 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Environment: Build from 4.5 Reporter: Sangeetha Hariharan Assignee: Koushik Das Fix For: 4.5.0 HA - No alerts being generated when SSVM/CPVM is being HA-ed to a different hosts. Steps to reproduce the problem: Zone with 1 cluster having 2 hosts. Bring down master host where SSVM and CPVM is running. All user Vms , SSVM and CPVM running in this host is HA-ed to another host. There is no Alert being generated for SSVM and CPVM being detected as being stopped . Also there are no events/alerts being generated for all the user Vms that were detected as being stopped and started in a different host. Should we expect events/alerts being generated for these as well ? mysql select * from alert; ++--+--++++-++-+-+--+--++ | id | uuid | type | cluster_id | pod_id | data_center_id | subject | sent_count | created | last_sent | resolved | archived | name | ++--+--++++-++-+-+--+--++ | 1 | aeef592e-3bb4-431e-911d-16280bf8a8ad | 14 | NULL | 0 | 0 | Management network CIDR is not configured originally. Set it default to 10.223.130.0/24 | 1 | 2014-10-09 22:19:14 | 2014-10-09 22:19:14 | NULL |0 | ALERT.MANAGEMENT | | 2 | 1a0bb67d-9346-4078-a80d-e6669116e7fd | 14 | NULL | 0 | 0 | Management server node 10.223.130.101 is up | 1 | 2014-10-09 22:19:16 | 2014-10-09 22:19:16 | NULL |0 | ALERT.MANAGEMENT | | 3 | 5c37924e-50cd-413f-a37a-ac275dbc46f9 | 13 | NULL | 0 | 0 | No usage server process running | 1 | 2014-10-09 23:19:14 | 2014-10-09 23:19:14 | NULL |0 | ALERT.USAGE| | 4 | 4d1b8b64-f59a-4405-a244-14e054297f04 |2 | 1 | 1 | 1 | System Alert: Low Available Storage in cluster cluster1 pod pod1 of availability zone zone1 | 1 | 2014-10-09 23:39:44 | 2014-10-09 23:39:44 | NULL |0 | ALERT.STORAGE | | 5 | aaf9bb96-799c-40d0-a652-96566c7ff47a |7 | NULL | 1 | 1 | Host is down, name: Rack3Host20.lab.vmops.com (id:1), availability zone: zone1, pod: pod1 | 1 | 2014-10-10 15:05:41 | 2014-10-10 15:05:41 | NULL |0 | ALERT.COMPUTE.HOST | ++--+--++++-++-+-+--+--++ 5 rows in set
[jira] [Resolved] (CLOUDSTACK-7697) HA - No alerts being generated when SSVM/CPVM is being HA-ed to a different hosts.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koushik Das resolved CLOUDSTACK-7697. - Resolution: Not a Problem HA - No alerts being generated when SSVM/CPVM is being HA-ed to a different hosts. -- Key: CLOUDSTACK-7697 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7697 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Environment: Build from 4.5 Reporter: Sangeetha Hariharan Assignee: Koushik Das Fix For: 4.5.0 HA - No alerts being generated when SSVM/CPVM is being HA-ed to a different hosts. Steps to reproduce the problem: Zone with 1 cluster having 2 hosts. Bring down master host where SSVM and CPVM is running. All user Vms , SSVM and CPVM running in this host is HA-ed to another host. There is no Alert being generated for SSVM and CPVM being detected as being stopped . Also there are no events/alerts being generated for all the user Vms that were detected as being stopped and started in a different host. Should we expect events/alerts being generated for these as well ? mysql select * from alert; ++--+--++++-++-+-+--+--++ | id | uuid | type | cluster_id | pod_id | data_center_id | subject | sent_count | created | last_sent | resolved | archived | name | ++--+--++++-++-+-+--+--++ | 1 | aeef592e-3bb4-431e-911d-16280bf8a8ad | 14 | NULL | 0 | 0 | Management network CIDR is not configured originally. Set it default to 10.223.130.0/24 | 1 | 2014-10-09 22:19:14 | 2014-10-09 22:19:14 | NULL |0 | ALERT.MANAGEMENT | | 2 | 1a0bb67d-9346-4078-a80d-e6669116e7fd | 14 | NULL | 0 | 0 | Management server node 10.223.130.101 is up | 1 | 2014-10-09 22:19:16 | 2014-10-09 22:19:16 | NULL |0 | ALERT.MANAGEMENT | | 3 | 5c37924e-50cd-413f-a37a-ac275dbc46f9 | 13 | NULL | 0 | 0 | No usage server process running | 1 | 2014-10-09 23:19:14 | 2014-10-09 23:19:14 | NULL |0 | ALERT.USAGE| | 4 | 4d1b8b64-f59a-4405-a244-14e054297f04 |2 | 1 | 1 | 1 | System Alert: Low Available Storage in cluster cluster1 pod pod1 of availability zone zone1 | 1 | 2014-10-09 23:39:44 | 2014-10-09 23:39:44 | NULL |0 | ALERT.STORAGE | | 5 | aaf9bb96-799c-40d0-a652-96566c7ff47a |7 | NULL | 1 | 1 | Host is down, name: Rack3Host20.lab.vmops.com (id:1), availability zone: zone1, pod: pod1 | 1 | 2014-10-10 15:05:41 | 2014-10-10 15:05:41 | NULL |0 | ALERT.COMPUTE.HOST | ++--+--++++-++-+-+--+--++ 5 rows in set (0.00 sec) mysql -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213475#comment-14213475 ] Bharat Kumar edited comment on CLOUDSTACK-7501 at 11/15/14 9:39 AM: if we do not mention any default hypervisor, Cloudstack tries to start a SSVM on different hypervisor after some retries. While creating a new SSVM vm we select the hypervisor type. If there is more than one hypervisor available for deployment we shuffle the list and pick one. Note: In case of CPVM we do not do this unless the CPVM is destroyed. was (Author: bharat.kumar): if we do not mention any default hypervisor, Cloudstack tries to start a vm on different hypervisor after some retries. While creating a new system vm we select the hypervisor type. If there is more than one hypervisor available for deployment we shuffle the list and pick one. System VM fails to move from one cluster to another cluster when hypervisor type differs Key: CLOUDSTACK-7501 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Bharat Kumar Priority: Critical Fix For: 4.5.0 Attachments: Ms.tar.gz Repro steps: 1. Create a LXC advance zone setup with one LXC cluster 2. When system vms are up .add one more KVM cluster 3. Put LXC host to maintenance Bug: System VM is not coming up on KVM cluster Expected result: System VMs should come up on KVM cluster Ms log shows : Cluster: 2 has HyperVisorType that does not match the VM, skipping this cluster which should not be the case in case of SSVM and CPVM attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7759) [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Likitha Shetty updated CLOUDSTACK-7759: --- Priority: Major (was: Critical) [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start Key: CLOUDSTACK-7759 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7759 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Environment: Latest build from 4.5 Reporter: Sanjeev N Assignee: Likitha Shetty Fix For: 4.5.0 Attachments: management-server.rar [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start Steps to Reproduce: === 1.Create CS 4.5 setup using vmware cluster 2.Wait for the system vms to come up Observations: == During system vms start up we see lot of javax.xml.ws.soap.SOAPFaultExceptions in the MS log file 2014-10-21 21:17:28,104 WARN [c.c.h.v.m.HttpNfcLeaseMO] (Thread-29:null) Unexpected exception javax.xml.ws.soap.SOAPFaultException: A specified parameter was not correct. percent at com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:129) at $Proxy413.httpNfcLeaseProgress(Unknown Source) at com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO.updateLeaseProgress(HttpNfcLeaseMO.java:104) at com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO$ProgressReporter.run(HttpNfcLeaseMO.java:163) But these exceptions disappear when the system vms are up and running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7759) [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213496#comment-14213496 ] Likitha Shetty commented on CLOUDSTACK-7759: Reducing the priority as it doesn't functionality and the System VMs successfully come up. [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start Key: CLOUDSTACK-7759 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7759 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Environment: Latest build from 4.5 Reporter: Sanjeev N Assignee: Likitha Shetty Fix For: 4.6.0 Attachments: management-server.rar [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start Steps to Reproduce: === 1.Create CS 4.5 setup using vmware cluster 2.Wait for the system vms to come up Observations: == During system vms start up we see lot of javax.xml.ws.soap.SOAPFaultExceptions in the MS log file 2014-10-21 21:17:28,104 WARN [c.c.h.v.m.HttpNfcLeaseMO] (Thread-29:null) Unexpected exception javax.xml.ws.soap.SOAPFaultException: A specified parameter was not correct. percent at com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:129) at $Proxy413.httpNfcLeaseProgress(Unknown Source) at com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO.updateLeaseProgress(HttpNfcLeaseMO.java:104) at com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO$ProgressReporter.run(HttpNfcLeaseMO.java:163) But these exceptions disappear when the system vms are up and running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7759) [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Likitha Shetty updated CLOUDSTACK-7759: --- Fix Version/s: (was: 4.5.0) 4.6.0 [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start Key: CLOUDSTACK-7759 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7759 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Environment: Latest build from 4.5 Reporter: Sanjeev N Assignee: Likitha Shetty Fix For: 4.6.0 Attachments: management-server.rar [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start Steps to Reproduce: === 1.Create CS 4.5 setup using vmware cluster 2.Wait for the system vms to come up Observations: == During system vms start up we see lot of javax.xml.ws.soap.SOAPFaultExceptions in the MS log file 2014-10-21 21:17:28,104 WARN [c.c.h.v.m.HttpNfcLeaseMO] (Thread-29:null) Unexpected exception javax.xml.ws.soap.SOAPFaultException: A specified parameter was not correct. percent at com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:129) at $Proxy413.httpNfcLeaseProgress(Unknown Source) at com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO.updateLeaseProgress(HttpNfcLeaseMO.java:104) at com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO$ProgressReporter.run(HttpNfcLeaseMO.java:163) But these exceptions disappear when the system vms are up and running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5482) Vmware - When nfs was down for about 1 hour , when snapshots were in progress , snapshot job failed when nfs was brought up leaving behind snaphots in CreatedOnPri
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ram Ganesh updated CLOUDSTACK-5482:
---
Assignee: edison su (was: Sateesh Chodapuneedi)
Vmware - When nfs was down for about 1 hour , when snapshots were in progress
, snapshot job failed when nfs was brought up leaving behind snaphots in
CreatedOnPrimary state.
-
Key: CLOUDSTACK-5482
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5482
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Environment: Build from 4.3
Reporter: Sangeetha Hariharan
Assignee: edison su
Fix For: 4.4.0, 4.5.0
Attachments: nfs12down.rar, vmware.rar, vmware.rar
Set up :
Advanced Zone with 2 5.1 ESXI hosts.
Steps to reproduce the problem:
1. Deploy 5 Vms in each of the hosts , so we start with 11 Vms.
2. Start concurrent snapshots for ROOT volumes of all the Vms.
3. Shutdown the Secondary storage server when the snapshots are in the
progress.
4. Bring the Secondary storage server up after 1 hour.
When the secondary storage was down , 2 of the snapshots were already
completed. 5 of them were in progress and the other 4 had not started yet.
Once the secondary store was brought up , I see the snapshots that were in
progress actually continue to download to secondary and succeed. But the
other 4 snapshots error out.
mysql select volume_id,status,created from snapshots;
+---+--+-+
| volume_id | status | created |
+---+--+-+
|22 | BackedUp | 2013-12-12 23:24:13 |
|21 | Destroyed| 2013-12-12 23:24:13 |
|20 | BackedUp | 2013-12-12 23:24:14 |
|19 | Destroyed| 2013-12-12 23:24:14 |
|18 | BackedUp | 2013-12-12 23:24:14 |
|17 | BackedUp | 2013-12-12 23:24:14 |
|16 | BackedUp | 2013-12-12 23:24:14 |
|14 | BackedUp | 2013-12-12 23:24:15 |
|25 | BackedUp | 2013-12-12 23:24:15 |
|24 | BackedUp | 2013-12-12 23:24:15 |
|23 | BackedUp | 2013-12-12 23:24:15 |
|22 | CreatedOnPrimary | 2013-12-12 23:53:38 |
|21 | BackedUp | 2013-12-12 23:53:38 |
|20 | BackedUp | 2013-12-12 23:53:38 |
|19 | BackedUp | 2013-12-12 23:53:39 |
|18 | CreatedOnPrimary | 2013-12-12 23:53:39 |
|17 | CreatedOnPrimary | 2013-12-12 23:53:40 |
|16 | CreatedOnPrimary | 2013-12-12 23:53:40 |
|14 | BackedUp | 2013-12-12 23:53:40 |
|25 | BackedUp | 2013-12-12 23:53:41 |
|24 | BackedUp | 2013-12-12 23:53:41 |
|23 | BackedUp | 2013-12-12 23:53:42 |
|21 | BackedUp | 2013-12-13 00:53:37 |
|19 | BackedUp | 2013-12-13 00:53:38 |
+---+--+-+
24 rows in set (0.00 sec)
This leaves behind incomplete snapshots. The directory does not have a ovf
file and has incomplete vmdk file.
[root@Rack3Host8 18]# ls -ltR
.:
total 12
drwxr-xr-x. 2 root root 4096 Dec 12 22:56 36d7964c-e545-41d7-b303-96359a88dcef
drwxr-xr-x. 2 root root 4096 Dec 12 22:30 68802f5f-84b1-42ad-8dca-4de7e83324e2
./36d7964c-e545-41d7-b303-96359a88dcef:
total 403256
-rw-r--r--. 1 root root 412524288 Dec 13 00:20
36d7964c-e545-41d7-b303-96359a88dcef-disk0.vmdk
./68802f5f-84b1-42ad-8dca-4de7e83324e2:
total 448860
-rw-r--r--. 1 root root 459168256 Dec 12 22:30
68802f5f-84b1-42ad-8dca-4de7e83324e2-disk0.vmdk
-rw-r--r--. 1 root root 6454 Dec 12 22:30
68802f5f-84b1-42ad-8dca-4de7e83324e2.ovf
[root@Rack3Host8 18]#
Following exception seen in the management server logs:
2013-12-12 20:23:13,021 DEBUG [c.c.a.t.Request] (AgentManager-Handler-2:null)
Seq 5-813367309: Processing: { Ans: , MgmtId: 95307354844397, via: 5, Ver:
v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{result:false,details:backup
snapshot exception: Exception: java.lang.Exception\nMessage: Unable to
finish the whole process to package as a OVA file\n,wait:0}}] }
2013-12-12 20:23:13,022 DEBUG [c.c.a.t.Request] (Job-Executor-1:ctx-83fb69a5
ctx-51e56052) Seq 5-813367309: Received: { Ans: , MgmtId: 95307354844397,
via: 5, Ver: v1, Flags: 10, { CopyCmdAnswer } }
2013-12-12 20:23:13,041 DEBUG [c.c.s.s.SnapshotManagerImpl]
(Job-Executor-1:ctx-83fb69a5 ctx-51e56052) Failed to
[jira] [Commented] (CLOUDSTACK-7530) [LXC] router VMs are not migrating to other cluster if we put its original host into maintenance
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213503#comment-14213503
]
Kishan Kavala commented on CLOUDSTACK-7530:
---
2014-11-15 15:23:19,364 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Work-Job-Executor-97:ctx-cf13ccba job-31/job-613) Remove job-613 from job
monitoring
2014-11-15 15:23:19,366 DEBUG [c.c.v.VirtualMachineManagerImpl]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615 ctx-9751a4a7) VM is already
stopped: VM[DomainRouter|r-127-VM]
2014-11-15 15:23:19,366 DEBUG [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615 ctx-9751a4a7) Done executing
VM work job:
com.cloud.vm.VmWorkStop{cleanup:false,userId:1,accountId:1,vmId:127,handlerName:VirtualMachineManagerImpl}
2014-11-15 15:23:19,366 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615 ctx-9751a4a7) Complete async
job-615, jobStatus: SUCCEEDED, resultCode: 0, result: null
2014-11-15 15:23:19,366 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615 ctx-9751a4a7) Publish async
job-615 complete on message bus
2014-11-15 15:23:19,366 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615 ctx-9751a4a7) Wake up jobs
related to job-615
2014-11-15 15:23:19,366 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615 ctx-9751a4a7) Update db
status for job-615
2014-11-15 15:23:19,367 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615 ctx-9751a4a7) Wake up jobs
joined with job-615 and disjoin all subjobs created from job- 615
2014-11-15 15:23:19,430 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615) Done with run of VM work
job: com.cloud.vm.VmWorkStop for VM 127, job origin: 480
2014-11-15 15:23:19,430 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615) Done executing
com.cloud.vm.VmWorkStop for job-615
2014-11-15 15:23:19,451 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(RouterMonitor-1:ctx-b081e6ea) Starting network Ntwk[204|Guest|8]...
2014-11-15 15:23:19,451 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(RouterMonitor-1:ctx-b081e6ea) Network id=204 is already implemented
2014-11-15 15:23:19,452 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(RouterMonitor-1:ctx-b081e6ea) Starting network Ntwk[202|Control|3]...
2014-11-15 15:23:19,453 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(RouterMonitor-1:ctx-b081e6ea) Network id=202 is already implemented
2014-11-15 15:23:19,453 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(RouterMonitor-1:ctx-b081e6ea) Starting network Ntwk[200|Public|1]...
2014-11-15 15:23:19,454 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(RouterMonitor-1:ctx-b081e6ea) Network id=200 is already implemented
2014-11-15 15:23:19,455 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(RouterMonitor-1:ctx-b081e6ea) Starting router VM[DomainRouter|r-127-VM]
[LXC] router VMs are not migrating to other cluster if we put its original
host into maintenance
-
Key: CLOUDSTACK-7530
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7530
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Fix For: 4.5.0
Repro steps:
Create a Zone with two LXC clusters each having one host
Launch a VM in this cluster
Put LXC host to maintenance which has router VM
Bug;
Router VM does not migrates to other available host in another cluster
Expected Result:
Router VM should migrate to other host in the 2nd cluster
Additional info to support my case :
1. When i started manually router vm it started in other cluster without issue
2. Other system vm like CPVM and SSVM in similar situation moves/recreated
for one cluster to another cluster .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7530) [LXC] router VMs are not migrating to other cluster if we put its original host into maintenance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213502#comment-14213502 ] Kishan Kavala commented on CLOUDSTACK-7530: --- If there are no user Vms running in the network, router Vm won't start after migration. Verified that VR started automatically in the other cluster when there are user Vms running in the same network. [LXC] router VMs are not migrating to other cluster if we put its original host into maintenance - Key: CLOUDSTACK-7530 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7530 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Fix For: 4.5.0 Repro steps: Create a Zone with two LXC clusters each having one host Launch a VM in this cluster Put LXC host to maintenance which has router VM Bug; Router VM does not migrates to other available host in another cluster Expected Result: Router VM should migrate to other host in the 2nd cluster Additional info to support my case : 1. When i started manually router vm it started in other cluster without issue 2. Other system vm like CPVM and SSVM in similar situation moves/recreated for one cluster to another cluster . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7530) [LXC] router VMs are not migrating to other cluster if we put its original host into maintenance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-7530. --- Resolution: Not a Problem [LXC] router VMs are not migrating to other cluster if we put its original host into maintenance - Key: CLOUDSTACK-7530 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7530 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Fix For: 4.5.0 Repro steps: Create a Zone with two LXC clusters each having one host Launch a VM in this cluster Put LXC host to maintenance which has router VM Bug; Router VM does not migrates to other available host in another cluster Expected Result: Router VM should migrate to other host in the 2nd cluster Additional info to support my case : 1. When i started manually router vm it started in other cluster without issue 2. Other system vm like CPVM and SSVM in similar situation moves/recreated for one cluster to another cluster . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6104) PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213506#comment-14213506 ] Sateesh Chodapuneedi commented on CLOUDSTACK-6104: -- Moved to 4.6 PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment -- Key: CLOUDSTACK-6104 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6104 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller, VMware Affects Versions: 4.5.0 Environment: CloudStack deployed over VMware ESXi hypervisor with Nexus 1000v as distributed virtual switch. Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: Future Currently PVLAN support is available in CloudStack deployment over VMware ESXi hypervisor for VMware dvSwitch only. This needs to be extended to Cisco Nexus 1000v as well. Code changes are required on resource front to ensure PVLAN setup/configuration done over Nexus 1000v switch in the same way as currently being done over VMware dvSwitch. FS - https://cwiki.apache.org/confluence/display/CLOUDSTACK/PVLAN+support+for+CloudStack+deployment+over+Nexus+1000v+in+VMware+environment Background of support of PVLAN in CloudStack :- https://cwiki.apache.org/confluence/display/CLOUDSTACK/Isolation+in+Advanced+Zone+using+PVLANs+-+Functional+Specification+for+VMWare+integration+with+CloudStack https://cwiki.apache.org/confluence/display/CLOUDSTACK/Isolation+in+Advanced+Zone+using+PVLANs https://cwiki.apache.org/confluence/display/CLOUDSTACK/PVLAN+for+isolation+within+a+VLAN -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6104) PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-6104: - Fix Version/s: (was: 4.5.0) Future PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment -- Key: CLOUDSTACK-6104 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6104 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller, VMware Affects Versions: 4.5.0 Environment: CloudStack deployed over VMware ESXi hypervisor with Nexus 1000v as distributed virtual switch. Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: Future Currently PVLAN support is available in CloudStack deployment over VMware ESXi hypervisor for VMware dvSwitch only. This needs to be extended to Cisco Nexus 1000v as well. Code changes are required on resource front to ensure PVLAN setup/configuration done over Nexus 1000v switch in the same way as currently being done over VMware dvSwitch. FS - https://cwiki.apache.org/confluence/display/CLOUDSTACK/PVLAN+support+for+CloudStack+deployment+over+Nexus+1000v+in+VMware+environment Background of support of PVLAN in CloudStack :- https://cwiki.apache.org/confluence/display/CLOUDSTACK/Isolation+in+Advanced+Zone+using+PVLANs+-+Functional+Specification+for+VMWare+integration+with+CloudStack https://cwiki.apache.org/confluence/display/CLOUDSTACK/Isolation+in+Advanced+Zone+using+PVLANs https://cwiki.apache.org/confluence/display/CLOUDSTACK/PVLAN+for+isolation+within+a+VLAN -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7714) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-7714: - Fix Version/s: (was: 4.5.0) 4.6.0 Triage and fix Coverity defects --- Key: CLOUDSTACK-7714 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7714 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Santhosh Kumar Edukulla Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 1. We have Coverity setup available, running as scheduled and individual owners are assigned with analyzed bugs. 2. As part of this bug, please triage and fix the relevant Coverity bugs assigned. It could be a count as small as 25 bugs. 3. First start with high impact in order to others later. 4. We can either triage them accordingly as fix required or false positive or not a bug accordingly. But, triage and fix accordingly wherever relevant and applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7714) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213508#comment-14213508 ] Sateesh Chodapuneedi commented on CLOUDSTACK-7714: -- Most of the coverity issues are minor and could be addressed in 4.6. Triage and fix Coverity defects --- Key: CLOUDSTACK-7714 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7714 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Santhosh Kumar Edukulla Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 1. We have Coverity setup available, running as scheduled and individual owners are assigned with analyzed bugs. 2. As part of this bug, please triage and fix the relevant Coverity bugs assigned. It could be a count as small as 25 bugs. 3. First start with high impact in order to others later. 4. We can either triage them accordingly as fix required or false positive or not a bug accordingly. But, triage and fix accordingly wherever relevant and applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7714) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213508#comment-14213508 ] Sateesh Chodapuneedi edited comment on CLOUDSTACK-7714 at 11/15/14 10:09 AM: - Most of the coverity issues seems minor issues and could be addressed in 4.6. was (Author: sateeshc): Most of the coverity issues are minor and could be addressed in 4.6. Triage and fix Coverity defects --- Key: CLOUDSTACK-7714 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7714 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Santhosh Kumar Edukulla Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 1. We have Coverity setup available, running as scheduled and individual owners are assigned with analyzed bugs. 2. As part of this bug, please triage and fix the relevant Coverity bugs assigned. It could be a count as small as 25 bugs. 3. First start with high impact in order to others later. 4. We can either triage them accordingly as fix required or false positive or not a bug accordingly. But, triage and fix accordingly wherever relevant and applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (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-tabpanelfocusedCommentId=14176679#comment-14176679 ] Rajesh Battala edited comment on CLOUDSTACK-5673 at 11/15/14 10:22 AM: --- from my above #1 comments it by design. I don't see any functionality is affected by it. if so, please feel free to open with details. was (Author: rajesh_battala): 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, 4.5.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] [Updated] (CLOUDSTACK-7712) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-7712: --- Fix Version/s: (was: 4.5.0) 4.6.0 Triage and fix Coverity defects --- Key: CLOUDSTACK-7712 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7712 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Santhosh Kumar Edukulla Assignee: Rajesh Battala Fix For: 4.6.0 1. We have Coverity setup available, running as scheduled and individual owners are assigned with analyzed bugs. 2. As part of this bug, please triage and fix the relevant Coverity bugs assigned. It could be a count as small as 25 bugs. 3. First start with high impact in order to others later. 4. We can either triage them accordingly as fix required or false positive or not a bug accordingly. But, triage and fix accordingly wherever relevant and applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (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 resolved CLOUDSTACK-5673. Resolution: Not a Problem [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, 4.5.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] [Resolved] (CLOUDSTACK-7582) Not able to remove tag from primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-7582. Resolution: Fixed Not able to remove tag from primary storage --- Key: CLOUDSTACK-7582 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7582 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.5.0 Reporter: prashant kumar mishra Assignee: Rajesh Battala Fix For: 4.5.0 steps to reproduce == 1-update storage tags 2-try to remove tag by passing empty value expected: tags should be removed actual storage tag is not getting removed API === http://10.147.59.173:8096/client/api?command=updateStoragePoolid=f672eae0-b400-3767-808f-b787a5c04d5ftags=capacitybytes=5497558138880response=xml updatestoragepoolresponse cloud-stack-version=4.5.0-SNAPSHOTstoragepoolidf672eae0-b400-3767-808f-b787a5c04d5f/idzoneidd5e96cca-0985-49fe-a777-49b257278c8a/zoneidzonenamemanasa/zonenamenameprimaryVMw/nameipaddress10.147.28.7/ipaddresspath/export/home/manasa/primaryVMw/pathcreated2014-09-12T11:26:37+0530/createdtypeNetworkFilesystem/typedisksizetotal5497558138880/disksizetotaldisksizeallocated4294967296/disksizeallocateddisksizeused2696516272128/disksizeusedtagsab/tagsstateUp/statescopeZONE/scopehypervisorVMware/hypervisor/storagepool/updatestoragepoolresponse -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6320) Upgrade 4.1.1 - 4.3.0 OVS provider should be inserted to the physical network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-6320: -- Assignee: (was: Kishan Kavala) Upgrade 4.1.1 - 4.3.0 OVS provider should be inserted to the physical network -- Key: CLOUDSTACK-6320 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6320 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Upgrading from CS 4.1.1 to CS 4.3.0, using Xenserver 6.1.0 Advanced zone with GRE isolation is configured before upgrade. Reporter: Florin Dumitrascu Fix For: 4.4.0, 4.5.0 When you create an Advanced zone in 4.3 code, server-side will automatically add OVS provider to its physical network. However, since your zone was created in 4.1 code and upgraded to 4.3, server-side won't automatically add OVS provider to its physical network. Full message thread: -Original Message- From: Alena Prokharchyk Sent: Friday, March 21, 2014 4:18 PM To: Jessica Wang; Florin Dumitrascu; Murali Reddy Cc: Nguyen Anh Tu (t...@apache.org); d...@cloudstack.apache.org Subject: Re: GRE isolation - no in service upgrade (4.1.1 to 4.3.0) - Is your zone an Advanced zone or Basic zone? (2) Then its a DB upgrade bug. If the GRE isolation is supported on the network in 4.1.1, DB upgrade should have inserted the provider to physical network. On 3/21/14, 3:51 PM, Jessica Wang jessica.w...@citrix.com wrote: [Alena] Not exactly like that. [Alena] None of the providers are added to the physical network by default if execute createPhysicalNetwork call via API. [Alena] Our CS UI does this job - adding the providers to the network - for you by calling addNetworkServiceProvider call. Actually, OVS provider is an exception. UI doesn't do the job because server-side already does the job. When you create an Advanced zone in 4.3 code, server-side will automatically add OVS provider to its physical network. However, since your zone was created in 4.1 code and upgraded to 4.3, server-side won't automatically add OVS provider to its physical network. Murali, please confirm. -Original Message- From: Alena Prokharchyk Sent: Friday, March 21, 2014 2:44 PM To: Florin Dumitrascu; Jessica Wang; Murali Reddy; Florin Dumitrascu Cc: Nguyen Anh Tu (t...@apache.org); d...@cloudstack.apache.org Subject: Re: GRE isolation - no in service upgrade (4.1.1 to 4.3.0) - Is your zone an Advanced zone or Basic zone? (2) On 3/21/14, 2:34 PM, Florin Dumitrascu florin.dumitra...@intunenetworks.com wrote: Hi, Alena, my assumption is that the Ovs provider is created when you create the physical network with GRE isolation (if someone can confirm ...). When I configured CS RC8 from scratch, I could see the provider and enable it in the GUI. Not exactly like that. None of the providers are added to the physical network by default if execute createPhysicalNetwork call via API. Our CS UI does this job - adding the providers to the network - for you by calling addNetworkServiceProvider call. But when I have upgraded from CS 4.1.1 to 4.3.0 RC9, I have preserved the existing configuration with the existing physical network. So my assumption is that the physical network was not updated with the OVS provider (such a provider was not needed in CS 4.1.1). So while you were on 4.1.1, GRE isolation was disabled? Did you enable it on 4.3? If there is a way to enable new isolation on the physical network, on my opinion - the UI should perform the background call and add all the providers associated with this option, to the physical network. So it would be a UI issue. Or the case was the following - the GRE isolation was enabled on your network while on 4.1.1, but new provider - OVS - was added in 4.3. And this provider wasn't added to existing physical networks during the upgrade. Then its a database upgrade bug. Please confirm which one from the above is correct. Jessica, I am building CentOS RPM packages from the RC source, using package.sh script in the source packaging folder. Not aware about the difference between oss and noredist. Also, my setup is for an advanced zone. Kind Regards, Florin -Original Message- From: Jessica Wang [mailto:jessica.w...@citrix.com] Sent: Friday, March 21, 2014 8:28 PM To: Florin Dumitrascu; Murali Reddy Cc: Nguyen Anh Tu (t...@apache.org); d...@cloudstack.apache.org; Alena Prokharchyk Subject: RE: GRE isolation - no in service upgrade (4.1.1 to 4.3.0) - Is your zone an Advanced zone or Basic zone? (2) Florin, UI
[jira] [Updated] (CLOUDSTACK-6719) OVS:VPC:UI wizard allowing to add non OVS enabled network to distributed VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-6719: -- Assignee: (was: Kishan Kavala) OVS:VPC:UI wizard allowing to add non OVS enabled network to distributed VPC Key: CLOUDSTACK-6719 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6719 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: sadhu suresh Fix For: 4.5.0 problem:OVS:VPC:UI: Add new tier wizard allowing to add non OVS enabled network to VPC created with OVS+distributed VPC VR Steps to Reprodude: 1.Bring up CS in advanced zon 2.create a vpc offering with OVS and along with other all supported services 3. create a VPC with above network offering 4.try to create non ovs network(i.e network created default isolated vpc offering) on ovs based VPC. actual result: allowing to add non OVS enabled network to OVS enabled VPC expected result: it should not allow to add non OVS enabled network to OVS enabled VPC. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
