[jira] [Created] (CLOUDSTACK-5689) component.test_vpc_network.TestVPCNetworkUpgrade.test_01_network_services_upgrade failing with SSH error
Gaurav Aradhye created CLOUDSTACK-5689: -- Summary: component.test_vpc_network.TestVPCNetworkUpgrade.test_01_network_services_upgrade failing with SSH error Key: CLOUDSTACK-5689 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5689 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.3.0 test_01_network_services_upgrade (integration.component.test_vpc_network.TestVPCNetworkUpgrade): CRITICAL: FAILED: test_01_network_services_upgrade: Traceback (most recent call last): File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /root/cloudstack/test/integration/component/test_vpc_network.py, line 1853, in test_01_network_services_upgrade (public_ip_1.ipaddress.ipaddress, e)) File /usr/local/lib/python2.7/unittest/case.py, line 393, in fail raise self.failureException(msg) AssertionError: Failed to SSH into VM - 10.147.53.36, SSH connection has Failed. Waited 600s. Error is Connection Failed -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5690) [Upgrade from 4.2.1-4.3]System VMs and Router VMs are not upgraded to new 64bit templates .
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
manasaveloori updated CLOUDSTACK-5690:
--
Attachment: mysqldump421.dmp
mysqldump43.dmp
[Upgrade from 4.2.1-4.3]System VMs and Router VMs are not upgraded to new
64bit templates .
Key: CLOUDSTACK-5690
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5690
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Upgrade
Affects Versions: 4.3.0
Environment: upgrade from 4.2.1 to 4.3
Reporter: manasaveloori
Priority: Critical
Fix For: 4.3.0
Attachments: mysqldump421.dmp, mysqldump43.dmp
Steps:
1.Deploy CS 4.2.1 .Use 32 bit templates.
2.Deploy some VRs.
3.Register 64bit templates.
4.Upgrade to 4.3.
5.Now stop and start(or destroy) the system VMs so that they get upgraded
to new 64 bit templates.
Observation:
The system VMs are not upgraded to new 64 bit template:
mysql select * from volumes where instance_id=5\G;before destroying
*** 1. row ***
id: 7
account_id: 1
domain_id: 1
pool_id: 2
last_pool_id: NULL
instance_id: 5
device_id: 0
name: ROOT-5
uuid: 6f324474-5fa5-44cb-8950-d0aced23f334
size: 0
folder: NULL
path: ROOT-5
pod_id: NULL
data_center_id: 2
iscsi_name: NULL
host_ip: NULL
volume_type: ROOT
pool_type: NULL
disk_offering_id: 9
template_id: 8
first_snapshot_backup_uuid: NULL
recreatable: 1
created: 2013-12-30 17:22:48
attached: NULL
updated: 2013-12-31 13:24:33
removed: 2013-12-31 13:24:33
state: Expunged
chain_info:
{diskDeviceBusName:scsi0:0,diskChain:[[f672eae0b4003767808fb787a5c04d5f]
s-5-VM/ROOT-5.vmdk]}
update_count: 6
disk_type: NULL
vm_snapshot_chain_size: NULL
iso_id: NULL
display_volume: 1
format: OVA
min_iops: NULL
max_iops: NULL
hv_ss_reserve: NULL
1 row in set (0.00 sec)
ERROR:
No query specified
mysql select * from volumes where instance_id=14\G;--after destroying.
*** 1. row ***
id: 17
account_id: 1
domain_id: 1
pool_id: 2
last_pool_id: NULL
instance_id: 14
device_id: 0
name: ROOT-14
uuid: d4e8a55a-0cdc-4bbb-bfba-a18f16e29ff9
size: 2097152000
folder: NULL
path: ROOT-14
pod_id: NULL
data_center_id: 2
iscsi_name: NULL
host_ip: NULL
volume_type: ROOT
pool_type: NULL
disk_offering_id: 9
template_id: 8
first_snapshot_backup_uuid: NULL
recreatable: 1
created: 2013-12-31 13:24:33
attached: NULL
updated: 2013-12-31 13:26:13
removed: NULL
state: Ready
chain_info:
{diskDeviceBusName:ide0:1,diskChain:[[f672eae0b4003767808fb787a5c04d5f]
s-14-VM/ROOT-14.vmdk]}
update_count: 2
disk_type: NULL
vm_snapshot_chain_size: NULL
iso_id: NULL
display_volume: 1
format: OVA
min_iops: NULL
max_iops: NULL
hv_ss_reserve: NULL
1 row in set (0.00 sec)
ERROR:
No query specified
Note:
For Router VMs the field requires upgrade is set to “ No”. So there is no
option to upgrade the VR to new 64 bit template.
Even after stop and start of the VR the template is not upgraded to 64 bit.
Attaching the mysql dumps.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5690) [Upgrade from 4.2.1-4.3]System VMs and Router VMs are not upgraded to new 64bit templates .
manasaveloori created CLOUDSTACK-5690:
-
Summary: [Upgrade from 4.2.1-4.3]System VMs and Router VMs are
not upgraded to new 64bit templates .
Key: CLOUDSTACK-5690
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5690
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Upgrade
Affects Versions: 4.3.0
Environment: upgrade from 4.2.1 to 4.3
Reporter: manasaveloori
Priority: Critical
Fix For: 4.3.0
Attachments: mysqldump421.dmp, mysqldump43.dmp
Steps:
1. Deploy CS 4.2.1 .Use 32 bit templates.
2. Deploy some VRs.
3. Register 64bit templates.
4. Upgrade to 4.3.
5. Now stop and start(or destroy) the system VMs so that they get upgraded
to new 64 bit templates.
Observation:
The system VMs are not upgraded to new 64 bit template:
mysql select * from volumes where instance_id=5\G;before destroying
*** 1. row ***
id: 7
account_id: 1
domain_id: 1
pool_id: 2
last_pool_id: NULL
instance_id: 5
device_id: 0
name: ROOT-5
uuid: 6f324474-5fa5-44cb-8950-d0aced23f334
size: 0
folder: NULL
path: ROOT-5
pod_id: NULL
data_center_id: 2
iscsi_name: NULL
host_ip: NULL
volume_type: ROOT
pool_type: NULL
disk_offering_id: 9
template_id: 8
first_snapshot_backup_uuid: NULL
recreatable: 1
created: 2013-12-30 17:22:48
attached: NULL
updated: 2013-12-31 13:24:33
removed: 2013-12-31 13:24:33
state: Expunged
chain_info:
{diskDeviceBusName:scsi0:0,diskChain:[[f672eae0b4003767808fb787a5c04d5f]
s-5-VM/ROOT-5.vmdk]}
update_count: 6
disk_type: NULL
vm_snapshot_chain_size: NULL
iso_id: NULL
display_volume: 1
format: OVA
min_iops: NULL
max_iops: NULL
hv_ss_reserve: NULL
1 row in set (0.00 sec)
ERROR:
No query specified
mysql select * from volumes where instance_id=14\G;--after destroying.
*** 1. row ***
id: 17
account_id: 1
domain_id: 1
pool_id: 2
last_pool_id: NULL
instance_id: 14
device_id: 0
name: ROOT-14
uuid: d4e8a55a-0cdc-4bbb-bfba-a18f16e29ff9
size: 2097152000
folder: NULL
path: ROOT-14
pod_id: NULL
data_center_id: 2
iscsi_name: NULL
host_ip: NULL
volume_type: ROOT
pool_type: NULL
disk_offering_id: 9
template_id: 8
first_snapshot_backup_uuid: NULL
recreatable: 1
created: 2013-12-31 13:24:33
attached: NULL
updated: 2013-12-31 13:26:13
removed: NULL
state: Ready
chain_info:
{diskDeviceBusName:ide0:1,diskChain:[[f672eae0b4003767808fb787a5c04d5f]
s-14-VM/ROOT-14.vmdk]}
update_count: 2
disk_type: NULL
vm_snapshot_chain_size: NULL
iso_id: NULL
display_volume: 1
format: OVA
min_iops: NULL
max_iops: NULL
hv_ss_reserve: NULL
1 row in set (0.00 sec)
ERROR:
No query specified
Note:
For Router VMs the field requires upgrade is set to “ No”. So there is no
option to upgrade the VR to new 64 bit template.
Even after stop and start of the VR the template is not upgraded to 64 bit.
Attaching the mysql dumps.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5560) [Hyper-V] Re-attach Data disk is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinav Roy closed CLOUDSTACK-5560.
---
Closing the issue after fix validation
[Hyper-V] Re-attach Data disk is failing
Key: CLOUDSTACK-5560
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5560
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Management Server, Storage
Controller
Affects Versions: 4.3.0
Environment: 4.3, Hyper-V
Reporter: Abhinav Roy
Assignee: Devdeep Singh
Priority: Critical
Labels: hyper-V,, hyper-v, hyperv
Fix For: 4.3.0
Steps :
1. Create an advanced zone setup with hyper-v as the host hypervisor type and
local storage for primary storage
2. Deploy a VM ex. VM1
3. Create some volumes v1, v2 ,v3
4. Attach v1 to VM1 .
5 Detach v1 from VM1
6. Attach v1 or v2 or v3 to VM1
Expected behaviour :
=
Attach , Detach and re-attach should be working fine.
Observed behaviour:
Attach and Detach is working fine but re-attach is failing with :
2013-12-19 12:15:21,874 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-304:ctx-ba54a897) executeRequest received response
[{org.apache.cloudstack.storage.command.AttachAnswer:{disk:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:5916489b-d8c3-433d-8439-04b10925d0c1,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:ce50406b-9038-37ba-9b72-6228d5eb0858,id:1,poolType:NetworkFilesystem,host:10.102.192.19,path:/HYPERV-SMB/abhinav-hyperv-ps1?user\u003dabhinav\u0026password\u003dfreebsd@123\u0026domain\u003dBLR,port:445,url:NetworkFilesystem://10.102.192.19//HYPERV-SMB/abhinav-hyperv-ps1?user\u003dabhinav\u0026password\u003dfreebsd@123\u0026domain\u003dBLR/?ROLE\u003dPrimary\u0026STOREUUID\u003dce50406b-9038-37ba-9b72-6228d5eb0858}},name:vol2,size:5368709120,volumeId:11,accountId:2,id:11,hypervisorType:Hyperv}},diskSeq:1,type:DATADISK,_details:{managed:false,storagePort:445,storageHost:10.102.192.19,volumeSize:5368709120}},result:false,details:org.apache.cloudstack.storage.command.AttachCommand
failed due to Hyper-V Job failed, Error Code:32775, Description:
\u0027i-2-8-VM\u0027 failed to add device \u0027Synthetic Disk Drive\u0027.
(Virtual machine ID
5F95525C-D979-450A-828D-8449855AF80E)\n\n\u0027i-2-8-VM\u0027: Cannot attach
storage media to the controller because the specified location is in use.
(Virtual machine ID
5F95525C-D979-450A-828D-8449855AF80E),contextMap:{},wait:0}}]
2013-12-19 12:15:21,874 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-304:ctx-ba54a897) Seq 1-562367802: Response Received:
2013-12-19 12:15:21,875 DEBUG [c.c.a.t.Request]
(DirectAgent-304:ctx-ba54a897) Seq 1-562367802: Processing: { Ans: , MgmtId:
280320865129348, via: 1, Ver: v1, Flags: 10,
[{org.apache.cloudstack.storage.command.AttachAnswer:{disk:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:5916489b-d8c3-433d-8439-04b10925d0c1,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:ce50406b-9038-37ba-9b72-6228d5eb0858,id:1,poolType:NetworkFilesystem,host:10.102.192.19,path:/HYPERV-SMB/abhinav-hyperv-ps1?user=abhinavpassword=freebsd@123domain=BLR,port:445,url:NetworkFilesystem://10.102.192.19//HYPERV-SMB/abhinav-hyperv-ps1?user=abhinavpassword=freebsd@123domain=BLR/?ROLE=PrimarySTOREUUID=ce50406b-9038-37ba-9b72-6228d5eb0858}},name:vol2,size:5368709120,volumeId:11,accountId:2,id:11,hypervisorType:Hyperv}},diskSeq:1,type:DATADISK,_details:{managed:false,storagePort:445,storageHost:10.102.192.19,volumeSize:5368709120}},result:false,details:org.apache.cloudstack.storage.command.AttachCommand
failed due to Hyper-V Job failed, Error Code:32775, Description: 'i-2-8-VM'
failed to add device 'Synthetic Disk Drive'. (Virtual machine ID
5F95525C-D979-450A-828D-8449855AF80E)\n\n'i-2-8-VM': Cannot attach storage
media to the controller because the specified location is in use. (Virtual
machine ID 5F95525C-D979-450A-828D-8449855AF80E),wait:0}}] }
2013-12-19 12:15:21,875 DEBUG [c.c.a.t.Request] (Job-Executor-23:ctx-45871688
ctx-af56967a) Seq 1-562367802: Received: { Ans: , MgmtId: 280320865129348,
via: 1, Ver: v1, Flags: 10, { AttachAnswer } }
2013-12-19 12:15:21,875 ERROR [c.c.a.ApiAsyncJobDispatcher]
(Job-Executor-23:ctx-45871688) Unexpected exception while executing
org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
com.cloud.utils.exception.CloudRuntimeException: Failed to attach volume:
vol2 to VM: v3; org.apache.cloudstack.storage.command.AttachCommand failed
due
[jira] [Closed] (CLOUDSTACK-4973) CLONE - Specified keyboard language is not showing as default in consoleView passed during deployVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi closed CLOUDSTACK-4973. --- Verified on 4.3 branch. CLONE - Specified keyboard language is not showing as default in consoleView passed during deployVM --- Key: CLOUDSTACK-4973 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4973 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VNC Proxy Affects Versions: 4.1.0, 4.2.0 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Priority: Critical Fix For: 4.3.0 While deploying a VM, user passes the keyboard parameter to specify the default language for that VM but in the consoleView, the default language selected is en-us irrespective of the default language of the VM. To change the language, user has to navigate through the dropdown menu provided in consoleView. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-4450) Possibility of /tmp/xapilog filling up the Root disk on Xenserver
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi closed CLOUDSTACK-4450. --- Verified on 4.3 branch with XenServer 6.2. Possibility of /tmp/xapilog filling up the Root disk on Xenserver -- Key: CLOUDSTACK-4450 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4450 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: XenServer Affects Versions: 4.2.0 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Fix For: 4.3.0 CloudStack installs /opt/xensource/sm/hostvmstats.py script into XenServer. And the script keeps outputting the log into /tmp/xapilog. Now the log is being huge size (Almost 120MBytes) since the file has no architecture to delete/compress. The info logged in /opt/xensource/sm/hostvmstats.py is not much useful. There are few cases in the past where CloudStack was contributing to Root filesystem being full on xenserver. We need to make sure either we delete/overwrite/rotate the file /tmp/xapilog in Xenserver. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-4612) Specified keyboard language is not showing as default in consoleView passed during deployVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi closed CLOUDSTACK-4612. --- Verified. Specified keyboard language is not showing as default in consoleView passed during deployVM --- Key: CLOUDSTACK-4612 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4612 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VNC Proxy Affects Versions: 4.1.0, 4.2.0 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Fix For: 4.2.1 While deploying a VM, user passes the keyboard parameter to specify the default language for that VM but in the consoleView, the default language selected is en-us irrespective of the default language of the VM. To change the language, user has to navigate through the dropdown menu provided in consoleView. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-4826) System VMs fail to start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-4826. --- Resolution: Fixed Added steps under Troubleshooting section: https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.2+%28KVM%29+System+Vm+Upgrade System VMs fail to start Key: CLOUDSTACK-4826 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4826 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc, KVM Affects Versions: 4.2.0 Environment: CentOS 6.4 qemu-kvm-0.12.1.2-2.355.0.1.el6_4.9.x86_64 Cloudstack installed from RPM repo listed in docs AND: libvirt-client-0.10.2-18.el6_4.14.x86_64 libvirt-0.10.2-18.el6_4.14.x86_64 qemu-kvm-0.12.1.2-2.355.0.1.el6.centos.7.x86_64 CloudStack 4.2 upgraded based on 4.2 release guide steps Reporter: Dave Garbus Assignee: Kishan Kavala Priority: Critical Fix For: 4.3.0 After upgrading from 4.1.1 to 4.2, system VMs did not restart properly when running cloudstack-sysvmadm. Since we do not rely heavily on them at this point, I removed them figuring they would simply be recreated (this has worked in the past). When CloudStack attempts to recreate the VMs, provisioning fails: agent.log (IPs are obscured): Timed out: /usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/patchviasocket.pl -n s-111-VM -p %template=domP%type=secstorage%host=.com%port=8250%name=s-111-VM%zone=1%pod=1%guid=s-111-VM%resource=com.cloud.storage.resource.PremiumSecondaryStorageResource%instance=SecStorage%sslcopy=true%role=templateProcessor%mtu=1500%eth2ip=XX.XX.XX.XX%eth2mask=255.255.255.0%gateway=XX.XX.XX.XX%public.network.device=eth2%eth0ip=169.254.0.47%eth0mask=255.255.0.0%eth1ip=XX.XX.XX.XX%eth1mask=255.255.255.0%mgmtcidr=XX.XX.XX.0/29%localgw=XX.XX.XX.XX%private.network.device=eth1%eth3ip=XX.XX.XX.XX%eth3mask=255.255.255.0%storageip=XX.XX.XX.XX%storagenetmask=255.255.255.0%storagegateway=XX.XX.XX.XX%internaldns1=XX.XX.XX.XX%internaldns2=XX.XX.XX.XX%dns1=XX.XX.XX.XX%dns2=XX.XX.XX.XX . Output is: I gained access to the VM using the root password, and this is what I found: root@systemvm:~# cat /etc/cloudstack-release Cloudstack Release 3.0 Mon Feb 6 15:10:04 PST 2012 root@systemvm:~# uname -a Linux systemvm 2.6.32-5-686-bigmem #1 SMP Mon Jan 16 16:42:05 UTC 2012 i686 GNU/Linux root@systemvm:~# /etc/init.d/cloud- cloud-early-config cloud-passwd-srvr root@systemvm:~# /etc/init.d/cloud-early-config start Executing cloud-early-config...Executing cloud-early-config...Detected that we are running inside kvm guest.../dev/vport0p1 not loaded, perhaps guest kernel is too oldroot@systemvm:~# I have the system vm template systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2, which is the latest (to my knowledge), on my secondary storage NFS mount, however, the SSVM is not able to be started, so I'm not sure this helps. Please let me know if more information is needed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5691) [Hyper-V] Attaching an uploaded volume to a VM is failing
Abhinav Roy created CLOUDSTACK-5691:
---
Summary: [Hyper-V] Attaching an uploaded volume to a VM is failing
Key: CLOUDSTACK-5691
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5691
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
Environment: hyperv, 4.3, CIFS as primary and secondary storage
Reporter: Abhinav Roy
Priority: Critical
Fix For: 4.3.0
Steps :
=
1. Deploy an advanced zone setup with hyperv.
2. Create a VM.
3. upload a volume.
4. Attach the volume uploaded in step 3 to the VM created in step 2.
Expected behaviour:
=
Attach volume should succeed.
Observed behaviour:
=
Attach volume fails with :
MS logs :
--
013-12-31 16:18:14,644 DEBUG [c.c.a.ApiServlet] (catalina-exec-7:ctx-e8c1f6eb)
===START=== 10.144.7.20 -- GET
command=attachVolumeid=86c04ec1-d29e-404b-b9c6-a42db8b5afe6virtualMachineId=51ba1f12-34a1-4108-968e-bbd9f6893545response=jsonsessionkey=Hy%2BMYL%2B00HT2HmcPy%2FMiDAr%2FQBw%3D_=1388486725851
2013-12-31 16:18:14,660 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-7:ctx-e8c1f6eb ctx-687f028b) submit async job-239, details:
AsyncJobVO {id:239, userId: 2, accountId: 2, instanceType: Volume, instanceId:
55, cmd: org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd,
cmdInfo:
{response:json,id:86c04ec1-d29e-404b-b9c6-a42db8b5afe6,sessionkey:Hy+MYL+00HT2HmcPy/MiDAr/QBw\u003d,cmdEventType:VOLUME.ATTACH,ctxUserId:2,virtualMachineId:51ba1f12-34a1-4108-968e-bbd9f6893545,httpmethod:GET,_:1388486725851,ctxAccountId:2,ctxStartEventId:672},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 280320865129348, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2013-12-31 16:18:14,660 DEBUG [c.c.a.ApiServlet] (catalina-exec-7:ctx-e8c1f6eb
ctx-687f028b) ===END=== 10.144.7.20 -- GET
command=attachVolumeid=86c04ec1-d29e-404b-b9c6-a42db8b5afe6virtualMachineId=51ba1f12-34a1-4108-968e-bbd9f6893545response=jsonsessionkey=Hy%2BMYL%2B00HT2HmcPy%2FMiDAr%2FQBw%3D_=1388486725851
2013-12-31 16:18:14,661 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Job-Executor-35:ctx-4fc638a9) Add job-239 into job monitoring
2013-12-31 16:18:14,662 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-35:ctx-4fc638a9) Executing AsyncJobVO {id:239, userId: 2,
accountId: 2, instanceType: Volume, instanceId: 55, cmd:
org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd, cmdInfo:
{response:json,id:86c04ec1-d29e-404b-b9c6-a42db8b5afe6,sessionkey:Hy+MYL+00HT2HmcPy/MiDAr/QBw\u003d,cmdEventType:VOLUME.ATTACH,ctxUserId:2,virtualMachineId:51ba1f12-34a1-4108-968e-bbd9f6893545,httpmethod:GET,_:1388486725851,ctxAccountId:2,ctxStartEventId:672},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 280320865129348, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2013-12-31 16:18:14,688 DEBUG [o.a.c.s.a.LocalStoragePoolAllocator]
(Job-Executor-35:ctx-4fc638a9 ctx-687f028b) LocalStoragePoolAllocator trying to
find storage pool to fit the vm
2013-12-31 16:18:14,688 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-35:ctx-4fc638a9 ctx-687f028b) ClusterScopeStoragePoolAllocator
looking for storage pool
2013-12-31 16:18:14,688 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-35:ctx-4fc638a9 ctx-687f028b) Looking for pools in dc: 2 pod:2
cluster:2
2013-12-31 16:18:14,691 DEBUG [o.a.c.s.a.AbstractStoragePoolAllocator]
(Job-Executor-35:ctx-4fc638a9 ctx-687f028b) Checking if storage pool is
suitable, name: null ,poolId: 4
2013-12-31 16:18:14,696 DEBUG [c.c.s.StorageManagerImpl]
(Job-Executor-35:ctx-4fc638a9 ctx-687f028b) Checking pool: 4 for volume
allocation [Vol[55|vm=null|DATADISK]], maxSize : 1997545660416,
totalAllocatedSize : 89599652352, askingSize : 0, allocated disable threshold:
0.85
2013-12-31 16:18:14,696 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-35:ctx-4fc638a9 ctx-687f028b) ClusterScopeStoragePoolAllocator
returning 1 suitable storage pools
2013-12-31 16:18:14,697 DEBUG [o.a.c.e.o.VolumeOrchestrator]
(Job-Executor-35:ctx-4fc638a9 ctx-687f028b) Trying to create
org.apache.cloudstack.storage.volume.VolumeObject@719ddf22 on
org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@33a46b74
2013-12-31 16:18:14,711 DEBUG
[o.a.c.s.d.d.CloudStackPrimaryDataStoreDriverImpl]
(Job-Executor-35:ctx-4fc638a9 ctx-687f028b) Creating volume:
org.apache.cloudstack.storage.volume.VolumeObject@74c64a24
2013-12-31 16:18:14,715 DEBUG [c.c.a.t.Request] (Job-Executor-35:ctx-4fc638a9
ctx-687f028b) Seq 5-234160586: Sending { Cmd
[jira] [Assigned] (CLOUDSTACK-5691) [Hyper-V] Attaching an uploaded volume to a VM is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Devdeep Singh reassigned CLOUDSTACK-5691:
-
Assignee: Devdeep Singh
[Hyper-V] Attaching an uploaded volume to a VM is failing
-
Key: CLOUDSTACK-5691
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5691
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
Environment: hyperv, 4.3, CIFS as primary and secondary storage
Reporter: Abhinav Roy
Assignee: Devdeep Singh
Priority: Critical
Labels: hyper-V,, hyper-v, hyperv
Fix For: 4.3.0
Steps :
=
1. Deploy an advanced zone setup with hyperv.
2. Create a VM.
3. upload a volume.
4. Attach the volume uploaded in step 3 to the VM created in step 2.
Expected behaviour:
=
Attach volume should succeed.
Observed behaviour:
=
Attach volume fails with :
MS logs :
--
013-12-31 16:18:14,644 DEBUG [c.c.a.ApiServlet]
(catalina-exec-7:ctx-e8c1f6eb) ===START=== 10.144.7.20 -- GET
command=attachVolumeid=86c04ec1-d29e-404b-b9c6-a42db8b5afe6virtualMachineId=51ba1f12-34a1-4108-968e-bbd9f6893545response=jsonsessionkey=Hy%2BMYL%2B00HT2HmcPy%2FMiDAr%2FQBw%3D_=1388486725851
2013-12-31 16:18:14,660 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-7:ctx-e8c1f6eb ctx-687f028b) submit async job-239, details:
AsyncJobVO {id:239, userId: 2, accountId: 2, instanceType: Volume,
instanceId: 55, cmd:
org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd, cmdInfo:
{response:json,id:86c04ec1-d29e-404b-b9c6-a42db8b5afe6,sessionkey:Hy+MYL+00HT2HmcPy/MiDAr/QBw\u003d,cmdEventType:VOLUME.ATTACH,ctxUserId:2,virtualMachineId:51ba1f12-34a1-4108-968e-bbd9f6893545,httpmethod:GET,_:1388486725851,ctxAccountId:2,ctxStartEventId:672},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 280320865129348, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2013-12-31 16:18:14,660 DEBUG [c.c.a.ApiServlet]
(catalina-exec-7:ctx-e8c1f6eb ctx-687f028b) ===END=== 10.144.7.20 -- GET
command=attachVolumeid=86c04ec1-d29e-404b-b9c6-a42db8b5afe6virtualMachineId=51ba1f12-34a1-4108-968e-bbd9f6893545response=jsonsessionkey=Hy%2BMYL%2B00HT2HmcPy%2FMiDAr%2FQBw%3D_=1388486725851
2013-12-31 16:18:14,661 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Job-Executor-35:ctx-4fc638a9) Add job-239 into job monitoring
2013-12-31 16:18:14,662 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-35:ctx-4fc638a9) Executing AsyncJobVO {id:239, userId: 2,
accountId: 2, instanceType: Volume, instanceId: 55, cmd:
org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd, cmdInfo:
{response:json,id:86c04ec1-d29e-404b-b9c6-a42db8b5afe6,sessionkey:Hy+MYL+00HT2HmcPy/MiDAr/QBw\u003d,cmdEventType:VOLUME.ATTACH,ctxUserId:2,virtualMachineId:51ba1f12-34a1-4108-968e-bbd9f6893545,httpmethod:GET,_:1388486725851,ctxAccountId:2,ctxStartEventId:672},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 280320865129348, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2013-12-31 16:18:14,688 DEBUG [o.a.c.s.a.LocalStoragePoolAllocator]
(Job-Executor-35:ctx-4fc638a9 ctx-687f028b) LocalStoragePoolAllocator trying
to find storage pool to fit the vm
2013-12-31 16:18:14,688 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-35:ctx-4fc638a9 ctx-687f028b) ClusterScopeStoragePoolAllocator
looking for storage pool
2013-12-31 16:18:14,688 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-35:ctx-4fc638a9 ctx-687f028b) Looking for pools in dc: 2 pod:2
cluster:2
2013-12-31 16:18:14,691 DEBUG [o.a.c.s.a.AbstractStoragePoolAllocator]
(Job-Executor-35:ctx-4fc638a9 ctx-687f028b) Checking if storage pool is
suitable, name: null ,poolId: 4
2013-12-31 16:18:14,696 DEBUG [c.c.s.StorageManagerImpl]
(Job-Executor-35:ctx-4fc638a9 ctx-687f028b) Checking pool: 4 for volume
allocation [Vol[55|vm=null|DATADISK]], maxSize : 1997545660416,
totalAllocatedSize : 89599652352, askingSize : 0, allocated disable
threshold: 0.85
2013-12-31 16:18:14,696 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-35:ctx-4fc638a9 ctx-687f028b) ClusterScopeStoragePoolAllocator
returning 1 suitable storage pools
2013-12-31 16:18:14,697 DEBUG [o.a.c.e.o.VolumeOrchestrator]
(Job-Executor-35:ctx-4fc638a9 ctx-687f028b) Trying to create
org.apache.cloudstack.storage.volume.VolumeObject@719ddf22 on
[jira] [Resolved] (CLOUDSTACK-5008) [VMWARE]Failed to start the VM after performing Cold Migration of Volume to Second Zone wide primary Storage
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi resolved CLOUDSTACK-5008.
--
Resolution: Fixed
This is issue is fixed by commit ae8ed582280b37e0c24a8f0f54702f02819a10b7.
For cold migration of volume, if the volume must be either detached from VM.
Migration of volume is allowed (mean live migration) if volume is attached to a
VM which is running.
Hence bug description should change here as the behavior is changed with above
commit.
Note:- To verify this bug following needs to be considered.
At step -7 volume must be detached before trying to initiate a migration.
At step -8 attach the volume and try to start the VM..
=
ae8ed582 (Alex Huang 2013-08-12 17:37:28 -0700 1550) // If the
disk is not attached to any VM then it can be moved. Otherwise, it needs to be
attached to a vm
ae8ed582 (Alex Huang 2013-08-12 17:37:28 -0700 1551) //
running on a hypervisor that supports storage motion so that it be be migrated.
ae8ed582 (Alex Huang 2013-08-12 17:37:28 -0700 1552) if
(instanceId != null !liveMigrateVolume) {
ae8ed582 (Alex Huang 2013-08-12 17:37:28 -0700 1553) throw
new InvalidParameterValueException(Volume needs to be detached from VM);
ae8ed582 (Alex Huang 2013-08-12 17:37:28 -0700 1554) }
[VMWARE]Failed to start the VM after performing Cold Migration of Volume to
Second Zone wide primary Storage
Key: CLOUDSTACK-5008
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5008
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller, VMware
Affects Versions: 4.2.1
Reporter: Sailaja Mada
Assignee: Sateesh Chodapuneedi
Priority: Critical
Fix For: 4.3.0
Attachments: migrationlogs.rar
Steps:
1. Configure Adv zone with VMWARE ESXi 5.0 Update 2 hypervisor
2. Configure two Zone wide primary storages
3. Have 2 VMWARE clusters each with 5.0 Update2 ESXi hosts
4. Deploy VM using user account
5. Attach 3 DATA volumes. Write DATA onto first DISK
6. Stop the VM
7. Migrate the DATA DISK 1 to second zone wide primary storage
8. Tried to start the VM after migration is completed.
Observation:
[VMWARE]Failed to start the VM after performing Cold Migration of Volume to
Second Zone wide primary Storage
2013-10-30 19:49:49,187 WARN [vmware.resource.VmwareResource]
(DirectAgent-267:10.102.192.19) StartCommand failed due to Exception:
java.lang.RuntimeException
Message: File
[]/vmfs/volumes/371681b9-ed4b0743/i-4-10-VM/9db1d292e0394eb39e69c8adee09e26c.vmdk
was not found
java.lang.RuntimeException: File
[]/vmfs/volumes/371681b9-ed4b0743/i-4-10-VM/9db1d292e0394eb39e69c8adee09e26c.vmdk
was not found
at
com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:411)
at
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.configureVm(VirtualMachineMO.java:843)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2966)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:513)
at
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2013-10-30 19:49:49,194 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-267:null) Seq 8-1057948407: Response Received:
2013-10-30 19:49:49,198 DEBUG [agent.transport.Request]
(DirectAgent-267:null) Seq 8-1057948407: Processing: { Ans: , MgmtId:
94838926819810, via: 8, Ver: v1, Flags: 110,
[{com.cloud.agent.api.StartAnswer:{vm:{id:10,name:i-4-10-VM,bootloader:HVM,type:User,cpus:1,minSpeed:500,maxSpeed:500,minRam:536870912,maxRam:536870912,hostName:sharedinst1,arch:x86_64,os:CentOS
5.3
[jira] [Commented] (CLOUDSTACK-5393) [Automation] Failed to create snapshot from ROOT volume in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859469#comment-13859469
]
sadhu suresh commented on CLOUDSTACK-5393:
--
not able to reproduce the issue on 4.2 branch. tested on dev setup by pulling
the latest code from 4.2 branch [for kvm agent-generated build from ACS4.2
branch and install agent on host from build],
Primary used :nfs
[Automation] Failed to create snapshot from ROOT volume in KVM
--
Key: CLOUDSTACK-5393
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5393
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Snapshot
Affects Versions: 4.3.0
Environment: KVM (RHEL 6.3)
Branch : 4.3
Reporter: Rayees Namathponnan
Assignee: edison su
Priority: Critical
Fix For: 4.3.0
Attachments: agent1.rar, agent2.rar, management-server.rar, ssvm.rar
Steps to reproduce
1) Create advanced zone in KVM
2) Deploy VM
3 ) Stop VM
4 ) Create snapshot from root volume
Snapshot creation failed with below exception
2013-12-05 15:39:44,194 DEBUG [c.c.a.t.Request] (Job-Executor-64:ctx-1b710e00
ctx-3cf3df4e) Seq 1-1244399478: Received: { Ans: , MgmtId: 29066118877352,
via: 1, Ver: v1, Flags: 10, { CreateObjectAnswer } }
2013-12-05 15:39:44,284 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
(Job-Executor-64:ctx-1b710e00 ctx-3cf3df4e) copyAsync inspecting src type
SNAPSHOT copyAsync inspecting dest type SNAPSHOT
2013-12-05 15:39:44,332 DEBUG [c.c.a.t.Request] (Job-Executor-64:ctx-1b710e00
ctx-3cf3df4e) Seq 2-332864214: Sending { Cmd , MgmtId: 29066118877352, via:
2(Rack2Host12.lab.vmops.com), Ver: v1, Flags: 100011, [{org.apache.cl
oudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215/8f7d268f-1a96-4d70-9c48-cb7f6cc935a8
,volume:{uuid:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesyst
em,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08
ca01d9}},name:ROOT-919,size:8589934592,path:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeId:988,vmName:i-2-919-QA,accountId:2,format:QCOW2,id:988,deviceId:0,hypervisorType:KVM},parentSnapshotPath
:/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215/d43b61bc-4ade-4753-b1d9-c0398388147d,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},vmName:i-2-919-QA,name:QA-eb54bbfa-12d5-49b5-808f-864dddedc1fd_ROOT-919_20131205233943,hypervisorType:KVM,id:54,quiescevm:false}},destTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:snapshots/2/988,volume:{uuid:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},name:ROOT-919,size:8589934592,path:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeId:988,vmName:i-2-919-QA,accountId:2,format:QCOW2,id:988,deviceId:0,hypervisorType:KVM},dataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.223.110.232:/export/home/rayees/SC_QA_AUTO4/secondary,_role:Image}},vmName:i-2-919-QA,name:QA-eb54bbfa-12d5-49b5-808f-864dddedc1fd_ROOT-919_20131205233943,hypervisorType:KVM,id:54,quiescevm:false}},executeInSequence:false,wait:21600}}]
}
2013-12-05 15:39:44,501 DEBUG [c.c.a.t.Request]
(StatsCollector-3:ctx-3ac54662) Seq 1-1244399477: Received: { Ans: , MgmtId:
29066118877352, via: 1, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
2013-12-05 15:39:44,900 DEBUG [c.c.a.t.Request] (AgentManager-Handler-1:null)
Seq 2-332864214: Processing: { Ans: , MgmtId: 29066118877352, via: 2, Ver:
v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{result:false,details:/usr/share/cloudstack-common/scripts/storage/qcow2/managesnapshot.sh:
line 178: 26840 Floating point exception(core dumped) $qemu_img
[jira] [Created] (CLOUDSTACK-5692) obscure passwords when using cifs as storage
Saksham Srivastava created CLOUDSTACK-5692: -- Summary: obscure passwords when using cifs as storage Key: CLOUDSTACK-5692 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5692 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Reporter: Saksham Srivastava Assignee: Saksham Srivastava Fix For: 4.3.0 Interaction with cifs storage is not obscuring password. This is found at API response while listing primary/secondary stores. Also few logs contain the password. There is a need to obscure the passwords at both the places. Environment: Hyper-V with cifs as secondary -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5393) [Automation] Failed to create snapshot from ROOT volume in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859473#comment-13859473
]
Nux commented on CLOUDSTACK-5393:
-
Can you post the RPMs somewhere? I'd like to test them out on my setup.
[Automation] Failed to create snapshot from ROOT volume in KVM
--
Key: CLOUDSTACK-5393
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5393
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Snapshot
Affects Versions: 4.3.0
Environment: KVM (RHEL 6.3)
Branch : 4.3
Reporter: Rayees Namathponnan
Assignee: edison su
Priority: Critical
Fix For: 4.3.0
Attachments: agent1.rar, agent2.rar, management-server.rar, ssvm.rar
Steps to reproduce
1) Create advanced zone in KVM
2) Deploy VM
3 ) Stop VM
4 ) Create snapshot from root volume
Snapshot creation failed with below exception
2013-12-05 15:39:44,194 DEBUG [c.c.a.t.Request] (Job-Executor-64:ctx-1b710e00
ctx-3cf3df4e) Seq 1-1244399478: Received: { Ans: , MgmtId: 29066118877352,
via: 1, Ver: v1, Flags: 10, { CreateObjectAnswer } }
2013-12-05 15:39:44,284 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
(Job-Executor-64:ctx-1b710e00 ctx-3cf3df4e) copyAsync inspecting src type
SNAPSHOT copyAsync inspecting dest type SNAPSHOT
2013-12-05 15:39:44,332 DEBUG [c.c.a.t.Request] (Job-Executor-64:ctx-1b710e00
ctx-3cf3df4e) Seq 2-332864214: Sending { Cmd , MgmtId: 29066118877352, via:
2(Rack2Host12.lab.vmops.com), Ver: v1, Flags: 100011, [{org.apache.cl
oudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215/8f7d268f-1a96-4d70-9c48-cb7f6cc935a8
,volume:{uuid:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesyst
em,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08
ca01d9}},name:ROOT-919,size:8589934592,path:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeId:988,vmName:i-2-919-QA,accountId:2,format:QCOW2,id:988,deviceId:0,hypervisorType:KVM},parentSnapshotPath
:/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215/d43b61bc-4ade-4753-b1d9-c0398388147d,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},vmName:i-2-919-QA,name:QA-eb54bbfa-12d5-49b5-808f-864dddedc1fd_ROOT-919_20131205233943,hypervisorType:KVM,id:54,quiescevm:false}},destTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:snapshots/2/988,volume:{uuid:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},name:ROOT-919,size:8589934592,path:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeId:988,vmName:i-2-919-QA,accountId:2,format:QCOW2,id:988,deviceId:0,hypervisorType:KVM},dataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.223.110.232:/export/home/rayees/SC_QA_AUTO4/secondary,_role:Image}},vmName:i-2-919-QA,name:QA-eb54bbfa-12d5-49b5-808f-864dddedc1fd_ROOT-919_20131205233943,hypervisorType:KVM,id:54,quiescevm:false}},executeInSequence:false,wait:21600}}]
}
2013-12-05 15:39:44,501 DEBUG [c.c.a.t.Request]
(StatsCollector-3:ctx-3ac54662) Seq 1-1244399477: Received: { Ans: , MgmtId:
29066118877352, via: 1, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
2013-12-05 15:39:44,900 DEBUG [c.c.a.t.Request] (AgentManager-Handler-1:null)
Seq 2-332864214: Processing: { Ans: , MgmtId: 29066118877352, via: 2, Ver:
v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{result:false,details:/usr/share/cloudstack-common/scripts/storage/qcow2/managesnapshot.sh:
line 178: 26840 Floating point exception(core dumped) $qemu_img convert -f
qcow2 -O qcow2 -s $snapshotname $disk $destPath/$destName /dev/nullFailed
to backup 8f7d268f-1a96-4d70-9c48-cb7f6cc935a8 for disk
[jira] [Commented] (CLOUDSTACK-5344) [Hyper-V] Console access does not work for any VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859477#comment-13859477 ] ASF subversion and git services commented on CLOUDSTACK-5344: - Commit b55d9ecf533a5253b0b5cdcd155c692b1d3d7bec in branch refs/heads/4.3 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b55d9ec ] CLOUDSTACK-5344 commit for console proxy rdp for hyperv [Hyper-V] Console access does not work for any VM - Key: CLOUDSTACK-5344 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5344 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server Affects Versions: 4.3.0 Environment: Latest build from 4.3 Reporter: Sanjeev N Assignee: Anshul Gangwar Priority: Blocker Labels: hyper-V, Fix For: 4.3.0 [Hyperv-V] Console access does not work for any VM Steps to Reproduce: 1.Bring up CS with latest build from 4.3 using hyperv 2.Wait for the CPVM to come up. 3.Deploy guest vm and try to access the vm's console Result: === Server Internal Error -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-5633) [Automation]cleanup failed due to network deletion failed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gaurav Aradhye reassigned CLOUDSTACK-5633:
--
Assignee: Gaurav Aradhye
[Automation]cleanup failed due to network deletion failed
-
Key: CLOUDSTACK-5633
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5633
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.3.0
Environment: xenserver 62
advanced zone
Reporter: Srikanteswararao Talluri
Assignee: Gaurav Aradhye
Fix For: 4.3.0
Creating this bug as a place holder for the following failures, needs further
analysis,
test_03_network_createFAILED Warning: Exception during cleanup :
Execute cmd: deletenetwork failed, due to: errorCode: 431, errorText:Networkd
id=334 doesn't exist
test_07_egress_fr7FAILED Warning! Cleanup failed: Execute cmd:
asyncquery failed, due to: {errorcode : 530, errortext : u'Failed to delete
network'}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5689) component.test_vpc_network.TestVPCNetworkUpgrade.test_01_network_services_upgrade failing with SSH error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye resolved CLOUDSTACK-5689. Resolution: Fixed The issue is resolved as part of CLOUDSTACK-5636 component.test_vpc_network.TestVPCNetworkUpgrade.test_01_network_services_upgrade failing with SSH error Key: CLOUDSTACK-5689 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5689 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.3.0 test_01_network_services_upgrade (integration.component.test_vpc_network.TestVPCNetworkUpgrade): CRITICAL: FAILED: test_01_network_services_upgrade: Traceback (most recent call last): File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /root/cloudstack/test/integration/component/test_vpc_network.py, line 1853, in test_01_network_services_upgrade (public_ip_1.ipaddress.ipaddress, e)) File /usr/local/lib/python2.7/unittest/case.py, line 393, in fail raise self.failureException(msg) AssertionError: Failed to SSH into VM - 10.147.53.36, SSH connection has Failed. Waited 600s. Error is Connection Failed -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5689) [Automation] component.test_vpc_network.TestVPCNetworkUpgrade.test_01_network_services_upgrade failing with SSH error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-5689: --- Summary: [Automation] component.test_vpc_network.TestVPCNetworkUpgrade.test_01_network_services_upgrade failing with SSH error (was: component.test_vpc_network.TestVPCNetworkUpgrade.test_01_network_services_upgrade failing with SSH error) [Automation] component.test_vpc_network.TestVPCNetworkUpgrade.test_01_network_services_upgrade failing with SSH error - Key: CLOUDSTACK-5689 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5689 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.3.0 test_01_network_services_upgrade (integration.component.test_vpc_network.TestVPCNetworkUpgrade): CRITICAL: FAILED: test_01_network_services_upgrade: Traceback (most recent call last): File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /root/cloudstack/test/integration/component/test_vpc_network.py, line 1853, in test_01_network_services_upgrade (public_ip_1.ipaddress.ipaddress, e)) File /usr/local/lib/python2.7/unittest/case.py, line 393, in fail raise self.failureException(msg) AssertionError: Failed to SSH into VM - 10.147.53.36, SSH connection has Failed. Waited 600s. Error is Connection Failed -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5693) [Automation] Destroy Virtual Machine operation fails with error Unable to delete vm snapshots for VM[User|vm-name]
Gaurav Aradhye created CLOUDSTACK-5693: -- Summary: [Automation] Destroy Virtual Machine operation fails with error Unable to delete vm snapshots for VM[User|vm-name] Key: CLOUDSTACK-5693 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5693 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API, KVM, VMware Affects Versions: 4.3.0 Environment: I have observed this issue in KVM and VMware. Yet to check on XenServer Reporter: Gaurav Aradhye Fix For: 4.3.0 Deploy a virtual machine and try to delete/destroy it through API or UI. Operation fails with error Unable to delete vm snapshots for VM[User|vm-name] More information in MS Logs. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5693) [Automation] Destroy Virtual Machine operation fails with error Unable to delete vm snapshots for VM[User|vm-name]
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-5693: --- Description: Deploy a virtual machine and try to delete/destroy it through API or UI. Operation fails with error Unable to delete vm snapshots for VM[User|vm-name] More information in MS Logs. The management server log is from VMware. was: Deploy a virtual machine and try to delete/destroy it through API or UI. Operation fails with error Unable to delete vm snapshots for VM[User|vm-name] More information in MS Logs. [Automation] Destroy Virtual Machine operation fails with error Unable to delete vm snapshots for VM[User|vm-name] Key: CLOUDSTACK-5693 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5693 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, KVM, VMware Affects Versions: 4.3.0 Environment: I have observed this issue in KVM and VMware. Yet to check on XenServer Reporter: Gaurav Aradhye Labels: automation Fix For: 4.3.0 Attachments: MgtSvr-Log.txt Deploy a virtual machine and try to delete/destroy it through API or UI. Operation fails with error Unable to delete vm snapshots for VM[User|vm-name] More information in MS Logs. The management server log is from VMware. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5693) [Automation] Destroy Virtual Machine operation fails with error Unable to delete vm snapshots for VM[User|vm-name]
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-5693: --- Attachment: MgtSvr-Log.txt [Automation] Destroy Virtual Machine operation fails with error Unable to delete vm snapshots for VM[User|vm-name] Key: CLOUDSTACK-5693 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5693 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, KVM, VMware Affects Versions: 4.3.0 Environment: I have observed this issue in KVM and VMware. Yet to check on XenServer Reporter: Gaurav Aradhye Labels: automation Fix For: 4.3.0 Attachments: MgtSvr-Log.txt Deploy a virtual machine and try to delete/destroy it through API or UI. Operation fails with error Unable to delete vm snapshots for VM[User|vm-name] More information in MS Logs. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5693) [Automation] Destroy Virtual Machine operation fails with error Unable to delete vm snapshots for VM[User|vm-name]
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-5693: --- Description: Deploy a virtual machine and try to delete/destroy it through API or UI. Operation fails with error Unable to delete vm snapshots for VM[User|vm-name] And after this error, VM's state transitions to stopped. More information in MS Logs. The management server log is from VMware. I could not found the agent log on the host. Please let me know if it is required. was: Deploy a virtual machine and try to delete/destroy it through API or UI. Operation fails with error Unable to delete vm snapshots for VM[User|vm-name] More information in MS Logs. The management server log is from VMware. I could not found the agent log on the host. Please let me know if it is required. [Automation] Destroy Virtual Machine operation fails with error Unable to delete vm snapshots for VM[User|vm-name] Key: CLOUDSTACK-5693 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5693 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, KVM, VMware Affects Versions: 4.3.0 Environment: I have observed this issue in KVM and VMware. Yet to check on XenServer Reporter: Gaurav Aradhye Labels: automation Fix For: 4.3.0 Attachments: MgtSvr-Log.txt Deploy a virtual machine and try to delete/destroy it through API or UI. Operation fails with error Unable to delete vm snapshots for VM[User|vm-name] And after this error, VM's state transitions to stopped. More information in MS Logs. The management server log is from VMware. I could not found the agent log on the host. Please let me know if it is required. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5693) [Automation] Destroy Virtual Machine operation fails with error Unable to delete vm snapshots for VM[User|vm-name]
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan resolved CLOUDSTACK-5693. - Resolution: Duplicate duplicate of https://issues.apache.org/jira/browse/CLOUDSTACK-5669 [Automation] Destroy Virtual Machine operation fails with error Unable to delete vm snapshots for VM[User|vm-name] Key: CLOUDSTACK-5693 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5693 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, KVM, VMware Affects Versions: 4.3.0 Environment: I have observed this issue in KVM and VMware. Yet to check on XenServer Reporter: Gaurav Aradhye Labels: automation Fix For: 4.3.0 Attachments: MgtSvr-Log.txt Deploy a virtual machine and try to delete/destroy it through API or UI. Operation fails with error Unable to delete vm snapshots for VM[User|vm-name] And after this error, VM's state transitions to stopped. More information in MS Logs. The management server log is from VMware. I could not found the agent log on the host. Please let me know if it is required. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5633) [Automation]cleanup failed due to network deletion failed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859513#comment-13859513
]
Gaurav Aradhye commented on CLOUDSTACK-5633:
Can't reproduce because it fails in previous operation due to issue 5669.
[Automation]cleanup failed due to network deletion failed
-
Key: CLOUDSTACK-5633
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5633
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.3.0
Environment: xenserver 62
advanced zone
Reporter: Srikanteswararao Talluri
Assignee: Gaurav Aradhye
Fix For: 4.3.0
Creating this bug as a place holder for the following failures, needs further
analysis,
test_03_network_createFAILED Warning: Exception during cleanup :
Execute cmd: deletenetwork failed, due to: errorCode: 431, errorText:Networkd
id=334 doesn't exist
test_07_egress_fr7FAILED Warning! Cleanup failed: Execute cmd:
asyncquery failed, due to: {errorcode : 530, errortext : u'Failed to delete
network'}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5393) [Automation] Failed to create snapshot from ROOT volume in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan closed CLOUDSTACK-5393.
---
Resolution: Fixed
I didnt see this issue in latest 4.3 branch automation runs, closing this
defect
[Automation] Failed to create snapshot from ROOT volume in KVM
--
Key: CLOUDSTACK-5393
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5393
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Snapshot
Affects Versions: 4.3.0
Environment: KVM (RHEL 6.3)
Branch : 4.3
Reporter: Rayees Namathponnan
Assignee: edison su
Priority: Critical
Fix For: 4.3.0
Attachments: agent1.rar, agent2.rar, management-server.rar, ssvm.rar
Steps to reproduce
1) Create advanced zone in KVM
2) Deploy VM
3 ) Stop VM
4 ) Create snapshot from root volume
Snapshot creation failed with below exception
2013-12-05 15:39:44,194 DEBUG [c.c.a.t.Request] (Job-Executor-64:ctx-1b710e00
ctx-3cf3df4e) Seq 1-1244399478: Received: { Ans: , MgmtId: 29066118877352,
via: 1, Ver: v1, Flags: 10, { CreateObjectAnswer } }
2013-12-05 15:39:44,284 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
(Job-Executor-64:ctx-1b710e00 ctx-3cf3df4e) copyAsync inspecting src type
SNAPSHOT copyAsync inspecting dest type SNAPSHOT
2013-12-05 15:39:44,332 DEBUG [c.c.a.t.Request] (Job-Executor-64:ctx-1b710e00
ctx-3cf3df4e) Seq 2-332864214: Sending { Cmd , MgmtId: 29066118877352, via:
2(Rack2Host12.lab.vmops.com), Ver: v1, Flags: 100011, [{org.apache.cl
oudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215/8f7d268f-1a96-4d70-9c48-cb7f6cc935a8
,volume:{uuid:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesyst
em,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08
ca01d9}},name:ROOT-919,size:8589934592,path:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeId:988,vmName:i-2-919-QA,accountId:2,format:QCOW2,id:988,deviceId:0,hypervisorType:KVM},parentSnapshotPath
:/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215/d43b61bc-4ade-4753-b1d9-c0398388147d,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},vmName:i-2-919-QA,name:QA-eb54bbfa-12d5-49b5-808f-864dddedc1fd_ROOT-919_20131205233943,hypervisorType:KVM,id:54,quiescevm:false}},destTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:snapshots/2/988,volume:{uuid:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},name:ROOT-919,size:8589934592,path:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeId:988,vmName:i-2-919-QA,accountId:2,format:QCOW2,id:988,deviceId:0,hypervisorType:KVM},dataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.223.110.232:/export/home/rayees/SC_QA_AUTO4/secondary,_role:Image}},vmName:i-2-919-QA,name:QA-eb54bbfa-12d5-49b5-808f-864dddedc1fd_ROOT-919_20131205233943,hypervisorType:KVM,id:54,quiescevm:false}},executeInSequence:false,wait:21600}}]
}
2013-12-05 15:39:44,501 DEBUG [c.c.a.t.Request]
(StatsCollector-3:ctx-3ac54662) Seq 1-1244399477: Received: { Ans: , MgmtId:
29066118877352, via: 1, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
2013-12-05 15:39:44,900 DEBUG [c.c.a.t.Request] (AgentManager-Handler-1:null)
Seq 2-332864214: Processing: { Ans: , MgmtId: 29066118877352, via: 2, Ver:
v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{result:false,details:/usr/share/cloudstack-common/scripts/storage/qcow2/managesnapshot.sh:
line 178: 26840 Floating point exception(core dumped) $qemu_img convert -f
qcow2 -O qcow2 -s $snapshotname $disk $destPath/$destName /dev/nullFailed
to backup 8f7d268f-1a96-4d70-9c48-cb7f6cc935a8 for disk
[jira] [Comment Edited] (CLOUDSTACK-764) nTier Apps 2.0 : Redundant Virtual Router for VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859537#comment-13859537 ] Karl Harris edited comment on CLOUDSTACK-764 at 12/31/13 3:48 PM: -- My colleagues and I have been tasked by my company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: 1. About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ 2. Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec 3. Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec 4. Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # These routers are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's any gotcha's we should know about? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? was (Author: karl.harris): Me and my colleagues have been tasked by my company, Sungard, to implement and test the functionality of this JIRA. Myself and several of my colleagues at Sungard have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: 1. About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ 2. Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec 3. Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec 4. Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # These routers are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's any gotcha's we should know about? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? nTier Apps 2.0 : Redundant Virtual Router for VPC - Key: CLOUDSTACK-764 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-764 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala This item is a sub task (2.17) of https://issues.apache.org/jira/browse/CLOUDSTACK-621 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-764) nTier Apps 2.0 : Redundant Virtual Router for VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859537#comment-13859537 ] Karl Harris commented on CLOUDSTACK-764: Me and my colleagues have been tasked by my company, Sungard, to implement and test the functionality of this JIRA. Myself and several of my colleagues at Sungard have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: 1. About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ 2. Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec 3. Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec 4. Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # These routers are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's any gotcha's we should know about? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? nTier Apps 2.0 : Redundant Virtual Router for VPC - Key: CLOUDSTACK-764 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-764 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala This item is a sub task (2.17) of https://issues.apache.org/jira/browse/CLOUDSTACK-621 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (CLOUDSTACK-764) nTier Apps 2.0 : Redundant Virtual Router for VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859537#comment-13859537 ] Karl Harris edited comment on CLOUDSTACK-764 at 12/31/13 3:49 PM: -- My colleagues and I have been tasked by my company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: 1. About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ 2. Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec 3. Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec 4. Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's any gotcha's we should know about? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? was (Author: karl.harris): My colleagues and I have been tasked by my company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: 1. About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ 2. Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec 3. Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec 4. Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # These routers are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's any gotcha's we should know about? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? nTier Apps 2.0 : Redundant Virtual Router for VPC - Key: CLOUDSTACK-764 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-764 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala This item is a sub task (2.17) of https://issues.apache.org/jira/browse/CLOUDSTACK-621 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (CLOUDSTACK-764) nTier Apps 2.0 : Redundant Virtual Router for VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859537#comment-13859537 ] Karl Harris edited comment on CLOUDSTACK-764 at 12/31/13 3:54 PM: -- My colleagues and I have been tasked by my company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: 1. About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ 2. Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec 3. Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec 4. Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's any gotcha's we should know about? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? was (Author: karl.harris): My colleagues and I have been tasked by my company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: 1. About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ 2. Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec 3. Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec 4. Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's any gotcha's we should know about? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? nTier Apps 2.0 : Redundant Virtual Router for VPC - Key: CLOUDSTACK-764 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-764 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala This item is a sub task (2.17) of https://issues.apache.org/jira/browse/CLOUDSTACK-621 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (CLOUDSTACK-764) nTier Apps 2.0 : Redundant Virtual Router for VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859537#comment-13859537 ] Karl Harris edited comment on CLOUDSTACK-764 at 12/31/13 3:54 PM: -- My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: 1. About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ 2. Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec 3. Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec 4. Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's any gotcha's we should know about? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? was (Author: karl.harris): My colleagues and I have been tasked by my company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: 1. About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ 2. Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec 3. Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec 4. Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's any gotcha's we should know about? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? nTier Apps 2.0 : Redundant Virtual Router for VPC - Key: CLOUDSTACK-764 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-764 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan
[jira] [Comment Edited] (CLOUDSTACK-764) nTier Apps 2.0 : Redundant Virtual Router for VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859537#comment-13859537 ] Karl Harris edited comment on CLOUDSTACK-764 at 12/31/13 3:57 PM: -- My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: #About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ #Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec #Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec #Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? was (Author: karl.harris): My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: 1. About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ 2. Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec 3. Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec 4. Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's any gotcha's we should know about? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? nTier Apps 2.0 : Redundant Virtual Router for VPC - Key: CLOUDSTACK-764 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-764 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala This item
[jira] [Comment Edited] (CLOUDSTACK-764) nTier Apps 2.0 : Redundant Virtual Router for VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859537#comment-13859537 ] Karl Harris edited comment on CLOUDSTACK-764 at 12/31/13 3:58 PM: -- My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ # Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec # Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? was (Author: karl.harris): My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: #About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ #Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec #Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec #Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? nTier Apps 2.0 : Redundant Virtual Router for VPC - Key: CLOUDSTACK-764 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-764 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala This item is a sub
[jira] [Comment Edited] (CLOUDSTACK-764) nTier Apps 2.0 : Redundant Virtual Router for VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859537#comment-13859537 ] Karl Harris edited comment on CLOUDSTACK-764 at 12/31/13 3:59 PM: -- My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ . # Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec . # Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec. # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? was (Author: karl.harris): My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ # Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec # Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? nTier Apps 2.0 : Redundant Virtual Router for VPC - Key: CLOUDSTACK-764 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-764 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala This item
[jira] [Comment Edited] (CLOUDSTACK-764) nTier Apps 2.0 : Redundant Virtual Router for VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859537#comment-13859537 ] Karl Harris edited comment on CLOUDSTACK-764 at 12/31/13 4:02 PM: -- My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/. # Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec . # Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? was (Author: karl.harris): My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ . # Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec . # Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? nTier Apps 2.0 : Redundant Virtual Router for VPC - Key: CLOUDSTACK-764 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-764 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala This item
[jira] [Comment Edited] (CLOUDSTACK-764) nTier Apps 2.0 : Redundant Virtual Router for VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859537#comment-13859537 ] Karl Harris edited comment on CLOUDSTACK-764 at 12/31/13 4:01 PM: -- My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ . # Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec . # Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? was (Author: karl.harris): My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/ . # Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec . # Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? nTier Apps 2.0 : Redundant Virtual Router for VPC - Key: CLOUDSTACK-764 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-764 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala This
[jira] [Comment Edited] (CLOUDSTACK-764) nTier Apps 2.0 : Redundant Virtual Router for VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859537#comment-13859537 ] Karl Harris edited comment on CLOUDSTACK-764 at 12/31/13 4:03 PM: -- My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: #About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/. #Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec . #Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec #Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? was (Author: karl.harris): My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/. # Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec . # Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? nTier Apps 2.0 : Redundant Virtual Router for VPC - Key: CLOUDSTACK-764 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-764 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala This item is a
[jira] [Comment Edited] (CLOUDSTACK-764) nTier Apps 2.0 : Redundant Virtual Router for VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859537#comment-13859537 ] Karl Harris edited comment on CLOUDSTACK-764 at 12/31/13 4:04 PM: -- My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/. # Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec . # Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? was (Author: karl.harris): My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: #About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/. #Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec . #Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec #Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? nTier Apps 2.0 : Redundant Virtual Router for VPC - Key: CLOUDSTACK-764 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-764 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala This item is a sub
[jira] [Comment Edited] (CLOUDSTACK-764) nTier Apps 2.0 : Redundant Virtual Router for VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859537#comment-13859537 ] Karl Harris edited comment on CLOUDSTACK-764 at 12/31/13 4:06 PM: -- My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # About RvR[ http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/]. # Cloudstack function spec for RvR [https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec] . # Cloudstack function spec for new VPC features [https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec] # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? was (Author: karl.harris): My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/. # Cloudstack function spec for RvR [https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec] . # Cloudstack function spec for new VPC features [https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec] # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? nTier Apps 2.0 : Redundant Virtual Router for VPC - Key: CLOUDSTACK-764 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-764 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala This
[jira] [Comment Edited] (CLOUDSTACK-764) nTier Apps 2.0 : Redundant Virtual Router for VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859537#comment-13859537 ] Karl Harris edited comment on CLOUDSTACK-764 at 12/31/13 4:06 PM: -- My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/. # Cloudstack function spec for RvR [https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec] . # Cloudstack function spec for new VPC features [https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec] # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? was (Author: karl.harris): My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # About RvR http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/. # Cloudstack function spec for RvR https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec . # Cloudstack function spec for new VPC features https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? nTier Apps 2.0 : Redundant Virtual Router for VPC - Key: CLOUDSTACK-764 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-764 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala This item
[jira] [Comment Edited] (CLOUDSTACK-764) nTier Apps 2.0 : Redundant Virtual Router for VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859537#comment-13859537 ] Karl Harris edited comment on CLOUDSTACK-764 at 12/31/13 4:07 PM: -- My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # [ http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/]. # Cloudstack function spec for RvR [https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec] . # Cloudstack function spec for new VPC features [https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec] # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? was (Author: karl.harris): My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # About RvR[ http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/]. # Cloudstack function spec for RvR [https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec] . # Cloudstack function spec for new VPC features [https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec] # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? nTier Apps 2.0 : Redundant Virtual Router for VPC - Key: CLOUDSTACK-764 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-764 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala This item is
[jira] [Comment Edited] (CLOUDSTACK-764) nTier Apps 2.0 : Redundant Virtual Router for VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859537#comment-13859537 ] Karl Harris edited comment on CLOUDSTACK-764 at 12/31/13 4:09 PM: -- My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # [http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform] # Cloudstack function spec for RvR [https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec] . # Cloudstack function spec for new VPC features [https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec] # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? was (Author: karl.harris): My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # [ http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform/]. # Cloudstack function spec for RvR [https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec] . # Cloudstack function spec for new VPC features [https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec] # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? nTier Apps 2.0 : Redundant Virtual Router for VPC - Key: CLOUDSTACK-764 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-764 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala This item is a sub task
[jira] [Comment Edited] (CLOUDSTACK-764) nTier Apps 2.0 : Redundant Virtual Router for VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859537#comment-13859537 ] Karl Harris edited comment on CLOUDSTACK-764 at 12/31/13 4:18 PM: -- My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # [http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform] # Cloudstack function spec for RvR [https://cwiki.apache.org/confluence/display/CLOUDSTACK/Reundant+Virtual+Router+Functional+Spec]. # Cloudstack function spec for new VPC features [https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec]. # Implemented code for RvR in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? was (Author: karl.harris): My colleagues and I have been tasked by our company, Sungard, to implement and test the functionality of this JIRA. We have done some preliminary work and I will outline what we've found and several questions we have. We will certainly have more questions/comments, but this is a good start. Please comment, correct or add to the statements and questions below: We have referenced: # [http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform] # Cloudstack function spec for RvR [https://cwiki.apache.org/confluence/display/CLOUDSTACK/Redundant+Virtual+Router+Functional+Spec] . # Cloudstack function spec for new VPC features [https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec] # Implemented codes for RvR Mostly it's in VirtualNetworkApplianceManagerImpl, as well as redundant_router directory of systemvm and in cloud-early-setup. What we know: # Redundant Virtual Routers (RvR's) are used in CloudStack public clouds per item 4 above. # The public RvRs are provisioned with the templates contained in redundant_router directory of systemvm. # Keepalived and Conntrackd do most of the heavy lifting monitoring and transitioning the current RvR's in public clouds. # Keepalived and Contrackd are setup with templates by systemvm. # The setup_router script calls the setup_redundant_router to provision a redundant router pair for a vm. # We will need to confirm each router of a redundant pair is provisioned under a separate Hypervisor to allow for no single point of failure. Questions: # Are there any other references which might be helpful? # It seems the VirtualNetworkApplianceManagerImpl and associated classes should be useable for vpcRvR's are there any gotcha's we should know about when using this class hierarchy ? # Are there any other single points of failure other than the unique Hypervisor mentioned above? # Can setting up a redundant router pair for a vpc be done by simply adding a call to setup_redundant_router script in the setup_vpcrouter routine for each vpcRouter marked as redundant? nTier Apps 2.0 : Redundant Virtual Router for VPC - Key: CLOUDSTACK-764 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-764 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala This item is a sub task (2.17) of
[jira] [Closed] (CLOUDSTACK-5393) [Automation] Failed to create snapshot from ROOT volume in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan closed CLOUDSTACK-5393.
---
Resolution: Cannot Reproduce
[Automation] Failed to create snapshot from ROOT volume in KVM
--
Key: CLOUDSTACK-5393
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5393
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Snapshot
Affects Versions: 4.3.0
Environment: KVM (RHEL 6.3)
Branch : 4.3
Reporter: Rayees Namathponnan
Assignee: edison su
Priority: Critical
Fix For: 4.3.0
Attachments: agent1.rar, agent2.rar, management-server.rar, ssvm.rar
Steps to reproduce
1) Create advanced zone in KVM
2) Deploy VM
3 ) Stop VM
4 ) Create snapshot from root volume
Snapshot creation failed with below exception
2013-12-05 15:39:44,194 DEBUG [c.c.a.t.Request] (Job-Executor-64:ctx-1b710e00
ctx-3cf3df4e) Seq 1-1244399478: Received: { Ans: , MgmtId: 29066118877352,
via: 1, Ver: v1, Flags: 10, { CreateObjectAnswer } }
2013-12-05 15:39:44,284 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
(Job-Executor-64:ctx-1b710e00 ctx-3cf3df4e) copyAsync inspecting src type
SNAPSHOT copyAsync inspecting dest type SNAPSHOT
2013-12-05 15:39:44,332 DEBUG [c.c.a.t.Request] (Job-Executor-64:ctx-1b710e00
ctx-3cf3df4e) Seq 2-332864214: Sending { Cmd , MgmtId: 29066118877352, via:
2(Rack2Host12.lab.vmops.com), Ver: v1, Flags: 100011, [{org.apache.cl
oudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215/8f7d268f-1a96-4d70-9c48-cb7f6cc935a8
,volume:{uuid:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesyst
em,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08
ca01d9}},name:ROOT-919,size:8589934592,path:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeId:988,vmName:i-2-919-QA,accountId:2,format:QCOW2,id:988,deviceId:0,hypervisorType:KVM},parentSnapshotPath
:/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215/d43b61bc-4ade-4753-b1d9-c0398388147d,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},vmName:i-2-919-QA,name:QA-eb54bbfa-12d5-49b5-808f-864dddedc1fd_ROOT-919_20131205233943,hypervisorType:KVM,id:54,quiescevm:false}},destTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:snapshots/2/988,volume:{uuid:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},name:ROOT-919,size:8589934592,path:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeId:988,vmName:i-2-919-QA,accountId:2,format:QCOW2,id:988,deviceId:0,hypervisorType:KVM},dataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.223.110.232:/export/home/rayees/SC_QA_AUTO4/secondary,_role:Image}},vmName:i-2-919-QA,name:QA-eb54bbfa-12d5-49b5-808f-864dddedc1fd_ROOT-919_20131205233943,hypervisorType:KVM,id:54,quiescevm:false}},executeInSequence:false,wait:21600}}]
}
2013-12-05 15:39:44,501 DEBUG [c.c.a.t.Request]
(StatsCollector-3:ctx-3ac54662) Seq 1-1244399477: Received: { Ans: , MgmtId:
29066118877352, via: 1, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
2013-12-05 15:39:44,900 DEBUG [c.c.a.t.Request] (AgentManager-Handler-1:null)
Seq 2-332864214: Processing: { Ans: , MgmtId: 29066118877352, via: 2, Ver:
v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{result:false,details:/usr/share/cloudstack-common/scripts/storage/qcow2/managesnapshot.sh:
line 178: 26840 Floating point exception(core dumped) $qemu_img convert -f
qcow2 -O qcow2 -s $snapshotname $disk $destPath/$destName /dev/nullFailed
to backup 8f7d268f-1a96-4d70-9c48-cb7f6cc935a8 for disk
/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215
to
[jira] [Reopened] (CLOUDSTACK-5393) [Automation] Failed to create snapshot from ROOT volume in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan reopened CLOUDSTACK-5393:
-
[Automation] Failed to create snapshot from ROOT volume in KVM
--
Key: CLOUDSTACK-5393
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5393
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Snapshot
Affects Versions: 4.3.0
Environment: KVM (RHEL 6.3)
Branch : 4.3
Reporter: Rayees Namathponnan
Assignee: edison su
Priority: Critical
Fix For: 4.3.0
Attachments: agent1.rar, agent2.rar, management-server.rar, ssvm.rar
Steps to reproduce
1) Create advanced zone in KVM
2) Deploy VM
3 ) Stop VM
4 ) Create snapshot from root volume
Snapshot creation failed with below exception
2013-12-05 15:39:44,194 DEBUG [c.c.a.t.Request] (Job-Executor-64:ctx-1b710e00
ctx-3cf3df4e) Seq 1-1244399478: Received: { Ans: , MgmtId: 29066118877352,
via: 1, Ver: v1, Flags: 10, { CreateObjectAnswer } }
2013-12-05 15:39:44,284 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
(Job-Executor-64:ctx-1b710e00 ctx-3cf3df4e) copyAsync inspecting src type
SNAPSHOT copyAsync inspecting dest type SNAPSHOT
2013-12-05 15:39:44,332 DEBUG [c.c.a.t.Request] (Job-Executor-64:ctx-1b710e00
ctx-3cf3df4e) Seq 2-332864214: Sending { Cmd , MgmtId: 29066118877352, via:
2(Rack2Host12.lab.vmops.com), Ver: v1, Flags: 100011, [{org.apache.cl
oudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215/8f7d268f-1a96-4d70-9c48-cb7f6cc935a8
,volume:{uuid:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesyst
em,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08
ca01d9}},name:ROOT-919,size:8589934592,path:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeId:988,vmName:i-2-919-QA,accountId:2,format:QCOW2,id:988,deviceId:0,hypervisorType:KVM},parentSnapshotPath
:/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215/d43b61bc-4ade-4753-b1d9-c0398388147d,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},vmName:i-2-919-QA,name:QA-eb54bbfa-12d5-49b5-808f-864dddedc1fd_ROOT-919_20131205233943,hypervisorType:KVM,id:54,quiescevm:false}},destTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:snapshots/2/988,volume:{uuid:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},name:ROOT-919,size:8589934592,path:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeId:988,vmName:i-2-919-QA,accountId:2,format:QCOW2,id:988,deviceId:0,hypervisorType:KVM},dataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.223.110.232:/export/home/rayees/SC_QA_AUTO4/secondary,_role:Image}},vmName:i-2-919-QA,name:QA-eb54bbfa-12d5-49b5-808f-864dddedc1fd_ROOT-919_20131205233943,hypervisorType:KVM,id:54,quiescevm:false}},executeInSequence:false,wait:21600}}]
}
2013-12-05 15:39:44,501 DEBUG [c.c.a.t.Request]
(StatsCollector-3:ctx-3ac54662) Seq 1-1244399477: Received: { Ans: , MgmtId:
29066118877352, via: 1, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
2013-12-05 15:39:44,900 DEBUG [c.c.a.t.Request] (AgentManager-Handler-1:null)
Seq 2-332864214: Processing: { Ans: , MgmtId: 29066118877352, via: 2, Ver:
v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{result:false,details:/usr/share/cloudstack-common/scripts/storage/qcow2/managesnapshot.sh:
line 178: 26840 Floating point exception(core dumped) $qemu_img convert -f
qcow2 -O qcow2 -s $snapshotname $disk $destPath/$destName /dev/nullFailed
to backup 8f7d268f-1a96-4d70-9c48-cb7f6cc935a8 for disk
/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215
to
[jira] [Updated] (CLOUDSTACK-5676) Live migration of VM is failing with a NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-5676:
---
Assignee: Devdeep Singh
Live migration of VM is failing with a NPE
--
Key: CLOUDSTACK-5676
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5676
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: hyperv , 4.3
Reporter: Abhinav Roy
Assignee: Devdeep Singh
Priority: Blocker
Fix For: 4.3.0
Steps to Reproduce:
1.Bring up CS in advanced zone with 2 hosts in a hyper-v cluster using CIFS
for both primary and secondary storage
2.Deploy one or two guest vms using default cent os template.
3.Migrate one of the VMs from Host1 to Host2
Expected Behaviour:
=
Live VM migration should be successful
Observed Behaviour:
===
Live VM migration fails with :
013-12-30 16:41:29,564 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-1:ctx-2ba86ed3 ctx-ca0be041) Sync job-95 execution on object
VmWorkJobQueue.16
2013-12-30 16:41:31,261 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(AsyncJobMgr-Heartbeat-1:ctx-c85fb697) Execute sync-queue item:
SyncQueueItemVO {id:30, queueId: 27, contentType: AsyncJob, contentId: 95,
lastProcessMsid: null, lastprocessNumber: null, lastProcessTime: null,
created: Mon Dec 30 16:41:29 IST 2013}
2013-12-30 16:41:31,263 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(AsyncJobMgr-Heartbeat-1:ctx-c85fb697) Schedule queued job-95
2013-12-30 16:41:31,277 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Job-Executor-2:ctx-ba975c56) Add job-95 into job monitoring
2013-12-30 16:41:31,278 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-2:ctx-ba975c56) Executing AsyncJobVO {id:95, userId: 2,
accountId: 2, instanceType: null, instanceId: null, cmd:
com.cloud.vm.VmWorkMigrate, cmdInfo:
rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAEHQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXNxAH4ABwAEcQB-AAlwcQB-AAk,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 280320865129348, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Mon Dec 30 16:41:29 IST 2013}
2013-12-30 16:41:31,279 DEBUG [c.c.v.VmWorkJobDispatcher]
(Job-Executor-2:ctx-ba975c56) Run VM work job: com.cloud.vm.VmWorkMigrate
2013-12-30 16:41:31,287 ERROR [c.c.v.VmWorkJobDispatcher]
(Job-Executor-2:ctx-ba975c56 ctx-ca0be041) Unable to complete AsyncJobVO
{id:95, userId: 2, accountId: 2, instanceType: null, instanceId: null, cmd:
com.cloud.vm.VmWorkMigrate, cmdInfo:
rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAEHQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXNxAH4ABwAEcQB-AAlwcQB-AAk,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 280320865129348, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Mon Dec 30 16:41:29 IST 2013}
java.lang.NullPointerException
at
com.cloud.vm.VmWorkMigrate.getDeployDestination(VmWorkMigrate.java:60)
at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4743)
at
com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:99)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:522)
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
[jira] [Updated] (CLOUDSTACK-5688) NPE when the KVM host is rebooted on the upgraded environment
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-5688:
---
Assignee: edison su
Edison can you review these KVM issues
NPE when the KVM host is rebooted on the upgraded environment
--
Key: CLOUDSTACK-5688
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5688
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Upgrade
Affects Versions: 4.3.0
Environment: upgraded from 4.2.1 to 4.3
Reporter: manasaveloori
Assignee: edison su
Priority: Critical
Fix For: 4.3.0
Attachments: agent.log, management-server.rar, mysqldump421.dmp,
mysqldump43.dmp
Steps:
1.Have CS 4.2.1 with KVM host.---advanced zone.
2.Upgrade the CS to 4.3.
3.Reboot the KVM host(did not enable maintenance)
4.The KVM host is connected and then disconnecting from the CS.
Observing the following NPE in CS logs:
2013-12-31 18:03:38,127 DEBUG [c.c.r.ResourceManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Dispatching resource state event
CREATE_HOST_VO_FOR_CONNECTED to BaremetalDhcpManagerImpl
2013-12-31 18:03:38,127 DEBUG [c.c.r.ResourceManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Dispatching resource state event
CREATE_HOST_VO_FOR_CONNECTED to NetworkUsageManagerImpl
2013-12-31 18:03:38,127 DEBUG [c.c.r.ResourceManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Dispatching resource state event
CREATE_HOST_VO_FOR_CONNECTED to BaremetalPxeManagerImpl
2013-12-31 18:03:38,128 DEBUG [c.c.r.ResourceManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Dispatching resource state event
CREATE_HOST_VO_FOR_CONNECTED to PaloAltoExternalFirewallElement
2013-12-31 18:03:38,128 DEBUG [c.c.r.ResourceManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Dispatching resource state event
CREATE_HOST_VO_FOR_CONNECTED to KvmServerDiscoverer
2013-12-31 18:03:38,172 DEBUG [c.c.r.ResourceState]
(AgentConnectTaskPool-194:ctx-00137ad5) Resource state update: [id = 1; name
= RHLE64; old state = Enabled; event = InternalCreated; new state = Enabled]
2013-12-31 18:03:38,173 DEBUG [c.c.h.Status]
(AgentConnectTaskPool-194:ctx-00137ad5) Transition:[Resource state = Enabled,
Agent event = AgentConnected, Host id = 1, name = RHLE64]
2013-12-31 18:03:38,185 DEBUG [c.c.h.Status]
(AgentConnectTaskPool-194:ctx-00137ad5) Agent status update: [id = 1; name =
RHLE64; old status = Alert; event = AgentConnected; new status = Connecting;
old update count = 390; new update count = 391]
2013-12-31 18:03:38,185 DEBUG [c.c.a.m.ClusteredAgentManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) create ClusteredAgentAttache for 1
2013-12-31 18:03:38,188 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Sending Connect to listener:
XcpServerDiscoverer
2013-12-31 18:03:38,189 DEBUG [c.c.h.x.d.XcpServerDiscoverer]
(AgentConnectTaskPool-194:ctx-00137ad5) Not XenServer so moving on.
2013-12-31 18:03:38,189 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Sending Connect to listener:
HypervServerDiscoverer
2013-12-31 18:03:38,189 DEBUG [c.c.h.h.d.HypervServerDiscoverer]
(AgentConnectTaskPool-194:ctx-00137ad5) Not Hyper-V hypervisor, so moving on.
2013-12-31 18:03:38,189 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Sending Connect to listener:
StoragePoolMonitor
2013-12-31 18:03:38,202 DEBUG [c.c.s.l.StoragePoolMonitor]
(AgentConnectTaskPool-194:ctx-00137ad5) Host 1 connected, sending down
storage pool information ...
2013-12-31 18:03:38,205 DEBUG [c.c.s.StorageManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Adding pool null to host 1
2013-12-31 18:03:38,215 DEBUG [c.c.a.t.Request]
(AgentConnectTaskPool-194:ctx-00137ad5) Seq 1-920387585: Sending { Cmd ,
MgmtId: 6758231703598, via: 1(RHLE64), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.ModifyStoragePoolCommand:{add:true,pool:{id:1,uuid:efbe1d5a-12c4-3a30-bef6-a219dfe81249,host:10.147.40.27,path:/export/home/manasa/primaryKVM,port:2049,type:NetworkFilesystem},localPath:/mnt//efbe1d5a-12c4-3a30-bef6-a219dfe81249,wait:0}}]
}
2013-12-31 18:03:38,220 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-6:null) Ping from 1
2013-12-31 18:03:38,228 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-6:null) Not processing PingRoutingCommand for agent
id=0; can't find the host in the DB
2013-12-31 18:03:38,233 DEBUG [c.c.a.t.Request] (AgentManager-Handler-4:null)
Seq 1-920387585: Processing: { Ans: , MgmtId: 6758231703598, via: 1, Ver:
v1, Flags: 10,
[jira] [Updated] (CLOUDSTACK-5574) KVM - HA - one of the Vms failed to start on another host when the host that it was running on was shutdown.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5574: --- Assignee: edison su Edison can you review these KVM issues KVM - HA - one of the Vms failed to start on another host when the host that it was running on was shutdown. Key: CLOUDSTACK-5574 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5574 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: edison su Priority: Critical Fix For: 4.3.0 KVM - HA - one of the Vms failed to start on another host when the host that it was running on was shutdown. Set up: Advanced zone with 2 KVM hosts (RHEL 6.3). Had 5 user Vms running on each host. Shutdown host1 ( execute echo o /proc/sysrq-trigger on host) All VMs from host1 , get HA-ed to host2. Bring host1 up. Shutdown host2. ( execute echo o /proc/sysrq-trigger on host) All VMs from host2 get HA-ed to host2 , except for 1 user Vm. It encounters the following exception in the agent logs when management server tries to start this Vm as part of HA process. 2013-12-19 13:32:56,997 WARN [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-3:null) LibvirtException org.libvirt.LibvirtException: internal error Process exited while reading console log output: at org.libvirt.ErrorHandler.processError(Unknown Source) at org.libvirt.Connect.processError(Unknown Source) at org.libvirt.Connect.processError(Unknown Source) at org.libvirt.Connect.domainCreateXML(Unknown Source) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1188) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3594) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1282) at com.cloud.agent.Agent.processRequest(Agent.java:498) at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:806) at com.cloud.utils.nio.Task.run(Task.java:83) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5683) kvm - Live migration fails with java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-5683:
---
Assignee: edison su
Edison can you review these KVM issues
kvm - Live migration fails with java.lang.NullPointerException
--
Key: CLOUDSTACK-5683
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5683
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Environment: Build from 4.3
Reporter: Sangeetha Hariharan
Assignee: edison su
Priority: Critical
Fix For: 4.3.0
Attachments: management-server.log
Steps to reproduce the problem:
Advanced zone set up with 2 KVM hosts.
Deploy few Vms in both hosts.
Live migrate vm from 1 host to another.
UI reports success , but the VM migration actually fails.
Following exception seen in management server logs:
013-12-30 17:35:03,451 ERROR [c.c.v.VmWorkJobDispatcher]
(Job-Executor-101:ctx-23e206c0 ctx-4ddc2410) Unable to complete AsyncJobVO
{id:76
, userId: 2, accountId: 2, instanceType: null, instanceId: null, cmd:
com.cloud.vm.VmWorkMigrate, cmdInfo: rO0ABXNyABpjb20uY2xvdWQudm0uVm1X
b3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9
MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbW
V0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAA3QAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAnNyAA5qYXZhLmxhbmcuTG9uZzuL5
JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXEAfgA
JcQB-AAlwcQB-AAk, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0,
resultCode: 0, result: null, initMsid: 82324189320212, completeMsid: null,
lastUpdated: null, lastPolled: null, created: Mon Dec 30 17:35:02 EST 2013}
java.lang.NullPointerException
at
com.cloud.vm.VmWorkMigrate.getDeployDestination(VmWorkMigrate.java:60)
at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4743)
at
com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:99)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:522)
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.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
2013-12-30 17:35:03,452 ERROR [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-101:ctx-23e206c0) Unexpected exception
java.lang.NullPointerException
2013-12-30 17:35:03,452 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-101:ctx-23e206c0) Complete async job-76, jobStatus: FAILED,
resultCode: 530, result: null
2013-12-30 17:35:03,463 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Job-Executor-102:ctx-e541857f) Add job-75 into job monitoring
2013-12-30 17:35:03,463 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-102:ctx-e541857f) Executing AsyncJobVO {id:75, userId: 2,
accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdInfo:
{response:json,sessionkey:4SFVHNVTkNP6Ys+kKkCAVp57j8w\u003d,virtualmachineid:17c74e6c-a39b-4c51-8e76-b75985ea6622,cmdEventType:VM.MIGRATE,hostid:9cc1f4fa-f972-42a1-be2c-213dc1c36504,ctxUserId:2,httpmethod:GET,_:1388442964044,ctxAccountId:2,ctxStartEventId:165},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 82324189320212, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Mon Dec 30 17:35:02 EST 2013}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5573) KVM- SSVM/CPVM stuck in Starting state Caused by: java.lang.NullPointerException.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-5573:
---
Assignee: edison su
Edison can you review these KVM issues
KVM- SSVM/CPVM stuck in Starting state Caused by:
java.lang.NullPointerException.
---
Key: CLOUDSTACK-5573
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5573
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Environment: Build from 4.3
Reporter: Sangeetha Hariharan
Assignee: edison su
Priority: Critical
Fix For: 4.3.0
Attachments: kvm-ssvm.rar, kvmhost-down-up.rar
Set up:
Advanced zone set up with 2 KVM (rhel 6.3) hosts.
Few Vms running on both hosts.
I was testing use cases of bringing down hosts and brings them back up again .
During this testing , SSVM got stuck in Starting state for ever.
Following exception seen in agent log:
2013-12-19 10:28:08,616 ERROR [agent.transport.Request]
(agentRequest-Handler-5:null) Caught problem with
[{com.cloud.agent.api.StartCommand:{vm:{id:35,name:s-35-MyTestVM,type:SecondaryStorageVm,cpus:1,minSpeed:500,maxSpeed:500,minRam:268435456,maxRam:268435456,arch:x86_64,os:Debian
GNU/Linux 5.0 (32-bit),bootArgs: template\u003ddomP type\u003dsecstorage
host\u003d10.223.49.6 port\u003d8250 name\u003ds-35-MyTestVM zone\u003d1
pod\u003d1 guid\u003ds-35-MyTestVM
resource\u003dcom.cloud.storage.resource.PremiumSecondaryStorageResource
instance\u003dSecStorage sslcopy\u003dtrue role\u003dtemplateProcessor
mtu\u003d1500 eth2ip\u003d10.223.138.133 eth2mask\u003d255.255.255.192
gateway\u003d10.223.138.129 public.network.device\u003deth2
eth0ip\u003d169.254.0.251 eth0mask\u003d255.255.0.0 eth1ip\u003d10.223.58.137
eth1mask\u003d255.255.255.192 mgmtcidr\u003d10.223.49.0/26
localgw\u003d10.223.58.129 private.network.device\u003deth1
eth3ip\u003d10.223.58.147 eth3mask\u003d255.255.255.192
storageip\u003d10.223.58.147 storagenetmask\u003d255.255.255.192
storagegateway\u003d10.223.58.129 internaldns1\u003d10.223.240.234
dns1\u003d10.223.240.232,rebootOnCrash:false,enableHA:false,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:6e5928251a8718f6,params:{},uuid:db3f9893-d98e-4fb4-a6a4-95f2c95ce407,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:488b20bf-e706-46b9-9039-4dd407aa23ba,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:4aedbaff-1e54-37a2-a150-0b67dbe58ed5,id:3,poolType:NetworkFilesystem,host:10.223.57.195,path:/export/home/kvm/primary1,port:2049,url:NetworkFilesystem://10.223.57.195//export/home/kvm/primary1/?ROLE\u003dPrimary\u0026STOREUUID\u003d4aedbaff-1e54-37a2-a150-0b67dbe58ed5}},name:ROOT-35,size:0,path:488b20bf-e706-46b9-9039-4dd407aa23ba,volumeId:35,vmName:s-35-MyTestVM,accountId:1,format:QCOW2,id:35,deviceId:0,hypervisorType:KVM}},diskSeq:0,path:488b20bf-e706-46b9-9039-4dd407aa23ba,type:ROOT,_details:{managed:false,storagePort:2049,storageHost:10.223.57.195,volumeSize:0}}],nics:[{deviceId:2,networkRateMbps:-1,defaultNic:true,uuid:35eb2804-514b-40d5-8e20-a2f423ca2625,ip:10.223.138.133,netmask:255.255.255.192,gateway:10.223.138.129,mac:06:66:22:00:00:15,dns1:10.223.240.232,broadcastType:Vlan,type:Public,broadcastUri:vlan://1382,isolationUri:vlan://1382,isSecurityGroupEnabled:false},{deviceId:0,networkRateMbps:-1,defaultNic:false,uuid:ea38c96f-cc88-463b-812e-a4a69b59d7f7,ip:169.254.0.251,netmask:255.255.0.0,gateway:169.254.0.1,mac:0e:00:a9:fe:00:fb,broadcastType:LinkLocal,type:Control,isSecurityGroupEnabled:false},{deviceId:1,networkRateMbps:-1,defaultNic:false,uuid:aa865f74-1add-476c-ad0f-86aed6b84155,ip:10.223.58.137,netmask:255.255.255.192,gateway:10.223.58.129,mac:06:10:f0:00:00:06,broadcastType:Native,type:Management,isSecurityGroupEnabled:false},{deviceId:3,networkRateMbps:-1,defaultNic:false,uuid:032a8d30-fdf9-493d-ad2c-e3c2627e1869,ip:10.223.58.147,netmask:255.255.255.192,gateway:10.223.58.129,mac:06:40:ce:00:00:10,broadcastType:Native,type:Storage,isSecurityGroupEnabled:false}]},hostIp:10.223.58.131,executeInSequence:false,contextMap:{},wait:0}},{com.cloud.agent.api.check.CheckSshCommand:{ip:169.254.0.251,port:3922,interval:6,retries:100,name:s-35-MyTestVM,contextMap:{},wait:0}}]
com.google.gson.JsonParseException: The JsonDeserializer
com.cloud.agent.transport.InterfaceTypeAdaptor@6db22920 failed to deserialize
json object
[jira] [Created] (CLOUDSTACK-5694) Xenserver - When VM is deleted outside of CS , VM state is not being synced to CS.
Sangeetha Hariharan created CLOUDSTACK-5694:
---
Summary: Xenserver - When VM is deleted outside of CS , VM state
is not being synced to CS.
Key: CLOUDSTACK-5694
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5694
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
Priority: Critical
Fix For: 4.3.0
[Vmsync]- xenserver - When VM is deleted outside of CS , VM state is not being
synced to CS.
PreReq:
Have few Vms deployed using Cloudstack.
Steps:
Outside of Cloudstack , Destroy an existing VM. ( stop the VM and then delete
the VM from xencenter.
There is an attempt made to stop the VM in CS that fails.
Should the expected behavior be to stop the VM and then destroy it in the CS?
Following exception seen in management server:
2013-12-26 20:14:42,543 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-342:ctx-433f534a) The VM is now missing marking it as Stopped
i-3-3-MyTestVM
2013-12-26 20:14:42,543 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-342:ctx-433f534a) Seq 1-1141178372: Response Received:
2013-12-26 20:14:42,543 DEBUG [c.c.a.t.Request] (DirectAgent-342:ctx-433f534a)
Seq 1-1141178372: Processing: { Ans: , MgmtId: 112516401760401, via: 1, Ver:
v1, Flags: 10,
[{com.cloud.agent.api.ClusterSyncAnswer:{_clusterId:1,_newStates:{i-3-3-MyTestVM:{t:157f5d61-037f-44eb-ae3d-0cd082d3cff0,u:Stopped}},_isExecuted:false,result:true,wait:0}}]
}
2013-12-26 20:14:42,547 DEBUG [c.c.v.VirtualMachineManagerImpl]
(DirectAgent-342:ctx-433f534a) VM i-3-3-MyTestVM: cs state = Running and
realState = Stopped
2013-12-26 20:14:42,547 DEBUG [c.c.v.VirtualMachineManagerImpl]
(DirectAgent-342:ctx-433f534a) VM i-3-3-MyTestVM: cs state = Running and
realState = Stopped
2013-12-26 20:14:42,547 DEBUG [c.c.h.HighAvailabilityManagerImpl]
(DirectAgent-342:ctx-433f534a) VM does not require investigation so I'm marking
it as Stopped: VM[User|TestVM-1]
2013-12-26 20:14:42,547 WARN [o.a.c.alerts] (DirectAgent-342:ctx-433f534a)
alertType:: 8 // dataCenterId:: 1 // podId:: 1 // clusterId:: null // message::
VM (name: TestVM-1, id: 3) stopped unexpectedly on host id:2, availability zone
id:1, pod id:1
2013-12-26 20:14:42,551 DEBUG [c.c.h.HighAvailabilityManagerImpl]
(DirectAgent-342:ctx-433f534a) VM is not HA enabled so we're done.
2013-12-26 20:14:42,551 WARN [c.c.a.m.DirectAgentAttache]
(DirectAgent-342:ctx-433f534a) Seq 1-1141178372: Exception caught
java.lang.NullPointerException
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1235)
at
com.cloud.ha.HighAvailabilityManagerImpl.scheduleRestart(HighAvailabilityManagerImpl.java:346)
at
com.cloud.vm.VirtualMachineManagerImpl.compareState(VirtualMachineManagerImpl.java:2686)
at
com.cloud.vm.VirtualMachineManagerImpl.deltaSync(VirtualMachineManagerImpl.java:2320)
at
com.cloud.vm.VirtualMachineManagerImpl.processAnswers(VirtualMachineManagerImpl.java:2797)
at com.cloud.agent.manager.AgentAttache.processAnswers(AgentAttache.java:296)
at
com.cloud.agent.manager.ClusteredDirectAgentAttache.processAnswers(ClusteredDirectAgentAttache.java:65)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:242)
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.innerRunAndReset(FutureTask.java:351)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
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)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5580) KVM - Network down - VMs crashed after HA.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5580: --- Assignee: edison su Edison can you review these KVM issues KVM - Network down - VMs crashed after HA. -- Key: CLOUDSTACK-5580 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5580 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: edison su Priority: Critical Fix For: 4.3.0 Attachments: crash1.png, crash2.png, crash3.png, kvm-hostdisconnect.rar KVM - Network down - VMs crashed after HA. 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. Most of the Vms (except for couple of them) crashed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5675) Destory VM is failing with Unable to delete vm snapshots for VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-5675:
---
Assignee: Devdeep Singh
Destory VM is failing with Unable to delete vm snapshots for VM
--
Key: CLOUDSTACK-5675
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5675
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: Hyperv , 4.3
Reporter: Abhinav Roy
Assignee: Devdeep Singh
Priority: Blocker
Fix For: 4.3.0
Steps :
===
1. Deploy a CS advanced zone setup with Hyper-V as hypervisor type
2. Create a VM
3. Destroy the VM
Expected result:
==
The VM should be created and destroyed successfully.
Observed result :
=
Destroy VM fails with :
2013-12-30 15:02:30,297 DEBUG [c.c.a.ApiServlet]
(catalina-exec-2:ctx-57d2f51b) ===START=== 10.144.7.20 -- GET
command=destroyVirtualMachineresponse=jsonsessionkey=P7hUEU1kTW2jFEVpcBKYxFUSxx4%3Did=706fae35-94d2-414d-94da-8c7b21051eddexpunge=true_=1388396154899
2013-12-30 15:02:30,344 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-2:ctx-57d2f51b ctx-03d0a162) submit async job-38, details:
AsyncJobVO {id:38, userId: 2, accountId: 2, instanceType: VirtualMachine,
instanceId: 6, cmd: org.apache.cloudstack.api.command.user.vm.DestroyVMCmd,
cmdInfo:
{response:json,id:706fae35-94d2-414d-94da-8c7b21051edd,sessionkey:P7hUEU1kTW2jFEVpcBKYxFUSxx4\u003d,cmdEventType:VM.DESTROY,ctxUserId:2,httpmethod:GET,_:1388396154899,ctxAccountId:2,expunge:true,ctxStartEventId:108},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 280320865129348, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2013-12-30 15:02:30,344 DEBUG [c.c.a.ApiServlet]
(catalina-exec-2:ctx-57d2f51b ctx-03d0a162) ===END=== 10.144.7.20 -- GET
command=destroyVirtualMachineresponse=jsonsessionkey=P7hUEU1kTW2jFEVpcBKYxFUSxx4%3Did=706fae35-94d2-414d-94da-8c7b21051eddexpunge=true_=1388396154899
2013-12-30 15:02:30,346 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Job-Executor-41:ctx-90d46ce0) Add job-38 into job monitoring
2013-12-30 15:02:30,346 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-41:ctx-90d46ce0) Executing AsyncJobVO {id:38, userId: 2,
accountId: 2, instanceType: VirtualMachine, instanceId: 6, cmd:
org.apache.cloudstack.api.command.user.vm.DestroyVMCmd, cmdInfo:
{response:json,id:706fae35-94d2-414d-94da-8c7b21051edd,sessionkey:P7hUEU1kTW2jFEVpcBKYxFUSxx4\u003d,cmdEventType:VM.DESTROY,ctxUserId:2,httpmethod:GET,_:1388396154899,ctxAccountId:2,expunge:true,ctxStartEventId:108},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 280320865129348, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2013-12-30 15:02:30,371 DEBUG [c.c.v.VirtualMachineManagerImpl]
(Job-Executor-41:ctx-90d46ce0 ctx-03d0a162) Destroying vm VM[User|av3]
2013-12-30 15:02:30,372 DEBUG [c.c.v.VirtualMachineManagerImpl]
(Job-Executor-41:ctx-90d46ce0 ctx-03d0a162) Stopped called on VM[User|av3]
but the state is Error
2013-12-30 15:02:30,404 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-41:ctx-90d46ce0 ctx-03d0a162) Sync job-39 execution on object
VmWorkJobQueue.6
2013-12-30 15:02:31,064 DEBUG [c.c.s.StatsCollector]
(StatsCollector-2:ctx-1f663345) StorageCollector is running...
2013-12-30 15:02:31,125 DEBUG [c.c.a.t.Request]
(StatsCollector-2:ctx-1f663345) Seq 2-1575288891: Received: { Ans: , MgmtId:
280320865129348, via: 2, Ver: v1, Flags: 10, { GetStorageStatsAnswer } }
2013-12-30 15:02:31,127 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-15:ctx-9d56111c) Seq 1-2099445910: Executing request
2013-12-30 15:02:31,128 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-15:ctx-9d56111c) POST request
tohttp://10.102.192.14:8250/api/HypervResource/com.cloud.agent.api.GetStorageStatsCommand
with
contents{id:b183fb1d-c446-3a6f-b7ee-ec18507f39ae,localPath:/HYPERV-SMB/abhinav-hyperv-ps1?user\u003dabhinav\u0026password\u003dfreebsd@123\u0026domain\u003dBLR,pooltype:NetworkFilesystem,contextMap:{},wait:0}
2013-12-30 15:02:31,128 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-15:ctx-9d56111c) Sending cmd to
http://10.102.192.14:8250/api/HypervResource/com.cloud.agent.api.GetStorageStatsCommand
cmd
[jira] [Updated] (CLOUDSTACK-5581) KVM - Network down - CPVM after being HA'ed remains in Alert state.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5581: --- Assignee: edison su Edison can you review these KVM issues KVM - Network down - CPVM after being HA'ed remains in Alert state. -- Key: CLOUDSTACK-5581 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5581 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: edison su Priority: Critical Fix For: 4.3.0 Attachments: kvm-hostdisconnect.rar KVM - Network down - CPVM after being HA'ed remains in Alert state. 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 (including CPVM) gets HA-ed to the other host. CPVM (v-48-MyTestVM ) after being HA'ed remains in Alert state. mysql select id,name,status , removed from host; ++---+--+-+ | id | name | status | removed | ++---+--+-+ | 1 | Rack3Host13.lab.vmops.com | Up | NULL| | 2 | Rack3Host14.lab.vmops.com | Up | NULL| | 3 | v-1-VM| Disconnected | 2013-12-17 22:55:12 | | 4 | s-35-MyTestVM | Up | 2013-12-19 19:40:20 | | 5 | v-48-MyTestVM | Alert| NULL| | 6 | s-62-MyTestVM | Up | NULL| ++---+--+-+ 6 rows in set (0.00 sec) Note - I am able to view the console proxy view of the user Vms. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5695) [Vmsync] - xenserver - VMs deployed outside of CS gets destroyed when vmsync is initiated from CS.
Sangeetha Hariharan created CLOUDSTACK-5695:
---
Summary: [Vmsync] - xenserver - VMs deployed outside of CS gets
destroyed when vmsync is initiated from CS.
Key: CLOUDSTACK-5695
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5695
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
Priority: Critical
Fix For: 4.3.0
[Vmsync] - xenserver - VMs deployed outside of CS gets destroyed when vmsync is
initiated from CS.
PreReq:
Have few Vms deployed using Cloudstack.
Steps:
Outside of Cloudstack , Deploy a new VM.
Vm fails to get deployed since CS issues a stop command for the VM.
Stopped the management server.
Outside of Cloudstack , Deploy a new VM.
Start the management server.
When Vmsync is initiated from CS , CS issues stop command for the VM ,
resulting in the Vm shutting down.
Management server logs when Vm is being shut down:
2013-12-26 19:18:41,388 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgent-33:ctx-4c7f780d) Process host VM state report from ping process.
host: 2
2013-12-26 19:18:41,390 INFO [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgent-33:ctx-4c7f780d) Unable to find matched VM in CloudStack DB. name:
yoyo
2013-12-26 19:18:41,393 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgent-33:ctx-4c7f780d) VM state report. host: 2, vm id: 6, power state:
PowerOn
2013-12-26 19:18:41,406 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgent-33:ctx-4c7f780d) VM state report is updated. host: 2, vm id: 6,
power stat
e: PowerOn
2013-12-26 19:18:42,298 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-5:ctx-c5aa0746) Seq 2-468320260: Executing request
2013-12-26 19:18:42,299 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-17:ctx-50469c06) Seq 1-1141178372: Executing request
2013-12-26 19:18:42,508 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-5:ctx-c5aa0746) Seq 2-468320260: Response Received:
2013-12-26 19:18:42,508 DEBUG [c.c.a.t.Request] (DirectAgent-5:ctx-c5aa0746)
Seq 2-468320260: Processing: { Ans: , MgmtId: 112516401760401, via: 2, Ver: v1,
Flags: 10, [{com.cloud.agent.api.Answer:{result:true,wait:0}}] }
2013-12-26 19:18:42,573 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-17:ctx-50469c06) Detecting a new state but couldn't find a old
state so adding it to
the changes: yoyo
2013-12-26 19:18:42,574 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-17:ctx-50469c06) Seq 1-1141178372: Response Received:
2013-12-26 19:18:42,574 DEBUG [c.c.a.t.Request] (DirectAgent-17:ctx-50469c06)
Seq 1-1141178372: Processing: { Ans: , MgmtId: 112516401760401, via: 1, Ver: v1
, Flags: 10,
[{com.cloud.agent.api.ClusterSyncAnswer:{_clusterId:1,_newStates:{yoyo:{t:157f5d61-037f-44eb-ae3d-0cd082d3cff0,u:Running,v:vir
idian:true;acpi:1;apic:true;pae:true;nx:true}},_isExecuted:false,result:true,wait:0}}]
}
2013-12-26 19:18:42,576 WARN [c.c.v.VirtualMachineManagerImpl]
(DirectAgent-17:ctx-50469c06) Found an alien VM yoyo
2013-12-26 19:18:42,576 DEBUG [c.c.v.VirtualMachineManagerImpl]
(DirectAgent-17:ctx-50469c06) Cleaning up a VM that is no longer found
deltaSync: yoyo
2013-12-26 19:18:42,582 DEBUG [c.c.a.t.Request] (DirectAgent-17:ctx-50469c06)
Seq 2-468320276: Sending { Cmd , MgmtId: 112516401760401, via: 2(Rack3Host23.la
b.vmops.com), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:yoyo,wait:0}}]
}
2013-12-26 19:18:42,582 DEBUG [c.c.a.t.Request] (DirectAgent-17:ctx-50469c06)
Seq 2-468320276: Executing: { Cmd , MgmtId: 112516401760401, via: 2(Rack3Host23
.lab.vmops.com), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:yoyo,wait:0}}]
}
2013-12-26 19:18:42,582 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-11:ctx-013a4466) Seq 2-468320276: Executing request
2013-12-26 19:18:42,678 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-11:ctx-013a4466) 9. The VM yoyo is in Stopping state
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5696) [Vmsync]- xenserver - Stopped state of VM is not synced to CS when VM is stopped outside of CS.
Sangeetha Hariharan created CLOUDSTACK-5696: --- Summary: [Vmsync]- xenserver - Stopped state of VM is not synced to CS when VM is stopped outside of CS. Key: CLOUDSTACK-5696 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5696 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 Priority: Critical Fix For: 4.3.0 Pre Req: Have few Vms deployed using Cloudstack. Steps: Outside of Cloudstack ,Stop VM Vm continues to remain in Running state in CS , even though the change in state is detected. Following exception seen in management server logs: 2013-12-26 17:02:10,026 DEBUG [c.c.v.VirtualMachineManagerImpl] (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt ate = Stopped 2013-12-26 17:02:10,027 DEBUG [c.c.v.VirtualMachineManagerImpl] (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt ate = Stopped 2013-12-26 17:02:10,027 DEBUG [c.c.h.HighAvailabilityManagerImpl] (DirectAgent-77:ctx-c28d9506) VM does not require investigation so I'm marki ng it as Stopped: VM[User|TestVM-tiny-host-1ps-0-1] 2013-12-26 17:02:10,027 WARN [o.a.c.alerts] (DirectAgent-77:ctx-c28d9506) alertType:: 8 // dataCenterId:: 1 // podId:: 1 // clusterId:: null // message:: VM (name: TestVM-tiny-host-1ps-0-1, id: 8) stopped unexpectedly on host id:1, availability zone id:1, pod id:1 2013-12-26 17:02:10,032 DEBUG [c.c.h.HighAvailabilityManagerImpl] (DirectAgent-77:ctx-c28d9506) VM is not HA enabled so we're done. 2013-12-26 17:02:10,032 WARN [c.c.a.m.DirectAgentAttache] (DirectAgent-77:ctx-c28d9506) Seq 1-799145986: Exception caught java.lang.NullPointerException at com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1235) at com.cloud.ha.HighAvailabilityManagerImpl.scheduleRestart(HighAvailabilityManagerImpl.java:346) at com.cloud.vm.VirtualMachineManagerImpl.compareState(VirtualMachineManagerImpl.java:2686) at com.cloud.vm.VirtualMachineManagerImpl.deltaSync(VirtualMachineManagerImpl.java:2320) at com.cloud.vm.VirtualMachineManagerImpl.processAnswers(VirtualMachineManagerImpl.java:2797) at com.cloud.agent.manager.AgentAttache.processAnswers(AgentAttache.java:296) at com.cloud.agent.manager.ClusteredDirectAgentAttache.processAnswers(ClusteredDirectAgentAttache.java:65) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:242) 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.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) 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) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5005) issue with stopping vms parallelly
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-5005:
---
Assignee: Kelven Yang
issue with stopping vms parallelly
---
Key: CLOUDSTACK-5005
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5005
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.2.1
Reporter: prashant kumar mishra
Assignee: Kelven Yang
Priority: Critical
Fix For: 4.3.0
Attachments: MS_XEN_DB.rar
steps to reproduce
---
1-prepare CS setup with xen 6.1
2-set execute.in.sequence.hypervisor.commands and
execute.in.sequence.network.element.commands to false
3-Restart MS
4-deploy 35 vms parallelly with default centOS template
5-try to stop all uservms using script
Expected
-
All vms should get stopped ,
Actual
before vms went in stopped state , Log show error messages
Logs
[root@localhost ~]# grep job-436
/var/log/cloudstack/management/management-server.log
2013-10-30 12:21:57,817 DEBUG [cloud.async.AsyncJobManagerImpl]
(ApiServer-1:null) submit async job-436 = [
432f8bd7-8f4b-4e72-b69b-b148fc1733dc ], details: AsyncJobVO {id:436, userId:
1, accountId: 1, sessionKey: null, instanceType: VirtualMachine, instanceId:
78, cmd: org.apache.cloudstack.api.command.user.vm.StopVMCmd, cmdOriginator:
null, cmdInfo:
{id:78,cmdEventType:VM.STOP,ctxUserId:1,httpmethod:GET,ctxAccountId:1,ctxStartEventId:1384},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 7484181839895,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2013-10-30 12:21:57,818 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
Executing org.apache.cloudstack.api.command.user.vm.StopVMCmd for job-436 = [
432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]
2013-10-30 12:21:57,941 DEBUG [cloud.api.ApiDispatcher]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
ControlledEntity name is:com.cloud.vm.VirtualMachine
2013-10-30 12:21:58,056 DEBUG [cloud.api.ApiDispatcher]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
ControlledEntity name is:com.cloud.uservm.UserVm
2013-10-30 12:21:58,111 DEBUG [cloud.api.ApiDispatcher]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
ControlledEntity name is:com.cloud.network.router.VirtualRouter
2013-10-30 12:21:58,528 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) VM
state transitted from :Running to Stopping with event: StopRequestedvm's
original host id: 3 new host id: 3 host id before state transition: 3
2013-10-30 12:21:58,696 DEBUG [agent.transport.Request]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Seq
3-125568146: Sending { Cmd , MgmtId: 7484181839895, via: 3, Ver: v1, Flags:
100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-78-VM,wait:0}}]
}
2013-10-30 12:21:58,696 DEBUG [agent.transport.Request]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Seq
3-125568146: Executing: { Cmd , MgmtId: 7484181839895, via: 3, Ver: v1,
Flags: 100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-78-VM,wait:0}}]
}
2013-10-30 12:22:58,051 DEBUG [agent.transport.Request]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Seq
3-125568146: Received: { Ans: , MgmtId: 7484181839895, via: 3, Ver: v1,
Flags: 10, { StopAnswer } }
2013-10-30 12:22:58,078 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
VM[User|f1ad8bfe-b9a4-4669-a37c-f0edb2f0098f] is stopped on the host.
Proceeding to release resource held.
2013-10-30 12:22:58,088 DEBUG [cloud.network.NetworkModelImpl]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Service
SecurityGroup is not supported in the network id=204
2013-10-30 12:22:58,095 DEBUG [cloud.network.NetworkManagerImpl]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
Changing active number of nics for network id=204 on -1
2013-10-30 12:22:58,123 DEBUG [cloud.network.NetworkManagerImpl]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Asking
VirtualRouter to release
Nic[89-78-d1a70d9b-1e6e-4de8-bd4b-6f0649faf997-10.1.1.177]
2013-10-30 12:22:58,123 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-122:job-436 = [
[jira] [Commented] (CLOUDSTACK-5005) issue with stopping vms parallelly
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859627#comment-13859627
]
Animesh Chaturvedi commented on CLOUDSTACK-5005:
Kelven can you check on this
issue with stopping vms parallelly
---
Key: CLOUDSTACK-5005
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5005
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.2.1
Reporter: prashant kumar mishra
Assignee: Kelven Yang
Priority: Critical
Fix For: 4.3.0
Attachments: MS_XEN_DB.rar
steps to reproduce
---
1-prepare CS setup with xen 6.1
2-set execute.in.sequence.hypervisor.commands and
execute.in.sequence.network.element.commands to false
3-Restart MS
4-deploy 35 vms parallelly with default centOS template
5-try to stop all uservms using script
Expected
-
All vms should get stopped ,
Actual
before vms went in stopped state , Log show error messages
Logs
[root@localhost ~]# grep job-436
/var/log/cloudstack/management/management-server.log
2013-10-30 12:21:57,817 DEBUG [cloud.async.AsyncJobManagerImpl]
(ApiServer-1:null) submit async job-436 = [
432f8bd7-8f4b-4e72-b69b-b148fc1733dc ], details: AsyncJobVO {id:436, userId:
1, accountId: 1, sessionKey: null, instanceType: VirtualMachine, instanceId:
78, cmd: org.apache.cloudstack.api.command.user.vm.StopVMCmd, cmdOriginator:
null, cmdInfo:
{id:78,cmdEventType:VM.STOP,ctxUserId:1,httpmethod:GET,ctxAccountId:1,ctxStartEventId:1384},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 7484181839895,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2013-10-30 12:21:57,818 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
Executing org.apache.cloudstack.api.command.user.vm.StopVMCmd for job-436 = [
432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]
2013-10-30 12:21:57,941 DEBUG [cloud.api.ApiDispatcher]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
ControlledEntity name is:com.cloud.vm.VirtualMachine
2013-10-30 12:21:58,056 DEBUG [cloud.api.ApiDispatcher]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
ControlledEntity name is:com.cloud.uservm.UserVm
2013-10-30 12:21:58,111 DEBUG [cloud.api.ApiDispatcher]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
ControlledEntity name is:com.cloud.network.router.VirtualRouter
2013-10-30 12:21:58,528 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) VM
state transitted from :Running to Stopping with event: StopRequestedvm's
original host id: 3 new host id: 3 host id before state transition: 3
2013-10-30 12:21:58,696 DEBUG [agent.transport.Request]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Seq
3-125568146: Sending { Cmd , MgmtId: 7484181839895, via: 3, Ver: v1, Flags:
100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-78-VM,wait:0}}]
}
2013-10-30 12:21:58,696 DEBUG [agent.transport.Request]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Seq
3-125568146: Executing: { Cmd , MgmtId: 7484181839895, via: 3, Ver: v1,
Flags: 100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-78-VM,wait:0}}]
}
2013-10-30 12:22:58,051 DEBUG [agent.transport.Request]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Seq
3-125568146: Received: { Ans: , MgmtId: 7484181839895, via: 3, Ver: v1,
Flags: 10, { StopAnswer } }
2013-10-30 12:22:58,078 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
VM[User|f1ad8bfe-b9a4-4669-a37c-f0edb2f0098f] is stopped on the host.
Proceeding to release resource held.
2013-10-30 12:22:58,088 DEBUG [cloud.network.NetworkModelImpl]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Service
SecurityGroup is not supported in the network id=204
2013-10-30 12:22:58,095 DEBUG [cloud.network.NetworkManagerImpl]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
Changing active number of nics for network id=204 on -1
2013-10-30 12:22:58,123 DEBUG [cloud.network.NetworkManagerImpl]
(Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Asking
VirtualRouter to release
Nic[89-78-d1a70d9b-1e6e-4de8-bd4b-6f0649faf997-10.1.1.177]
2013-10-30 12:22:58,123 DEBUG
[jira] [Updated] (CLOUDSTACK-5694) [vmsync] - Xenserver - When VM is deleted outside of CS , VM state is not being synced to CS.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-5694:
---
Assignee: Kelven Yang
[vmsync] - Xenserver - When VM is deleted outside of CS , VM state is not
being synced to CS.
-
Key: CLOUDSTACK-5694
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5694
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Environment: Build from 4.3
Reporter: Sangeetha Hariharan
Assignee: Kelven Yang
Priority: Critical
Fix For: 4.3.0
[Vmsync]- xenserver - When VM is deleted outside of CS , VM state is not
being synced to CS.
PreReq:
Have few Vms deployed using Cloudstack.
Steps:
Outside of Cloudstack , Destroy an existing VM. ( stop the VM and then delete
the VM from xencenter.
There is an attempt made to stop the VM in CS that fails.
Should the expected behavior be to stop the VM and then destroy it in the CS?
Following exception seen in management server:
2013-12-26 20:14:42,543 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-342:ctx-433f534a) The VM is now missing marking it as Stopped
i-3-3-MyTestVM
2013-12-26 20:14:42,543 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-342:ctx-433f534a) Seq 1-1141178372: Response Received:
2013-12-26 20:14:42,543 DEBUG [c.c.a.t.Request]
(DirectAgent-342:ctx-433f534a) Seq 1-1141178372: Processing: { Ans: , MgmtId:
112516401760401, via: 1, Ver: v1, Flags: 10,
[{com.cloud.agent.api.ClusterSyncAnswer:{_clusterId:1,_newStates:{i-3-3-MyTestVM:{t:157f5d61-037f-44eb-ae3d-0cd082d3cff0,u:Stopped}},_isExecuted:false,result:true,wait:0}}]
}
2013-12-26 20:14:42,547 DEBUG [c.c.v.VirtualMachineManagerImpl]
(DirectAgent-342:ctx-433f534a) VM i-3-3-MyTestVM: cs state = Running and
realState = Stopped
2013-12-26 20:14:42,547 DEBUG [c.c.v.VirtualMachineManagerImpl]
(DirectAgent-342:ctx-433f534a) VM i-3-3-MyTestVM: cs state = Running and
realState = Stopped
2013-12-26 20:14:42,547 DEBUG [c.c.h.HighAvailabilityManagerImpl]
(DirectAgent-342:ctx-433f534a) VM does not require investigation so I'm
marking it as Stopped: VM[User|TestVM-1]
2013-12-26 20:14:42,547 WARN [o.a.c.alerts] (DirectAgent-342:ctx-433f534a)
alertType:: 8 // dataCenterId:: 1 // podId:: 1 // clusterId:: null //
message:: VM (name: TestVM-1, id: 3) stopped unexpectedly on host id:2,
availability zone id:1, pod id:1
2013-12-26 20:14:42,551 DEBUG [c.c.h.HighAvailabilityManagerImpl]
(DirectAgent-342:ctx-433f534a) VM is not HA enabled so we're done.
2013-12-26 20:14:42,551 WARN [c.c.a.m.DirectAgentAttache]
(DirectAgent-342:ctx-433f534a) Seq 1-1141178372: Exception caught
java.lang.NullPointerException
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1235)
at
com.cloud.ha.HighAvailabilityManagerImpl.scheduleRestart(HighAvailabilityManagerImpl.java:346)
at
com.cloud.vm.VirtualMachineManagerImpl.compareState(VirtualMachineManagerImpl.java:2686)
at
com.cloud.vm.VirtualMachineManagerImpl.deltaSync(VirtualMachineManagerImpl.java:2320)
at
com.cloud.vm.VirtualMachineManagerImpl.processAnswers(VirtualMachineManagerImpl.java:2797)
at com.cloud.agent.manager.AgentAttache.processAnswers(AgentAttache.java:296)
at
com.cloud.agent.manager.ClusteredDirectAgentAttache.processAnswers(ClusteredDirectAgentAttache.java:65)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:242)
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.innerRunAndReset(FutureTask.java:351)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
[jira] [Updated] (CLOUDSTACK-5551) [UI] Search not working in account's setting page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5551: --- Assignee: Jessica Wang [UI] Search not working in account's setting page -- Key: CLOUDSTACK-5551 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5551 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Environment: branch 4.3 Reporter: Rayees Namathponnan Assignee: Jessica Wang Priority: Critical Fix For: 4.3.0 Steps to reproduce Step 1 : Install Management server with 4.3 build Step 2 : create an account Step 3 : select the account - select setting Step 4 : In search box, enter Expected Result Nothing should be displayed in search result Actual Result Search is not working here, same content before search displayed -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5694) [vmsync] - Xenserver - When VM is deleted outside of CS , VM state is not being synced to CS.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan updated CLOUDSTACK-5694:
Summary: [vmsync] - Xenserver - When VM is deleted outside of CS , VM state
is not being synced to CS. (was: Xenserver - When VM is deleted outside of CS
, VM state is not being synced to CS.)
[vmsync] - Xenserver - When VM is deleted outside of CS , VM state is not
being synced to CS.
-
Key: CLOUDSTACK-5694
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5694
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
Priority: Critical
Fix For: 4.3.0
[Vmsync]- xenserver - When VM is deleted outside of CS , VM state is not
being synced to CS.
PreReq:
Have few Vms deployed using Cloudstack.
Steps:
Outside of Cloudstack , Destroy an existing VM. ( stop the VM and then delete
the VM from xencenter.
There is an attempt made to stop the VM in CS that fails.
Should the expected behavior be to stop the VM and then destroy it in the CS?
Following exception seen in management server:
2013-12-26 20:14:42,543 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-342:ctx-433f534a) The VM is now missing marking it as Stopped
i-3-3-MyTestVM
2013-12-26 20:14:42,543 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-342:ctx-433f534a) Seq 1-1141178372: Response Received:
2013-12-26 20:14:42,543 DEBUG [c.c.a.t.Request]
(DirectAgent-342:ctx-433f534a) Seq 1-1141178372: Processing: { Ans: , MgmtId:
112516401760401, via: 1, Ver: v1, Flags: 10,
[{com.cloud.agent.api.ClusterSyncAnswer:{_clusterId:1,_newStates:{i-3-3-MyTestVM:{t:157f5d61-037f-44eb-ae3d-0cd082d3cff0,u:Stopped}},_isExecuted:false,result:true,wait:0}}]
}
2013-12-26 20:14:42,547 DEBUG [c.c.v.VirtualMachineManagerImpl]
(DirectAgent-342:ctx-433f534a) VM i-3-3-MyTestVM: cs state = Running and
realState = Stopped
2013-12-26 20:14:42,547 DEBUG [c.c.v.VirtualMachineManagerImpl]
(DirectAgent-342:ctx-433f534a) VM i-3-3-MyTestVM: cs state = Running and
realState = Stopped
2013-12-26 20:14:42,547 DEBUG [c.c.h.HighAvailabilityManagerImpl]
(DirectAgent-342:ctx-433f534a) VM does not require investigation so I'm
marking it as Stopped: VM[User|TestVM-1]
2013-12-26 20:14:42,547 WARN [o.a.c.alerts] (DirectAgent-342:ctx-433f534a)
alertType:: 8 // dataCenterId:: 1 // podId:: 1 // clusterId:: null //
message:: VM (name: TestVM-1, id: 3) stopped unexpectedly on host id:2,
availability zone id:1, pod id:1
2013-12-26 20:14:42,551 DEBUG [c.c.h.HighAvailabilityManagerImpl]
(DirectAgent-342:ctx-433f534a) VM is not HA enabled so we're done.
2013-12-26 20:14:42,551 WARN [c.c.a.m.DirectAgentAttache]
(DirectAgent-342:ctx-433f534a) Seq 1-1141178372: Exception caught
java.lang.NullPointerException
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1235)
at
com.cloud.ha.HighAvailabilityManagerImpl.scheduleRestart(HighAvailabilityManagerImpl.java:346)
at
com.cloud.vm.VirtualMachineManagerImpl.compareState(VirtualMachineManagerImpl.java:2686)
at
com.cloud.vm.VirtualMachineManagerImpl.deltaSync(VirtualMachineManagerImpl.java:2320)
at
com.cloud.vm.VirtualMachineManagerImpl.processAnswers(VirtualMachineManagerImpl.java:2797)
at com.cloud.agent.manager.AgentAttache.processAnswers(AgentAttache.java:296)
at
com.cloud.agent.manager.ClusteredDirectAgentAttache.processAnswers(ClusteredDirectAgentAttache.java:65)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:242)
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.innerRunAndReset(FutureTask.java:351)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
at
[jira] [Updated] (CLOUDSTACK-5696) [Vmsync]- xenserver - Stopped state of VM is not synced to CS when VM is stopped outside of CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeetha Hariharan updated CLOUDSTACK-5696: Attachment: management-server.rar [Vmsync]- xenserver - Stopped state of VM is not synced to CS when VM is stopped outside of CS. --- Key: CLOUDSTACK-5696 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5696 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Kelven Yang Priority: Critical Fix For: 4.3.0 Attachments: management-server.rar Pre Req: Have few Vms deployed using Cloudstack. Steps: Outside of Cloudstack ,Stop VM Vm continues to remain in Running state in CS , even though the change in state is detected. Following exception seen in management server logs: 2013-12-26 17:02:10,026 DEBUG [c.c.v.VirtualMachineManagerImpl] (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt ate = Stopped 2013-12-26 17:02:10,027 DEBUG [c.c.v.VirtualMachineManagerImpl] (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt ate = Stopped 2013-12-26 17:02:10,027 DEBUG [c.c.h.HighAvailabilityManagerImpl] (DirectAgent-77:ctx-c28d9506) VM does not require investigation so I'm marki ng it as Stopped: VM[User|TestVM-tiny-host-1ps-0-1] 2013-12-26 17:02:10,027 WARN [o.a.c.alerts] (DirectAgent-77:ctx-c28d9506) alertType:: 8 // dataCenterId:: 1 // podId:: 1 // clusterId:: null // message:: VM (name: TestVM-tiny-host-1ps-0-1, id: 8) stopped unexpectedly on host id:1, availability zone id:1, pod id:1 2013-12-26 17:02:10,032 DEBUG [c.c.h.HighAvailabilityManagerImpl] (DirectAgent-77:ctx-c28d9506) VM is not HA enabled so we're done. 2013-12-26 17:02:10,032 WARN [c.c.a.m.DirectAgentAttache] (DirectAgent-77:ctx-c28d9506) Seq 1-799145986: Exception caught java.lang.NullPointerException at com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1235) at com.cloud.ha.HighAvailabilityManagerImpl.scheduleRestart(HighAvailabilityManagerImpl.java:346) at com.cloud.vm.VirtualMachineManagerImpl.compareState(VirtualMachineManagerImpl.java:2686) at com.cloud.vm.VirtualMachineManagerImpl.deltaSync(VirtualMachineManagerImpl.java:2320) at com.cloud.vm.VirtualMachineManagerImpl.processAnswers(VirtualMachineManagerImpl.java:2797) at com.cloud.agent.manager.AgentAttache.processAnswers(AgentAttache.java:296) at com.cloud.agent.manager.ClusteredDirectAgentAttache.processAnswers(ClusteredDirectAgentAttache.java:65) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:242) 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.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) 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) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5696) [Vmsync]- xenserver - Stopped state of VM is not synced to CS when VM is stopped outside of CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5696: --- Assignee: Kelven Yang [Vmsync]- xenserver - Stopped state of VM is not synced to CS when VM is stopped outside of CS. --- Key: CLOUDSTACK-5696 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5696 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Kelven Yang Priority: Critical Fix For: 4.3.0 Attachments: management-server.rar Pre Req: Have few Vms deployed using Cloudstack. Steps: Outside of Cloudstack ,Stop VM Vm continues to remain in Running state in CS , even though the change in state is detected. Following exception seen in management server logs: 2013-12-26 17:02:10,026 DEBUG [c.c.v.VirtualMachineManagerImpl] (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt ate = Stopped 2013-12-26 17:02:10,027 DEBUG [c.c.v.VirtualMachineManagerImpl] (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt ate = Stopped 2013-12-26 17:02:10,027 DEBUG [c.c.h.HighAvailabilityManagerImpl] (DirectAgent-77:ctx-c28d9506) VM does not require investigation so I'm marki ng it as Stopped: VM[User|TestVM-tiny-host-1ps-0-1] 2013-12-26 17:02:10,027 WARN [o.a.c.alerts] (DirectAgent-77:ctx-c28d9506) alertType:: 8 // dataCenterId:: 1 // podId:: 1 // clusterId:: null // message:: VM (name: TestVM-tiny-host-1ps-0-1, id: 8) stopped unexpectedly on host id:1, availability zone id:1, pod id:1 2013-12-26 17:02:10,032 DEBUG [c.c.h.HighAvailabilityManagerImpl] (DirectAgent-77:ctx-c28d9506) VM is not HA enabled so we're done. 2013-12-26 17:02:10,032 WARN [c.c.a.m.DirectAgentAttache] (DirectAgent-77:ctx-c28d9506) Seq 1-799145986: Exception caught java.lang.NullPointerException at com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1235) at com.cloud.ha.HighAvailabilityManagerImpl.scheduleRestart(HighAvailabilityManagerImpl.java:346) at com.cloud.vm.VirtualMachineManagerImpl.compareState(VirtualMachineManagerImpl.java:2686) at com.cloud.vm.VirtualMachineManagerImpl.deltaSync(VirtualMachineManagerImpl.java:2320) at com.cloud.vm.VirtualMachineManagerImpl.processAnswers(VirtualMachineManagerImpl.java:2797) at com.cloud.agent.manager.AgentAttache.processAnswers(AgentAttache.java:296) at com.cloud.agent.manager.ClusteredDirectAgentAttache.processAnswers(ClusteredDirectAgentAttache.java:65) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:242) 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.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) 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) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5695) [Vmsync] - xenserver - VMs deployed outside of CS gets destroyed when vmsync is initiated from CS.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-5695:
---
Assignee: Kelven Yang
[Vmsync] - xenserver - VMs deployed outside of CS gets destroyed when vmsync
is initiated from CS.
--
Key: CLOUDSTACK-5695
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5695
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Environment: Build from 4.3
Reporter: Sangeetha Hariharan
Assignee: Kelven Yang
Priority: Critical
Fix For: 4.3.0
[Vmsync] - xenserver - VMs deployed outside of CS gets destroyed when vmsync
is initiated from CS.
PreReq:
Have few Vms deployed using Cloudstack.
Steps:
Outside of Cloudstack , Deploy a new VM.
Vm fails to get deployed since CS issues a stop command for the VM.
Stopped the management server.
Outside of Cloudstack , Deploy a new VM.
Start the management server.
When Vmsync is initiated from CS , CS issues stop command for the VM ,
resulting in the Vm shutting down.
Management server logs when Vm is being shut down:
2013-12-26 19:18:41,388 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgent-33:ctx-4c7f780d) Process host VM state report from ping process.
host: 2
2013-12-26 19:18:41,390 INFO [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgent-33:ctx-4c7f780d) Unable to find matched VM in CloudStack DB.
name: yoyo
2013-12-26 19:18:41,393 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgent-33:ctx-4c7f780d) VM state report. host: 2, vm id: 6, power
state: PowerOn
2013-12-26 19:18:41,406 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgent-33:ctx-4c7f780d) VM state report is updated. host: 2, vm id: 6,
power stat
e: PowerOn
2013-12-26 19:18:42,298 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-5:ctx-c5aa0746) Seq 2-468320260: Executing request
2013-12-26 19:18:42,299 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-17:ctx-50469c06) Seq 1-1141178372: Executing request
2013-12-26 19:18:42,508 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-5:ctx-c5aa0746) Seq 2-468320260: Response Received:
2013-12-26 19:18:42,508 DEBUG [c.c.a.t.Request] (DirectAgent-5:ctx-c5aa0746)
Seq 2-468320260: Processing: { Ans: , MgmtId: 112516401760401, via: 2, Ver:
v1,
Flags: 10, [{com.cloud.agent.api.Answer:{result:true,wait:0}}] }
2013-12-26 19:18:42,573 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-17:ctx-50469c06) Detecting a new state but couldn't find a old
state so adding it to
the changes: yoyo
2013-12-26 19:18:42,574 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-17:ctx-50469c06) Seq 1-1141178372: Response Received:
2013-12-26 19:18:42,574 DEBUG [c.c.a.t.Request] (DirectAgent-17:ctx-50469c06)
Seq 1-1141178372: Processing: { Ans: , MgmtId: 112516401760401, via: 1, Ver:
v1
, Flags: 10,
[{com.cloud.agent.api.ClusterSyncAnswer:{_clusterId:1,_newStates:{yoyo:{t:157f5d61-037f-44eb-ae3d-0cd082d3cff0,u:Running,v:vir
idian:true;acpi:1;apic:true;pae:true;nx:true}},_isExecuted:false,result:true,wait:0}}]
}
2013-12-26 19:18:42,576 WARN [c.c.v.VirtualMachineManagerImpl]
(DirectAgent-17:ctx-50469c06) Found an alien VM yoyo
2013-12-26 19:18:42,576 DEBUG [c.c.v.VirtualMachineManagerImpl]
(DirectAgent-17:ctx-50469c06) Cleaning up a VM that is no longer found
deltaSync: yoyo
2013-12-26 19:18:42,582 DEBUG [c.c.a.t.Request] (DirectAgent-17:ctx-50469c06)
Seq 2-468320276: Sending { Cmd , MgmtId: 112516401760401, via:
2(Rack3Host23.la
b.vmops.com), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:yoyo,wait:0}}]
}
2013-12-26 19:18:42,582 DEBUG [c.c.a.t.Request] (DirectAgent-17:ctx-50469c06)
Seq 2-468320276: Executing: { Cmd , MgmtId: 112516401760401, via:
2(Rack3Host23
.lab.vmops.com), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:yoyo,wait:0}}]
}
2013-12-26 19:18:42,582 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-11:ctx-013a4466) Seq 2-468320276: Executing request
2013-12-26 19:18:42,678 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-11:ctx-013a4466) 9. The VM yoyo is in Stopping state
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5656) UI shows PF,LB,firewall,static NAT rule operations success on non upgraded VR but logs show VR requires upgrade.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-5656:
---
Assignee: Jessica Wang
UI shows PF,LB,firewall,static NAT rule operations success on non upgraded VR
but logs show VR requires upgrade.
Key: CLOUDSTACK-5656
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5656
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: UI
Affects Versions: 4.3.0
Environment: 2.2.14 to 4.3 upgrade
Reporter: manasaveloori
Assignee: Jessica Wang
Priority: Critical
Fix For: 4.3.0
1. Have CS 2.2.14 with xen 5.6sp2.
2.Deploy some VRS.
3. Upgrade to 4.3.
4. Perform any operation which sends commands to non upgraded VR like
applying static nat,firewall rules,PF etc.
Observation:
UI shows all the operations as success but in logs we can see the messages as
2013-12-27 15:04:31,326 DEBUG [c.c.a.ApiServlet]
(catalina-exec-12:ctx-c0ac9a16 ctx-ed5f06a6) ===END=== 10.252.192.34 -- GET
command=createFirewallRuleresponse=jsonsessionkey=DE4U5L%2FWnxa60eF2LoJPuY6FVHw%3Dcidrlist=0.0.0.0%2F0protocol=tcpstartport=1endport=65535ipaddressid=4_=1388136871014
2013-12-27 15:04:31,354 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Applying ip association in
network Ntwk[205|Guest|6]
2013-12-27 15:04:31,354 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Router r-6-VM requires upgrade,
so not sending apply ip association commands to the backend
2013-12-27 15:04:31,362 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Applying firewall rules in
network Ntwk[205|Guest|6]
2013-12-27 15:04:31,363 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Router r-6-VM requires upgrade,
so not sending apply firewall rules commands to the backend
2013-12-27 15:04:31,430 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Complete async job-24, jobStatus:
SUCCEEDED, resultCode: 0, result:
org.apache.cloudstack.api.response.FirewallResponse/firewallrule/{id:b772c804-09cc-4eaa-96a3-61adcf1cb242,protocol:tcp,startport:1,endport:65535,ipaddressid:4,networkid:205,ipaddress:10.147.47.6,state:Active,cidrlist:,tags:[]}
2013-12-27 15:04:31,483 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-18:ctx-0bb79ed5) Done executing
org.apache.cloudstack.api.command.user.firewall.CreateFirewallRuleCmd for
job-24
UI shoul aslo show the message as Router requires upgrade and the action
should fail.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5557) [UI] Invalid UI for Network-Guest Network-AnyVPCN/w.Able to see all configuration(FW/PF/LB)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5557: --- Assignee: Jessica Wang [UI] Invalid UI for Network-Guest Network-AnyVPCN/w.Able to see all configuration(FW/PF/LB) --- Key: CLOUDSTACK-5557 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5557 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: manasaveloori Assignee: Jessica Wang Priority: Critical Fix For: 4.3.0 Attachments: VPCTierNW.jpg Steps: 1. Create a VPC. 2. Create a tier network and VM using that network. 3. Acquire IP and enable PF/LB rule. Obseravation: Under Network-GuestNetworks-Click on VPC tier network-IPaddresses. Able to view the IP address and all the configurable items in UI(firewall,PF,LB)like for normal networks. Also user is allowed to configure the rules which results in exception Attaching the SC -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5694) [vmsync] - Xenserver - When VM is deleted outside of CS , VM state is not being synced to CS.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan updated CLOUDSTACK-5694:
Attachment: management-server.rar
[vmsync] - Xenserver - When VM is deleted outside of CS , VM state is not
being synced to CS.
-
Key: CLOUDSTACK-5694
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5694
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Environment: Build from 4.3
Reporter: Sangeetha Hariharan
Assignee: Kelven Yang
Priority: Critical
Fix For: 4.3.0
Attachments: management-server.rar
[Vmsync]- xenserver - When VM is deleted outside of CS , VM state is not
being synced to CS.
PreReq:
Have few Vms deployed using Cloudstack.
Steps:
Outside of Cloudstack , Destroy an existing VM. ( stop the VM and then delete
the VM from xencenter.
There is an attempt made to stop the VM in CS that fails.
Should the expected behavior be to stop the VM and then destroy it in the CS?
Following exception seen in management server:
2013-12-26 20:14:42,543 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-342:ctx-433f534a) The VM is now missing marking it as Stopped
i-3-3-MyTestVM
2013-12-26 20:14:42,543 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-342:ctx-433f534a) Seq 1-1141178372: Response Received:
2013-12-26 20:14:42,543 DEBUG [c.c.a.t.Request]
(DirectAgent-342:ctx-433f534a) Seq 1-1141178372: Processing: { Ans: , MgmtId:
112516401760401, via: 1, Ver: v1, Flags: 10,
[{com.cloud.agent.api.ClusterSyncAnswer:{_clusterId:1,_newStates:{i-3-3-MyTestVM:{t:157f5d61-037f-44eb-ae3d-0cd082d3cff0,u:Stopped}},_isExecuted:false,result:true,wait:0}}]
}
2013-12-26 20:14:42,547 DEBUG [c.c.v.VirtualMachineManagerImpl]
(DirectAgent-342:ctx-433f534a) VM i-3-3-MyTestVM: cs state = Running and
realState = Stopped
2013-12-26 20:14:42,547 DEBUG [c.c.v.VirtualMachineManagerImpl]
(DirectAgent-342:ctx-433f534a) VM i-3-3-MyTestVM: cs state = Running and
realState = Stopped
2013-12-26 20:14:42,547 DEBUG [c.c.h.HighAvailabilityManagerImpl]
(DirectAgent-342:ctx-433f534a) VM does not require investigation so I'm
marking it as Stopped: VM[User|TestVM-1]
2013-12-26 20:14:42,547 WARN [o.a.c.alerts] (DirectAgent-342:ctx-433f534a)
alertType:: 8 // dataCenterId:: 1 // podId:: 1 // clusterId:: null //
message:: VM (name: TestVM-1, id: 3) stopped unexpectedly on host id:2,
availability zone id:1, pod id:1
2013-12-26 20:14:42,551 DEBUG [c.c.h.HighAvailabilityManagerImpl]
(DirectAgent-342:ctx-433f534a) VM is not HA enabled so we're done.
2013-12-26 20:14:42,551 WARN [c.c.a.m.DirectAgentAttache]
(DirectAgent-342:ctx-433f534a) Seq 1-1141178372: Exception caught
java.lang.NullPointerException
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1235)
at
com.cloud.ha.HighAvailabilityManagerImpl.scheduleRestart(HighAvailabilityManagerImpl.java:346)
at
com.cloud.vm.VirtualMachineManagerImpl.compareState(VirtualMachineManagerImpl.java:2686)
at
com.cloud.vm.VirtualMachineManagerImpl.deltaSync(VirtualMachineManagerImpl.java:2320)
at
com.cloud.vm.VirtualMachineManagerImpl.processAnswers(VirtualMachineManagerImpl.java:2797)
at com.cloud.agent.manager.AgentAttache.processAnswers(AgentAttache.java:296)
at
com.cloud.agent.manager.ClusteredDirectAgentAttache.processAnswers(ClusteredDirectAgentAttache.java:65)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:242)
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.innerRunAndReset(FutureTask.java:351)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
[jira] [Assigned] (CLOUDSTACK-5683) kvm - Live migration fails with java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su reassigned CLOUDSTACK-5683:
-
Assignee: Kelven Yang (was: edison su)
NPE in vmsync code
kvm - Live migration fails with java.lang.NullPointerException
--
Key: CLOUDSTACK-5683
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5683
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Environment: Build from 4.3
Reporter: Sangeetha Hariharan
Assignee: Kelven Yang
Priority: Critical
Fix For: 4.3.0
Attachments: management-server.log
Steps to reproduce the problem:
Advanced zone set up with 2 KVM hosts.
Deploy few Vms in both hosts.
Live migrate vm from 1 host to another.
UI reports success , but the VM migration actually fails.
Following exception seen in management server logs:
013-12-30 17:35:03,451 ERROR [c.c.v.VmWorkJobDispatcher]
(Job-Executor-101:ctx-23e206c0 ctx-4ddc2410) Unable to complete AsyncJobVO
{id:76
, userId: 2, accountId: 2, instanceType: null, instanceId: null, cmd:
com.cloud.vm.VmWorkMigrate, cmdInfo: rO0ABXNyABpjb20uY2xvdWQudm0uVm1X
b3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9
MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbW
V0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAA3QAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAnNyAA5qYXZhLmxhbmcuTG9uZzuL5
JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXEAfgA
JcQB-AAlwcQB-AAk, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0,
resultCode: 0, result: null, initMsid: 82324189320212, completeMsid: null,
lastUpdated: null, lastPolled: null, created: Mon Dec 30 17:35:02 EST 2013}
java.lang.NullPointerException
at
com.cloud.vm.VmWorkMigrate.getDeployDestination(VmWorkMigrate.java:60)
at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4743)
at
com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:99)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:522)
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.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
2013-12-30 17:35:03,452 ERROR [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-101:ctx-23e206c0) Unexpected exception
java.lang.NullPointerException
2013-12-30 17:35:03,452 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-101:ctx-23e206c0) Complete async job-76, jobStatus: FAILED,
resultCode: 530, result: null
2013-12-30 17:35:03,463 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Job-Executor-102:ctx-e541857f) Add job-75 into job monitoring
2013-12-30 17:35:03,463 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-102:ctx-e541857f) Executing AsyncJobVO {id:75, userId: 2,
accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdInfo:
{response:json,sessionkey:4SFVHNVTkNP6Ys+kKkCAVp57j8w\u003d,virtualmachineid:17c74e6c-a39b-4c51-8e76-b75985ea6622,cmdEventType:VM.MIGRATE,hostid:9cc1f4fa-f972-42a1-be2c-213dc1c36504,ctxUserId:2,httpmethod:GET,_:1388442964044,ctxAccountId:2,ctxStartEventId:165},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 82324189320212, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Mon Dec 30 17:35:02 EST 2013}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5613) CloudStack 4.2.0 - Usage server is running but tables remain empty
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859637#comment-13859637 ] Vadim Kim. commented on CLOUDSTACK-5613: Please, check that usage server has created log files under /var/log/cloudstack/usage/. In my case this folder was empty so there was hard to analyze the root cause of the problem. CloudStack 4.2.0 - Usage server is running but tables remain empty -- Key: CLOUDSTACK-5613 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5613 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.2.0 Environment: Ubuntu 12.04.03 LTS Reporter: Guy Beaupré Priority: Blocker CloudStack Usage service is installed and reported as running by Ubuntu 12.04.03 LTS but usage tables remains empty. I have tried to install cloudstack-usage from the source and the provided package ( .deb ) but I get the same issue. CloudStack event manager report the following even if Ubuntu is showing running: No usage server process running An internet colleague reported the same issue with Ubuntu 12.04.03 and confirmed that it is working with CentOS. Supplemental Information: 1. Usage server is running: service cloudstack-usage status * cloudstack-usage is running 2. Management log shows: [cloud.ha.HighAvailabilityManagerImpl] (HA-1:null) checking health of usage server [cloud.ha.HighAvailabilityManagerImpl] (HA-1:null) usage server running? false, heartbeat: null [apache.cloudstack.alerts] (HA-1:null) alertType: : 13 // dataCenterId:: 0 // podId:: 0 // clusterId:: null // message:: No usage server process running -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-4506) In a mixed hypervisor setup, destroying a VM whose host has been removed, throws a NPE and the ROOT volume of that VM also is not deleted from the primary.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859650#comment-13859650
]
ASF subversion and git services commented on CLOUDSTACK-4506:
-
Commit 9d52a4362d0398945dab2b8d9e6aba2332efe960 in branch refs/heads/4.3 from
[~edison]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9d52a43 ]
CLOUDSTACK-4506: fix NPE in case hostid is null
In a mixed hypervisor setup, destroying a VM whose host has been removed,
throws a NPE and the ROOT volume of that VM also is not deleted from the
primary.
---
Key: CLOUDSTACK-4506
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4506
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller
Affects Versions: 4.2.0
Environment: Advanced zone setup having clusters of different
hypervisor types. Ex KVM and VMWARE
Reporter: Abhinav Roy
Assignee: edison su
Priority: Critical
Fix For: 4.3.0
Attachments: CS-4506.zip
Steps :
=
1. Deploy a CS 4.2 setup with KVM and VMWARE clusters having one host each.
2. Create some VMs on KVM (ex- kvm1 and kvm2)
3. Put the KVM host in maintenance mode and then remove the Host. Now kvm1
and kvm2 are in stopped state.
4. Destroy kvm1
Observations :
1. when kvm1 is destroyed it fails with the following exception
2013-08-26 13:10:09,205 DEBUG [cloud.api.ApiServlet] (catalina-exec-19:null)
===START=== 10.144.6.17 -- GET
command=destroyVirtualMachineid=d613f6e5-c53a-4f6b-be31-32f101eb6c99response=jsonsessionkey=bU49tWdfVUJUrq65PbMmzGbe0PE%3D_=1377502661180
2013-08-26 13:10:09,242 DEBUG [cloud.async.AsyncJobManagerImpl]
(catalina-exec-19:null) submit async job-78 = [
8018e79c-a47e-4a54-b3a4-68963f3c11a9 ], details: AsyncJobVO {id:78, userId:
2, accountId: 2, sessionKey: null, instanceType: VirtualMachine, instanceId:
3, cmd: org.apache.cloudstack.api.command.user.vm.DestroyVMCmd,
cmdOriginator: null, cmdInfo:
{response:json,id:d613f6e5-c53a-4f6b-be31-32f101eb6c99,sessionkey:bU49tWdfVUJUrq65PbMmzGbe0PE\u003d,cmdEventType:VM.DESTROY,ctxUserId:2,httpmethod:GET,_:1377502661180,ctxAccountId:2,ctxStartEventId:245},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 226870599129537,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2013-08-26 13:10:09,245 DEBUG [cloud.api.ApiServlet] (catalina-exec-19:null)
===END=== 10.144.6.17 -- GET
command=destroyVirtualMachineid=d613f6e5-c53a-4f6b-be31-32f101eb6c99response=jsonsessionkey=bU49tWdfVUJUrq65PbMmzGbe0PE%3D_=1377502661180
2013-08-26 13:10:09,249 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-50:job-78 = [ 8018e79c-a47e-4a54-b3a4-68963f3c11a9 ]) Executing
org.apache.cloudstack.api.command.user.vm.DestroyVMCmd for job-78 = [
8018e79c-a47e-4a54-b3a4-68963f3c11a9 ]
2013-08-26 13:10:09,282 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-50:job-78 = [ 8018e79c-a47e-4a54-b3a4-68963f3c11a9 ])
Destroying vm VM[User|v1]
2013-08-26 13:10:09,282 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-50:job-78 = [ 8018e79c-a47e-4a54-b3a4-68963f3c11a9 ]) VM is
already stopped: VM[User|v1]
2013-08-26 13:10:09,308 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-50:job-78 = [ 8018e79c-a47e-4a54-b3a4-68963f3c11a9 ]) VM state
transitted from :Stopped to Destroyed with event: DestroyRequestedvm's
original host id: 1 new host id: null host id before state transition: null
2013-08-26 13:10:09,324 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-50:job-78 = [ 8018e79c-a47e-4a54-b3a4-68963f3c11a9 ])
Unexpected exception while executing
org.apache.cloudstack.api.command.user.vm.DestroyVMCmd
java.lang.NullPointerException
at
com.cloud.capacity.CapacityManagerImpl.releaseVmCapacity(CapacityManagerImpl.java:187)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
com.cloud.capacity.CapacityManagerImpl.postStateTransitionEvent(CapacityManagerImpl.java:718)
at
com.cloud.capacity.CapacityManagerImpl.postStateTransitionEvent(CapacityManagerImpl.java:101)
at com.cloud.utils.fsm.StateMachine2.transitTo(StateMachine2.java:117)
at
com.cloud.vm.VirtualMachineManagerImpl.stateTransitTo(VirtualMachineManagerImpl.java:1324)
at
[jira] [Resolved] (CLOUDSTACK-4506) In a mixed hypervisor setup, destroying a VM whose host has been removed, throws a NPE and the ROOT volume of that VM also is not deleted from the primary.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su resolved CLOUDSTACK-4506.
---
Resolution: Fixed
In a mixed hypervisor setup, destroying a VM whose host has been removed,
throws a NPE and the ROOT volume of that VM also is not deleted from the
primary.
---
Key: CLOUDSTACK-4506
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4506
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller
Affects Versions: 4.2.0
Environment: Advanced zone setup having clusters of different
hypervisor types. Ex KVM and VMWARE
Reporter: Abhinav Roy
Assignee: edison su
Priority: Critical
Fix For: 4.3.0
Attachments: CS-4506.zip
Steps :
=
1. Deploy a CS 4.2 setup with KVM and VMWARE clusters having one host each.
2. Create some VMs on KVM (ex- kvm1 and kvm2)
3. Put the KVM host in maintenance mode and then remove the Host. Now kvm1
and kvm2 are in stopped state.
4. Destroy kvm1
Observations :
1. when kvm1 is destroyed it fails with the following exception
2013-08-26 13:10:09,205 DEBUG [cloud.api.ApiServlet] (catalina-exec-19:null)
===START=== 10.144.6.17 -- GET
command=destroyVirtualMachineid=d613f6e5-c53a-4f6b-be31-32f101eb6c99response=jsonsessionkey=bU49tWdfVUJUrq65PbMmzGbe0PE%3D_=1377502661180
2013-08-26 13:10:09,242 DEBUG [cloud.async.AsyncJobManagerImpl]
(catalina-exec-19:null) submit async job-78 = [
8018e79c-a47e-4a54-b3a4-68963f3c11a9 ], details: AsyncJobVO {id:78, userId:
2, accountId: 2, sessionKey: null, instanceType: VirtualMachine, instanceId:
3, cmd: org.apache.cloudstack.api.command.user.vm.DestroyVMCmd,
cmdOriginator: null, cmdInfo:
{response:json,id:d613f6e5-c53a-4f6b-be31-32f101eb6c99,sessionkey:bU49tWdfVUJUrq65PbMmzGbe0PE\u003d,cmdEventType:VM.DESTROY,ctxUserId:2,httpmethod:GET,_:1377502661180,ctxAccountId:2,ctxStartEventId:245},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 226870599129537,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2013-08-26 13:10:09,245 DEBUG [cloud.api.ApiServlet] (catalina-exec-19:null)
===END=== 10.144.6.17 -- GET
command=destroyVirtualMachineid=d613f6e5-c53a-4f6b-be31-32f101eb6c99response=jsonsessionkey=bU49tWdfVUJUrq65PbMmzGbe0PE%3D_=1377502661180
2013-08-26 13:10:09,249 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-50:job-78 = [ 8018e79c-a47e-4a54-b3a4-68963f3c11a9 ]) Executing
org.apache.cloudstack.api.command.user.vm.DestroyVMCmd for job-78 = [
8018e79c-a47e-4a54-b3a4-68963f3c11a9 ]
2013-08-26 13:10:09,282 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-50:job-78 = [ 8018e79c-a47e-4a54-b3a4-68963f3c11a9 ])
Destroying vm VM[User|v1]
2013-08-26 13:10:09,282 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-50:job-78 = [ 8018e79c-a47e-4a54-b3a4-68963f3c11a9 ]) VM is
already stopped: VM[User|v1]
2013-08-26 13:10:09,308 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-50:job-78 = [ 8018e79c-a47e-4a54-b3a4-68963f3c11a9 ]) VM state
transitted from :Stopped to Destroyed with event: DestroyRequestedvm's
original host id: 1 new host id: null host id before state transition: null
2013-08-26 13:10:09,324 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-50:job-78 = [ 8018e79c-a47e-4a54-b3a4-68963f3c11a9 ])
Unexpected exception while executing
org.apache.cloudstack.api.command.user.vm.DestroyVMCmd
java.lang.NullPointerException
at
com.cloud.capacity.CapacityManagerImpl.releaseVmCapacity(CapacityManagerImpl.java:187)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
com.cloud.capacity.CapacityManagerImpl.postStateTransitionEvent(CapacityManagerImpl.java:718)
at
com.cloud.capacity.CapacityManagerImpl.postStateTransitionEvent(CapacityManagerImpl.java:101)
at com.cloud.utils.fsm.StateMachine2.transitTo(StateMachine2.java:117)
at
com.cloud.vm.VirtualMachineManagerImpl.stateTransitTo(VirtualMachineManagerImpl.java:1324)
at
com.cloud.vm.VirtualMachineManagerImpl.destroy(VirtualMachineManagerImpl.java:1355)
at
org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.destroyVirtualMachine(VMEntityManagerImpl.java:259)
at
[jira] [Updated] (CLOUDSTACK-5665) XEN patch/hotfix certification - XS 6.0.2 XS602E030 patch installation fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudha Ponnaganti updated CLOUDSTACK-5665:
-
Description:
XEN hotfix installation procedure
1. Hosts master slave installed with
XS 6.0.2 base + Hotfix XS602E001 to XS602E029 + CSPs
2. Basic zone with cluster of above master slave hosts
security group default with NO security rules
Deploy two VMs
3. MS: master host put to maintenance mode - VMs migrate to slave host
4. MS: unmanage cluster
5. master host: install hotfix XS602E030 + CSP , reboot master
6. MS: master host cancel maintenance mode
7. MS: manage cluster
8. MS: slave host put to maintenance mode, VMs FAIL migrate to master
Unable to complete hotfix installation
2013-12-26 16:51:25,307 INFO [xen.resource.CitrixResourceBase]
(DirectAgent-56:null) VM does not exist on
XenServerc6c75483-b35b-4a7c-9e2d-2274e34dd437
2013-12-26 16:51:25,307 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-56:null) Seq 1-265617550: Response Received:
2013-12-26 16:51:25,307 DEBUG [agent.transport.Request] (DirectAgent-56:null)
Seq 1-265617550: Processing: { Ans: , MgmtId: 7692017993539, via: 1, Ver: v1,
Flags: 110, [{com.cloud.agent.api.StopAnswer:{result:true,details:VM
does not exist,wait:0}}] }
2013-12-26 16:51:25,307 DEBUG [agent.manager.AgentAttache]
(DirectAgent-56:null) Seq 1-265617550: Unable to find listener.
2013-12-26 16:51:25,307 DEBUG [agent.manager.AgentAttache]
(DirectAgent-56:null) Seq 1-265617550: No more commands found
2013-12-26 16:51:25,313 DEBUG [vm.dao.VMInstanceDaoImpl] (HA-Worker-3:work-19)
Unable to update VM[DomainRouter|r-4-VM]: DB Data={Host=4; State=Running;
updated=13; time=Thu Dec 26 16:51:25 PST 2013} New Data: {Host=4;
State=Stopping; updated=12; time=Thu Dec 26 16:51:25 PST 2013} Stale Data:
{Host=4; State=Running; updated=11; time=Thu Dec 26 16:51:22 PST 2013}
2013-12-26 16:51:25,313 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(HA-Worker-3:work-19) Unable to stop VM due to VM is being operated on.
2013-12-26 16:51:25,313 WARN [cloud.ha.HighAvailabilityManagerImpl]
(HA-Worker-3:work-19) Unable to migrate vm from 4
2013-12-26 16:51:25,314 DEBUG [cloud.resource.ResourceManagerImpl]
(HA-Worker-3:work-19) No next resource state for host 4 while current state is
ErrorInMaintenance with event UnableToMigrate
com.cloud.utils.fsm.NoTransitionException: No next resource state found for
current state =ErrorInMaintenance event =UnableToMigrate
at
com.cloud.resource.ResourceManagerImpl.resourceStateTransitTo(ResourceManagerImpl.java:1178)
at
com.cloud.resource.ResourceManagerImpl.maintenanceFailed(ResourceManagerImpl.java:2313)
at
com.cloud.ha.HighAvailabilityManagerImpl.migrate(HighAvailabilityManagerImpl.java:602)
at
com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:858)
2013-12-26 16:51:25,314 INFO [cloud.ha.HighAvailabilityManagerImpl]
(HA-Worker-3:work-19) Completed HAWork[19-Migration-4-Running-Migrating]
2013-12-26 16:51:25,324 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-57:null) Task failed! Task record: uuid:
38ce6cd4-9ab2-7e46-4d10-dafe25a83084
nameLabel: Async.VM.pool_migrate
nameDescription:
allowedOperations: []
currentOperations: {}
created: Thu Dec 26 16:55:03 PST 2013
finished: Thu Dec 26 16:55:03 PST 2013
status: failure
residentOn: com.xensource.xenapi.Host@40561b9c
progress: 1.0
type: none/
result:
errorInfo: [VM_REQUIRES_SR,
OpaqueRef:6e9c09e8-9ed5-1e21-2048-d848a084a15a,
OpaqueRef:eec84d31-9691-1ba4-f7bb-39db42ac8628]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
2013-12-26 16:51:25,332 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-57:null) Unable to migrate VM(s-1-VM) from
host(d044a044-1a30-4c01-ae83-11d2631a4ffe) due to Task failed! Task record:
uuid: 38ce6cd4-9ab2-7e46-4d10-dafe25a83084
nameLabel: Async.VM.pool_migrate
nameDescription:
allowedOperations: []
currentOperations: {}
created: Thu Dec 26 16:55:03 PST 2013
finished: Thu Dec 26 16:55:03 PST 2013
status: failure
residentOn: com.xensource.xenapi.Host@40561b9c
progress: 1.0
type: none/
result:
errorInfo: [VM_REQUIRES_SR,
OpaqueRef:6e9c09e8-9ed5-1e21-2048-d848a084a15a,
OpaqueRef:eec84d31-9691-1ba4-f7bb-39db42ac8628]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
Task failed! Task record: uuid:
38ce6cd4-9ab2-7e46-4d10-dafe25a83084
nameLabel: Async.VM.pool_migrate
nameDescription:
:
residentOn:
[jira] [Updated] (CLOUDSTACK-5598) XEN patch/hotfix certification - XS 6.2 SP1 patch installation fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudha Ponnaganti updated CLOUDSTACK-5598:
-
Environment:
hostXS 6.2 + hot fix installed :
XS62E001
XS62E002
XS62E004
XS62E005
XS62E007
XS62E008
XS62E009
XS62E010
XS62E011
XS62E012
XS62E013
was:
MS 3.0.7 Patch DCloudStack-PATCH_D-3.0.7-7-rhel6.3.tar.gz
hostXS 6.2 + hot fix installed :
XS62E001
XS62E002
XS62E004
XS62E005
XS62E007
XS62E008
XS62E009
XS62E010
XS62E011
XS62E012
XS62E013
XEN patch/hotfix certification - XS 6.2 SP1 patch installation fail
---
Key: CLOUDSTACK-5598
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5598
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: pre-4.0.0
Environment: hostXS 6.2 + hot fix installed :
XS62E001
XS62E002
XS62E004
XS62E005
XS62E007
XS62E008
XS62E009
XS62E010
XS62E011
XS62E012
XS62E013
Reporter: angeline shen
Priority: Critical
Fix For: pre-4.0.0
Per http://wiki-ccp.citrix.com/pages/viewpage.action?pageId=11829631
Xen Patch installation procedure
1. completed steps 1 thru 7 to upgrade master XEN host to XS 6.2 + 6.2 SP1
2. On slave host, perform step 8: on MS put slave host in maintenance mode
Result: On slave host: all guest VMs fail to migrate to master host, slave
host remained in Preparemaintenance mode
MS Log:
2013-12-19 18:51:37,965 DEBUG [cloud.capacity.CapacityManagerImpl]
(HA-Worker-0:work-2) CPU STATS after allocation: for host: 1, old used: 2100,
old reserved: 0, actual total: 9044, total with overprovisioning: 9044; new
us
ed:2600, reserved:0; requested cpu:500,alloc_from_last:false
2013-12-19 18:51:37,965 DEBUG [cloud.capacity.CapacityManagerImpl]
(HA-Worker-0:work-2) RAM STATS after allocation: for host: 1, old used:
2818572288, old reserved: 0, total: 16001258112; new used: 3087007744,
reserved: 0;
requested mem: 268435456,alloc_from_last:false
2013-12-19 18:51:37,976 DEBUG [agent.transport.Request] (HA-Worker-0:work-2)
Seq 5-357629969: Waiting for Seq 357629965 Scheduling: { Cmd , MgmtId:
7692017993539, via: 5, Ver: v1, Flags: 100111, [{MigrateCommand:{vmName
:s-1-VM,destIp:10.223.51.3,hostGuid:95273a98-5144-42a8-8fb9-2e9761ff2320,isWindows:false,wait:0}}]
}
2013-12-19 18:51:38,146 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-11:null) Task failed! Task record: uuid:
4ea260eb-f447-cf59-fc0a-ab830d87f9d4
nameLabel: Async.VM.pool_migrate
nameDescription:
allowedOperations: []currentOperations: {} created: Thu
Dec 19 18:54:55 PST 2013 finished: Thu Dec 19 18:54:55 PST 2013
status: FAILURE
residentOn: com.xensource.xenapi.Host@6d9f1105
progress: 1.0
type: none/ result: errorInfo:
[VM_REQUIRES_SR, OpaqueRef:b68a7638-2937-58ea-0f5d-52cc3e2f6905,
OpaqueRef:fb25c62b-174a-2a50-fdc0-9ff47c37170c]
otherConfig: {}subtaskOf:
com.xensource.xenapi.Task@aaf13f6f subtasks: [] 2013-12-19
18:51:38,149 WARN [xen.resource.CitrixResourceBase] (DirectAgent-11:null)
Unable to migrate VM(i-2-3-VM) from
host(f6c18d41-fa40-440b-932d-f84bf64e5772) due to Task failed! Task record:
uuid: 4ea260eb-f447-cf59-fc0a-ab830d87f9d4
nameLabel: Async.VM.pool_migrate nameDescription:
allowedOperations: []
currentOperations: {}
created: Thu Dec 19 18:54:55 PST 2013
finished: Thu Dec 19 18:54:55 PST 2013
status: FAILURE
residentOn: com.xensource.xenapi.Host@6d9f1105
progress: 1.0
type: none/
result:
errorInfo: [VM_REQUIRES_SR,
OpaqueRef:b68a7638-2937-58ea-0f5d-52cc3e2f6905,
OpaqueRef:fb25c62b-174a-2a50-fdc0-9ff47c37170c]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
Task failed! Task record: uuid:
4ea260eb-f447-cf59-fc0a-ab830d87f9d4
nameLabel: Async.VM.pool_migrate
nameDescription:
allowedOperations: []
currentOperations: {} created: Thu Dec 19 18:54:55 PST 2013
finished: Thu Dec 19 18:54:55 PST 2013
status: FAILURE
residentOn: com.xensource.xenapi.Host@6d9f1105
progress: 1.0
type: none/
result:
errorInfo: [VM_REQUIRES_SR,
OpaqueRef:b68a7638-2937-58ea-0f5d-52cc3e2f6905,
OpaqueRef:fb25c62b-174a-2a50-fdc0-9ff47c37170c]
[jira] [Updated] (CLOUDSTACK-5598) XEN patch/hotfix certification - XS 6.2 SP1 patch installation fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudha Ponnaganti updated CLOUDSTACK-5598:
-
Description:
Xen Patch installation procedure
1. completed steps 1 thru 7 to upgrade master XEN host to XS 6.2 + 6.2 SP1
2. On slave host, perform step 8: on MS put slave host in maintenance mode
Result: On slave host: all guest VMs fail to migrate to master host, slave
host remained in Preparemaintenance mode
MS Log:
2013-12-19 18:51:37,965 DEBUG [cloud.capacity.CapacityManagerImpl]
(HA-Worker-0:work-2) CPU STATS after allocation: for host: 1, old used: 2100,
old reserved: 0, actual total: 9044, total with overprovisioning: 9044; new us
ed:2600, reserved:0; requested cpu:500,alloc_from_last:false
2013-12-19 18:51:37,965 DEBUG [cloud.capacity.CapacityManagerImpl]
(HA-Worker-0:work-2) RAM STATS after allocation: for host: 1, old used:
2818572288, old reserved: 0, total: 16001258112; new used: 3087007744,
reserved: 0;
requested mem: 268435456,alloc_from_last:false
2013-12-19 18:51:37,976 DEBUG [agent.transport.Request] (HA-Worker-0:work-2)
Seq 5-357629969: Waiting for Seq 357629965 Scheduling: { Cmd , MgmtId:
7692017993539, via: 5, Ver: v1, Flags: 100111, [{MigrateCommand:{vmName
:s-1-VM,destIp:10.223.51.3,hostGuid:95273a98-5144-42a8-8fb9-2e9761ff2320,isWindows:false,wait:0}}]
}
2013-12-19 18:51:38,146 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-11:null) Task failed! Task record: uuid:
4ea260eb-f447-cf59-fc0a-ab830d87f9d4
nameLabel: Async.VM.pool_migrate
nameDescription:
allowedOperations: []currentOperations: {} created: Thu Dec
19 18:54:55 PST 2013 finished: Thu Dec 19 18:54:55 PST 2013
status: FAILURE
residentOn: com.xensource.xenapi.Host@6d9f1105
progress: 1.0
type: none/ result: errorInfo:
[VM_REQUIRES_SR, OpaqueRef:b68a7638-2937-58ea-0f5d-52cc3e2f6905,
OpaqueRef:fb25c62b-174a-2a50-fdc0-9ff47c37170c]
otherConfig: {}subtaskOf:
com.xensource.xenapi.Task@aaf13f6f subtasks: [] 2013-12-19
18:51:38,149 WARN [xen.resource.CitrixResourceBase] (DirectAgent-11:null)
Unable to migrate VM(i-2-3-VM) from host(f6c18d41-fa40-440b-932d-f84bf64e5772)
due to Task failed! Task record: uuid:
4ea260eb-f447-cf59-fc0a-ab830d87f9d4
nameLabel: Async.VM.pool_migrate nameDescription:
allowedOperations: []
currentOperations: {}
created: Thu Dec 19 18:54:55 PST 2013
finished: Thu Dec 19 18:54:55 PST 2013
status: FAILURE
residentOn: com.xensource.xenapi.Host@6d9f1105
progress: 1.0
type: none/
result:
errorInfo: [VM_REQUIRES_SR,
OpaqueRef:b68a7638-2937-58ea-0f5d-52cc3e2f6905,
OpaqueRef:fb25c62b-174a-2a50-fdc0-9ff47c37170c]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
Task failed! Task record: uuid:
4ea260eb-f447-cf59-fc0a-ab830d87f9d4
nameLabel: Async.VM.pool_migrate
nameDescription:
allowedOperations: []
currentOperations: {} created: Thu Dec 19 18:54:55 PST 2013
finished: Thu Dec 19 18:54:55 PST 2013
status: FAILURE
residentOn: com.xensource.xenapi.Host@6d9f1105
progress: 1.0
type: none/
result:
errorInfo: [VM_REQUIRES_SR,
OpaqueRef:b68a7638-2937-58ea-0f5d-52cc3e2f6905,
OpaqueRef:fb25c62b-174a-2a50-fdc0-9ff47c37170c]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.checkForSuccess(CitrixResourceBase.java:3178)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.migrateVM(CitrixResourceBase.java:3324)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:2877)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:441)
at
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:55)
at
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:217)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
at
[jira] [Commented] (CLOUDSTACK-5648) CopyTemplate and CopyISO across zones fails after NFS migration to S3
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859707#comment-13859707 ] Jessica Wang commented on CLOUDSTACK-5648: -- Commit cda040af2d7b253a6f1fb5e83ef368a8ba236a6c in branch refs/heads/4.3 from Jessica Wang [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cda040a ] CLOUDSTACK-5606: UI copy template, copy ISO action when a template/ISO to be copied is not associated with a specific zone, UI does not pass sourcezoneid parameter to API. CopyTemplate and CopyISO across zones fails after NFS migration to S3 - Key: CLOUDSTACK-5648 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5648 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: ISO, Template Affects Versions: 4.3.0 Environment: Multiple zones with Xenserver host in one zone and KVM host in another 4.3 Management Server Reporter: Pavan Kumar Bandarupally Assignee: Min Chen Priority: Blocker Fix For: 4.3.0 Copying a template across zones throws an error. I have migrated NFS storage for each zone to Object store. The templates and ISOs on the NFS stores prior to migration. When we try to copy them across zones after migration to Object store, an error is thrown. 2013-12-26 19:48:01,182 DEBUG [c.c.a.ApiServlet] (catalina-exec-9:ctx-0ef95fd9) ===START=== 10.146.0.11 -- GET command=copyTemplateid=8cc2d430-6cb4-11e3-8c94-064a0c20sourcezoneid=undefineddestzoneid=1f7a3adf-d65c-44cd-9e27-97e8100779dcresponse=jsonsessionkey=mI5C%2FdjWSjiTSOQbRTodZYH4bOQ%3D_=1388048113932 2013-12-26 19:48:01,951 DEBUG [c.c.a.ApiDispatcher] (catalina-exec-9:ctx-0ef95fd9 ctx-65dcf2b1) Object entity uuid = undefined does not exist in the database. 2013-12-26 19:48:01,966 INFO [c.c.a.ApiServer] (catalina-exec-9:ctx-0ef95fd9 ctx-65dcf2b1) Unable to execute API command copytemplate due to invalid value. Invalid parameter sourcezoneid value=undefined due to incorrect long value format, or entity does not exist or due to incorrect parameter annotation for the field in api cmd class. 2013-12-26 19:48:01,970 DEBUG [c.c.a.ApiServlet] (catalina-exec-9:ctx-0ef95fd9 ctx-65dcf2b1) ===END=== 10.146.0.11 -- GET command=copyTemplateid=8cc2d430-6cb4-11e3-8c94-064a0c20sourcezoneid=undefineddestzoneid=1f7a3adf-d65c-44cd-9e27-97e8100779dcresponse=jsonsessionkey=mI5C%2FdjWSjiTSOQbRTodZYH4bOQ%3D_=1388048113932 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5648) CopyTemplate and CopyISO across zones fails after NFS migration to S3
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859708#comment-13859708 ] Jessica Wang commented on CLOUDSTACK-5648: -- Commit c1101eb695e4d1ea201ccd884a3acceb2539b201 in branch refs/heads/master from Jessica Wang [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c1101eb ] CLOUDSTACK-5606: UI copy template, copy ISO action when a template/ISO to be copied is not associated with a specific zone, UI does not pass sourcezoneid parameter to API. CopyTemplate and CopyISO across zones fails after NFS migration to S3 - Key: CLOUDSTACK-5648 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5648 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: ISO, Template Affects Versions: 4.3.0 Environment: Multiple zones with Xenserver host in one zone and KVM host in another 4.3 Management Server Reporter: Pavan Kumar Bandarupally Assignee: Min Chen Priority: Blocker Fix For: 4.3.0 Copying a template across zones throws an error. I have migrated NFS storage for each zone to Object store. The templates and ISOs on the NFS stores prior to migration. When we try to copy them across zones after migration to Object store, an error is thrown. 2013-12-26 19:48:01,182 DEBUG [c.c.a.ApiServlet] (catalina-exec-9:ctx-0ef95fd9) ===START=== 10.146.0.11 -- GET command=copyTemplateid=8cc2d430-6cb4-11e3-8c94-064a0c20sourcezoneid=undefineddestzoneid=1f7a3adf-d65c-44cd-9e27-97e8100779dcresponse=jsonsessionkey=mI5C%2FdjWSjiTSOQbRTodZYH4bOQ%3D_=1388048113932 2013-12-26 19:48:01,951 DEBUG [c.c.a.ApiDispatcher] (catalina-exec-9:ctx-0ef95fd9 ctx-65dcf2b1) Object entity uuid = undefined does not exist in the database. 2013-12-26 19:48:01,966 INFO [c.c.a.ApiServer] (catalina-exec-9:ctx-0ef95fd9 ctx-65dcf2b1) Unable to execute API command copytemplate due to invalid value. Invalid parameter sourcezoneid value=undefined due to incorrect long value format, or entity does not exist or due to incorrect parameter annotation for the field in api cmd class. 2013-12-26 19:48:01,970 DEBUG [c.c.a.ApiServlet] (catalina-exec-9:ctx-0ef95fd9 ctx-65dcf2b1) ===END=== 10.146.0.11 -- GET command=copyTemplateid=8cc2d430-6cb4-11e3-8c94-064a0c20sourcezoneid=undefineddestzoneid=1f7a3adf-d65c-44cd-9e27-97e8100779dcresponse=jsonsessionkey=mI5C%2FdjWSjiTSOQbRTodZYH4bOQ%3D_=1388048113932 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-669) Better VM Sync
[ https://issues.apache.org/jira/browse/CLOUDSTACK-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859710#comment-13859710 ] ASF subversion and git services commented on CLOUDSTACK-669: Commit 30941607188615b0ff502854c38ddac8413fd231 in branch refs/heads/4.3 from [~kelveny] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3094160 ] CLOUDSTACK-669: Finalize VM work dispatching mechanism to avoid big switch statement Better VM Sync -- Key: CLOUDSTACK-669 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-669 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Reporter: Hari Kannan Assignee: Kelven Yang Fix For: 4.3.0 https://cwiki.apache.org/confluence/display/CLOUDSTACK/VMWare+Enhancements+-+Support+for+DRS+and+VM+HA -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5192) [Automation] Test case TestSecurityGroup.test_08_security_group failed, expected exception not raised
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan updated CLOUDSTACK-5192:
Assignee: Gaurav Aradhye
[Automation] Test case TestSecurityGroup.test_08_security_group failed,
expected exception not raised
--
Key: CLOUDSTACK-5192
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5192
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.3.0
Environment: KVM automation
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Fix For: 4.3.0
Test cases
integration.component.test_project_resources.TestSecurityGroup.test_08_security_group
failed in Basic SG KVM automation run; observed below error
Error Message
Exception not raised
begin captured logging
test_08_security_group
(integration.component.test_project_resources.TestSecurityGroup): DEBUG:
Created security group with ID: 81914871-83e9-44ee-b882-ccd90226ef2e
test_08_security_group
(integration.component.test_project_resources.TestSecurityGroup): DEBUG:
Authorizing ingress rule for sec group ID:
81914871-83e9-44ee-b882-ccd90226ef2e for ssh access
test_08_security_group
(integration.component.test_project_resources.TestSecurityGroup): DEBUG:
Deployed VM (ID: 3169df57-1f93-4180-a290-7af45a5b605b) in project:
6b78292d-921d-4c14-8e6c-e0b0138e13b7
test_08_security_group
(integration.component.test_project_resources.TestSecurityGroup): DEBUG:
Deploying VM with security group: 81914871-83e9-44ee-b882-ccd90226ef2e
outside project:6b78292d-921d-4c14-8e6c-e0b0138e13b7
- end captured logging -
Stacktrace
File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
testMethod()
File
/Repo_30X/ipcl/cloudstack/test/integration/component/test_project_resources.py,
line 1320, in test_08_security_group
securitygroupids=[security_group.id],
File /usr/local/lib/python2.7/unittest/case.py, line 112, in __exit__
{0} not raised.format(exc_name))
Exception not raised
begin captured logging
test_08_security_group
(integration.component.test_project_resources.TestSecurityGroup): DEBUG:
Created security group with ID: 81914871-83e9-44ee-b882-ccd90226ef2e
test_08_security_group
(integration.component.test_project_resources.TestSecurityGroup): DEBUG:
Authorizing ingress rule for sec group ID:
81914871-83e9-44ee-b882-ccd90226ef2e for ssh access
test_08_security_group
(integration.component.test_project_resources.TestSecurityGroup): DEBUG:
Deployed VM (ID: 3169df57-1f93-4180-a290-7af45a5b605b) in project:
6b78292d-921d-4c14-8e6c-e0b0138e13b7
test_08_security_group
(integration.component.test_project_resources.TestSecurityGroup): DEBUG:
Deploying VM with security group: 81914871-83e9-44ee-b882-ccd90226ef2e
outside project:6b78292d-921d-4c14-8e6c-e0b0138e13b7
- end captured logging -
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-4490) [Automation] ssh.close not happening leading to potential failures in Netscaler test scripts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-4490: Assignee: Girish Shilamkar [Automation] ssh.close not happening leading to potential failures in Netscaler test scripts Key: CLOUDSTACK-4490 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4490 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.2.0 Environment: 4.2, Netscaler as public LB provider Reporter: Sowmya Krishnan Assignee: Girish Shilamkar Priority: Minor Fix For: 4.3.0 ssh connections through remoteSSHClient.py not closing connections causing potential failures in Netscaler scripts. This is generally not a problem with VMs since we cleanup up the account after the script ends, but with ssh to external devices like Netscaler, we end up with too many open sessions causing NS to refuse more connections. We end up with the following error in NS: Error: Connection limit to CFE exceeded (This happens to be a known issue with certain versions of NS) In any case, I think we should either fix remoteSSHClient or add an explicit close in the test scripts. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-5688) NPE when the KVM host is rebooted on the upgraded environment
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su reassigned CLOUDSTACK-5688:
-
Assignee: Kelven Yang (was: edison su)
NPE related to new vmsync
NPE when the KVM host is rebooted on the upgraded environment
--
Key: CLOUDSTACK-5688
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5688
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Upgrade
Affects Versions: 4.3.0
Environment: upgraded from 4.2.1 to 4.3
Reporter: manasaveloori
Assignee: Kelven Yang
Priority: Critical
Fix For: 4.3.0
Attachments: agent.log, management-server.rar, mysqldump421.dmp,
mysqldump43.dmp
Steps:
1.Have CS 4.2.1 with KVM host.---advanced zone.
2.Upgrade the CS to 4.3.
3.Reboot the KVM host(did not enable maintenance)
4.The KVM host is connected and then disconnecting from the CS.
Observing the following NPE in CS logs:
2013-12-31 18:03:38,127 DEBUG [c.c.r.ResourceManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Dispatching resource state event
CREATE_HOST_VO_FOR_CONNECTED to BaremetalDhcpManagerImpl
2013-12-31 18:03:38,127 DEBUG [c.c.r.ResourceManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Dispatching resource state event
CREATE_HOST_VO_FOR_CONNECTED to NetworkUsageManagerImpl
2013-12-31 18:03:38,127 DEBUG [c.c.r.ResourceManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Dispatching resource state event
CREATE_HOST_VO_FOR_CONNECTED to BaremetalPxeManagerImpl
2013-12-31 18:03:38,128 DEBUG [c.c.r.ResourceManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Dispatching resource state event
CREATE_HOST_VO_FOR_CONNECTED to PaloAltoExternalFirewallElement
2013-12-31 18:03:38,128 DEBUG [c.c.r.ResourceManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Dispatching resource state event
CREATE_HOST_VO_FOR_CONNECTED to KvmServerDiscoverer
2013-12-31 18:03:38,172 DEBUG [c.c.r.ResourceState]
(AgentConnectTaskPool-194:ctx-00137ad5) Resource state update: [id = 1; name
= RHLE64; old state = Enabled; event = InternalCreated; new state = Enabled]
2013-12-31 18:03:38,173 DEBUG [c.c.h.Status]
(AgentConnectTaskPool-194:ctx-00137ad5) Transition:[Resource state = Enabled,
Agent event = AgentConnected, Host id = 1, name = RHLE64]
2013-12-31 18:03:38,185 DEBUG [c.c.h.Status]
(AgentConnectTaskPool-194:ctx-00137ad5) Agent status update: [id = 1; name =
RHLE64; old status = Alert; event = AgentConnected; new status = Connecting;
old update count = 390; new update count = 391]
2013-12-31 18:03:38,185 DEBUG [c.c.a.m.ClusteredAgentManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) create ClusteredAgentAttache for 1
2013-12-31 18:03:38,188 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Sending Connect to listener:
XcpServerDiscoverer
2013-12-31 18:03:38,189 DEBUG [c.c.h.x.d.XcpServerDiscoverer]
(AgentConnectTaskPool-194:ctx-00137ad5) Not XenServer so moving on.
2013-12-31 18:03:38,189 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Sending Connect to listener:
HypervServerDiscoverer
2013-12-31 18:03:38,189 DEBUG [c.c.h.h.d.HypervServerDiscoverer]
(AgentConnectTaskPool-194:ctx-00137ad5) Not Hyper-V hypervisor, so moving on.
2013-12-31 18:03:38,189 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Sending Connect to listener:
StoragePoolMonitor
2013-12-31 18:03:38,202 DEBUG [c.c.s.l.StoragePoolMonitor]
(AgentConnectTaskPool-194:ctx-00137ad5) Host 1 connected, sending down
storage pool information ...
2013-12-31 18:03:38,205 DEBUG [c.c.s.StorageManagerImpl]
(AgentConnectTaskPool-194:ctx-00137ad5) Adding pool null to host 1
2013-12-31 18:03:38,215 DEBUG [c.c.a.t.Request]
(AgentConnectTaskPool-194:ctx-00137ad5) Seq 1-920387585: Sending { Cmd ,
MgmtId: 6758231703598, via: 1(RHLE64), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.ModifyStoragePoolCommand:{add:true,pool:{id:1,uuid:efbe1d5a-12c4-3a30-bef6-a219dfe81249,host:10.147.40.27,path:/export/home/manasa/primaryKVM,port:2049,type:NetworkFilesystem},localPath:/mnt//efbe1d5a-12c4-3a30-bef6-a219dfe81249,wait:0}}]
}
2013-12-31 18:03:38,220 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-6:null) Ping from 1
2013-12-31 18:03:38,228 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-6:null) Not processing PingRoutingCommand for agent
id=0; can't find the host in the DB
2013-12-31 18:03:38,233 DEBUG [c.c.a.t.Request] (AgentManager-Handler-4:null)
Seq 1-920387585: Processing: { Ans: , MgmtId: 6758231703598, via: 1, Ver:
v1, Flags: 10,
[jira] [Updated] (CLOUDSTACK-4441) test_02_deploy_ha_vm_from_iso test needs a usable ISO in the services dictionary
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan updated CLOUDSTACK-4441:
Assignee: Srikanteswararao Talluri
test_02_deploy_ha_vm_from_iso test needs a usable ISO in the services
dictionary
Key: CLOUDSTACK-4441
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4441
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Test
Affects Versions: 4.2.1
Reporter: Srikanteswararao Talluri
Assignee: Srikanteswararao Talluri
Fix For: 4.3.0
VM deployment from ISO is failing
Execute cmd: asyncquery failed, due to: {errorcode : 533, errortext :
u'Unable to create a deployment for
VM[User|03cedf48-f467-4940-99d1-ea3a35236ee2]'}
begin captured logging
testclient.testcase.TestDeployHaEnabledVM: DEBUG: Registered ISO: testISO
testclient.testcase.TestDeployHaEnabledVM: DEBUG: Deploying instance in the
account: test-7R7739
- end captured logging -
Stacktrace
Traceback (most recent call last):
File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
testMethod()
File /root/cloudstack/test/integration/component/test_stopped_vm.py, line
965, in test_02_deploy_ha_vm_from_iso
startvm=True
File
/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py, line
388, in create
virtual_machine = apiclient.deployVirtualMachine(cmd, method=method)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 1177, in deployVirtualMachine
response = self.connection.marvin_request(command,
response_type=response, method=method)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line
230, in marvin_request
response = self.poll(asyncJobId, response_type)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line
91, in poll
asyncquery, asyncResonse.jobresult)
cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode :
533, errortext : u'Unable to create a deployment for
VM[User|03cedf48-f467-4940-99d1-ea3a35236ee2]'}
begin captured logging
testclient.testcase.TestDeployHaEnabledVM: DEBUG: Registered ISO: testISO
testclient.testcase.TestDeployHaEnabledVM: DEBUG: Deploying instance in the
account: test-7R7739
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-4340) [Automation] Test cases TestVMLifeCycleStoppedVPCVR.test_07_migrate_instance_in_network failed during migration
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan updated CLOUDSTACK-4340:
Assignee: Rayees Namathponnan
[Automation] Test cases
TestVMLifeCycleStoppedVPCVR.test_07_migrate_instance_in_network failed during
migration
---
Key: CLOUDSTACK-4340
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4340
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API, Automation
Affects Versions: 4.2.0
Environment: Automation
4.2
Reporter: Rayees Namathponnan
Assignee: Rayees Namathponnan
Fix For: 4.3.0
Attachments: management-server.rar
Test cases
integration.component.test_vpc_vm_life_cycle.TestVMLifeCycleStoppedVPCVR.test_07_migrate_instance_in_network
failed with latest build, failed during migration;
observed below error in automation log
--
Failed to migrate instance, Execute cmd: asyncquery failed, due to:
{errorcode : 530, errortext : u'Cannot migrate VM, VM is already presnt on
this host, please specify valid destination host to migrate the VM'}
begin captured logging
testclient.testcase.TestVMLifeCycleStoppedVPCVR: DEBUG: Check the status of
VPC virtual router
testclient.testcase.TestVMLifeCycleStoppedVPCVR: DEBUG: Checking if the host
is available for migration?
testclient.testcase.TestVMLifeCycleStoppedVPCVR: DEBUG: Validating if the
network rules work properly or not?
testclient.testcase.TestVMLifeCycleStoppedVPCVR: DEBUG: Checking if we can
SSH into VM_1 through 10.223.122.78?
paramiko.transport: DEBUG: starting thread (client mode): 0xad8f910L
paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_4.3)
paramiko.transport: DEBUG: kex algos:['diffie-hellman-group-exchange-sha1',
'diffie-hellman-group14-sha1', 'diffie-hellman-group1-sha1'] server
key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-cbc', '3des-cbc',
'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour',
'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr',
'aes192-ctr', 'aes256-ctr'] server encrypt:['aes128-cbc', '3des-cbc',
'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour',
'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr',
'aes192-ctr', 'aes256-ctr'] client mac:['hmac-md5', 'hmac-sha1',
'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96',
'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160',
'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client
compress:['none', 'z...@openssh.com'] server compress:['none',
'z...@openssh.com'] client lang:[''] server lang:[''] kex follows?False
paramiko.transport: DEBUG: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr
paramiko.transport: DEBUG: using kex diffie-hellman-group1-sha1; server key
type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local
hmac-sha1, remote hmac-sha1; compression: local none, remote none
paramiko.transport: DEBUG: Switch to new keys ...
paramiko.transport: DEBUG: Adding ssh-rsa host key for 10.223.122.78:
0f8b3ff9dc4dce10340227dab3cac032
paramiko.transport: DEBUG: Trying discovered key
76be480fa6b8ad3b78082d6d19e4ee44 in /root/.ssh/id_rsa
paramiko.transport: DEBUG: userauth is OK
paramiko.transport: INFO: Authentication (publickey) failed.
paramiko.transport: DEBUG: userauth is OK
paramiko.transport: INFO: Authentication (password) successful!
sshClient: DEBUG: SSH connect: root@10.223.122.78 with passwd password
paramiko.transport: DEBUG: EOF in transport thread
testclient.testcase.TestVMLifeCycleStoppedVPCVR: DEBUG: SSH into VM is
successfully
testclient.testcase.TestVMLifeCycleStoppedVPCVR: DEBUG: Verifying if we can
ping to outside world from VM?
paramiko.transport: DEBUG: [chan 1] Max packet in: 34816 bytes
paramiko.transport: DEBUG: [chan 1] Max packet out: 32768 bytes
paramiko.transport: INFO: Secsh channel 1 opened.
paramiko.transport: DEBUG: [chan 1] Sesch channel 1 request ok
paramiko.transport: DEBUG: [chan 1] EOF received (1)
sshClient: DEBUG: {Cmd: ping -c 1 www.google.com via Host: 10.223.122.78}
{returns: ['PING www.google.com (74.125.239.145) 56(84) bytes of data.', '64
bytes from nuq05s02-in-f17.1e100.net (74.125.239.145): icmp_seq=1 ttl=48
time=5.49 ms', '', '--- www.google.com ping statistics ---', '1 packets
transmitted, 1 received, 0% packet loss, time 0ms', 'rtt min/avg/max/mdev =
5.497/5.497/5.497/0.000 ms']}
[jira] [Assigned] (CLOUDSTACK-5557) [UI] Invalid UI for Network-Guest Network-AnyVPCN/w.Able to see all configuration(FW/PF/LB)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang reassigned CLOUDSTACK-5557: Assignee: manasaveloori (was: Jessica Wang) manasaveloori, You only provided observation (i.e. incorrect behavior). You didn't provide expected result (i.e. correct behavior). Please provide: (1) expected result (i.e. correct behavior) (2) database dump OR your URL Jessica [UI] Invalid UI for Network-Guest Network-AnyVPCN/w.Able to see all configuration(FW/PF/LB) --- Key: CLOUDSTACK-5557 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5557 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: manasaveloori Assignee: manasaveloori Priority: Critical Fix For: 4.3.0 Attachments: VPCTierNW.jpg Steps: 1. Create a VPC. 2. Create a tier network and VM using that network. 3. Acquire IP and enable PF/LB rule. Obseravation: Under Network-GuestNetworks-Click on VPC tier network-IPaddresses. Able to view the IP address and all the configurable items in UI(firewall,PF,LB)like for normal networks. Also user is allowed to configure the rules which results in exception Attaching the SC -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-4339) [Automation] Test case test_vpc_network.py:TestVPCNetworkGc failed to cleanup vpc offering
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan closed CLOUDSTACK-4339.
---
Resolution: Cannot Reproduce
this issue not found in latest runs
[Automation] Test case test_vpc_network.py:TestVPCNetworkGc failed to cleanup
vpc offering
---
Key: CLOUDSTACK-4339
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4339
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.2.0
Environment: Automation
Reporter: Rayees Namathponnan
Fix For: 4.3.0
WE may no need to delete service offering as part of cleanup
Warning: Exception during cleanup : Execute cmd: asyncquery failed, due to:
{errorcode : 530, errortext : uCan't delete vpc offering 103 as its used by
1 vpcs. To make the network offering unavaiable, disable it}
Stacktrace
Traceback (most recent call last):
File /usr/local/lib/python2.7/site-packages/nose/suite.py, line 227, in
run
self.tearDown()
File /usr/local/lib/python2.7/site-packages/nose/suite.py, line 350, in
tearDown
self.teardownContext(ancestor)
File /usr/local/lib/python2.7/site-packages/nose/suite.py, line 366, in
teardownContext
try_run(context, names)
File /usr/local/lib/python2.7/site-packages/nose/util.py, line 469, in
try_run
return func()
File
/Repo_30X/ipcl/cloudstack/test/integration/component/test_vpc_network.py,
line 2256, in tearDownClass
raise Exception(Warning: Exception during cleanup : %s % e)
Exception: Warning: Exception during cleanup : Execute cmd: asyncquery
failed, due to: {errorcode : 530, errortext : uCan't delete vpc offering 103
as its used by 1 vpcs. To make the network offering unavaiable, disable it}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-4284) Add test for EIP category : enable/disable staticNAT on destroyed VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-4284: Assignee: Gaurav Aradhye Add test for EIP category : enable/disable staticNAT on destroyed VM Key: CLOUDSTACK-4284 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4284 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Environment: commit id # e6d03f2322822aee331a1a2aa60190c4c755c402 Reporter: venkata swamybabu budumuru Assignee: Gaurav Aradhye Fix For: 4.3.0 Steps to be added for the test : Steps to reproduce: 1. Have latest CloudStack setup with at least one EIP/ELB enabled zone. 2. Login as non-ROOT domain user, deploy at least one VM Observations: (i) The above action will associate an EIP with is_system=1 (3) Acquire an additional public ip and enable static NAT on this. Observations: (ii) This will release the is_system=1 ip (The ip mentioned in observation (i)) and enables staticNAT on the acquired ip with is_system set to 0 (4) Destroy the userVM (5) Try to disableStaticNat before the above destroyed VM moves to expunging. As of now the 5th step is failing. This bug is being tracked under https://issues.apache.org/jira/browse/CLOUDSTACK-4206. This is test is good candidate for automation. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-4283) [Marvin][Integration][component] Add tests for multiple shared networks with different VLAN but same subnet
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-4283: Assignee: Girish Shilamkar [Marvin][Integration][component] Add tests for multiple shared networks with different VLAN but same subnet --- Key: CLOUDSTACK-4283 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4283 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Environment: commit id # e6d03f2322822aee331a1a2aa60190c4c755c402 Reporter: venkata swamybabu budumuru Assignee: Girish Shilamkar Fix For: 4.3.0 Steps to be added for Test : Steps to reproduce: 1. Have latest CloudStack setup with at least 1 advanced zone. 2. Create a shared network with the following details using the defaultSharedNetworkOffering VLAN : 1200 gateway : 1.1.1.1 startip : 1.1.1.100 endip : 1.1.1.110 3. Create another shared network with different VLAN but with same above subnet VLAN : 2361 gateway : 1.1.1.1 startip : 1.1.1.100 endip : 1.1.1.110 The above test should succeed. There is already bug filed for this (https://issues.apache.org/jira/browse/CLOUDSTACK-4282) where it is currently not allowing. This is good candidate for automation. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-4261) [Automaiton] TestVPCNetworkUpgrade.test_01_network_services_upgrade failed to upgrade the network offering
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan closed CLOUDSTACK-4261.
---
Resolution: Cannot Reproduce
not found this issue in latest runs
[Automaiton] TestVPCNetworkUpgrade.test_01_network_services_upgrade failed to
upgrade the network offering
--
Key: CLOUDSTACK-4261
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4261
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.2.0
Environment: Automation
Reporter: Rayees Namathponnan
Fix For: 4.3.0
TestVPCNetworkUpgrade.test_01_network_services_upgrade failed to upgrade the
network offering
Observed below error in log
Error Message
failed to upgrade the network offering- Execute cmd: asyncquery failed, due
to: {errorcode : 530, errortext : u'Failed to implement network (with
specified id) elements and resources as a part of network update'}
begin captured logging
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Creating a VPC offering..
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Check if the VPC offering
is created successfully?
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: VPC offering is created
successfully - VPC off-D6D8U7
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Enabling the VPC offering
created
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: creating a VPC network in
the account: test-SIDD23
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Check if the VPC network is
created successfully?
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: VPC network validated -
TestVPC-ZVCYT5
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Creating network with
network offering: 68270510-b671-4c67-99d6-038825ddab10
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Created network with ID:
f355327c-4d8e-44b3-a4e5-52f615a74f24
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: deploying VMs in network:
Test Network
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Deployed VM in network:
f355327c-4d8e-44b3-a4e5-52f615a74f24
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Deployed another VM in
network: f355327c-4d8e-44b3-a4e5-52f615a74f24
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Associating public IP for
network: Test Network
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Associated 10.223.122.98
with network f355327c-4d8e-44b3-a4e5-52f615a74f24
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Creating LB rule for IP
address: 10.223.122.98
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Adding virtual machines
1aa01bbe-2a3a-4c4f-87fe-5b14b052e8dd and 89c0a243-3797-4129-8dbb-e2ad91227f75
to LB rule
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Associating public IP for
network: Test Network
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Associated 10.223.122.95
with network f355327c-4d8e-44b3-a4e5-52f615a74f24
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Enabling static NAT for IP:
10.223.122.95
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Static NAT enabled for IP:
10.223.122.95
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Adding NetwrokACl rules to
make PF and LB accessible
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Adding Egress rules to
network Test Network to access internet
testclient.testcase.TestVPCNetworkUpgrade: DEBUG: Checking if we can SSH into
VM_1? - IP: 10.223.122.98
paramiko.transport: DEBUG: starting thread (client mode): 0x49bdd90L
paramiko.transport: ERROR: Exception: Error reading SSH protocol banner
paramiko.transport: ERROR: Traceback (most recent call last):
paramiko.transport: ERROR: File
/usr/local/lib/python2.7/site-packages/paramiko/transport.py, line 1555, in
run
paramiko.transport: ERROR: self._check_banner()
paramiko.transport: ERROR: File
/usr/local/lib/python2.7/site-packages/paramiko/transport.py, line 1681, in
_check_banner
paramiko.transport: ERROR: raise SSHException('Error reading SSH protocol
banner' + str(x))
paramiko.transport: ERROR: SSHException: Error reading SSH protocol banner
paramiko.transport: ERROR:
paramiko.transport: DEBUG: starting thread (client mode): 0x49c08d0L
paramiko.transport: ERROR: Exception: Error reading SSH protocol banner
paramiko.transport: ERROR: Traceback (most recent call last):
paramiko.transport: ERROR: File
/usr/local/lib/python2.7/site-packages/paramiko/transport.py, line 1555, in
run
paramiko.transport: ERROR: self._check_banner()
paramiko.transport: ERROR: File
[jira] [Commented] (CLOUDSTACK-5329) MigrateVMCmd on stopped VM is failing with NPE when trying to migrate to zone-wide-primary storage.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859736#comment-13859736
]
ASF subversion and git services commented on CLOUDSTACK-5329:
-
Commit 23841e3369877e404e4c7f4000a1ee540d1dcfa8 in branch refs/heads/4.3 from
[~zhou2324]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=23841e3 ]
CLOUDSTACK-5329: fix NPE, in case of zone wide primary storage
MigrateVMCmd on stopped VM is failing with NPE when trying to migrate to
zone-wide-primary storage.
---
Key: CLOUDSTACK-5329
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5329
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller
Affects Versions: 4.3.0
Reporter: manasaveloori
Assignee: edison su
Priority: Critical
Fix For: 4.3.0
Attachments: management-server.rar
Steps:
1.Have a CS with multiple zone wide primary storage using KVM host.
2.Deploy a VM and stop it.
3.Now goto Migrate VM.Drop down lists the available primary storage to
migrate.
4.Now migrate the VM to another zone wide primary storage.
Observation:
Observed the following NPE:
2013-12-02 21:16:04,537 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-49:ctx-63bbd88b) Executing AsyncJobVO {id:91, userId: 2,
accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdInfo:
{response:json,sessionkey:bETJCcI/wg7sd2gWxD7zzG5wotQ\u003d,virtualmachineid:d22ce820-339c-4c80-a16b-dd21bd7a8804,cmdEventType:VM.MIGRATE,ctxUserId:2,storageid:b01ec063-b9c5-3685-b5ea-c816554f1ffe,httpmethod:GET,_:1385979761075,ctxAccountId:2,ctxStartEventId:293},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 6758231703598, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2013-12-02 21:16:04,562 ERROR [c.c.a.ApiAsyncJobDispatcher]
(Job-Executor-49:ctx-63bbd88b) Unexpected exception while executing
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd
java.lang.NullPointerException
at
com.cloud.vm.UserVmManagerImpl.vmStorageMigration(UserVmManagerImpl.java:3954)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy169.vmStorageMigration(Unknown Source)
at
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd.execute(MigrateVMCmd.java:150)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161)
at
com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109)
at
com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:520)
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
[jira] [Resolved] (CLOUDSTACK-5329) MigrateVMCmd on stopped VM is failing with NPE when trying to migrate to zone-wide-primary storage.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su resolved CLOUDSTACK-5329.
---
Resolution: Fixed
MigrateVMCmd on stopped VM is failing with NPE when trying to migrate to
zone-wide-primary storage.
---
Key: CLOUDSTACK-5329
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5329
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller
Affects Versions: 4.3.0
Reporter: manasaveloori
Assignee: edison su
Priority: Critical
Fix For: 4.3.0
Attachments: management-server.rar
Steps:
1.Have a CS with multiple zone wide primary storage using KVM host.
2.Deploy a VM and stop it.
3.Now goto Migrate VM.Drop down lists the available primary storage to
migrate.
4.Now migrate the VM to another zone wide primary storage.
Observation:
Observed the following NPE:
2013-12-02 21:16:04,537 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-49:ctx-63bbd88b) Executing AsyncJobVO {id:91, userId: 2,
accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdInfo:
{response:json,sessionkey:bETJCcI/wg7sd2gWxD7zzG5wotQ\u003d,virtualmachineid:d22ce820-339c-4c80-a16b-dd21bd7a8804,cmdEventType:VM.MIGRATE,ctxUserId:2,storageid:b01ec063-b9c5-3685-b5ea-c816554f1ffe,httpmethod:GET,_:1385979761075,ctxAccountId:2,ctxStartEventId:293},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 6758231703598, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2013-12-02 21:16:04,562 ERROR [c.c.a.ApiAsyncJobDispatcher]
(Job-Executor-49:ctx-63bbd88b) Unexpected exception while executing
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd
java.lang.NullPointerException
at
com.cloud.vm.UserVmManagerImpl.vmStorageMigration(UserVmManagerImpl.java:3954)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy169.vmStorageMigration(Unknown Source)
at
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd.execute(MigrateVMCmd.java:150)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161)
at
com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109)
at
com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:520)
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
[jira] [Updated] (CLOUDSTACK-5656) UI shows PF,LB,firewall,static NAT rule operations success on non upgraded VR but logs show VR requires upgrade.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jessica Wang updated CLOUDSTACK-5656:
-
manasaveloori,
This is an API bug, NOT an UI bug.
UI just shows whatever API returns.
When API returns success, UI shows success.
When API returns error, UI shows error.
In this case, UI shows success because API returns success.
so, createFirewallRule API has to be fixed to return error instead of success
in this scenario.
I'll change component from UI to API.
Jessica
UI shows PF,LB,firewall,static NAT rule operations success on non upgraded VR
but logs show VR requires upgrade.
Key: CLOUDSTACK-5656
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5656
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API
Affects Versions: 4.3.0
Environment: 2.2.14 to 4.3 upgrade
Reporter: manasaveloori
Assignee: Jessica Wang
Priority: Critical
Fix For: 4.3.0
1. Have CS 2.2.14 with xen 5.6sp2.
2.Deploy some VRS.
3. Upgrade to 4.3.
4. Perform any operation which sends commands to non upgraded VR like
applying static nat,firewall rules,PF etc.
Observation:
UI shows all the operations as success but in logs we can see the messages as
2013-12-27 15:04:31,326 DEBUG [c.c.a.ApiServlet]
(catalina-exec-12:ctx-c0ac9a16 ctx-ed5f06a6) ===END=== 10.252.192.34 -- GET
command=createFirewallRuleresponse=jsonsessionkey=DE4U5L%2FWnxa60eF2LoJPuY6FVHw%3Dcidrlist=0.0.0.0%2F0protocol=tcpstartport=1endport=65535ipaddressid=4_=1388136871014
2013-12-27 15:04:31,354 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Applying ip association in
network Ntwk[205|Guest|6]
2013-12-27 15:04:31,354 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Router r-6-VM requires upgrade,
so not sending apply ip association commands to the backend
2013-12-27 15:04:31,362 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Applying firewall rules in
network Ntwk[205|Guest|6]
2013-12-27 15:04:31,363 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Router r-6-VM requires upgrade,
so not sending apply firewall rules commands to the backend
2013-12-27 15:04:31,430 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Complete async job-24, jobStatus:
SUCCEEDED, resultCode: 0, result:
org.apache.cloudstack.api.response.FirewallResponse/firewallrule/{id:b772c804-09cc-4eaa-96a3-61adcf1cb242,protocol:tcp,startport:1,endport:65535,ipaddressid:4,networkid:205,ipaddress:10.147.47.6,state:Active,cidrlist:,tags:[]}
2013-12-27 15:04:31,483 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-18:ctx-0bb79ed5) Done executing
org.apache.cloudstack.api.command.user.firewall.CreateFirewallRuleCmd for
job-24
UI shoul aslo show the message as Router requires upgrade and the action
should fail.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-5656) UI shows PF,LB,firewall,static NAT rule operations success on non upgraded VR but logs show VR requires upgrade.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jessica Wang reassigned CLOUDSTACK-5656:
Assignee: Animesh Chaturvedi (was: Jessica Wang)
Animesh,
This is an API bug, not UI bug.
Please assign it to an API developer.
Jessica
UI shows PF,LB,firewall,static NAT rule operations success on non upgraded VR
but logs show VR requires upgrade.
Key: CLOUDSTACK-5656
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5656
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API
Affects Versions: 4.3.0
Environment: 2.2.14 to 4.3 upgrade
Reporter: manasaveloori
Assignee: Animesh Chaturvedi
Priority: Critical
Fix For: 4.3.0
1. Have CS 2.2.14 with xen 5.6sp2.
2.Deploy some VRS.
3. Upgrade to 4.3.
4. Perform any operation which sends commands to non upgraded VR like
applying static nat,firewall rules,PF etc.
Observation:
UI shows all the operations as success but in logs we can see the messages as
2013-12-27 15:04:31,326 DEBUG [c.c.a.ApiServlet]
(catalina-exec-12:ctx-c0ac9a16 ctx-ed5f06a6) ===END=== 10.252.192.34 -- GET
command=createFirewallRuleresponse=jsonsessionkey=DE4U5L%2FWnxa60eF2LoJPuY6FVHw%3Dcidrlist=0.0.0.0%2F0protocol=tcpstartport=1endport=65535ipaddressid=4_=1388136871014
2013-12-27 15:04:31,354 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Applying ip association in
network Ntwk[205|Guest|6]
2013-12-27 15:04:31,354 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Router r-6-VM requires upgrade,
so not sending apply ip association commands to the backend
2013-12-27 15:04:31,362 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Applying firewall rules in
network Ntwk[205|Guest|6]
2013-12-27 15:04:31,363 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Router r-6-VM requires upgrade,
so not sending apply firewall rules commands to the backend
2013-12-27 15:04:31,430 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Complete async job-24, jobStatus:
SUCCEEDED, resultCode: 0, result:
org.apache.cloudstack.api.response.FirewallResponse/firewallrule/{id:b772c804-09cc-4eaa-96a3-61adcf1cb242,protocol:tcp,startport:1,endport:65535,ipaddressid:4,networkid:205,ipaddress:10.147.47.6,state:Active,cidrlist:,tags:[]}
2013-12-27 15:04:31,483 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-18:ctx-0bb79ed5) Done executing
org.apache.cloudstack.api.command.user.firewall.CreateFirewallRuleCmd for
job-24
UI shoul aslo show the message as Router requires upgrade and the action
should fail.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (CLOUDSTACK-5557) [UI] Invalid UI for Network-Guest Network-AnyVPCN/w.Able to see all configuration(FW/PF/LB)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859728#comment-13859728 ] Jessica Wang edited comment on CLOUDSTACK-5557 at 12/31/13 10:12 PM: - manasaveloori, You only provided observation (i.e. incorrect behavior). You didn't provide expected result (i.e. correct behavior). Please provide: (1) expected result (i.e. correct behavior) (2) database dump (3) your URL (the URL the bug can be seen) Either (2) or (3) needs to be provided. It will be even better if you can provide both (2) and (3). Jessica was (Author: jessicawang): manasaveloori, You only provided observation (i.e. incorrect behavior). You didn't provide expected result (i.e. correct behavior). Please provide: (1) expected result (i.e. correct behavior) (2) database dump OR your URL Jessica [UI] Invalid UI for Network-Guest Network-AnyVPCN/w.Able to see all configuration(FW/PF/LB) --- Key: CLOUDSTACK-5557 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5557 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: manasaveloori Assignee: manasaveloori Priority: Critical Fix For: 4.3.0 Attachments: VPCTierNW.jpg Steps: 1. Create a VPC. 2. Create a tier network and VM using that network. 3. Acquire IP and enable PF/LB rule. Obseravation: Under Network-GuestNetworks-Click on VPC tier network-IPaddresses. Able to view the IP address and all the configurable items in UI(firewall,PF,LB)like for normal networks. Also user is allowed to configure the rules which results in exception Attaching the SC -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5684) kvm - Not able to live migrate Vms outside of cloudstack because of vnc ipaddress being tied up to 1 kvm host.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su resolved CLOUDSTACK-5684. --- Resolution: Won't Fix It's by design, community changes the vnc listening address to private address of kvm host instead of wildcard *, to make it safer. Our kvm agent code can workaround this issue, by dynamically change the vnc listening address during the vm migration. So there should not be a problem if the vm is migrated through cloudstack UI. But it may have a problem when migrating vm out-of-band. kvm - Not able to live migrate Vms outside of cloudstack because of vnc ipaddress being tied up to 1 kvm host. -- Key: CLOUDSTACK-5684 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5684 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: edison su Priority: Critical Fix For: 4.3.0 kvm - Not able to live migrate Vms outside of cloudstack because of vnc ipaddress being tied up to 1 kvm host. Steps to reproduce the problem: Advanced zone set up with 2 KVM hosts. Deploy few Vms in both hosts. Try to live migrate Vm outside of cloudplatform. Live migration fails : root@Rack3Host14 CloudPlatform-4.3-997-rhel6.3]# virsh migrate --live i-3-5-VM qemu+ssh://10.223.58.130/system The authenticity of host '10.223.58.130 (10.223.58.130)' can't be established. RSA key fingerprint is fb:07:f7:7e:84:a9:97:7c:3d:35:2a:9e:72:43:75:c5. Are you sure you want to continue connecting (yes/no)? yes root@10.223.58.130's password: error: Cannot recv data: Warning: Permanently added '10.223.58.130' (RSA) to the list of known hosts. : Connection reset by peer3.58.130 [root@Rack3Host14 CloudPlatform-4.3-997-rhel6.3]# When I removed the ipadress entry for the VNC from the Vms , we are able to live migrate the Vms successfully. To enable live migration: graphics type='vnc' port='5905' autoport='yes'/ Current vnc port entries : graphics type='vnc' port='5901' autoport='yes' listen='10.223.58.130' listen type='address' address='10.223.58.130'/ /graphics -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5697) multiple public ranges don't work with vxlan on KVM
Marcus Sorensen created CLOUDSTACK-5697: --- Summary: multiple public ranges don't work with vxlan on KVM Key: CLOUDSTACK-5697 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5697 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.3.0 Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: 4.3.0 You can add multiple VLAN/VNI network ranges to your public traffic in cloudstack, these don't work with VXLAN on KVM. In other words, only guest traffic type creates VNI interfaces and bridges. Tested a solution and will push shortly. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5551) [UI] Search not working in account's setting page
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jessica Wang updated CLOUDSTACK-5551:
-
Component/s: (was: UI)
API
API developer,
listConfigurations API wrongly ignores name parameter when accountid
parameter is specified.
e.g. pass both name=aaa and accountid=8eb12cfe-5ec9-11e3-80db-3c970e739c3e
to listConfigurations API,
API response wrongly includes entries whose name does NOT contain aaa:
http://10.215.3.26:8080/client/api?command=listConfigurationsaccountid=8eb12cfe-5ec9-11e3-80db-3c970e739c3eresponse=jsonsessionkey=EKf2AvkPyPqv39X52Z6RvHR7zfs%3Dname=aaalistAll=truepage=1pagesize=20_=1388529120930
{
listconfigurationsresponse: {
count: 9,
configuration: [
{
category: Advanced,
name: allow.public.user.templates,
value: true,
scope: account,
description: If false, users will not be able to create
public templates.
},
{
category: Network,
name: remote.access.vpn.client.iprange,
value: 10.1.2.1-10.1.2.8,
scope: account,
description: The range of ips to be allocated to remote
access vpn clients. The first ip in the range is used by the VPN server
},
{
category: Advanced,
name: use.system.public.ips,
value: true,
scope: account,
description: If true, when account has dedicated public ip
range(s), once the ips dedicated to the account have been consumed ips will be
acquired from the system pool
},
{
category: Advanced,
name: use.system.guest.vlans,
value: true,
scope: account,
description: If true, when account has dedicated guest vlan
range(s), once the vlans dedicated to the account have been consumed vlans will
be allocated from the system pool
},
{
category: Advanced,
name: use.system.guest.vlans,
value: true,
scope: account,
description: If true, when account has dedicated guest vlan
range(s), once the vlans dedicated to the account have been consumed vlans will
be allocated from the system pool
},
{
category: Advanced,
name: use.system.guest.vlans,
value: true,
scope: account,
description: If true, when account has dedicated guest vlan
range(s), once the vlans dedicated to the account have been consumed vlans will
be allocated from the system pool
},
{
category: Advanced,
name: use.system.guest.vlans,
value: true,
scope: account,
description: If true, when account has dedicated guest vlan
range(s), once the vlans dedicated to the account have been consumed vlans will
be allocated from the system pool
},
{
category: Advanced,
name: use.system.guest.vlans,
value: true,
scope: account,
description: If true, when account has dedicated guest vlan
range(s), once the vlans dedicated to the account have been consumed vlans will
be allocated from the system pool
},
{
category: Advanced,
name: use.system.guest.vlans,
value: true,
scope: account,
description: If true, when account has dedicated guest vlan
range(s), once the vlans dedicated to the account have been consumed vlans will
be allocated from the system pool
}
]
}
}
[UI] Search not working in account's setting page
--
Key: CLOUDSTACK-5551
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5551
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API
Affects Versions: 4.3.0
Environment: branch 4.3
Reporter: Rayees Namathponnan
Assignee: Jessica Wang
Priority: Critical
Fix For: 4.3.0
Steps to reproduce
Step 1 : Install Management server with 4.3 build
Step 2 : create an account
Step 3 : select the account - select setting
Step 4 : In search box, enter
Expected Result
Nothing should be displayed in search result
Actual Result
Search is not working here, same content before search displayed
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-5551) [UI] Search not working in account's setting page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang reassigned CLOUDSTACK-5551: Assignee: Animesh Chaturvedi (was: Jessica Wang) Animesh, This is an API bug, NOT an UI bug. (I've written down what's wrong with listConfigurations API) Please assign it to an API developer. Jessica [UI] Search not working in account's setting page -- Key: CLOUDSTACK-5551 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5551 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.3.0 Environment: branch 4.3 Reporter: Rayees Namathponnan Assignee: Animesh Chaturvedi Priority: Critical Fix For: 4.3.0 Steps to reproduce Step 1 : Install Management server with 4.3 build Step 2 : create an account Step 3 : select the account - select setting Step 4 : In search box, enter Expected Result Nothing should be displayed in search result Actual Result Search is not working here, same content before search displayed -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5698) [UI] search not working in Router - Network ACL lists panel
Rayees Namathponnan created CLOUDSTACK-5698: --- Summary: [UI] search not working in Router - Network ACL lists panel Key: CLOUDSTACK-5698 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5698 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Priority: Critical Fix For: 4.3.0 Steps to reproduce 1) Create VPC 2) Add few Network ACL list 3) Select Network ACL list and search with some junk characters Expected result Nothing should be displayed in search Actual result Search is not working here -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5680) Contrail:MS:API: Contrail DHCP fails with exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859764#comment-13859764 ] Vinod Nair commented on CLOUDSTACK-5680: The root cause of the issue to some extent is because of CLOUDSTACK-5681. If you manually ( using mysql) update CIDR in the networks table without specifying a gateway you will run into this issue.. Contrail:MS:API: Contrail DHCP fails with exception --- Key: CLOUDSTACK-5680 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5680 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Contrail, Management Server Affects Versions: 4.2.0 Environment: Contrail Reporter: Parth Jagirdar Instance creation succeeds but IP doesn't get assigned. 2013-12-27 17:00:53,915 INFO [contrail.api.ApiConnector] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) Response Status: HTTP/1.1 503 Service Unavailable 2013-12-27 17:00:53,915 ERROR [contrail.api.ApiConnector] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) create api request failed: Service Unavailable 2013-12-27 17:00:53,915 ERROR [contrail.api.ApiConnector] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) Failure message: Virtual-Network(default-domain:default-project:contrail) has no defined subnet(s) 2013-12-27 17:00:53,916 WARN [contrail.management.ContrailGuru] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) virtual-machine update com.cloud.exception.InternalErrorException: Unable to create instance-ip i-2-3036-VM-0 at net.juniper.contrail.model.InstanceIpModel.update(InstanceIpModel.java:99) at net.juniper.contrail.model.VMInterfaceModel.update(VMInterfaceModel.java:227) at net.juniper.contrail.model.VirtualMachineModel.update(VirtualMachineModel.java:327) at net.juniper.contrail.management.ContrailGuru.reserve(ContrailGuru.java:228) at com.cloud.network.NetworkManagerImpl.prepareNic(NetworkManagerImpl.java:2157) at com.cloud.network.NetworkManagerImpl.prepare(NetworkManagerImpl.java:2127) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:886) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3406) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2966) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2952) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420) 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 java.util.concurrent.FutureTask.run(FutureTask.java:166) 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:724) 2013-12-27 17:00:53,920 DEBUG [cloud.network.NetworkManagerImpl] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) Changing active number of nics for network id=215 on 1 2013-12-27 17:00:53,930 DEBUG [cloud.network.NetworkManagerImpl] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) Asking ContrailElementImpl_EnhancerByCloudStack_749d004 to prepare for Nic[12138-3036-c0945234-c3a2-451b-ae04-f465478eee1e-null] 2013-12-27 17:00:53,930 DEBUG [contrail.management.ContrailElement] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) NetworkElement prepare: contrail, traffic type: Guest 2013-12-27 17:00:53,930 DEBUG [contrail.management.ContrailElement] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) ignore network contrail 2013-12-27 17:00:53,936 DEBUG [cloud.network.NetworkModelImpl] (Job-Executor-24:job-17 = [ 5316fcdb-7550-41ea-94eb-7718d0c80ab9 ]) Service SecurityGroup is not
[jira] [Commented] (CLOUDSTACK-5697) multiple public ranges don't work with vxlan on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859767#comment-13859767 ] ASF subversion and git services commented on CLOUDSTACK-5697: - Commit 83f1f68408b3b9da9eac096d95638ee13aabab30 in branch refs/heads/4.3 from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=83f1f68 ] CLOUDSTACK-5697 - public ip ranges should allow VNI rather than only working with untagged multiple public ranges don't work with vxlan on KVM --- Key: CLOUDSTACK-5697 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5697 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.3.0 Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: 4.3.0 You can add multiple VLAN/VNI network ranges to your public traffic in cloudstack, these don't work with VXLAN on KVM. In other words, only guest traffic type creates VNI interfaces and bridges. Tested a solution and will push shortly. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5697) multiple public ranges don't work with vxlan on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Sorensen resolved CLOUDSTACK-5697. - Resolution: Fixed multiple public ranges don't work with vxlan on KVM --- Key: CLOUDSTACK-5697 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5697 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.3.0 Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: 4.3.0 You can add multiple VLAN/VNI network ranges to your public traffic in cloudstack, these don't work with VXLAN on KVM. In other words, only guest traffic type creates VNI interfaces and bridges. Tested a solution and will push shortly. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5697) multiple public ranges don't work with vxlan on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Sorensen closed CLOUDSTACK-5697. --- multiple public ranges don't work with vxlan on KVM --- Key: CLOUDSTACK-5697 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5697 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.3.0 Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: 4.3.0 You can add multiple VLAN/VNI network ranges to your public traffic in cloudstack, these don't work with VXLAN on KVM. In other words, only guest traffic type creates VNI interfaces and bridges. Tested a solution and will push shortly. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
