[jira] [Updated] (CLOUDSTACK-9012) coreos test case automation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-9012: --- Issue Type: Test (was: Bug) > coreos test case automation > --- > > Key: CLOUDSTACK-9012 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9012 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: shweta agarwal > > Automated a full scenario of coreos guest OS support: > it includes registering coreos templates present at > http://dl.openvm.eu/cloudstack/coreos/x86_64/ > 1. based on hypervisor types of zone > 2. creating ssh key pair > 3. creating a sample user data > 4. creating a coreos virtual machine using this ssh keypair and userdata > 5. verifying ssh access to coreo os machine using keypair and core username > 6. verifying userdata is applied on virtual machine and the service asked in > sample data is actually running > 7. Verifying userdata in router vm as well -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9179) Verify register ssh key pair can not be used to register same ssh keys with different name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-9179: --- Issue Type: Test (was: Bug) > Verify register ssh key pair can not be used to register same ssh keys with > different name > -- > > Key: CLOUDSTACK-9179 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9179 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.6.0 >Reporter: shweta agarwal > Fix For: 4.6.1 > > > Verify register ssh key pair can be used to register same ssh keys with > different name > there were issues in list virtual machine API when user were registering > same ssh key with different key pair name and Creating VM with different > key pair. List virtual machine was returning same key pair for both the vm > though two different key pair name was used to deploy them . So now we block > registering same ssh key using two different key pair name . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9177) Atomation of Usage events for "uploadedVolume"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-9177: --- Issue Type: Test (was: Bug) > Atomation of Usage events for "uploadedVolume" > --- > > Key: CLOUDSTACK-9177 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9177 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.6.0 >Reporter: shweta agarwal > Fix For: 4.6.0 > > > Verify volume.upload event is generated when volume is uploaded and > VOLUME.CREATE event is generated when uploaded volume is attached to a VM -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9178) Verify correct Guest OS (RHEL 7) Mapping for vmware
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-9178: --- Issue Type: Test (was: Bug) > Verify correct Guest OS (RHEL 7) Mapping for vmware > --- > > Key: CLOUDSTACK-9178 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9178 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.6.0 >Reporter: shweta agarwal > Fix For: 4.6.1 > > > Verify Rhel7 guest OS vm is mapped to correct guest OS types . T verify this > Attach / Detach ISO operation is performed on VM . If the guest OS mapping is > correct and pointing to rhel7 then only attach/detach ISO operation will be > successful otherwise it will fail -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9277) Test to verify Scale CentOS7 VM does not fails with error "Cannot scale up the vm because of memory constraint violation"
shweta agarwal created CLOUDSTACK-9277: -- Summary: Test to verify Scale CentOS7 VM does not fails with error "Cannot scale up the vm because of memory constraint violation" Key: CLOUDSTACK-9277 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9277 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Reporter: shweta agarwal There was a bug as follows : REPO STEPS = Enable dynamic scaling in Global settings Register an CentOS 7 tempplate(with tools) and tick dynamic scaling Deploy VM with this template Start the VM and try to change service offering EXPECTED RESULT: VM should start with static limit 4x and scale up when offering is changed ACTUAL RESULT: VM starts with maximum static limit of and doesn't scale up with error in ms log : Cannot scale up the vm because of memory constraint violation: Automated a test case to verify dynamic scaling on CentOs7 VM works properly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9276) Test to verify Private template is visible in project
shweta agarwal created CLOUDSTACK-9276: -- Summary: Test to verify Private template is visible in project Key: CLOUDSTACK-9276 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9276 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Reporter: shweta agarwal there was a bug as follows STEPS TO REPRODUCT: 1 Select a project view, and go into volumes view 2 Create a template from a Volume and wait until the process is complete 3 The template cannot be found in the project 4 Navigate back to the "Default view" The template can be found in the templates screen in this view ISSUE: Private template get created outside the project context. These templates are not visible in project view. Done the Automation to verify Template created from Volume inside a project is created for that project and list template with the project id returns the created template inside the scope of project -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9275) Test to verify attaching 7th Disk to windows server 2012R2 instance
shweta agarwal created CLOUDSTACK-9275: -- Summary: Test to verify attaching 7th Disk to windows server 2012R2 instance Key: CLOUDSTACK-9275 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9275 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Reporter: shweta agarwal There was a bug as follows : Issue Cannot attach more than 6 disks to a Windows 2012 R2 VM. Root Cause Analysis While trying to obtain the SCSI id to attach a disk to, CS should ignore the reserved SCSI id 7. But this is not being honored in case of VMs with SCSI controller of type 'VirtualLsiLogicSASController'. And so in case of Windows 2012 R2 VMs, CS chooses to attach the 7th disk on the reserved SCSI id and this fails on vCenter. Steps to reproduce 1. Set global config vmware.root.disk.controller to 'osdefault' 2. Deploy a Windows 2012 R2 instance. 3. Attach 6 disks to the VM. 4. Try attaching a 7th disk to the VM - Fails. Automated a Test case which try to attach 7 data disk to windows server R2 VM on vmware. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9274) API listVMSnapshot returns value for tags ‘project’ and ‘projectid’ when called with project id param
shweta agarwal created CLOUDSTACK-9274: -- Summary: API listVMSnapshot returns value for tags ‘project’ and ‘projectid’ when called with project id param Key: CLOUDSTACK-9274 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9274 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Reporter: shweta agarwal There was a bug as follows REPRO STEPS == 1. Create a project 2. Create a VM in this project 3. Create a VM-Snapshot of this VM 4. Do an API call with command listVMSnapshot like this command=listVMSnapshot&listall=true&projectid=&response=json 5. Take a look at the output. Response Tags "project" and "projectid" are empty, but should contain values! EXPECTED BEHAVIOR == API response should contain 'project' and 'projectid' tags. ACTUAL BEHAVIOR == API response DOESN'T contain 'project' and 'projectid' tags. This automation is to verify that Listvmsnapshot api returns non empty project and projectid when called with project id parmas -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9273) 'listProjects' doesn't return tags 'vmstopped' or 'vmrunning' when their value is zero
shweta agarwal created CLOUDSTACK-9273: -- Summary: 'listProjects' doesn't return tags 'vmstopped' or 'vmrunning' when their value is zero Key: CLOUDSTACK-9273 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9273 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Reporter: shweta agarwal Automating a Test case to verify that listproject api returns vmrunning and vmstopped tags when their value is even zero Automating against the bug REPRO STEPS == 1. Create a project 2. Create a VM in this project 3. Do an API call with command like this command=listProjects&account=admin&domainid=&response=json 5. Take a look at the output. vmstopped tag would be missing since there are no VMs in stopped state(assuming the newly created Vms in running', stop the VM and run the API call now we would not get a tag vmrunning in the response however we would observe vmstopepd tag. EXPECTED BEHAVIOR == API response should contain 'vmstopped' and 'vmrunning' when their values are zero for API call 'listProjects'. ACTUAL BEHAVIOR == API response should contain 'vmstopped' and 'vmrunning' when their values are zero for API call 'listProjects'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9179) Verify register ssh key pair can not be used to register same ssh keys with different name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-9179: --- Summary: Verify register ssh key pair can not be used to register same ssh keys with different name (was: Verify register ssh key pair can be used to register same ssh keys with different name) > Verify register ssh key pair can not be used to register same ssh keys with > different name > -- > > Key: CLOUDSTACK-9179 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9179 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.6.0 >Reporter: shweta agarwal > Fix For: 4.6.1 > > > Verify register ssh key pair can be used to register same ssh keys with > different name > there were issues in list virtual machine API when user were registering > same ssh key with different key pair name and Creating VM with different > key pair. List virtual machine was returning same key pair for both the vm > though two different key pair name was used to deploy them . So now we block > registering same ssh key using two different key pair name . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9179) Verify register ssh key pair can be used to register same ssh keys with different name
shweta agarwal created CLOUDSTACK-9179: -- Summary: Verify register ssh key pair can be used to register same ssh keys with different name Key: CLOUDSTACK-9179 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9179 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.6.0 Reporter: shweta agarwal Fix For: 4.6.1 Verify register ssh key pair can be used to register same ssh keys with different name there were issues in list virtual machine API when user were registering same ssh key with different key pair name and Creating VM with different key pair. List virtual machine was returning same key pair for both the vm though two different key pair name was used to deploy them . So now we block registering same ssh key using two different key pair name . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9178) Verify correct Guest OS (RHEL 7) Mapping for vmware
shweta agarwal created CLOUDSTACK-9178: -- Summary: Verify correct Guest OS (RHEL 7) Mapping for vmware Key: CLOUDSTACK-9178 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9178 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.6.0 Reporter: shweta agarwal Fix For: 4.6.1 Verify Rhel7 guest OS vm is mapped to correct guest OS types . T verify this Attach / Detach ISO operation is performed on VM . If the guest OS mapping is correct and pointing to rhel7 then only attach/detach ISO operation will be successful otherwise it will fail -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9177) Atomation of Usage events for "uploadedVolume"
shweta agarwal created CLOUDSTACK-9177: -- Summary: Atomation of Usage events for "uploadedVolume" Key: CLOUDSTACK-9177 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9177 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.6.0 Reporter: shweta agarwal Fix For: 4.6.0 Verify volume.upload event is generated when volume is uploaded and VOLUME.CREATE event is generated when uploaded volume is attached to a VM -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9012) coreos test case automation
shweta agarwal created CLOUDSTACK-9012: -- Summary: coreos test case automation Key: CLOUDSTACK-9012 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9012 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Reporter: shweta agarwal Automated a full scenario of coreos guest OS support: it includes registering coreos templates present at http://dl.openvm.eu/cloudstack/coreos/x86_64/ 1. based on hypervisor types of zone 2. creating ssh key pair 3. creating a sample user data 4. creating a coreos virtual machine using this ssh keypair and userdata 5. verifying ssh access to coreo os machine using keypair and core username 6. verifying userdata is applied on virtual machine and the service asked in sample data is actually running 7. Verifying userdata in router vm as well -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8789) setting userdata for VM is failing with b64decode TypeError: Incorrect padding
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14900392#comment-14900392
]
shweta agarwal commented on CLOUDSTACK-8789:
try for two three times and you will hit it.
I hit it again
2015-09-21 07:56:24,525 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-338:ctx-2f5e8368) Copying VR with ip 169.254.3.67 config file into
host 10.220.131.125
2015-09-21 07:56:24,903 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-338:ctx-2f5e8368) VR Config file vm_password.json got created in
VR, ip 169.254.3.67 with content
{"ip_address":"192.168.200.199","password":"saved_password","type":"vmpassword"}
2015-09-21 07:56:24,903 DEBUG [c.c.a.r.v.VirtualRoutingResource]
(DirectAgent-338:ctx-2f5e8368) Processing FileConfigItem, copying 80 characters
to vm_password.json took 383ms
2015-09-21 07:56:24,903 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-338:ctx-2f5e8368) Executing command in VR:
/opt/cloud/bin/router_proxy.sh update_config.py 169.254.3.67 vm_password.json
2015-09-21 07:56:25,283 ERROR [c.c.u.s.SshHelper]
(DirectAgent-338:ctx-2f5e8368) SSH execution of command
/opt/cloud/bin/router_proxy.sh update_config.py 169.254.3.67 vm_password.json
has an error status code in return. result output: [INFO] update_config.py ::
Processing incoming file => vm_password.json
[INFO] Processing JSON file vm_password.json
Traceback (most recent call last):
File "/opt/cloud/bin/update_config.py", line 140, in
process_file()
File "/opt/cloud/bin/update_config.py", line 54, in process_file
finish_config()
File "/opt/cloud/bin/update_config.py", line 44, in finish_config
returncode = configure.main([])
File "/opt/cloud/bin/configure.py", line 831, in main
metadata.process()
File "/opt/cloud/bin/configure.py", line 258, in process
self.__createfile(ip, folder, file, data)
File "/opt/cloud/bin/configure.py", line 274, in __createfile
data = base64.b64decode(data)
File "/usr/lib/python2.7/base64.py", line 76, in b64decode
raise TypeError(msg)
TypeError: Incorrect padding
2015-09-21 07:56:25,286 DEBUG [c.c.a.r.v.VirtualRoutingResource]
(DirectAgent-338:ctx-2f5e8368) Processing ScriptConfigItem, executing
update_config.py vm_password.json took 383ms
> setting userdata for VM is failing with b64decode TypeError: Incorrect padding
> --
>
> Key: CLOUDSTACK-8789
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8789
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.0
>Reporter: shweta agarwal
>Priority: Blocker
> Fix For: 4.6.0
>
> Attachments: management-server.log.tar.gz
>
>
> Repro steps:
> 1. Used cloudmonkey for deploy Virtual machine with userdata field
> deploy virtualmachine zoneid=1 templateid=5 serviceofferingid=1
> userdata="dXNlcmRhdGE="
> Error:
> Userdata is not set in the VM
> Ms log shows follwoing error:
> 2015-08-31 07:30:12,534 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-419:ctx-34cc397c) Executing command in VR:
> /opt/cloud/bin/router_proxy.sh update_config.py 169.254.2.76 vm_password.json
> 2015-08-31 07:30:13,238 ERROR [c.c.u.s.SshHelper]
> (DirectAgent-419:ctx-34cc397c) SSH execution of command
> /opt/cloud/bin/router_proxy.sh update_config.py 169.254.2.76 vm_password.json
> has an error status code in return. result output: [INFO] update_config.py ::
> Processing incoming file => vm_password.json
> [INFO] Processing JSON file vm_password.json
> Traceback (most recent call last):
> File "/opt/cloud/bin/update_config.py", line 140, in
> process_file()
> File "/opt/cloud/bin/update_config.py", line 54, in process_file
> finish_config()
> File "/opt/cloud/bin/update_config.py", line 44, in finish_config
> returncode = configure.main([])
> File "/opt/cloud/bin/configure.py", line 664, in main
> metadata.process()
> File "/opt/cloud/bin/configure.py", line 257, in process
> self.__createfile(ip, folder, file, data)
> File "/opt/cloud/bin/configure.py", line 273, in __createfile
> data = base64.b64decode(data)
> File "/usr/lib/python2.7/base64.py", line 76, in b64decode
> raise TypeError(msg)
> TypeError: Incorrect padding
> 2015-08-31 07:30:13,240 DEBUG [c.c.a.r.v.VirtualRoutingResource]
> (DirectAgent-419:ctx-34cc397c) Processing ScriptConfigItem, executing
> update_config.py vm_password.json took 706ms
> 2015-08-31 07:30:13,240 WARN [c.c.a.r.v.VirtualRoutingResource]
> (DirectAgent-419:ctx-34cc397c) Expected 1 answers while executing
> SavePasswordCommand but received 2
> 2015-08-31 07:30:13,240 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-419:ctx-34cc397c) Seq 1-423816872
[jira] [Created] (CLOUDSTACK-8820) Showing error when try to add advance zone using VMWare ESXi 6.0 host
shweta agarwal created CLOUDSTACK-8820: -- Summary: Showing error when try to add advance zone using VMWare ESXi 6.0 host Key: CLOUDSTACK-8820 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8820 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.6.0 Reporter: shweta agarwal Priority: Critical Steps to reproduce: 1.Installed VMWare Server 6.0 2.Installed VMware Vsphere Client 6.0 3.Prepared vmware host using VMware-VMvisor-Installer-6.0.0-2494585.x86_64.iso 4.Added vmware host to VMware Vsphere Client 6.0. 5.Prepared latest CS setup 6. Try creating a vmware zone using a vmware 6.0 host Actual behavior: Showing error 'Failed to add VMware DC to zone due to : null' when try to add advance zone using VMWare ESXi 6.0 host. Expected behavior: Add advance zone operation should be successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8789) setting userdata for VM is failing with b64decode TypeError: Incorrect padding
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-8789: --- Attachment: management-server.log.tar.gz > setting userdata for VM is failing with b64decode TypeError: Incorrect padding > -- > > Key: CLOUDSTACK-8789 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8789 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: shweta agarwal >Priority: Critical > Fix For: 4.6.0 > > Attachments: management-server.log.tar.gz > > > Repro steps: > 1. Used cloudmonkey for deploy Virtual machine with userdata field > deploy virtualmachine zoneid=1 templateid=5 serviceofferingid=1 > userdata="dXNlcmRhdGE=" > Error: > Userdata is not set in the VM > Ms log shows follwoing error: > 2015-08-31 07:30:12,534 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-419:ctx-34cc397c) Executing command in VR: > /opt/cloud/bin/router_proxy.sh update_config.py 169.254.2.76 vm_password.json > 2015-08-31 07:30:13,238 ERROR [c.c.u.s.SshHelper] > (DirectAgent-419:ctx-34cc397c) SSH execution of command > /opt/cloud/bin/router_proxy.sh update_config.py 169.254.2.76 vm_password.json > has an error status code in return. result output: [INFO] update_config.py :: > Processing incoming file => vm_password.json > [INFO] Processing JSON file vm_password.json > Traceback (most recent call last): > File "/opt/cloud/bin/update_config.py", line 140, in > process_file() > File "/opt/cloud/bin/update_config.py", line 54, in process_file > finish_config() > File "/opt/cloud/bin/update_config.py", line 44, in finish_config > returncode = configure.main([]) > File "/opt/cloud/bin/configure.py", line 664, in main > metadata.process() > File "/opt/cloud/bin/configure.py", line 257, in process > self.__createfile(ip, folder, file, data) > File "/opt/cloud/bin/configure.py", line 273, in __createfile > data = base64.b64decode(data) > File "/usr/lib/python2.7/base64.py", line 76, in b64decode > raise TypeError(msg) > TypeError: Incorrect padding > 2015-08-31 07:30:13,240 DEBUG [c.c.a.r.v.VirtualRoutingResource] > (DirectAgent-419:ctx-34cc397c) Processing ScriptConfigItem, executing > update_config.py vm_password.json took 706ms > 2015-08-31 07:30:13,240 WARN [c.c.a.r.v.VirtualRoutingResource] > (DirectAgent-419:ctx-34cc397c) Expected 1 answers while executing > SavePasswordCommand but received 2 > 2015-08-31 07:30:13,240 DEBUG [c.c.a.m.DirectAgentAttache] > (DirectAgent-419:ctx-34cc397c) Seq 1-4238168724332367732: Cancelling because > one of the answers is false and it is stop on error. > 2015-08-31 07:30:13,240 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-41 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8790) SSh to few vms are failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal updated CLOUDSTACK-8790:
---
Attachment: management-server.log.tar.gz
> SSh to few vms are failing
> --
>
> Key: CLOUDSTACK-8790
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8790
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.0
>Reporter: shweta agarwal
>Priority: Critical
> Attachments: management-server.log.tar.gz
>
>
> Repro steps:
> create a ssh keypair
> Deploy several VMs with keypair field
> destroy few vms
> deploy more vms with keypair
> Bug:
> Notice keypair for certain VMs are not set hence ssh for those vms are failing
> MS log for those vms shows :
> 2015-08-31 07:30:12,149 ERROR [c.c.u.s.SshHelper]
> (DirectAgent-210:ctx-8227b3be) SSH execution of command
> /opt/cloud/bin/router_proxy.sh update_config.py 169.254.2.76
> vm_dhcp_entry.json has an error status code in return. result output: [INFO]
> update_config.py :: Processing incoming file => vm_dhcp_entry.json
> [INFO] Processing JSON file vm_dhcp_entry.json
> VM-6a153536-58c4-4951-b99f-478e2c3ca097
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
> VM-b9b0adf4-6e7f-488a-b3ae-53eb8eebf779
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
> VM-14c664dd-7a0b-453a-bfa1-57ca5227c79f
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
> VM-ed569557-34e5-4bc1-a395-4d868cfeb54a
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
> VM-ae103b7d-33f2-4011-9afa-b5e711722f9f
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
> VM-aa122877-abde-4674-962d-0cc5a8caf4f7
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
> VM-3cf6e5d5-5abc-491f-a9dd-994ff51cfa5e
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
> VM-56dfbd5a-3783-48c8-9366-cf348bf4e1d4
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
> VM-e3cee5b1-4631-45d9-9ee3-dc29c91e6828
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
> Traceback (most recent call last):
> File "/opt/cloud/bin/update_config.py", line 140, in
> process_file()
> File "/opt/cloud/bin/update_config.py", line 54, in process_file
> finish_config()
> File "/opt/cloud/bin/update_config.py", line 44, in finish_config
> returncode = configure.main([])
> File "/opt/cloud/bin/configure.py", line 664, in main
> metadata.process()
> File "/opt/cloud/bin/configure.py", line 257, in process
> self.__createfile(ip, folder, file, data)
> File "/opt/cloud/bin/configure.py", line 273, in __createfile
> data = base64.b64decode(data)
> File "/usr/lib/python2.7/base64.py", line 76, in b64decode
> raise TypeError(msg)
> TypeError: Incorrect padding
> 2015-08-31 07:30:12,149 DEBUG [c.c.a.r.v.VirtualRoutingResource]
> (DirectAgent-210:ctx-8227b3be) Processing ScriptConfigItem, executing
> update_config.py vm_dhcp_entry.json took 574ms
> 2015-08-31 07:30:12,149 WARN [c.c.a.r.v.VirtualRoutingResource]
> (DirectAgent-210:ctx-8227b3be) Expected 1 answers while executing
> DhcpEntryCommand but received 2
> 2015-08-31 07:30:12,149 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-210:ctx-8227b3be) Seq 1-4238168724332367731: Response Received:
> 2015-08-31 07:30:12,151 DEBUG [c.c.a.t.Request]
> (DirectAgent-210:ctx-8227b3be) Seq 1-4238168724332367731: Processing: { Ans:
> , MgmtId: 233845177509810, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.routing.GroupAnswer":{"results":["null - success:
> ","null - failed: [INFO] update_config.py :: Processing incoming file =>
> vm_dhcp_entry.json\n[INFO] Processing JSON file
> vm_dhcp_entry.json\nVM-6a153536-58c4-4951-b99f-478e2c3ca097
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nVM-b9b0adf4-6e7f-488a-b3ae-53eb8eebf779
>
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nVM-14c664dd-7a0b-453a-bfa1-57ca5227c79f
>
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nVM-ed569557-34e5-4bc1-a395-4d868cfeb54a
>
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nVM-ae103b7d-33f2-4011-9afa-b5e711722f9f
>
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nVM-aa122877-abde-4674-962d-0cc5a8caf4f7
>
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nVM-3cf6e5d5-5abc-491f-a9dd-994ff51cfa5e
>
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nVM-56dfbd5a-3783-48c8-9366-cf348bf4e1d4
>
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nVM-e3cee5b1-4631-45d9-9ee3-dc29c91e6828
> VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nTraceback (most recent call
> last):\n File \"/opt/cloud/bin/update_config.py\", line 140, in \n
> process_file()\n File \"/opt/cloud/bin/update_config.py\", line 54, in
> process_file\nfinish_config()\n File
> \"/opt/cloud/bin/update_config.py\", line 44, in finish_config\n
> returncode = configure.main([])\n File \"/opt/cloud/bin/configure.py\", line
> 664, in main\nmetadata.process()\n File \"/opt/cloud/bin/configure.py\
[jira] [Created] (CLOUDSTACK-8790) SSh to few vms are failing
shweta agarwal created CLOUDSTACK-8790:
--
Summary: SSh to few vms are failing
Key: CLOUDSTACK-8790
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8790
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.6.0
Reporter: shweta agarwal
Priority: Critical
Repro steps:
create a ssh keypair
Deploy several VMs with keypair field
destroy few vms
deploy more vms with keypair
Bug:
Notice keypair for certain VMs are not set hence ssh for those vms are failing
MS log for those vms shows :
2015-08-31 07:30:12,149 ERROR [c.c.u.s.SshHelper]
(DirectAgent-210:ctx-8227b3be) SSH execution of command
/opt/cloud/bin/router_proxy.sh update_config.py 169.254.2.76 vm_dhcp_entry.json
has an error status code in return. result output: [INFO] update_config.py ::
Processing incoming file => vm_dhcp_entry.json
[INFO] Processing JSON file vm_dhcp_entry.json
VM-6a153536-58c4-4951-b99f-478e2c3ca097 VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
VM-b9b0adf4-6e7f-488a-b3ae-53eb8eebf779 VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
VM-14c664dd-7a0b-453a-bfa1-57ca5227c79f VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
VM-ed569557-34e5-4bc1-a395-4d868cfeb54a VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
VM-ae103b7d-33f2-4011-9afa-b5e711722f9f VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
VM-aa122877-abde-4674-962d-0cc5a8caf4f7 VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
VM-3cf6e5d5-5abc-491f-a9dd-994ff51cfa5e VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
VM-56dfbd5a-3783-48c8-9366-cf348bf4e1d4 VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
VM-e3cee5b1-4631-45d9-9ee3-dc29c91e6828 VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3
Traceback (most recent call last):
File "/opt/cloud/bin/update_config.py", line 140, in
process_file()
File "/opt/cloud/bin/update_config.py", line 54, in process_file
finish_config()
File "/opt/cloud/bin/update_config.py", line 44, in finish_config
returncode = configure.main([])
File "/opt/cloud/bin/configure.py", line 664, in main
metadata.process()
File "/opt/cloud/bin/configure.py", line 257, in process
self.__createfile(ip, folder, file, data)
File "/opt/cloud/bin/configure.py", line 273, in __createfile
data = base64.b64decode(data)
File "/usr/lib/python2.7/base64.py", line 76, in b64decode
raise TypeError(msg)
TypeError: Incorrect padding
2015-08-31 07:30:12,149 DEBUG [c.c.a.r.v.VirtualRoutingResource]
(DirectAgent-210:ctx-8227b3be) Processing ScriptConfigItem, executing
update_config.py vm_dhcp_entry.json took 574ms
2015-08-31 07:30:12,149 WARN [c.c.a.r.v.VirtualRoutingResource]
(DirectAgent-210:ctx-8227b3be) Expected 1 answers while executing
DhcpEntryCommand but received 2
2015-08-31 07:30:12,149 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-210:ctx-8227b3be) Seq 1-4238168724332367731: Response Received:
2015-08-31 07:30:12,151 DEBUG [c.c.a.t.Request] (DirectAgent-210:ctx-8227b3be)
Seq 1-4238168724332367731: Processing: { Ans: , MgmtId: 233845177509810, via:
1, Ver: v1, Flags: 10,
[{"com.cloud.agent.api.routing.GroupAnswer":{"results":["null - success:
","null - failed: [INFO] update_config.py :: Processing incoming file =>
vm_dhcp_entry.json\n[INFO] Processing JSON file
vm_dhcp_entry.json\nVM-6a153536-58c4-4951-b99f-478e2c3ca097
VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nVM-b9b0adf4-6e7f-488a-b3ae-53eb8eebf779
VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nVM-14c664dd-7a0b-453a-bfa1-57ca5227c79f
VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nVM-ed569557-34e5-4bc1-a395-4d868cfeb54a
VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nVM-ae103b7d-33f2-4011-9afa-b5e711722f9f
VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nVM-aa122877-abde-4674-962d-0cc5a8caf4f7
VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nVM-3cf6e5d5-5abc-491f-a9dd-994ff51cfa5e
VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nVM-56dfbd5a-3783-48c8-9366-cf348bf4e1d4
VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nVM-e3cee5b1-4631-45d9-9ee3-dc29c91e6828
VM-2619da1e-43b2-4cff-8cb5-58d7cc3709d3\nTraceback (most recent call last):\n
File \"/opt/cloud/bin/update_config.py\", line 140, in \n
process_file()\n File \"/opt/cloud/bin/update_config.py\", line 54, in
process_file\nfinish_config()\n File \"/opt/cloud/bin/update_config.py\",
line 44, in finish_config\nreturncode = configure.main([])\n File
\"/opt/cloud/bin/configure.py\", line 664, in main\nmetadata.process()\n
File \"/opt/cloud/bin/configure.py\", line 257, in process\n
self.__createfile(ip, folder, file, data)\n File
\"/opt/cloud/bin/configure.py\", line 273, in __createfile\ndata =
base64.b64decode(data)\n File \"/usr/lib/python2.7/base64.py\", line 76, in
b64decode\nraise TypeError(msg)\nTypeError: Incorrect
padding\n"],"result":false,"wait":0}}] }
2015-08-31 07:30:12,151 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-123:ctx-37118a0d job-282/job
[jira] [Created] (CLOUDSTACK-8789) setting userdata for VM is failing with b64decode TypeError: Incorrect padding
shweta agarwal created CLOUDSTACK-8789: -- Summary: setting userdata for VM is failing with b64decode TypeError: Incorrect padding Key: CLOUDSTACK-8789 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8789 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.6.0 Reporter: shweta agarwal Priority: Critical Fix For: 4.6.0 Repro steps: 1. Used cloudmonkey for deploy Virtual machine with userdata field deploy virtualmachine zoneid=1 templateid=5 serviceofferingid=1 userdata="dXNlcmRhdGE=" Error: Userdata is not set in the VM Ms log shows follwoing error: 2015-08-31 07:30:12,534 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-419:ctx-34cc397c) Executing command in VR: /opt/cloud/bin/router_proxy.sh update_config.py 169.254.2.76 vm_password.json 2015-08-31 07:30:13,238 ERROR [c.c.u.s.SshHelper] (DirectAgent-419:ctx-34cc397c) SSH execution of command /opt/cloud/bin/router_proxy.sh update_config.py 169.254.2.76 vm_password.json has an error status code in return. result output: [INFO] update_config.py :: Processing incoming file => vm_password.json [INFO] Processing JSON file vm_password.json Traceback (most recent call last): File "/opt/cloud/bin/update_config.py", line 140, in process_file() File "/opt/cloud/bin/update_config.py", line 54, in process_file finish_config() File "/opt/cloud/bin/update_config.py", line 44, in finish_config returncode = configure.main([]) File "/opt/cloud/bin/configure.py", line 664, in main metadata.process() File "/opt/cloud/bin/configure.py", line 257, in process self.__createfile(ip, folder, file, data) File "/opt/cloud/bin/configure.py", line 273, in __createfile data = base64.b64decode(data) File "/usr/lib/python2.7/base64.py", line 76, in b64decode raise TypeError(msg) TypeError: Incorrect padding 2015-08-31 07:30:13,240 DEBUG [c.c.a.r.v.VirtualRoutingResource] (DirectAgent-419:ctx-34cc397c) Processing ScriptConfigItem, executing update_config.py vm_password.json took 706ms 2015-08-31 07:30:13,240 WARN [c.c.a.r.v.VirtualRoutingResource] (DirectAgent-419:ctx-34cc397c) Expected 1 answers while executing SavePasswordCommand but received 2 2015-08-31 07:30:13,240 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-419:ctx-34cc397c) Seq 1-4238168724332367732: Cancelling because one of the answers is false and it is stop on error. 2015-08-31 07:30:13,240 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-41 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8756) Incorrect guest os mapping in CCP 4.2.1-6 for CentOS 5.9
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708773#comment-14708773 ] shweta agarwal commented on CLOUDSTACK-8756: 1) Create VM from ISO of CentOS5.9 or greater version on VMware 2) Try to attach VMwaretools from CCP and failed. 3) Try to attach VMwaretools from ESXi and also failed. 4) When checked VM EditSetting>>Options>>GeneralOptions in ESXi, Version is "Other (64-bit)". 5) In CS UI, the version for this VM is "CentOS5.9(32bit)" which is correct. This will cause CentOS( 5.9 or any other greater version) unable to be provided on VMware certain operations like attach and detach iso. so this test case is about verifying that attach and detach iso is working fine with vmware VMs especially when using centos guset os > Incorrect guest os mapping in CCP 4.2.1-6 for CentOS 5.9 > > > Key: CLOUDSTACK-8756 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8756 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.1 >Reporter: prashant kumar mishra >Assignee: shweta agarwal > Fix For: 4.5.1 > > > 1) Create VM from ISO of CentOS5.9 on VMware > 2) Try to attach VMwaretools from CCP and failed. > 3) Try to attach VMwaretools from ESXi and also failed. > 4) When checked VM EditSetting>>Options>>GeneralOptions in ESXi, Version is > "Other (64-bit)". > 5) In CCP UI, the version for this VM is "CentOS5.9(32bit)" which is correct. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8757) FTP modules are not loaded in VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708764#comment-14708764 ] shweta agarwal commented on CLOUDSTACK-8757: To have Active FTP working in isolated networks VRs need the have the following modules loaded (In order to map the FTP Data and FTP CMD to the same frontend IP): modprobe nf_conntrack_ftp modprobe nf_nat_ftp in some versions of Cloudstack we noted that these modules are not loaded on CS Routers by default . So this test case is for verifying that these modules are loaded by default in VR and if not report an error > FTP modules are not loaded in VR > > > Key: CLOUDSTACK-8757 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8757 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.1 >Reporter: prashant kumar mishra >Assignee: shweta agarwal > Fix For: 4.5.2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7515) [LXC] user VM is getting different mac than the one with router for the same VM in case of shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7515. -- > [LXC] user VM is getting different mac than the one with router for the same > VM in case of shared network > -- > > Key: CLOUDSTACK-7515 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7515 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Network Controller >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala > Fix For: 4.5.0 > > Attachments: agen-user-vm.tar.gz, agent-router.tar.gz, > management-server.log.2014-09-08.gz > > > Repro steps: > 1. Create a advanced zone with LXC hosts having 2 clusters .one cluster > having one host and other having two host .all host are LXC > 2. Create a shared Network > 3. Create a VM using only shared network as default network > Bug: > Notice mac address that VM has is different than the one Router has for the > same vm > router VM shows > cat /etc/dhcphosts.txt > 06:2e:70:00:00:1d,set:10_147_31_148,10.147.31.148,VM-bb8425ca-d97a-48dc-a69d-7ceb3ba454e2,infinite > 06:b7:8a:00:00:18,set:10_147_31_143,10.147.31.143,VM-afcdd0b3-59e0-4104-8fe8-f12b344c6336,infinite > 06:45:08:00:00:19,set:10_147_31_144,10.147.31.144,VM-ef2bbfd7-59d1-4e43-97fb-1a1ac233be9b,infinite > 06:e2:c6:00:00:1b,set:10_147_31_146,10.147.31.146,VM-f0e8245a-b382-45d7-a01d-e63c111fbef5,infinite > For USER VM with IP 10.147.31.144 > router has mac06:45:08:00:00:19 but VM has mac 06:4d:15:46:f3:c6 > Ifconfig on VM shows > ifconfig > eth0: flags=4163 mtu 1500 > inet6 fe80::44d:15ff:fe46:f3c6 prefixlen 64 scopeid 0x20 > ether 06:4d:15:46:f3:c6 txqueuelen 1000 (Ethernet) > RX packets 1938 bytes 414054 (404.3 KiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 14 bytes 2700 (2.6 KiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > lo: flags=73 mtu 65536 > inet 127.0.0.1 netmask 255.0.0.0 > inet6 ::1 prefixlen 128 scopeid 0x10 > loop txqueuelen 0 (Local Loopback) > RX packets 0 bytes 0 (0.0 B) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 0 bytes 0 (0.0 B) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > Additional information : > dumpxml of LXC vm shows same mac which is available with router > Notice even IP is not set for such VMs > Attaching Ms and agent logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7383) [LXC][UI] dont show vm snapshot button in UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7383: --- Attachment: lxc.png > [LXC][UI] dont show vm snapshot button in UI > > > Key: CLOUDSTACK-7383 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7383 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.5.0 > > Attachments: lxc.png, vmsnap.png > > > Repro steps: > Vm snapshot is not supported in LXC so we should not show VM snapshot option > in UI in instance tab , the way we do it for KVM .We dont show VM snapshot > button in cae of KVM vm. > Attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-7383) [LXC][UI] dont show vm snapshot button in UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal reopened CLOUDSTACK-7383: still see bot take vm snapshot option and view vm snapshot option in instance->details view > [LXC][UI] dont show vm snapshot button in UI > > > Key: CLOUDSTACK-7383 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7383 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.5.0 > > Attachments: vmsnap.png > > > Repro steps: > Vm snapshot is not supported in LXC so we should not show VM snapshot option > in UI in instance tab , the way we do it for KVM .We dont show VM snapshot > button in cae of KVM vm. > Attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7384) [LXC][UI] show change service offering command option only when VM is in stop state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7384. -- Verified . fixed > [LXC][UI] show change service offering command option only when VM is in stop > state > --- > > Key: CLOUDSTACK-7384 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7384 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang > Fix For: 4.5.0 > > Attachments: change.png > > > we should show change service offerings of a LXC VM in stop state in > Instance detail tab , the way we do it in KVM VMs. > Currently we show change service offering option in LXC VMs when VM is > running as well > Attaching screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-7318) [UI] processing wheel continue to spin even after error messaage during VM snapshot creation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal reopened CLOUDSTACK-7318: issue still reproducible but now in taking volume snapshot instead of VM snaphot > [UI] processing wheel continue to spin even after error messaage during VM > snapshot creation > > > Key: CLOUDSTACK-7318 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7318 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Mihaela Stoica > Fix For: 4.6.0 > > Attachments: processingwheel.png > > > Repro steps: > Create a LXC VM > When VM is running try to createa VM snapshot > Bug: > Notice you get message VM snapshot is not enabled for hypervisor type: LXC > but spinnign wheel continue to spin . attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7402) [UI] no option to delete or copy template across zone for registered template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7402. -- > [UI] no option to delete or copy template across zone for registered template > - > > Key: CLOUDSTACK-7402 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7402 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: shweta agarwal > Fix For: Future > > Attachments: temp.png > > > Repro steps: > Register a template . > Once its ready notice there is no command button to delete this template > Also there is not command option to copy template across zone > Attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7804) [CEPH] Adding RBD primary storage is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7804. -- > [CEPH] Adding RBD primary storage is failing > -- > > Key: CLOUDSTACK-7804 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7804 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Blocker > Fix For: 4.5.0 > > Attachments: MS.tar.gz, agent.tar.gz > > > Repro steps : > 1. Create a LXC zone with NFS primary storage > 2. Once System VMs are up add Ceph storage as another primary storage > Bug: > Storage addition is failing. It goes to initialized state but after some time > gets message storage addition failed . > attached MS log and Agents log for the same -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7430) [UI] no option to remove /delete host from cluster from UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7430. -- > [UI] no option to remove /delete host from cluster from UI > -- > > Key: CLOUDSTACK-7430 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7430 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang > Fix For: 4.5.0 > > Attachments: 2014-10-17-jessica.PNG, delete-host.png > > > Repro steps: > 1. Create a Zone > 2. Put host to maintenance > 3. when host is in maintenance try to remove/delete host from cluster via Ui > Bug: > No option to delete host > attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7485) [LXC] Debian VMs fails to start in LXC host
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal closed CLOUDSTACK-7485.
--
> [LXC] Debian VMs fails to start in LXC host
> ---
>
> Key: CLOUDSTACK-7485
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7485
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
> Fix For: 4.5.0
>
> Attachments: agent.tar.gz
>
>
> Repro steps:
> Create a LXC setup
> Register debian Template
> Create Debian VM
> Bug:
> Debian VMs fails to start
> Agent log shows:
> 2014-09-04 17:34:01,902 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-5:null) starting i-2-5-VM:
> i-2-5-VM
> 6c3618c2-0189-4678-8242-f53bc1099cee
> Debian GNU/Linux 6(64-bit)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>dir='/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/3ddee90e-6037-489c-b4ac-1df9867bf378'/>
>
>
>
>
>
>
>
>
>
> 524288
>
>
>
> 1
>
> exe
> /sbin/init
>
>
> 500
>
> restart
> destroy
> destroy
>
> 2014-09-04 17 at org.libvirt.Connect.processError(Unknown Source)
> at org.libvirt.Connect.domainCreateXML(Unknown Source)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1238)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3766)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1332)
> at com.cloud.agent.Agent.processRequest(Agent.java:503)
> at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:810)
> at com.cloud.utils.nio.Task.run(Task.java:84)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> 2014-09-04 17:34:02,207 DEBUG [kvm.storage.KVMStoragePoolManager]
> (agentRequest-Handler-5:null) Disconnecting disk
> 3ddee90e-6037-489c-b4ac-1df9867bf378
> 2014-09-04 17:34:02,208 DEBUG [kvm.storage.LibvirtStorageAdaptor]
> (agentRequest-Handler-5:null) Trying to fetch storage pool
> dfa2ec3c-d133-3284-8583-0a0845aa4424 from libvirt
> 2014-09-04 17:34:02,231 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Seq 1-8326029811101205191: { Ans: , MgmtId:
> 233845178472723, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":5,"name":"i-2-5-VM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"arch":"x86_64","os":"Debian
> GNU/Linux 6(64-bit)","platfo:34:02,207 WARN
> [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-5:null)
> LibvirtException
> org.libvirt.LibvirtException: internal error: guest failed to start: cannot
> find init path '/sbin/init' relative to container root: No such file or
> directory
> at org.libvirt.ErrorHandler.processError(Unknown Source)
> at org.libvirt.Connect.processError(Unknown Source)
> at org.libvirt.Connect.processError(Unknown Source)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7486) [LXC] Fedora VM fails to start on LXc host
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal closed CLOUDSTACK-7486.
--
> [LXC] Fedora VM fails to start on LXc host
> ---
>
> Key: CLOUDSTACK-7486
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7486
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
> Fix For: 4.5.0
>
> Attachments: agent.tar.gz
>
>
> Repro Steps:
> Repro steps:
> Create a LXC setup
> Register debian Template
> Create Debian VM
> Bug:
> Debian VMs fails to start
> Agent log shows:
> 2014-09-04 17:29:08,581 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-2:null) starting i-2-3-VM:
> i-2-3-VM
> a2dafe32-9d8c-47a8-abe5-9af100987155
> Fedora 9
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>dir='/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/36d7a92b-a78b-4f30-83bb-c65ea7768627'/>
>
>
>
>
>
>
>
>
>
> 524288
>
>
>
> 1
>
> exe
> /sbin/init
>
>
> 500
>
> restart
> destroy
> destroy
>
> 2014-09-04 17:29:08,944 WARN [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-2:null) LibvirtExceptiondestroy
>
> 2014-09-04 17:29:08,944 WARN [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-2:null) LibvirtException
> org.libvirt.LibvirtException: internal error: guest failed to start: cannot
> find init path '/sbin/init' relative to container root: No such file or
> directory
> 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:1238)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3766)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1332)
> at com.cloud.agent.Agent.processRequest(Agent.java:503)
> at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:810)
> at com.cloud.utils.nio.Task.run(Task.java:84)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> 2014-09-04 17:29:08,945 DEBUG [kvm.storage.KVMStoragePoolManager]
> (agentRequest-Handler-2:null) Disconnecting disk
> 36d7a92b-a78b-4f30-83bb-c65ea7768627
> 2014-09-04 17:29:08,945 DEBUG [kvm.storage.LibvirtStorageAdaptor]
> (agentRequest-Handler-2:null) Trying to fetch storage pool
> dfa2ec3c-d133-3284-8583-0a0845aa4424 from libvirt
> 2014-09-04 17:29:08,971 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Seq 1-8326029811101205165: { Ans: , MgmtId:
> 233845178472723, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":3,"name":"i-2-3-VM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"arch":"x86_64","os":"Fedora
> 9","platformEmulator":"Fedora
> 9","bootArgs":"","enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"SpGVlce3UZ95WXoV9NerqA==","vncAddr":"10.147.28.42","params":{},"uuid":"a2dafe32-9d8c-47a8-abe5-9af100987155","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"36d7a92b-a78b-4f30-83bb-c65ea7768627","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"dfa2ec3c-d133-3284-8583-0a0845aa4424","id":2,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/shweta/goleta.lxc.primary","port":2049,"url":"NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=Primary&STOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424"}},"name":"ROOT-3","size":20480,"path":"36d7a92b-a78b-4f30-83bb-c65ea7768627","volumeId":3,"vmName":"i-2-3-VM","accountId":2,"format":"DIR","provisioningType":"THIN","id":3,"deviceId":0,"hypervisorType":"LXC"}},"diskSeq":0,"path":"36d7a92b-a78b-4f30-83bb-c65ea7768627","type":"ROOT","_details":{"managed":"false","storagePort":"2049","storageHost":"10.147.28.7","volumeSize":"20480"}},{"data":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"ISO"}],"nics":[{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"pxeDisable":false,"nicUuid":"8cf8970b-75be-4646-b44f-8dea032e78bc","uuid":"e6370f8f-bab
[jira] [Reopened] (CLOUDSTACK-6224) VM Snapshot inconsistent size
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal reopened CLOUDSTACK-6224: I tried to verify the bug . Bug is still not fixed. I created a VM on vmware 5.1 with a template of size 2GB and data disk of size 5GB . Then i created a VM snapshot of this VM When usage is generated for the VM snapshot the usage for root disk is only 37KB , for data disk usage was fine. > VM Snapshot inconsistent size > - > > Key: CLOUDSTACK-6224 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6224 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server >Affects Versions: 4.2.1 > Environment: Cloudstack 4.2.1 > XenServer 6.2 > Vcenter 5.5 ESXi >Reporter: Artjoms Petrovs >Assignee: Mike Tutkowski > Labels: snapshot, vmware, xen > Fix For: 4.4.0 > > > During the creation of VM Snapshot [VMware], resulting size is written in > table „volumes”, column vm_snapshot_chain_size. It seems that size of a VM > Snapshot is calculated manually via the method getVMSnapshotChainSize(..) > and it gives overexpected result ( hundreds of terabytes ) and is much larger > than the filesize, that we can see in VMware itself. By calculating the vmdk > and vmsn file sizes manually. Xen VM snapshots [disks only] give similar > results. For me it seems that either the method works incorrectly, either it > loops between some simlinks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7806) Agent state remians connecting for secondary storage VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal updated CLOUDSTACK-7806:
---
Attachment: cloud.log
> Agent state remians connecting for secondary storage VM
> ---
>
> Key: CLOUDSTACK-7806
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7806
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: cloud.log
>
>
> Repro steps :
> Create a LXC Zone setup.
> Notice Agent status of Secondary storage VM will be connecting once Sceondary
> Storage VM is in running state .
> SSVM cloud log shows :
> 2014-10-28 09:38:10,340 DEBUG [utils.script.Script]
> (agentRequest-Handler-1:nulll
> ) Executing: /usr/local/cloud/systemvm/config_ssl.sh -i 10.147.30.190 -h
> s-1-VM
> 2014-10-28 09:38:10,377 DEBUG [cloud.agent.Agent] (Agent-Handler-4:null)
> Receivee
> d response: Seq 0-159: { Ans: , MgmtId: 233845178472723, via: 1, Ver: v1,
> Flagss
> : 100010,
> [{"com.cloud.agent.api.PingAnswer":{"_command":{"hostType":"Storage",""
> hostId":0,"wait":0},"result":true,"wait":0}}] }
> 2014-10-28 09:38:11,487 DEBUG [utils.script.Script]
> (agentRequest-Handler-1:nulll
> ) Execution is successful.
> 2014-10-28 09:38:11,487 DEBUG [utils.script.Script]
> (agentRequest-Handler-1:nulll
> ) Stopping web server: apache2apache2: Could not reliably determine the
> server'ss
> fully qualified domain name, using 10.147.30.190 for ServerName
> ... waiting .
> Starting web server: apache2apache2: Could not reliably determine the
> server's ff
> ully qualified domain name, using 10.147.30.190 for ServerName
> .
> 2014-10-28 09:38:11,487 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null)
> Seq 1-7097954487712612353: { Ans: , MgmtId: 233845178472723, via: 1, Ver:
> v1, FF
> lags: 110,
> [{"com.cloud.agent.api.SecStorageSetupAnswer":{"_dir":"4a409f9f-33f8--
> 3898-b4b8-39a2e3d01cb1","result":true,"details":"success","wait":0}}] }
> attaching entire cloud.log
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7806) Agent state remians connecting for secondary storage VM
shweta agarwal created CLOUDSTACK-7806:
--
Summary: Agent state remians connecting for secondary storage VM
Key: CLOUDSTACK-7806
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7806
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: SystemVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Priority: Blocker
Fix For: 4.5.0
Attachments: cloud.log
Repro steps :
Create a LXC Zone setup.
Notice Agent status of Secondary storage VM will be connecting once Sceondary
Storage VM is in running state .
SSVM cloud log shows :
2014-10-28 09:38:10,340 DEBUG [utils.script.Script]
(agentRequest-Handler-1:nulll
) Executing: /usr/local/cloud/systemvm/config_ssl.sh -i 10.147.30.190 -h s-1-VM
2014-10-28 09:38:10,377 DEBUG [cloud.agent.Agent] (Agent-Handler-4:null)
Receivee
d response: Seq 0-159: { Ans: , MgmtId: 233845178472723, via: 1, Ver: v1,
Flagss
: 100010,
[{"com.cloud.agent.api.PingAnswer":{"_command":{"hostType":"Storage",""
hostId":0,"wait":0},"result":true,"wait":0}}] }
2014-10-28 09:38:11,487 DEBUG [utils.script.Script]
(agentRequest-Handler-1:nulll
) Execution is successful.
2014-10-28 09:38:11,487 DEBUG [utils.script.Script]
(agentRequest-Handler-1:nulll
) Stopping web server: apache2apache2: Could not reliably determine the
server'ss
fully qualified domain name, using 10.147.30.190 for ServerName
... waiting .
Starting web server: apache2apache2: Could not reliably determine the server's
ff
ully qualified domain name, using 10.147.30.190 for ServerName
.
2014-10-28 09:38:11,487 DEBUG [cloud.agent.Agent] (agentRequest-Handler-1:null)
Seq 1-7097954487712612353: { Ans: , MgmtId: 233845178472723, via: 1, Ver: v1,
FF
lags: 110,
[{"com.cloud.agent.api.SecStorageSetupAnswer":{"_dir":"4a409f9f-33f8--
3898-b4b8-39a2e3d01cb1","result":true,"details":"success","wait":0}}] }
attaching entire cloud.log
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7804) [CEPH] Adding RBD primary storage is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7804: --- Description: Repro steps : 1. Create a LXC zone with NFS primary storage 2. Once System VMs are up add Ceph storage as another primary storage Bug: Storage addition is failing. It goes to initialized state but after some time gets message storage addition failed . attached MS log and Agents log for the same was: Repro steps : 1. Create a LXC zone with NFS primary storage 2. Once System VMs are up add Ceph storage as another primary storage Bug: Storage addition is failing. It goes to initialized state but after some time gets message storage addition failed . > [CEPH] Adding RBD primary storage is failing > -- > > Key: CLOUDSTACK-7804 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7804 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Blocker > Fix For: 4.5.0 > > Attachments: MS.tar.gz, agent.tar.gz > > > Repro steps : > 1. Create a LXC zone with NFS primary storage > 2. Once System VMs are up add Ceph storage as another primary storage > Bug: > Storage addition is failing. It goes to initialized state but after some time > gets message storage addition failed . > attached MS log and Agents log for the same -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7804) [CEPH] Adding RBD primary storage is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7804: --- Attachment: MS.tar.gz > [CEPH] Adding RBD primary storage is failing > -- > > Key: CLOUDSTACK-7804 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7804 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Blocker > Fix For: 4.5.0 > > Attachments: MS.tar.gz, agent.tar.gz > > > Repro steps : > 1. Create a LXC zone with NFS primary storage > 2. Once System VMs are up add Ceph storage as another primary storage > Bug: > Storage addition is failing. It goes to initialized state but after some time > gets message storage addition failed . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7804) [CEPH] Adding RBD primary storage is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7804: --- Attachment: agent.tar.gz > [CEPH] Adding RBD primary storage is failing > -- > > Key: CLOUDSTACK-7804 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7804 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Blocker > Fix For: 4.5.0 > > Attachments: agent.tar.gz > > > Repro steps : > 1. Create a LXC zone with NFS primary storage > 2. Once System VMs are up add Ceph storage as another primary storage > Bug: > Storage addition is failing. It goes to initialized state but after some time > gets message storage addition failed . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7804) [CEPH] Adding RBD primary storage is failing
shweta agarwal created CLOUDSTACK-7804: -- Summary: [CEPH] Adding RBD primary storage is failing Key: CLOUDSTACK-7804 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7804 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Blocker Fix For: 4.5.0 Repro steps : 1. Create a LXC zone with NFS primary storage 2. Once System VMs are up add Ceph storage as another primary storage Bug: Storage addition is failing. It goes to initialized state but after some time gets message storage addition failed . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7568) [LXC] system VM fails to start on LXC host
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal closed CLOUDSTACK-7568.
--
> [LXC] system VM fails to start on LXC host
> ---
>
> Key: CLOUDSTACK-7568
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7568
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Blocker
> Fix For: 4.5.0
>
>
> Repro steps:
> Create a LXC advance zone and enable it . Notice System VMs fails to start.
> Agent log shows :
> 2014-09-17 12:14:12,737 WARN [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-4:null) LibvirtException
> org.libvirt.LibvirtException: unsupported configuration: CPU tuning is not
> available on this host
> 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:1253)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3781)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1347)
> at com.cloud.agent.Agent.processRequest(Agent.java:503)
> at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:810)
> at com.cloud.utils.nio.Task.run(Task.java:84)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> 2014-09-17 12:14:12,738 DEBUG [kvm.storage.KVMStoragePoolManager]
> (agentRequest-Handler-4:null) Disconnecting disk
> 2c68fd25-7f69-4db6-b0d9-3e8072dea698
> 2014-09-17 12:14:12,738 DEBUG [kvm.storage.LibvirtStorageAdaptor]
> (agentRequest-Handler-4:null) Trying to fetch storage pool
> dfa2ec3c-d133-3284-8583-0a0845aa4424 from libvirt
> 2014-09-17 12:14:12,846 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-4:null) Seq 1-4318389092694884367: { Ans: , MgmtId:
> 233845178472723, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":1,"name":"v-1-VM","type":"ConsoleProxy","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":1073741824,"maxRam":1073741824,"arch":"x86_64","os":"Debian
> GNU/Linux 5.0 (64-bit)","platformEmulator":"Debian GNU/Linux 5","bootArgs":"
> template=domP type=consoleproxy host=10.147.28.41 port=8250 name=v-1-VM
> zone=1 pod=1 guid=Proxy.1 proxy_vm=1 disable_rp_filter=true
> eth2ip=10.147.30.160 eth2mask=255.255.255.0 gateway=10.147.30.1
> eth0ip=169.254.1.68 eth0mask=255.255.0.0 eth1ip=10.147.28.167
> eth1mask=255.255.255.0 mgmtcidr=10.147.28.0/24 localgw=10.147.28.1
> internaldns1=10.140.50.6
> dns1=10.140.50.6","enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"vzcOWbWjEvLy75PCdH0IIg==","vncAddr":"10.147.28.49","params":{},"uuid":"b43765e9-c099-45f9-9ceb-8d455f9bf2a7","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"2c68fd25-7f69-4db6-b0d9-3e8072dea698","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"dfa2ec3c-d133-3284-8583-0a0845aa4424","id":1,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/shweta/goleta.lxc.primary","port":2049,"url":"NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=Primary&STOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424"}},"name":"ROOT-1","size":0,"path":"2c68fd25-7f69-4db6-b0d9-3e8072dea698","volumeId":1,"vmName":"v-1-VM","accountId":1,"format":"QCOW2","provisioningType":"THIN","id":1,"deviceId":0,"hypervisorType":"LXC"}},"diskSeq":0,"path":"2c68fd25-7f69-4db6-b0d9-3e8072dea698","type":"ROOT","_details":{"managed":"false","storagePort":"2049","storageHost":"10.147.28.7","volumeSize":"0"}}],"nics":[{"deviceId":2,"networkRateMbps":-1,"defaultNic":true,"pxeDisable":true,"nicUuid":"b1ca319a-0dbf-46c1-84db-f72b1bfa4aa0","uuid":"30ffae39-67d2-47cf-afe7-48e7265dcdd6","ip":"10.147.30.160","netmask":"255.255.255.0","gateway":"10.147.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7569) [LXC] NetworkManager service restarts when we reboot LXC agent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7569. -- > [LXC] NetworkManager service restarts when we reboot LXC agent > -- > > Key: CLOUDSTACK-7569 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7569 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Blocker > Fix For: 4.5.0 > > > Repro steps: > Create a LXC zone. > Once zone is up and enable Reboot LXC host > Bug: > Network manager service starts with reboot of LXC host. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7569) [LXC] NetworkManager service restarts when we reboot LXC agent
shweta agarwal created CLOUDSTACK-7569: -- Summary: [LXC] NetworkManager service restarts when we reboot LXC agent Key: CLOUDSTACK-7569 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7569 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Blocker Fix For: 4.5.0 Repro steps: Create a LXC zone. Once zone is up and enable Reboot LXC host Bug: Network manager service starts with reboot of LXC host. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7497. -- Verified fixed > [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC > --- > > Key: CLOUDSTACK-7497 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang >Priority: Blocker > Labels: DEVREV > Fix For: 4.5.0 > > Attachments: MS.tar.gz, after_checked_in_UI_fix.PNG, cloud.dmp, > jessica_web_site_loaded_with_Shweta_databaseDump_1A.PNG, > jessica_web_site_loaded_with_Shweta_databaseDump_1B.PNG, shweta_website.PNG > > > Repro steps: > Create a LXC zone with 2 cluster one LXc and one KVM > Create VM with LXC template > Bug: > Deploy vm fails as hypervisor type is passed as KVM > 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24) ===START=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:09,581 INFO [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 > ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the > hypervisor type of the template > 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] > (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM > 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] > (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7568) [LXC] system VM fails to start on LXC host
shweta agarwal created CLOUDSTACK-7568:
--
Summary: [LXC] system VM fails to start on LXC host
Key: CLOUDSTACK-7568
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7568
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Blocker
Fix For: 4.5.0
Repro steps:
Create a LXC advance zone and enable it . Notice System VMs fails to start.
Agent log shows :
2014-09-17 12:14:12,737 WARN [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-4:null) LibvirtException
org.libvirt.LibvirtException: unsupported configuration: CPU tuning is not
available on this host
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:1253)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3781)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1347)
at com.cloud.agent.Agent.processRequest(Agent.java:503)
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:810)
at com.cloud.utils.nio.Task.run(Task.java:84)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
2014-09-17 12:14:12,738 DEBUG [kvm.storage.KVMStoragePoolManager]
(agentRequest-Handler-4:null) Disconnecting disk
2c68fd25-7f69-4db6-b0d9-3e8072dea698
2014-09-17 12:14:12,738 DEBUG [kvm.storage.LibvirtStorageAdaptor]
(agentRequest-Handler-4:null) Trying to fetch storage pool
dfa2ec3c-d133-3284-8583-0a0845aa4424 from libvirt
2014-09-17 12:14:12,846 DEBUG [cloud.agent.Agent] (agentRequest-Handler-4:null)
Seq 1-4318389092694884367: { Ans: , MgmtId: 233845178472723, via: 1, Ver: v1,
Flags: 10,
[{"com.cloud.agent.api.StartAnswer":{"vm":{"id":1,"name":"v-1-VM","type":"ConsoleProxy","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":1073741824,"maxRam":1073741824,"arch":"x86_64","os":"Debian
GNU/Linux 5.0 (64-bit)","platformEmulator":"Debian GNU/Linux 5","bootArgs":"
template=domP type=consoleproxy host=10.147.28.41 port=8250 name=v-1-VM zone=1
pod=1 guid=Proxy.1 proxy_vm=1 disable_rp_filter=true eth2ip=10.147.30.160
eth2mask=255.255.255.0 gateway=10.147.30.1 eth0ip=169.254.1.68
eth0mask=255.255.0.0 eth1ip=10.147.28.167 eth1mask=255.255.255.0
mgmtcidr=10.147.28.0/24 localgw=10.147.28.1 internaldns1=10.140.50.6
dns1=10.140.50.6","enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"vzcOWbWjEvLy75PCdH0IIg==","vncAddr":"10.147.28.49","params":{},"uuid":"b43765e9-c099-45f9-9ceb-8d455f9bf2a7","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"2c68fd25-7f69-4db6-b0d9-3e8072dea698","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"dfa2ec3c-d133-3284-8583-0a0845aa4424","id":1,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/shweta/goleta.lxc.primary","port":2049,"url":"NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=Primary&STOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424"}},"name":"ROOT-1","size":0,"path":"2c68fd25-7f69-4db6-b0d9-3e8072dea698","volumeId":1,"vmName":"v-1-VM","accountId":1,"format":"QCOW2","provisioningType":"THIN","id":1,"deviceId":0,"hypervisorType":"LXC"}},"diskSeq":0,"path":"2c68fd25-7f69-4db6-b0d9-3e8072dea698","type":"ROOT","_details":{"managed":"false","storagePort":"2049","storageHost":"10.147.28.7","volumeSize":"0"}}],"nics":[{"deviceId":2,"networkRateMbps":-1,"defaultNic":true,"pxeDisable":true,"nicUuid":"b1ca319a-0dbf-46c1-84db-f72b1bfa4aa0","uuid":"30ffae39-67d2-47cf-afe7-48e7265dcdd6","ip":"10.147.30.160","netmask":"255.255.255.0","gateway":"10.147.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7546) [LXC] agent addition to MS is failing if we stop service NetworkManager
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7546. -- > [LXC] agent addition to MS is failing if we stop service NetworkManager > > > Key: CLOUDSTACK-7546 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7546 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Blocker > Fix For: 4.5.0 > > > Repro Steps: > 1. Install MS and agent on two different host > 2. Stop networkmanager on host and also chkconfig networkmanager off > 3. Create a Advance zone with LXC > Bug: > Agent addition to CS will fail > agent log shows : > 2014-09-15 16:38:26,027 ERROR [cloud.agent.AgentShell] (main:null) Unable to > start agent: > com.cloud.utils.exception.CloudRuntimeException: Failed to connect socket to > '/var/run/libvirt/libvirt-sock': No such file or directory > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:830) > at com.cloud.agent.Agent.(Agent.java:163) > at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:401) > at > com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:371) > at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:355) > at com.cloud.agent.AgentShell.start(AgentShell.java:465) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243) > 2014-09-15 16:39:37,406 INFO [cloud.agent.AgentShell] (main:null) Agent > started > Additional info : > checked Libvirtd status once agent fails to start and status was stopped in > above scenario > But if we dont stop networkmanager service before adding agent to CS then > agent addition succeeds without fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133816#comment-14133816 ] shweta agarwal commented on CLOUDSTACK-7497: n now my setup is different so you cant reproduce it on my setup > [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC > --- > > Key: CLOUDSTACK-7497 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang >Priority: Blocker > Fix For: 4.5.0 > > Attachments: MS.tar.gz, cloud.dmp, > jessica_web_site_loaded_with_Shweta_databaseDump_1A.PNG, > jessica_web_site_loaded_with_Shweta_databaseDump_1B.PNG, shweta_website.PNG > > > Repro steps: > Create a LXC zone with 2 cluster one LXc and one KVM > Create VM with LXC template > Bug: > Deploy vm fails as hypervisor type is passed as KVM > 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24) ===START=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:09,581 INFO [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 > ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the > hypervisor type of the template > 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] > (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM > 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] > (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133814#comment-14133814 ] shweta agarwal commented on CLOUDSTACK-7497: Jessica , I reproduced this bug several times on several different browser. Let me write repro steps for you more clearly : 1. Create a zone with 2 cluster . One LXC cluster and One KVM cluster 2. Register LXC template 3. Create a KVM VM first . Very important step. 4. Now create a LXC VM Bug: API error Deploy vm fails as hypervisor type is passed as KVM > [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC > --- > > Key: CLOUDSTACK-7497 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang >Priority: Blocker > Fix For: 4.5.0 > > Attachments: MS.tar.gz, cloud.dmp, > jessica_web_site_loaded_with_Shweta_databaseDump_1A.PNG, > jessica_web_site_loaded_with_Shweta_databaseDump_1B.PNG, shweta_website.PNG > > > Repro steps: > Create a LXC zone with 2 cluster one LXc and one KVM > Create VM with LXC template > Bug: > Deploy vm fails as hypervisor type is passed as KVM > 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24) ===START=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:09,581 INFO [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 > ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the > hypervisor type of the template > 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] > (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM > 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] > (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7497: --- Assignee: Jessica Wang (was: shweta agarwal) > [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC > --- > > Key: CLOUDSTACK-7497 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang >Priority: Blocker > Fix For: 4.5.0 > > Attachments: MS.tar.gz, cloud.dmp, > jessica_web_site_loaded_with_Shweta_databaseDump_1A.PNG, > jessica_web_site_loaded_with_Shweta_databaseDump_1B.PNG, shweta_website.PNG > > > Repro steps: > Create a LXC zone with 2 cluster one LXc and one KVM > Create VM with LXC template > Bug: > Deploy vm fails as hypervisor type is passed as KVM > 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24) ===START=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:09,581 INFO [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 > ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the > hypervisor type of the template > 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] > (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM > 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] > (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7546) [LXC] agent addition to MS is failing if we stop service NetworkManager
shweta agarwal created CLOUDSTACK-7546: -- Summary: [LXC] agent addition to MS is failing if we stop service NetworkManager Key: CLOUDSTACK-7546 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7546 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Blocker Fix For: 4.5.0 Repro Steps: 1. Install MS and agent on two different host 2. Stop networkmanager on host and also chkconfig networkmanager off 3. Create a Advance zone with LXC Bug: Agent addition to CS will fail agent log shows : 2014-09-15 16:38:26,027 ERROR [cloud.agent.AgentShell] (main:null) Unable to start agent: com.cloud.utils.exception.CloudRuntimeException: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:830) at com.cloud.agent.Agent.(Agent.java:163) at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:401) at com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:371) at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:355) at com.cloud.agent.AgentShell.start(AgentShell.java:465) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243) 2014-09-15 16:39:37,406 INFO [cloud.agent.AgentShell] (main:null) Agent started Additional info : checked Libvirtd status once agent fails to start and status was stopped in above scenario But if we dont stop networkmanager service before adding agent to CS then agent addition succeeds without fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7314) [LXC] getting libvirt exception while stopping VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7314. -- Resolution: Fixed > [LXC] getting libvirt exception while stopping VM > - > > Key: CLOUDSTACK-7314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7314 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala > Fix For: 4.5.0 > > Attachments: agent.log > > > Repro steps: > 1. Create a LXC VM > 2. Stop the VM > Bug: > Even though VM stops Agent log show exception > Failed to stop VM :i-2-71-VM : > org.libvirt.LibvirtException: Mount namespaces are not available on this > platform: Function not implemented > at org.libvirt.ErrorHandler.processError(Unknown Source) > at org.libvirt.Connect.processError(Unknown Source) > at org.libvirt.Domain.processError(Unknown Source) > at org.libvirt.Domain.shutdown(Unknown Source) > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.stopVM(LibvirtComputingResource.java:4566) > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.stopVM(LibvirtComputingResource.java:4505) > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3478) > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1262) > at com.cloud.agent.Agent.processRequest(Agent.java:501) > at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808) > at com.cloud.utils.nio.Task.run(Task.java:84) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java: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.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7401) [LXC] storage migration for LXC VMs are failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal closed CLOUDSTACK-7401.
--
Resolution: Fixed
> [LXC] storage migration for LXC VMs are failing
> ---
>
> Key: CLOUDSTACK-7401
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7401
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
> Fix For: 4.5.0
>
>
> Repro steps :
> Create a LXC VM in a zone having two primary shared storage
> stop the vm
> Migrate the root disk of VM to another Primary storage
> Bug:
> migration fails with java NPE
> Expection :
> either enable storage migration or gracefully handle it by giving proper
> message
> MS log shows :
> 2014-08-22 16:37:03,606 DEBUG [o.a.c.s.c.a.StorageCacheRandomAllocator]
> (Work-Job-Executor-117:ctx-b8749277 job-640/job-641 ctx-3675a1df) Can't find
> staging storage in zone: 2
> 2014-08-22 16:37:03,662 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-117:ctx-b8749277 job-640/job-641 ctx-3675a1df) Seq
> 2-5838635441909144321: Sending { Cmd , MgmtId: 233845178472597, via:
> 2(Rack3Pod1Host42), Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"1317fed3-0666-45b4-8849-0316206c58e7","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"2a4208e2-8f5e-3b6a-bede-315c90250d0a","id":6,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/shweta/goleta.lxc.primary1","port":2049,"url":"NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary1/?ROLE=Primary&STOREUUID=2a4208e2-8f5e-3b6a-bede-315c90250d0a"}},"name":"ROOT-76","size":550604800,"path":"1317fed3-0666-45b4-8849-0316206c58e7","volumeId":80,"vmName":"i-2-76-VM","accountId":2,"provisioningType":"THIN","id":80,"deviceId":0,"hypervisorType":"LXC"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"1317fed3-0666-45b4-8849-0316206c58e7","volumeType":"ROOT","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.147.28.7/export/home/shweta/goleta.lxc.secondary","_role":"Image"}},"name":"ROOT-76","size":550604800,"path":"volumes/2/80","volumeId":80,"vmName":"i-2-76-VM","accountId":2,"provisioningType":"THIN","id":80,"deviceId":0,"hypervisorType":"LXC"}},"executeInSequence":false,"options":{},"wait":10800}}]
> }
> 2014-08-22 16:37:03,665 DEBUG [c.c.a.t.Request] (AgentManager-Handler-2:null)
> Seq 2-5838635441909144321: Processing: { Ans: , MgmtId: 233845178472597,
> via: 2, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"java.lang.NullPointerException\n\tat
>
> com.cloud.hypervisor.kvm.storage.KVMStorageProcessor.copyVolumeFromPrimaryToSecondary(KVMStorageProcessor.java:438)\n\tat
>
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:89)\n\tat
>
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:53)\n\tat
>
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1356)\n\tat
> com.cloud.agent.Agent.processRequest(Agent.java:503)\n\tat
> com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:810)\n\tat
> com.cloud.utils.nio.Task.run(Task.java:84)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat
> java.lang.Thread.run(Thread.java:744)\n","wait":0}}] }
> 2014-08-22 16:37:03,665 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-117:ctx-b8749277 job-640/job-641 ctx-3675a1df) Seq
> 2-5838635441909144321: Received: { Ans: , MgmtId: 233845178472597, via: 2,
> Ver: v1, Flags: 10, { Answer } }
> 2014-08-22 16:37:03,665 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
> (Work-Job-Executor-117:ctx-b8749277 job-640/job-641 ctx-3675a1df) copy to
> image store failed: java.lang.NullPointerException
> at
> com.cloud.hypervisor.kvm.storage.KVMStorageProcessor.copyVolumeFromPrimaryToSecondary(KVMStorageProcessor.java:438)
> at
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:89)
> at
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:53)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1356)
> at com.cloud.agent.Agent.proces
[jira] [Closed] (CLOUDSTACK-7403) [LXC] download root volume for stopped VM is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal closed CLOUDSTACK-7403.
--
Resolution: Fixed
feature not supported
> [LXC] download root volume for stopped VM is failing
> -
>
> Key: CLOUDSTACK-7403
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7403
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Storage Controller
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
> Fix For: 4.5.0
>
>
> Repro steps:
> Create a LXC VM
> Stop the VM
> Download root volume of the VM
> Bug:
> it fails with error message Failed to copy the volume from the source primary
> storage pool to secondary storage.
> Ms log shows :
> 014-08-22 17:38:22,219 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-5:ctx-dadec6c2 ctx-4f82d146) submit async job-648, details:
> AsyncJobVO {id:648, userId: 2, accountId: 2, instanceType: Volume,
> instanceId: 80, cmd:
> org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd, cmdInfo:
> {"id":"1317fed3-0666-45b4-8849-0316206c58e7","response":"json","sessionkey":"BC5+3ivJ/aXytluoUicBfBzviOQ\u003d","ctxDetails":"{\"com.cloud.storage.Volume\":\"1317fed3-0666-45b4-8849-0316206c58e7\",\"com.cloud.dc.DataCenter\":\"b2be995b-c505-4d3c-a1bb-e8b019d5611c\"}","cmdEventType":"VOLUME.EXTRACT","ctxUserId":"2","zoneid":"b2be995b-c505-4d3c-a1bb-e8b019d5611c","httpmethod":"GET","_":"1408709304879","uuid":"1317fed3-0666-45b4-8849-0316206c58e7","ctxAccountId":"2","ctxStartEventId":"1036","mode":"HTTP_DOWNLOAD"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 233845178472597, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-08-22 17:38:22,219 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-8:ctx-4c88ae36 job-648) Add job-648 into job monitoring
> 2014-08-22 17:38:22,219 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-8:ctx-4c88ae36 job-648) Executing AsyncJobVO {id:648,
> userId: 2, accountId: 2, instanceType: Volume, instanceId: 80, cmd:
> org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd, cmdInfo:
> {"id":"1317fed3-0666-45b4-8849-0316206c58e7","response":"json","sessionkey":"BC5+3ivJ/aXytluoUicBfBzviOQ\u003d","ctxDetails":"{\"com.cloud.storage.Volume\":\"1317fed3-0666-45b4-8849-0316206c58e7\",\"com.cloud.dc.DataCenter\":\"b2be995b-c505-4d3c-a1bb-e8b019d5611c\"}","cmdEventType":"VOLUME.EXTRACT","ctxUserId":"2","zoneid":"b2be995b-c505-4d3c-a1bb-e8b019d5611c","httpmethod":"GET","_":"1408709304879","uuid":"1317fed3-0666-45b4-8849-0316206c58e7","ctxAccountId":"2","ctxStartEventId":"1036","mode":"HTTP_DOWNLOAD"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 233845178472597, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-08-22 17:38:22,219 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-5:ctx-dadec6c2 ctx-4f82d146) ===END=== 10.146.0.131 -- GET
> command=extractVolume&id=1317fed3-0666-45b4-8849-0316206c58e7&zoneid=b2be995b-c505-4d3c-a1bb-e8b019d5611c&mode=HTTP_DOWNLOAD&response=json&sessionkey=BC5%2B3ivJ%2FaXytluoUicBfBzviOQ%3D&_=1408709304879
> 2014-08-22 17:38:22,318 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
> (API-Job-Executor-8:ctx-4c88ae36 job-648 ctx-2287787f) copyAsync inspecting
> src type VOLUME copyAsync inspecting dest type VOLUME
> 2014-08-22 17:38:22,327 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-8:ctx-4c88ae36 job-648 ctx-2287787f) Seq
> 9-7487234380503450103: Sending { Cmd , MgmtId: 233845178472597, via:
> 9(Rack3Pod1Host52), Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"1317fed3-0666-45b4-8849-0316206c58e7","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"2a4208e2-8f5e-3b6a-bede-315c90250d0a","id":6,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/shweta/goleta.lxc.primary1","port":2049,"url":"NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary1/?ROLE=Primary&STOREUUID=2a4208e2-8f5e-3b6a-bede-315c90250d0a"}},"name":"ROOT-76","size":550604800,"path":"1317fed3-0666-45b4-8849-0316206c58e7","volumeId":80,"vmName":"i-2-76-VM","accountId":2,"provisioningType":"THIN","id":80,"deviceId":0,"hypervisorType":"LXC"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"1317fed3-0666-45b4-8849-0316206c58e7","volumeType":"ROOT","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.147.28.7/export/home/shweta/goleta.lxc.secondary","_role":"Image"}},"name"
[jira] [Closed] (CLOUDSTACK-7251) [LXC] VM installation fails when using local storage as primary storage
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal closed CLOUDSTACK-7251.
--
Resolution: Fixed
> [LXC] VM installation fails when using local storage as primary storage
> ---
>
> Key: CLOUDSTACK-7251
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7251
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
> Fix For: 4.5.0
>
>
> Repro steps:
> Create a LXC setup with local storage enabled
> create a service offering with local storage
> create a VM with theta service offering
> Bug:
> VM creation error out
> MS log shows :
> 2014-08-05 05:01:56,832 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-17:ctx-66f0332c job-200/job-201 ctx-1f8afb7d) Seq
> 1-8575416640466846714: Sending { Cmd , MgmtId: 233845177509765, via:
> 1(Rack1Pod1Host23), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.StartCommand":{"vm":{"id":17,"name":"i-2-17-VM","type":"User","cpus":1,"minSpeed":128,"maxSpeed":128,"minRam":134217728,"maxRam":134217728,"arch":"x86_64","os":"CentOS
> 6.4
> (64-bit)","platformEmulator":"Other","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"f7a4e3e8e4fec4f9","params":{},"uuid":"5cfab85b-ceae-4df0-ac0e-a07a84bda843","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"0b021367-8870-495f-93b0-f28e3d0e86d7","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"2bbf9d08-b442-4a87-9f26-41d39679747b","id":3,"poolType":"Filesystem","host":"10.147.40.23","path":"/var/lib/libvirt/images","port":0,"url":"Filesystem://10.147.40.23/var/lib/libvirt/images/?ROLE=Primary&STOREUUID=2bbf9d08-b442-4a87-9f26-41d39679747b"}},"name":"ROOT-17","size":0,"path":"0b021367-8870-495f-93b0-f28e3d0e86d7","volumeId":18,"vmName":"i-2-17-VM","accountId":2,"provisioningType":"THIN","id":18,"deviceId":0,"hypervisorType":"LXC"}},"diskSeq":0,"path":"0b021367-8870-495f-93b0-f28e3d0e86d7","type":"ROOT","_details":{"managed":"false","storagePort":"0","storageHost":"10.147.40.23","volumeSize":"0"}},{"data":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"ISO"}],"nics":[{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"pxeDisable":false,"nicUuid":"065d160a-9bd8-4d34-b9ea-655014468157","uuid":"675b6a8c-2ab1-4ea1-bf20-3ddd910b9ecd","ip":"10.1.1.232","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:4a:e1:00:0b","dns1":"10.140.50.6","dns2":"","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://1046","isolationUri":"vlan://1046","isSecurityGroupEnabled":false}]},"hostIp":"10.147.40.23","executeInSequence":false,"wait":0}}]
> }
> 2014-08-05 05:01:57,272 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-21:ctx-3c782bac) ===START=== 10.146.0.131 -- GET
> command=queryAsyncJobResult&jobId=80f71511-b142-4d46-8108-697905b62179&response=json&sessionkey=X745JY%2BC0rOgkt4Sbx3muCB1eJQ%3D&_=1407229318792
> 2014-08-05 05:01:57,332 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-21:ctx-3c782bac ctx-2802cc3d) ===END=== 10.146.0.131 -- GET
> command=queryAsyncJobResult&jobId=80f71511-b142-4d46-8108-697905b62179&response=json&sessionkey=X745JY%2BC0rOgkt4Sbx3muCB1eJQ%3D&_=1407229318792
> 2014-08-05 05:01:57,355 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-1:ctx-a0a21868) HostStatsCollector is running...
> 2014-08-05 05:01:57,361 WARN [o.a.c.f.j.AsyncJobExecutionContext]
> (StatsCollector-1:ctx-a0a21868) Job is executed without a context, setup
> psudo job for the executing thread
> 2014-08-05 05:01:58,006 DEBUG [c.c.a.t.Request]
> (StatsCollector-1:ctx-a0a21868) Seq 1-8575416640466846715: Received: { Ans:
> , MgmtId: 233845177509765, via: 1, Ver: v1, Flags: 10, { GetHostStatsAnswer }
> }
> 2014-08-05 05:01:58,059 DEBUG [c.c.h.d.HostDaoImpl] (ClusteredAgentManager
> Timer:ctx-599ebf73) Resetting hosts suitable for reconnect
> 2014-08-05 05:01:58,060 DEBUG [c.c.h.d.HostDaoImpl] (ClusteredAgentManager
> Timer:ctx-599ebf73) Completed resetting hosts suitable for reconnect
> 2014-08-05 05:01:58,060 DEBUG [c.c.h.d.HostDaoImpl] (ClusteredAgentManager
> Timer:ctx-599ebf73) Acquiring hosts for clusters already owned by this
> management server
> 2014-08-05 05:01:58,061 DEBUG [c.c.h.d.HostDaoImpl] (ClusteredAgentManager
> Timer:ctx-599ebf73) Completed acquiring hosts for clusters already owned by
> this management server
> 2014-08-05 05:01:58,061 DEBUG [c.c.h.d.HostDaoImpl] (ClusteredAgentManager
> Timer:ctx-599ebf73) Acquiring hosts for clusters not owne
[jira] [Closed] (CLOUDSTACK-7252) [LXC] VM not starting for first time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7252. -- Resolution: Fixed > [LXC] VM not starting for first time > > > Key: CLOUDSTACK-7252 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7252 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala > Fix For: 4.5.0 > > > Repro steps: > Create a LXC zone using LXC host on rhel 6.x > register a LXC template > Create a VM > when VM is running try accessing vm console using virsh > Bug : > console view shows : > Connected to domain i-2-15-VM > Escape character is ^] > Welcome to CentOS > Starting udev: /bin/mknod: `/dev/loop0': Operation not permitted > /bin/chown: cannot access `/dev/loop0': No such file or directory > /bin/mknod: `/dev/loop1': Operation not permitted > /bin/chown: cannot access `/dev/loop1': No such file or directory > /bin/mknod: `/dev/loop2': Operation not permitted > /bin/chown: cannot access `/dev/loop2': No such file or directory > /bin/mknod: `/dev/loop3': Operation not permitted > /bin/chown: cannot access `/dev/loop3': No such file or directory > /bin/mknod: `/dev/loop4': Operation not permitted > /bin/chown: cannot access `/dev/loop4': No such file or directory > /bin/mknod: `/dev/loop5': Operation not permitted > /bin/chown: cannot access `/dev/loop5': No such file or directory > /bin/mknod: `/dev/loop6': Operation not permitted > /bin/chown: cannot access `/dev/loop6': No such file or directory > /bin/mknod: `/dev/loop7': Operation not permitted > /bin/chown: cannot access `/dev/loop7': No such file or directory > /bin/mknod: `/dev/lp0': Operation not permitted > /bin/chown: cannot access `/dev/lp0': No such file or directory > /bin/mknod: `/dev/lp1': Operation not permitted > /bin/chown: cannot access `/dev/lp1': No such file or directory > /bin/mknod: `/dev/lp2': Operation not permitted > /bin/chown: cannot access `/dev/lp2': No such file or directory > /bin/mknod: `/dev/lp3': Operation not permitted > /bin/chown: cannot access `/dev/lp3': No such file or directory > /bin/mknod: `/dev/net/tun': Operation not permitted > /bin/mknod: `/dev/ppp': Operation not permitted > /bin/mknod: `/dev/fuse': Operation not permitted > /sbin/start_udev: line 269: /proc/sys/kernel/hotplug: Read-only file system > /sbin/start_udev: line 299: /etc/sysconfig/network: No such file or directory >[ OK ] > Setting hostname Rack1Pod1Host23: [ OK ] > Checking filesystems > WARNING: couldn't open /etc/fstab: No such file or directory >[ OK ] > warning: can't open /etc/fstab: No such file or directory > mount: can't find / in /etc/fstab or /etc/mtab > Mounting local filesystems: warning: can't open /etc/fstab: No such file or > directory >[ OK ] > Enabling /etc/fstab swaps: swapon: /etc/fstab: open failed: No such file or > directory >[FAILED] > Additional info : > do a stop /start of VM and VM starts correctly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7171) not getting console of user vm via virsh on kvm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7171: --- Priority: Minor (was: Blocker) > not getting console of user vm via virsh on kvm > --- > > Key: CLOUDSTACK-7171 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7171 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 > Environment: KMV host on centos6.2 > advance zone >Reporter: shweta agarwal >Assignee: Murali Reddy >Priority: Minor > Fix For: 4.5.0 > > Attachments: MSlog.tar.gz, kvmhostlog.tar.gz > > > Repro steps: > Create a KVM(centos6.2) advance zone setup . Once everything is uop created a > user vm with default centos 5.5 template > On KVM host try to access console of this user vm via vrish > Bug : > Nothing happens > I even tried registering ubuntu template and created a ubuntu VM still not > able to access console via virsh for ubuntu VM as well > But able to access console via virsh for system vms , CPVM, SSVM, router vm > Attaching MS logs and kvm logs for the same -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7172) not getting Console view of vms in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal closed CLOUDSTACK-7172.
--
Resolution: Fixed
> not getting Console view of vms in KVM
> ---
>
> Key: CLOUDSTACK-7172
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7172
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
> Environment: KVM advance zone on build
> CloudPlatform-4.5.0-78-rhel6.3.tar.gz
>Reporter: shweta agarwal
>Assignee: Murali Reddy
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: MSlog.tar.gz, kvmhostlog.tar.gz
>
>
> Repro steps:
> 1. Create an advacne zone with KVM host .
> 2. Once system vms are up and running try accessing console view of vm
> Bug :
> Console view not coming up getting message The connection was reset
> Ms log shows :
> 014-07-23 04:38:06,662 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-5:null) Ping from 3
> 2014-07-23 04:38:09,002 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-4:null) SeqA 2-9868: Processing Seq 2-9868: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":1,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-07-23 04:38:09,049 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-4:null) SeqA 2-9868: Sending Seq 2-9868: { Ans: ,
> MgmtId: 233845177509765, via: 2, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2014-07-23 04:38:18,964 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-13:null) SeqA 2-9869: Processing Seq 2-9869: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":1,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-07-23 04:38:19,034 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-13:null) SeqA 2-9869: Sending Seq 2-9869: { Ans: ,
> MgmtId: 233845177509765, via: 2, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2014-07-23 04:38:21,992 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-4:ctx-a44d6b26) AutoScaling Monitor is running...
> 2014-07-23 04:38:27,328 DEBUG [c.c.c.ConsoleProxyManagerImpl]
> (consoleproxy-1:ctx-2fbab117) Zone 1 is ready to launch console proxy
> 2014-07-23 04:38:27,451 DEBUG [o.a.c.s.SecondaryStorageManagerImpl]
> (secstorage-1:ctx-99b6542a) Zone 1 is ready to launch secondary storage VM
> 2014-07-23 04:38:28,964 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-20:null) SeqA 2-9870: Processing Seq 2-9870: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":1,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-07-23 04:38:29,029 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-20:null) SeqA 2-9870: Sending Seq 2-9870: { Ans: ,
> MgmtId: 233845177509765, via: 2, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> attaching agent and MS logs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7097) failing to add kvm host to MS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7097. -- > failing to add kvm host to MS > -- > > Key: CLOUDSTACK-7097 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7097 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Management Server >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > Attachments: management-server.log.tar.gz > > > Repro steps: > Create a agent on rhel 6.3 > create a MS on rhel 6.3 > Try creating a zone > Bug : zone creation fails at adding host step > MS log shows : > 014-07-11 03:33:46,284 WARN [c.c.a.d.ParamGenericValidationWorker] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Received unknown parameters for > command addHost. Unknown parameters : clustertype > 2014-07-11 03:33:46,294 INFO [c.c.r.ResourceManagerImpl] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Trying to add a new host at > http://10.147.40.24 in data center 1 > 2014-07-11 03:33:46,487 DEBUG [c.c.u.s.SSHCmdHelper] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm > 2014-07-11 03:33:47,505 DEBUG [c.c.u.s.SSHCmdHelper] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm > 2014-07-11 03:33:48,556 DEBUG [c.c.u.s.SSHCmdHelper] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm > 2014-07-11 03:33:49,607 DEBUG [c.c.h.k.d.LibvirtServerDiscoverer] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) It's not a KVM enabled machine > 2014-07-11 03:33:49,608 WARN [c.c.r.ResourceManagerImpl] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Unable to find the server > resources at http://10.147.40.24 > 2014-07-11 03:33:49,611 INFO [c.c.u.e.CSExceptionErrorCode] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Could not find exception: > com.cloud.exception.DiscoveryException in error code list for exceptions > 2014-07-11 03:33:49,611 WARN [o.a.c.a.c.a.h.AddHostCmd] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Exception: > com.cloud.exception.DiscoveryException: Unable to add the host > at > com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:791) > at > com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586) > 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 $Proxy148.discoverHosts(Unknown Source) > at > org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517) > at > com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) > 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.ApiServlet.processRequest(ApiServlet.java:115) > at com.cloud.api.ApiServlet.doPost(ApiServlet.java:82) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) >
[jira] [Closed] (CLOUDSTACK-7116) unable to add KVM host to MS with error java.lang.UnsupportedClassVersionError: com/cloud/agent/AgentShell : Unsupported major.minor version 51.0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7116. -- > unable to add KVM host to MS with error > java.lang.UnsupportedClassVersionError: com/cloud/agent/AgentShell : > Unsupported major.minor version 51.0 > - > > Key: CLOUDSTACK-7116 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7116 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Damodar Reddy T >Priority: Blocker > Fix For: 4.5.0 > > Attachments: cloudstack-agent.err, management-server.log.tar.gz > > > Repro steps: > 1. Create a KVM host on rhel 6.3 > As I used following build > http://repo-ccp.citrix.com/releases/ASF/rhel/6.3/master/CloudPlatform-4.5.0-57-rhel6.3.tar.gz > so i need to install jsvc outside of cloudstack for which I have done the > following step: > yum install java-gcj-compat > rpm -Uvh > ftp://rpmfind.net/linux/centos/6.5/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > and then I installed agent > Once agent installation is complete I tried to add this KVM host to MS > and host addition failed with MS logs showing > 2014-07-16 06:09:19,082 DEBUG [c.c.h.k.d.LibvirtServerDiscoverer] > (catalina-exec-7:ctx-ec9fe1d8 ctx-949d2702) Timeout, to wait for the host > connecting to mgt svr, assuming it is failed > 2014-07-16 06:09:19,083 WARN [c.c.r.ResourceManagerImpl] > (catalina-exec-7:ctx-ec9fe1d8 ctx-949d2702) Unable to find the server > resources at http://10.147.40.23 > 2014-07-16 06:09:19,084 INFO [c.c.u.e.CSExceptionErrorCode] > (catalina-exec-7:ctx-ec9fe1d8 ctx-949d2702) Could not find exception: > com.cloud.exception.DiscoveryException in error code list for exceptions > 2014-07-16 06:09:19,084 WARN [o.a.c.a.c.a.h.AddHostCmd] > (catalina-exec-7:ctx-ec9fe1d8 ctx-949d2702) Exception: > com.cloud.exception.DiscoveryException: Unable to add the host > at > com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:791) > at > com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586) > 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 $Proxy148.discoverHosts(Unknown Source) > at > org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517) > at > com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) > 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.ApiServlet.processRequest(ApiServlet.java:115) > at com.cloud.api.ApiServlet.doPost(ApiServlet.java:82) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicati
[jira] [Closed] (CLOUDSTACK-7316) hitting java.lang.reflect.InvocationTargetException while starting usage server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7316. -- Resolution: Fixed > hitting java.lang.reflect.InvocationTargetException while starting usage > server > --- > > Key: CLOUDSTACK-7316 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7316 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Damodar Reddy T >Priority: Blocker > Fix For: 4.5.0 > > Attachments: usage.tar.gz > > > Repro steps: > Install MS and usage server > Start MS and usage server > Bug: > Usage server will stop after starting > usage log shows : > java.lang.reflect.InvocationTargetException > 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.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243) > Caused by: org.springframework.beans.factory.BeanCreationException: Error > creating bean with name 'vmDiskUsageParser': Injection of autowired > dependencies failed; nested exception is > org.springframework.beans.factory.BeanCreationException: Could not autowire > field: private com.cloud.usage.dao.UsageDao > com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'usageDaoImpl' defined in URL > [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]: > BeanPostProcessor before instantiation of bean failed; nested exception is > net.sf.cglib.core.CodeGenerationException: > java.lang.ExceptionInInitializerError-->null > at > org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:288) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1116) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628) > at > org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932) > at > org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479) > at > org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:139) > at > org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:83) > at com.cloud.usage.UsageServer.start(UsageServer.java:57) > ... 5 more > Caused by: org.springframework.beans.factory.BeanCreationException: Could not > autowire field: private com.cloud.usage.dao.UsageDao > com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'usageDaoImpl' defined in URL > [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]: > BeanPostProcessor before instantiation of bean failed; nested exception is > net.sf.cglib.core.CodeGenerationException: > java.lang.ExceptionInInitializerError-->null > at > org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:5
[jira] [Closed] (CLOUDSTACK-7397) [LXC][Rhel7] add libcgroup-tools dependency in agent installation on rhel7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7397. -- > [LXC][Rhel7] add libcgroup-tools dependency in agent installation on rhel7 > -- > > Key: CLOUDSTACK-7397 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7397 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Blocker > Fix For: 4.5.0 > > > [LXC][Rhel7] add libcgroup-tools dependency in agent installation on rhel7 > for more details > http://docs.fedoraproject.org/en-US/Fedora/16/html/Resource_Management_Guide/ch-Using_Control_Groups.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7211) system VM not coming up in LXC zone for rhel 6.x
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7211. -- > system VM not coming up in LXC zone for rhel 6.x > -- > > Key: CLOUDSTACK-7211 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7211 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Amogh Vasekar >Priority: Blocker > Fix For: 4.5.0 > > Attachments: MS.tar.gz, agent.tar.gz > > > created a zone with LXC hypervisor on rhel 6.3 host > Pre seeded the KVM template as LXC > On enabling zone Syemt VMs are not coming up > Agent log shows : > ttempting to create storage pool dfa2ec3c-d133-3284-8583-0a0845aa4424 > (NetworkFilesystem) in libvirt > 2014-07-31 04:56:50,260 INFO [kvm.storage.LibvirtStorageAdaptor] > (agentRequest-Handler-1:null) Attempting to create storage pool > 4032a858-88b0-3c03-8477-8984eb6b390b (NetworkFilesystem) in libvirt > 2014-07-31 04:56:50,417 INFO [kvm.storage.LibvirtStorageAdaptor] > (agentRequest-Handler-1:null) Attempting to create volume > 1c123c1a-1873-11e4-87de-4524e40b898e (NetworkFilesystem) in pool > dfa2ec3c-d133-3284-8583-0a0845aa4424 with size 262144 > 2014-07-31 04:57:14,052 INFO [kvm.storage.LibvirtStorageAdaptor] > (agentRequest-Handler-1:null) Attempting to remove storage pool > 4032a858-88b0-3c03-8477-8984eb6b390b from libvirt > 2014-07-31 04:57:14,388 INFO [kvm.storage.LibvirtStorageAdaptor] > (agentRequest-Handler-2:null) Creating volume > 75d88b46-1b93-4065-a348-460b8d3911fb from template > 1c123c1a-1873-11e4-87de-4524e40b898e in pool > dfa2ec3c-d133-3284-8583-0a0845aa4424 (NetworkFilesystem) with size 0 > 2014-07-31 04:57:14,389 INFO [kvm.storage.LibvirtStorageAdaptor] > (agentRequest-Handler-2:null) Attempting to create volume > 75d88b46-1b93-4065-a348-460b8d3911fb (NetworkFilesystem) in pool > dfa2ec3c-d133-3284-8583-0a0845aa4424 with size 262144 > 2014-07-31 04:57:14,948 WARN [cloud.agent.Agent] > (agentRequest-Handler-3:null) Caught: > java.lang.NullPointerException > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.createVif(LibvirtComputingResource.java:3990) > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.createVifs(LibvirtComputingResource.java:3733) > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3766) > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1332) > at com.cloud.agent.Agent.processRequest(Agent.java:501) > at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808) > at com.cloud.utils.nio.Task.run(Task.java:84) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > 2014-07-31 04:57:15,700 INFO [kvm.storage.LibvirtStorageAdaptor] > (agentRequest-Handler-5:null) Creating volume > cac2c108-9f11-4ad7-981e-92a4a0bd05d4 from template > 1c123c1a-1873-11e4-87de-4524e40b898e in pool > dfa2ec3c-d133-3284-8583-0a0845aa4424 (NetworkFilesystem) with size 0 > 2014-07-31 04:57:15,701 INFO [kvm.storage.LibvirtStorageAdaptor] > (agentRequest-Handler-5:null) Attempting to create volume > cac2c108-9f11-4ad7-981e-92a4a0bd05d4 (NetworkFilesystem) in pool > dfa2ec3c-d133-3284-8583-0a0845aa4424 with size 262144 > 2014-07-31 04:57:16,262 WARN [cloud.agent.Agent] > (agentRequest-Handler-1:null) Caught: > java.lang.NullPointerException > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.createVif(LibvirtComputingResource.java:3990) > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.createVifs(LibvirtComputingResource.java:3733) > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3766) > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1332) > at com.cloud.agent.Agent.processRequest(Agent.java:501) > at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808) > at com.cloud.utils.nio.Task.run(Task.java:84) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java: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 JIR
[jira] [Closed] (CLOUDSTACK-7315) [LXC] libvirt Exception when deleting volume as a part of expunge VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal closed CLOUDSTACK-7315.
--
> [LXC] libvirt Exception when deleting volume as a part of expunge VM
>
>
> Key: CLOUDSTACK-7315
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7315
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: agent.log
>
>
> Repro steps:
> Create a LXC VM
> Destroy the VM with expunge=true :
> Agent log shows following exception :
> Instructing libvirt to remove volume c24ecda3-128f-4e3e-bec9-04aca09cdeb1
> from pool dfa2ec3c-d133-3284-8583-0a0845aa4424
> 2014-08-12 04:38:37,759 DEBUG [kvm.storage.KVMStorageProcessor]
> (agentRequest-Handler-3:null) Failed to delete volume:
> com.cloud.utils.exception.CloudRuntimeException:
> org.libvirt.LibvirtException: cannot remove directory
> '/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/c24ecda3-128f-4e3e-bec9-04aca09cdeb1':
> Directory not empty
> at
> com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.deletePhysicalDisk(LibvirtStorageAdaptor.java:856)
> at
> com.cloud.hypervisor.kvm.storage.LibvirtStoragePool.deletePhysicalDisk(LibvirtStoragePool.java:175)
> at
> com.cloud.hypervisor.kvm.storage.KVMStorageProcessor.deleteVolume(KVMStorageProcessor.java:1203)
> at
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:124)
> at
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:57)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1356)
> at com.cloud.agent.Agent.processRequest(Agent.java:501)
> at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808)
> at com.cloud.utils.nio.Task.run(Task.java:84)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2014-08-12 04:38:37,759 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Seq 1-4558487247829097659: { Ans: , MgmtId:
> 233845177509765, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
> org.libvirt.LibvirtException: cannot remove directory
> '/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/c24ecda3-128f-4e3e-bec9-04aca09cdeb1':
> Directory not empty","wait":0}}] }
> 2014-08-12 04:38:38,321 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Processing command:
> com.cloud.agent.api.GetStorageStatsCommand
> 2014-08-12 04:38:38,321 DEBUG [kvm.storage.LibvirtStorageAdaptor]
> (agentRequest-Handler-1:null)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7377) [RHEL7] D option is installing mariadb which is incompatible with CS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7377. -- > [RHEL7] D option is installing mariadb which is incompatible with CS > - > > Key: CLOUDSTACK-7377 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7377 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: shweta agarwal >Priority: Blocker > Fix For: 4.5.0 > > > Repro steps: > Untar 8.rhel7.tar.gz > Use D option to install Database server > use M option to install MS > Start MS > Bug: > MS start will fail as D option has installed mariadb which is incompatible > with MS -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129939#comment-14129939 ] shweta agarwal commented on CLOUDSTACK-7497: if you plan to use it today u can use my setup: MS : 10.147.28.52 login/password: root/password > [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC > --- > > Key: CLOUDSTACK-7497 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang >Priority: Blocker > Fix For: 4.5.0 > > Attachments: MS.tar.gz, cloud.dmp > > > Repro steps: > Create a LXC zone with 2 cluster one LXc and one KVM > Create VM with LXC template > Bug: > Deploy vm fails as hypervisor type is passed as KVM > 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24) ===START=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:09,581 INFO [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 > ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the > hypervisor type of the template > 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] > (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM > 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] > (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7497: --- Attachment: cloud.dmp MS.tar.gz > [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC > --- > > Key: CLOUDSTACK-7497 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: shweta agarwal >Priority: Blocker > Fix For: 4.5.0 > > Attachments: MS.tar.gz, cloud.dmp > > > Repro steps: > Create a LXC zone with 2 cluster one LXc and one KVM > Create VM with LXC template > Bug: > Deploy vm fails as hypervisor type is passed as KVM > 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24) ===START=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:09,581 INFO [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 > ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the > hypervisor type of the template > 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] > (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM > 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] > (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7497: --- Assignee: Jessica Wang (was: shweta agarwal) > [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC > --- > > Key: CLOUDSTACK-7497 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang >Priority: Blocker > Fix For: 4.5.0 > > Attachments: MS.tar.gz, cloud.dmp > > > Repro steps: > Create a LXC zone with 2 cluster one LXc and one KVM > Create VM with LXC template > Bug: > Deploy vm fails as hypervisor type is passed as KVM > 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24) ===START=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:09,581 INFO [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 > ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the > hypervisor type of the template > 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] > (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM > 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] > (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129925#comment-14129925 ] shweta agarwal commented on CLOUDSTACK-7497: I choose Template . Attaching DB dumb as well > [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC > --- > > Key: CLOUDSTACK-7497 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: shweta agarwal >Priority: Blocker > Fix For: 4.5.0 > > > Repro steps: > Create a LXC zone with 2 cluster one LXc and one KVM > Create VM with LXC template > Bug: > Deploy vm fails as hypervisor type is passed as KVM > 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24) ===START=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:09,581 INFO [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 > ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the > hypervisor type of the template > 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] > (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM > 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] > (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7400) [LXC] migration of VMs are failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7400. -- > [LXC] migration of VMs are failing > --- > > Key: CLOUDSTACK-7400 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7400 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > > [LXC] migration of VMs are failing with message Unsupported Hypervisor Type > for VM migration, we support XenServer/VMware/KVM/Ovm/Hyperv only -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7428) [LXC] advance zone with security group is disable for LXC hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7428. -- > [LXC] advance zone with security group is disable for LXC hypervisor > > > Key: CLOUDSTACK-7428 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7428 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Blocker > Fix For: 4.5.0 > > > Repro steps: > 1. Create a advance zone with SG > 2. Add a Lxc cluster to it > Bug: > cluster addition will fail stating LXC is not supported hypervisor type for > SG enabled zone -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7429) [LXC][UI] hypervisor dropdown in advance zone with SG is not showing LXC hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7429. -- > [LXC][UI] hypervisor dropdown in advance zone with SG is not showing LXC > hypervisor > --- > > Key: CLOUDSTACK-7429 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7429 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Blocker > Fix For: 4.5.0 > > Attachments: lxc-sg.png > > > Repro Steps : > Try creating a SG enabled advance zone with LXC hypervisor. > Bug: > Hypervisor dropdown is not showing LXC hypervisor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7447) [LXC] primary storage is not mounting on host added later to cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7447. -- > [LXC] primary storage is not mounting on host added later to cluster > > > Key: CLOUDSTACK-7447 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7447 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Storage Controller >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > Attachments: management-server.log.tar.gz > > > Repro steps: > 1.Create a LXC Basic zone with one host > 2. Once zone is up and SSVM are running add another host to the cluster > Bug: > Primary storage is not mounted on the host added later in step 2 > Expected Result: > primary storage should be mounted on all host as and when they are added to > cluster > high impact when launching vms using affinity and anti affinity groups -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7477) [LXC] the workaround for cpu,cpuacct are co-mounted problem of libvirt is removed when agent shutsdown and restarted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7477. -- > [LXC] the workaround for cpu,cpuacct are co-mounted problem of libvirt is > removed when agent shutsdown and restarted > > > Key: CLOUDSTACK-7477 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7477 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Blocker > > Repro steps: > 1. Create a LXC setup > 2. create few vms > 3. shut down host LXC agent > 4. Once Agent states become disconnected start host gain > Bug > Note all the mounts in host > mount > proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) > sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel) > devtmpfs on /dev type devtmpfs > (rw,nosuid,seclabel,size=3981488k,nr_inodes=995372,mode=755) > securityfs on /sys/kernel/security type securityfs > (rw,nosuid,nodev,noexec,relatime) > tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel) > devpts on /dev/pts type devpts > (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000) > tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755) > tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,seclabel,mode=755) > cgroup on /sys/fs/cgroup/systemd type cgroup > (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) > pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) > cgroup on /sys/fs/cgroup/cpuset type cgroup > (rw,nosuid,nodev,noexec,relatime,cpuset) > cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup > (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu) > cgroup on /sys/fs/cgroup/memory type cgroup > (rw,nosuid,nodev,noexec,relatime,memory) > cgroup on /sys/fs/cgroup/devices type cgroup > (rw,nosuid,nodev,noexec,relatime,devices) > cgroup on /sys/fs/cgroup/freezer type cgroup > (rw,nosuid,nodev,noexec,relatime,freezer) > cgroup on /sys/fs/cgroup/net_cls type cgroup > (rw,nosuid,nodev,noexec,relatime,net_cls) > cgroup on /sys/fs/cgroup/blkio type cgroup > (rw,nosuid,nodev,noexec,relatime,blkio) > cgroup on /sys/fs/cgroup/perf_event type cgroup > (rw,nosuid,nodev,noexec,relatime,perf_event) > cgroup on /sys/fs/cgroup/hugetlb type cgroup > (rw,nosuid,nodev,noexec,relatime,hugetlb) > configfs on /sys/kernel/config type configfs (rw,relatime) > /dev/mapper/rhel_rack3pod1host49-root on / type xfs > (rw,relatime,seclabel,attr2,inode64,noquota) > selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime) > systemd-1 on /proc/sys/fs/binfmt_misc type autofs > (rw,relatime,fd=35,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) > mqueue on /dev/mqueue type mqueue (rw,relatime,seclabel) > hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel) > debugfs on /sys/kernel/debug type debugfs (rw,relatime) > sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) > sunrpc on /proc/fs/nfsd type nfsd (rw,relatime) > /dev/mapper/rhel_rack3pod1host49-home on /home type xfs > (rw,relatime,seclabel,attr2,inode64,noquota) > /dev/sda1 on /boot type xfs (rw,relatime,seclabel,attr2,inode64,noquota) > 10.147.28.7:/export/home/shweta/goleta.lxc.primary on > /mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424 type nfs > (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.147.28.7,mountvers=3,mountport=47246,mountproto=udp,local_lock=none,addr=10.147.28.7) > fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) > it again contains all those cgroups mount point which we deleted earlier as a > part of LXC agent instalation . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7531) [LXC] ha enabled VM not restarted once a shutdown host is restarted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7531. -- Resolution: Invalid After some time I noticed HA VM restarted > [LXC] ha enabled VM not restarted once a shutdown host is restarted > --- > > Key: CLOUDSTACK-7531 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7531 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kiran Koneti > Fix For: 4.5.0 > > > Repro steps: > 1. Create a Zone with two cluster each having one LXC host > 2. Create some ha enabled VM > 3. Shutdown host machine having ha enabled VM and wait till the status of > agent is disconnected on MS > 4. start host machine > Bug: > Ha enabled VM goes to stop state as soon as Host machine comes up and agent > status is up on CS > Expected result: > HA enabled VM should restart > Additional information > For all that time when Host was shutdown the agent state was disconnected and > all the HA enabled is shown as up and running but as soon as I restarted Host > the HA enabled VM stopped . Ideally HA thread should kick in and restart > those VM on other or same host . > Attaching MS and agent log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7531) [LXC] ha enabled VM not restarted once a shutdown host is restarted
shweta agarwal created CLOUDSTACK-7531: -- Summary: [LXC] ha enabled VM not restarted once a shutdown host is restarted Key: CLOUDSTACK-7531 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7531 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kiran Koneti Fix For: 4.5.0 Repro steps: 1. Create a Zone with two cluster each having one LXC host 2. Create some ha enabled VM 3. Shutdown host machine having ha enabled VM and wait till the status of agent is disconnected on MS 4. start host machine Bug: Ha enabled VM goes to stop state as soon as Host machine comes up and agent status is up on CS Expected result: HA enabled VM should restart Additional information For all that time when Host was shutdown the agent state was disconnected and all the HA enabled is shown as up and running but as soon as I restarted Host the HA enabled VM stopped . Ideally HA thread should kick in and restart those VM on other or same host . Attaching MS and agent log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7478) [LXC] VM creation should fail when creating LXC VM with data disk and w/o having ceph as primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7478. -- Verified fixed > [LXC] VM creation should fail when creating LXC VM with data disk and w/o > having ceph as primary storage > > > Key: CLOUDSTACK-7478 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7478 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > Attachments: agent.log.tar.gz, ms.tar.gz > > > Repro steps: > 1. Create a LXC zone with only nfs > 2. Create a VM with data disk > Bug: > VM creations passes without giving error that data disk needs ceph storage > Even usage events for data disk is also generated. > VM shows no data disk with it > dumxml of VM shows: > > i-2-21-VM > 7da917bf-dd91-4185-92ce-a419b6a7e396 > CentOS 6.3 (64-bit) > 524288 > 524288 > 1 > > 500 > > > /machine > > > exe > /sbin/init > > > > > > > > > > > > destroy > restart > destroy > > /usr/libexec/libvirt_lxc > >dir='/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/138ef448-03d7-4344-92a9-3e981b8826b6'/> > > > > > > > > > > > > > > > > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7504) [LXC] ha enabled VM not started on other host of cluster when original host is put to maintenance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7504. -- > [LXC] ha enabled VM not started on other host of cluster when original host > is put to maintenance > - > > Key: CLOUDSTACK-7504 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7504 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > Attachments: Ms.tar.gz > > > Repro steps: > Create a LXC zone with two lxc host in a cluster > Create a HA enabled Service offering > Create a VM with ha enabled service offerings > Put host on maintenance which has this ha enabled VM > Expected result : > HA enabled VM should start on other available LXC host in the cluster > Bug: > HA enabled VM stops but don't start on other hosts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7530) [LXC] router VMs are not migrating to other cluster if we put its original host into maintenance
shweta agarwal created CLOUDSTACK-7530: -- Summary: [LXC] router VMs are not migrating to other cluster if we put its original host into maintenance Key: CLOUDSTACK-7530 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7530 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Fix For: 4.5.0 Repro steps: Create a Zone with two LXC clusters each having one host Launch a VM in this cluster Put LXC host to maintenance which has router VM Bug; Router VM does not migrates to other available host in another cluster Expected Result: Router VM should migrate to other host in the 2nd cluster Additional info to support my case : 1. When i started manually router vm it started in other cluster without issue 2. Other system vm like CPVM and SSVM in similar situation moves/recreated for one cluster to another cluster . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7507) [LXC] router VMs are not migrating to other host in the cluster putting its original host into maintenance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7507. -- Verified fixed. though router VM is not migrating across cluster for which I am filing separate bug > [LXC] router VMs are not migrating to other host in the cluster putting its > original host into maintenance > -- > > Key: CLOUDSTACK-7507 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7507 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > > Repro steps: > Create a Zone with LXC cluster having two host in the LXC cluster > Launch a VM in this cluster > Put LXC host to maintenance which has router VM > Bug; > Router VM does not migrates to other available host > Expected Result: > Router VM should migrate to other host in the cluster -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7473) [LXC]putting host into maintenance is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal closed CLOUDSTACK-7473.
--
> [LXC]putting host into maintenance is failing
> --
>
> Key: CLOUDSTACK-7473
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7473
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Blocker
> Attachments: agent.log.tar.gz, ms.tar.gz
>
>
> Repro stesp:
> 1. create a zone with a LXC cluster having 2 host
> 2. create few LXC vms
> 3. Put one host into maintenance which has some VM running
> Bug:
> Putting host into maintenance will never pass. host will remain in preparing
> for maintenance stage and then goes to disconnect state.
> Agent log shows :
> 2014-09-02 19:08:12,663 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-1:null) Failed to execute while migrating domain:
> org.libvirt.LibvirtException: this function is not supported by the
> connection driver: virDomainMigrate2
> 2014-09-02 19:08:12,665 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Seq 1-3693233169420517550: { Ans: , MgmtId:
> 233845178472723, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.MigrateAnswer":{"result":false,"details":"org.libvirt.LibvirtException:
> this function is not supported by the connection driver:
> virDomainMigrate2","wait":0}}] }
> 2014-09-02 19:08:13,004 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-4:null) Request:Seq 1-3693233169420517551: { Cmd ,
> MgmtId: 233845178472723, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.MigrateCommand":{"vmName":"i-2-7-VM","destIp":"10.147.28.49","hostGuid":"2b2a1b9f-7582-378f-b54f-1dbb8f69e239-LibvirtComputingResource","isWindows":false,"vmTO":{"id":7,"name":"i-2-7-VM","type":"User","cpus":1,"minSpeed":128,"maxSpeed":128,"minRam":134217728,"maxRam":134217728,"arch":"x86_64","os":"Red
> Hat Enterprise Linux
> 7.0","platformEmulator":"Other","bootArgs":"","enableHA":true,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"QY0cKnTfogzaS49R283f1g==","params":{"Message.ReservedCapacityFreed.Flag":"false"},"uuid":"caf07a92-9f6c-49df-a7e4-27289e715448","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"981fe152-6ee5--ae41-474736c881cf","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"dfa2ec3c-d133-3284-8583-0a0845aa4424","id":1,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/shweta/goleta.lxc.primary","port":2049,"url":"NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=Primary&STOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424"}},"name":"ROOT-7","size":647321600,"path":"981fe152-6ee5--ae41-474736c881cf","volumeId":7,"vmName":"i-2-7-VM","accountId":2,"format":"DIR","provisioningType":"THIN","id":7,"deviceId":0,"hypervisorType":"LXC"}},"diskSeq":0,"path":"981fe152-6ee5--ae41-474736c881cf","type":"ROOT","_details":{"managed":"false","storagePort":"2049","storageHost":"10.147.28.7","volumeSize":"647321600"}},{"data":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"ISO"}],"nics":[{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"pxeDisable":false,"nicUuid":"95826449-4163-46b8-91b7-8bf94f19ab8e","uuid":"d4db3da8-4e6c-4e29-b6bb-a6613d55fa2f","ip":"10.147.30.166","netmask":"255.255.255.0","gateway":"10.147.30.1","mac":"06:54:96:00:00:07","dns1":"10.140.50.6","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://30","isolationUri":"vlan://30","isSecurityGroupEnabled":true}]},"executeInSequence":false,"wait":0}}]
> }
> 2014-09-02 19:08:13,005 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-4:null) Processing command:
> com.cloud.agent.api.MigrateCommand
> 2014-09-02 19:08:13,006 DEBUG [kvm.resource.LibvirtConnection]
> (agentRequest-Handler-4:null) can't find connection: KVM, for vm: i-2-7-VM,
> continue
> 2014-09-02 19:08:13,018 INFO [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-4:null) Live migration of instance i-2-7-VM initiated
> 2014-09-02 19:08:13,103 INFO [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-5:null) Waiting for migration of s-1-VM to complete,
> waited 1000ms
> 2014-09-02 19:08:13,118 INFO [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-4:null) Migration thread for i-2-7-VM is done
> 2014-09-02 19:08:13,119 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-4:null) Failed to execute while migrating domain:
> org.libvirt.LibvirtException: this function i
[jira] [Closed] (CLOUDSTACK-7472) Change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7472. -- > Change cloudstack agent.properties file for rhel 7 to include > kvmclock.disable=true > --- > > Key: CLOUDSTACK-7472 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7472 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > > We need to minimize manual steps that needs to be done after agent > installation so change cloudstack agent.properties file for rhel 7 to include > kvmclock.disable=true -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-7316) hitting java.lang.reflect.InvocationTargetException while starting usage server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal reopened CLOUDSTACK-7316: verified on EAP1 build. Problem still exists > hitting java.lang.reflect.InvocationTargetException while starting usage > server > --- > > Key: CLOUDSTACK-7316 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7316 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Damodar Reddy T >Priority: Blocker > Fix For: 4.5.0 > > Attachments: usage.tar.gz > > > Repro steps: > Install MS and usage server > Start MS and usage server > Bug: > Usage server will stop after starting > usage log shows : > java.lang.reflect.InvocationTargetException > 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.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243) > Caused by: org.springframework.beans.factory.BeanCreationException: Error > creating bean with name 'vmDiskUsageParser': Injection of autowired > dependencies failed; nested exception is > org.springframework.beans.factory.BeanCreationException: Could not autowire > field: private com.cloud.usage.dao.UsageDao > com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'usageDaoImpl' defined in URL > [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]: > BeanPostProcessor before instantiation of bean failed; nested exception is > net.sf.cglib.core.CodeGenerationException: > java.lang.ExceptionInInitializerError-->null > at > org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:288) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1116) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628) > at > org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932) > at > org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479) > at > org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:139) > at > org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:83) > at com.cloud.usage.UsageServer.start(UsageServer.java:57) > ... 5 more > Caused by: org.springframework.beans.factory.BeanCreationException: Could not > autowire field: private com.cloud.usage.dao.UsageDao > com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'usageDaoImpl' defined in URL > [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]: > BeanPostProcessor before instantiation of bean failed; nested exception is > net.sf.cglib.core.CodeGenerationException: > java.lang.ExceptionInInitializerError-->null > at > org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnota
[jira] [Closed] (CLOUDSTACK-7378) [rhel7] usage server installation is failing with java7 dependency
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7378. -- > [rhel7] usage server installation is failing with java7 dependency > -- > > Key: CLOUDSTACK-7378 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7378 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Damodar Reddy T >Priority: Blocker > Fix For: 4.5.0 > > > usage server installation is failing with java7 dependency on rhel 7 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7501: --- Assignee: (was: Abhinandan Prateek) > System VM fails to move from one cluster to another cluster when hypervisor > type differs > > > Key: CLOUDSTACK-7501 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Priority: Critical > Fix For: 4.5.0 > > Attachments: Ms.tar.gz > > > Repro steps: > 1. Create a LXC advance zone setup with one LXC cluster > 2. When system vms are up .add one more KVM cluster > 3. Put LXC host to maintenance > Bug: > System VM is not coming up on KVM cluster > Expected result: > System VMs should come up on KVM cluster > Ms log shows : > Cluster: 2 has HyperVisorType that does not match the VM, skipping this > cluster > which should not be the case in case of SSVM and CPVM > attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7515) [LXC] user VM is getting different mac than the one with router for the same VM in case of shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126749#comment-14126749 ] shweta agarwal commented on CLOUDSTACK-7515: making it blocker as its stopping my all testing related to shared networks > [LXC] user VM is getting different mac than the one with router for the same > VM in case of shared network > -- > > Key: CLOUDSTACK-7515 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7515 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Network Controller >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Blocker > Fix For: 4.5.0 > > Attachments: agen-user-vm.tar.gz, agent-router.tar.gz, > management-server.log.2014-09-08.gz > > > Repro steps: > 1. Create a advanced zone with LXC hosts having 2 clusters .one cluster > having one host and other having two host .all host are LXC > 2. Create a shared Network > 3. Create a VM using only shared network as default network > Bug: > Notice mac address that VM has is different than the one Router has for the > same vm > router VM shows > cat /etc/dhcphosts.txt > 06:2e:70:00:00:1d,set:10_147_31_148,10.147.31.148,VM-bb8425ca-d97a-48dc-a69d-7ceb3ba454e2,infinite > 06:b7:8a:00:00:18,set:10_147_31_143,10.147.31.143,VM-afcdd0b3-59e0-4104-8fe8-f12b344c6336,infinite > 06:45:08:00:00:19,set:10_147_31_144,10.147.31.144,VM-ef2bbfd7-59d1-4e43-97fb-1a1ac233be9b,infinite > 06:e2:c6:00:00:1b,set:10_147_31_146,10.147.31.146,VM-f0e8245a-b382-45d7-a01d-e63c111fbef5,infinite > For USER VM with IP 10.147.31.144 > router has mac06:45:08:00:00:19 but VM has mac 06:4d:15:46:f3:c6 > Ifconfig on VM shows > ifconfig > eth0: flags=4163 mtu 1500 > inet6 fe80::44d:15ff:fe46:f3c6 prefixlen 64 scopeid 0x20 > ether 06:4d:15:46:f3:c6 txqueuelen 1000 (Ethernet) > RX packets 1938 bytes 414054 (404.3 KiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 14 bytes 2700 (2.6 KiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > lo: flags=73 mtu 65536 > inet 127.0.0.1 netmask 255.0.0.0 > inet6 ::1 prefixlen 128 scopeid 0x10 > loop txqueuelen 0 (Local Loopback) > RX packets 0 bytes 0 (0.0 B) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 0 bytes 0 (0.0 B) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > Additional information : > dumpxml of LXC vm shows same mac which is available with router > Notice even IP is not set for such VMs > Attaching Ms and agent logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7515) [LXC] user VM is getting different mac than the one with router for the same VM in case of shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7515: --- Priority: Blocker (was: Critical) > [LXC] user VM is getting different mac than the one with router for the same > VM in case of shared network > -- > > Key: CLOUDSTACK-7515 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7515 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Network Controller >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Blocker > Fix For: 4.5.0 > > Attachments: agen-user-vm.tar.gz, agent-router.tar.gz, > management-server.log.2014-09-08.gz > > > Repro steps: > 1. Create a advanced zone with LXC hosts having 2 clusters .one cluster > having one host and other having two host .all host are LXC > 2. Create a shared Network > 3. Create a VM using only shared network as default network > Bug: > Notice mac address that VM has is different than the one Router has for the > same vm > router VM shows > cat /etc/dhcphosts.txt > 06:2e:70:00:00:1d,set:10_147_31_148,10.147.31.148,VM-bb8425ca-d97a-48dc-a69d-7ceb3ba454e2,infinite > 06:b7:8a:00:00:18,set:10_147_31_143,10.147.31.143,VM-afcdd0b3-59e0-4104-8fe8-f12b344c6336,infinite > 06:45:08:00:00:19,set:10_147_31_144,10.147.31.144,VM-ef2bbfd7-59d1-4e43-97fb-1a1ac233be9b,infinite > 06:e2:c6:00:00:1b,set:10_147_31_146,10.147.31.146,VM-f0e8245a-b382-45d7-a01d-e63c111fbef5,infinite > For USER VM with IP 10.147.31.144 > router has mac06:45:08:00:00:19 but VM has mac 06:4d:15:46:f3:c6 > Ifconfig on VM shows > ifconfig > eth0: flags=4163 mtu 1500 > inet6 fe80::44d:15ff:fe46:f3c6 prefixlen 64 scopeid 0x20 > ether 06:4d:15:46:f3:c6 txqueuelen 1000 (Ethernet) > RX packets 1938 bytes 414054 (404.3 KiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 14 bytes 2700 (2.6 KiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > lo: flags=73 mtu 65536 > inet 127.0.0.1 netmask 255.0.0.0 > inet6 ::1 prefixlen 128 scopeid 0x10 > loop txqueuelen 0 (Local Loopback) > RX packets 0 bytes 0 (0.0 B) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 0 bytes 0 (0.0 B) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > Additional information : > dumpxml of LXC vm shows same mac which is available with router > Notice even IP is not set for such VMs > Attaching Ms and agent logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7515) [LXC] user VM is getting different mac than the one with router for the same VM in case of shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7515: --- Description: Repro steps: 1. Create a advanced zone with LXC hosts having 2 clusters .one cluster having one host and other having two host .all host are LXC 2. Create a shared Network 3. Create a VM using only shared network as default network Bug: Notice mac address that VM has is different than the one Router has for the same vm router VM shows cat /etc/dhcphosts.txt 06:2e:70:00:00:1d,set:10_147_31_148,10.147.31.148,VM-bb8425ca-d97a-48dc-a69d-7ceb3ba454e2,infinite 06:b7:8a:00:00:18,set:10_147_31_143,10.147.31.143,VM-afcdd0b3-59e0-4104-8fe8-f12b344c6336,infinite 06:45:08:00:00:19,set:10_147_31_144,10.147.31.144,VM-ef2bbfd7-59d1-4e43-97fb-1a1ac233be9b,infinite 06:e2:c6:00:00:1b,set:10_147_31_146,10.147.31.146,VM-f0e8245a-b382-45d7-a01d-e63c111fbef5,infinite For USER VM with IP 10.147.31.144 router has mac06:45:08:00:00:19 but VM has mac 06:4d:15:46:f3:c6 Ifconfig on VM shows ifconfig eth0: flags=4163 mtu 1500 inet6 fe80::44d:15ff:fe46:f3c6 prefixlen 64 scopeid 0x20 ether 06:4d:15:46:f3:c6 txqueuelen 1000 (Ethernet) RX packets 1938 bytes 414054 (404.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 14 bytes 2700 (2.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 0 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Additional information : dumpxml of LXC vm shows same mac which is available with router Notice even IP is not set for such VMs Attaching Ms and agent logs was: Repro steps: 1. Create a advanced zone with LXC hosts having 2 clusters .one cluster having one host and other having two host .all host are LXC 2. Create a shared Network 3. Create a VM using only shared network as default network Bug: Notice mac address that VM has is different than the one Router has for the same vm router VM shows cat /etc/dhcphosts.txt 06:2e:70:00:00:1d,set:10_147_31_148,10.147.31.148,VM-bb8425ca-d97a-48dc-a69d-7ceb3ba454e2,infinite 06:b7:8a:00:00:18,set:10_147_31_143,10.147.31.143,VM-afcdd0b3-59e0-4104-8fe8-f12b344c6336,infinite 06:45:08:00:00:19,set:10_147_31_144,10.147.31.144,VM-ef2bbfd7-59d1-4e43-97fb-1a1ac233be9b,infinite 06:e2:c6:00:00:1b,set:10_147_31_146,10.147.31.146,VM-f0e8245a-b382-45d7-a01d-e63c111fbef5,infinite For USER VM with IP 10.147.31.144 router has mac06:45:08:00:00:19 but VM has mac 06:4d:15:46:f3:c6 Ifconfig on VM shows ifconfig eth0: flags=4163 mtu 1500 inet6 fe80::44d:15ff:fe46:f3c6 prefixlen 64 scopeid 0x20 ether 06:4d:15:46:f3:c6 txqueuelen 1000 (Ethernet) RX packets 1938 bytes 414054 (404.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 14 bytes 2700 (2.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 0 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Notice even IP is not set for such VMs Attaching Ms and agent logs > [LXC] user VM is getting different mac than the one with router for the same > VM in case of shared network > -- > > Key: CLOUDSTACK-7515 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7515 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Network Controller >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > Attachments: agen-user-vm.tar.gz, agent-router.tar.gz, > management-server.log.2014-09-08.gz > > > Repro steps: > 1. Create a advanced zone with LXC hosts having 2 clusters .one cluster > having one host and other having two host .all host are LXC > 2. Create a shared Network > 3. Create a VM using only shared network as default network > Bug: > Notice mac address that VM has is different than the one Router has for the > same vm > router VM shows > cat /etc/dhcphosts.txt > 06:2e:70:00:00:1d,set:10_147_31_148,10.147.31.148,VM-bb8425ca-d97a-48dc-a69
[jira] [Updated] (CLOUDSTACK-7515) [LXC] user VM is getting different mac than the one with router for the same VM in case of shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7515: --- Attachment: agent-router.tar.gz management-server.log.2014-09-08.gz agen-user-vm.tar.gz > [LXC] user VM is getting different mac than the one with router for the same > VM in case of shared network > -- > > Key: CLOUDSTACK-7515 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7515 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Network Controller >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > Attachments: agen-user-vm.tar.gz, agent-router.tar.gz, > management-server.log.2014-09-08.gz > > > Repro steps: > 1. Create a advanced zone with LXC hosts having 2 clusters .one cluster > having one host and other having two host .all host are LXC > 2. Create a shared Network > 3. Create a VM using only shared network as default network > Bug: > Notice mac address that VM has is different than the one Router has for the > same vm > router VM shows > cat /etc/dhcphosts.txt > 06:2e:70:00:00:1d,set:10_147_31_148,10.147.31.148,VM-bb8425ca-d97a-48dc-a69d-7ceb3ba454e2,infinite > 06:b7:8a:00:00:18,set:10_147_31_143,10.147.31.143,VM-afcdd0b3-59e0-4104-8fe8-f12b344c6336,infinite > 06:45:08:00:00:19,set:10_147_31_144,10.147.31.144,VM-ef2bbfd7-59d1-4e43-97fb-1a1ac233be9b,infinite > 06:e2:c6:00:00:1b,set:10_147_31_146,10.147.31.146,VM-f0e8245a-b382-45d7-a01d-e63c111fbef5,infinite > For USER VM with IP 10.147.31.144 > router has mac06:45:08:00:00:19 but VM has mac 06:4d:15:46:f3:c6 > Ifconfig on VM shows > ifconfig > eth0: flags=4163 mtu 1500 > inet6 fe80::44d:15ff:fe46:f3c6 prefixlen 64 scopeid 0x20 > ether 06:4d:15:46:f3:c6 txqueuelen 1000 (Ethernet) > RX packets 1938 bytes 414054 (404.3 KiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 14 bytes 2700 (2.6 KiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > lo: flags=73 mtu 65536 > inet 127.0.0.1 netmask 255.0.0.0 > inet6 ::1 prefixlen 128 scopeid 0x10 > loop txqueuelen 0 (Local Loopback) > RX packets 0 bytes 0 (0.0 B) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 0 bytes 0 (0.0 B) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > Notice even IP is not set for such VMs > Attaching Ms and agent logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7515) [LXC] user VM is getting different mac than the one with router for the same VM in case of shared network
shweta agarwal created CLOUDSTACK-7515: -- Summary: [LXC] user VM is getting different mac than the one with router for the same VM in case of shared network Key: CLOUDSTACK-7515 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7515 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM, Network Controller Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.0 Repro steps: 1. Create a advanced zone with LXC hosts having 2 clusters .one cluster having one host and other having two host .all host are LXC 2. Create a shared Network 3. Create a VM using only shared network as default network Bug: Notice mac address that VM has is different than the one Router has for the same vm router VM shows cat /etc/dhcphosts.txt 06:2e:70:00:00:1d,set:10_147_31_148,10.147.31.148,VM-bb8425ca-d97a-48dc-a69d-7ceb3ba454e2,infinite 06:b7:8a:00:00:18,set:10_147_31_143,10.147.31.143,VM-afcdd0b3-59e0-4104-8fe8-f12b344c6336,infinite 06:45:08:00:00:19,set:10_147_31_144,10.147.31.144,VM-ef2bbfd7-59d1-4e43-97fb-1a1ac233be9b,infinite 06:e2:c6:00:00:1b,set:10_147_31_146,10.147.31.146,VM-f0e8245a-b382-45d7-a01d-e63c111fbef5,infinite For USER VM with IP 10.147.31.144 router has mac06:45:08:00:00:19 but VM has mac 06:4d:15:46:f3:c6 Ifconfig on VM shows ifconfig eth0: flags=4163 mtu 1500 inet6 fe80::44d:15ff:fe46:f3c6 prefixlen 64 scopeid 0x20 ether 06:4d:15:46:f3:c6 txqueuelen 1000 (Ethernet) RX packets 1938 bytes 414054 (404.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 14 bytes 2700 (2.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 0 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Notice even IP is not set for such VMs Attaching Ms and agent logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7507) [LXC] router VMs are not migrating to other host in the cluster putting its original host into maintenance
shweta agarwal created CLOUDSTACK-7507: -- Summary: [LXC] router VMs are not migrating to other host in the cluster putting its original host into maintenance Key: CLOUDSTACK-7507 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7507 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.0 Repro steps: Create a Zone with LXC cluster having two host in the LXC cluster Launch a VM in this cluster Put LXC host to maintenance which has router VM Bug; Router VM does not migrates to other available host Expected Result: Router VM should migrate to other host in the cluster -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7504) [LXC] ha enabled VM not started on other host of cluster when original host is put to maintenance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7504: --- Attachment: Ms.tar.gz > [LXC] ha enabled VM not started on other host of cluster when original host > is put to maintenance > - > > Key: CLOUDSTACK-7504 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7504 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > Attachments: Ms.tar.gz > > > Repro steps: > Create a LXC zone with two lxc host in a cluster > Create a HA enabled Service offering > Create a VM with ha enabled service offerings > Put host on maintenance which has this ha enabled VM > Expected result : > HA enabled VM should start on other available LXC host in the cluster > Bug: > HA enabled VM stops but don't start on other hosts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7504) [LXC] ha enabled VM not started on other host of cluster when original host is put to maintenance
shweta agarwal created CLOUDSTACK-7504: -- Summary: [LXC] ha enabled VM not started on other host of cluster when original host is put to maintenance Key: CLOUDSTACK-7504 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7504 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.0 Repro steps: Create a LXC zone with two lxc host in a cluster Create a HA enabled Service offering Create a VM with ha enabled service offerings Put host on maintenance which has this ha enabled VM Expected result : HA enabled VM should start on other available LXC host in the cluster Bug: HA enabled VM stops but don't start on other hosts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-7497) [LXC][UI] deploy VM failing as hypervisor type passed is KVM instead of LXC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal reopened CLOUDSTACK-7497: I am able to reproduce it Narrowing it down further Have a mixed cluster types .One kvm type and one lxc type. Create first KVM VM and then try to create LXC vm . VM creation will fail > [LXC][UI] deploy VM failing as hypervisor type passed is KVM instead of LXC > > > Key: CLOUDSTACK-7497 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Blocker > Fix For: 4.5.0 > > > Repro steps: > Create a LXC zone with 2 cluster one LXc and one KVM > Create VM with LXC template > Bug: > Deploy vm fails as hypervisor type is passed as KVM > 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24) ===START=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:09,581 INFO [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 > ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the > hypervisor type of the template > 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] > (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END=== 10.146.0.131 -- GET > command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 > 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] > (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM > 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] > (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7501: --- Assignee: Abhinandan Prateek (was: Kishan Kavala) > System VM fails to move from one cluster to another cluster when hypervisor > type differs > > > Key: CLOUDSTACK-7501 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Abhinandan Prateek >Priority: Critical > Fix For: 4.5.0 > > Attachments: Ms.tar.gz > > > Repro steps: > 1. Create a LXC advance zone setup with one LXC cluster > 2. When system vms are up .add one more KVM cluster > 3. Put LXC host to maintenance > Bug: > System VM is not coming up on KVM cluster > Expected result: > System VMs should come up on KVM cluster > Ms log shows : > Cluster: 2 has HyperVisorType that does not match the VM, skipping this > cluster > which should not be the case in case of SSVM and CPVM > attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7501: --- Summary: System VM fails to move from one cluster to another cluster when hypervisor type differs (was: [LXC] System VM fails to move from one cluster to another cluster when hypervisor type differs) > System VM fails to move from one cluster to another cluster when hypervisor > type differs > > > Key: CLOUDSTACK-7501 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > Attachments: Ms.tar.gz > > > Repro steps: > 1. Create a LXC advance zone setup with one LXC cluster > 2. When system vms are up .add one more KVM cluster > 3. Put LXC host to maintenance > Bug: > System VM is not coming up on KVM cluster > Expected result: > System VMs should come up on KVM cluster > Ms log shows : > Cluster: 2 has HyperVisorType that does not match the VM, skipping this > cluster > which should not be the case in case of SSVM and CPVM > attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7501) [LXC] System VM fails to move from one cluster to another cluster when hypervisor type differs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7501: --- Attachment: Ms.tar.gz > [LXC] System VM fails to move from one cluster to another cluster when > hypervisor type differs > -- > > Key: CLOUDSTACK-7501 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > Attachments: Ms.tar.gz > > > Repro steps: > 1. Create a LXC advance zone setup with one LXC cluster > 2. When system vms are up .add one more KVM cluster > 3. Put LXC host to maintenance > Bug: > System VM is not coming up on KVM cluster > Expected result: > System VMs should come up on KVM cluster > Ms log shows : > Cluster: 2 has HyperVisorType that does not match the VM, skipping this > cluster > which should not be the case in case of SSVM and CPVM > attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7501) [LXC] System VM fails to move from one cluster to another cluster when hypervisor type differs
shweta agarwal created CLOUDSTACK-7501: -- Summary: [LXC] System VM fails to move from one cluster to another cluster when hypervisor type differs Key: CLOUDSTACK-7501 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.0 Repro steps: 1. Create a LXC advance zone setup with one LXC cluster 2. When system vms are up .add one more KVM cluster 3. Put LXC host to maintenance Bug: System VM is not coming up on KVM cluster Expected result: System VMs should come up on KVM cluster Ms log shows : Cluster: 2 has HyperVisorType that does not match the VM, skipping this cluster which should not be the case in case of SSVM and CPVM attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7497) [LXC][UI] deploy VM failing as hypervisor type passed is KVM instead of LXC
shweta agarwal created CLOUDSTACK-7497: -- Summary: [LXC][UI] deploy VM failing as hypervisor type passed is KVM instead of LXC Key: CLOUDSTACK-7497 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Blocker Fix For: 4.5.0 Repro steps: Create a LXC zone with 2 cluster one LXc and one KVM Create VM with LXC template Bug: Deploy vm fails as hypervisor type is passed as KVM 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-7b5dcb24) ===START=== 10.146.0.131 -- GET command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 2014-09-05 14:06:09,581 INFO [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the hypervisor type of the template 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END=== 10.146.0.131 -- GET command=deployVirtualMachine&response=json&sessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3D&zoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82a&templateid=2175190d-212a-4078-aedb-d25e4ddcdeb3&hypervisor=KVM&serviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810b&affinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47&iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48&_=1409906169711 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7487) [UI] Public, Featured, routing option are not shown while registering templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7487: --- Attachment: template.png > [UI] Public, Featured, routing option are not shown while registering > templates > > > Key: CLOUDSTACK-7487 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7487 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal > Fix For: 4.5.0 > > Attachments: template.png > > > Repro steps: > Open RegisterTemplate dialog box > Notice Public, Featured and routing option check boxes are not shown while > registering templates > Attaching screenshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7487) [UI] Public, Featured, routing option are not shown while registering templates
shweta agarwal created CLOUDSTACK-7487: -- Summary: [UI] Public, Featured, routing option are not shown while registering templates Key: CLOUDSTACK-7487 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7487 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: shweta agarwal Fix For: 4.5.0 Repro steps: Open RegisterTemplate dialog box Notice Public, Featured and routing option check boxes are not shown while registering templates Attaching screenshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7485) [LXC] Debian VMs fails to start in LXC host
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal updated CLOUDSTACK-7485:
---
Attachment: agent.tar.gz
> [LXC] Debian VMs fails to start in LXC host
> ---
>
> Key: CLOUDSTACK-7485
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7485
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: agent.tar.gz
>
>
> Repro steps:
> Create a LXC setup
> Register debian Template
> Create Debian VM
> Bug:
> Debian VMs fails to start
> Agent log shows:
> 2014-09-04 17:34:01,902 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-5:null) starting i-2-5-VM:
> i-2-5-VM
> 6c3618c2-0189-4678-8242-f53bc1099cee
> Debian GNU/Linux 6(64-bit)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>dir='/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/3ddee90e-6037-489c-b4ac-1df9867bf378'/>
>
>
>
>
>
>
>
>
>
> 524288
>
>
>
> 1
>
> exe
> /sbin/init
>
>
> 500
>
> restart
> destroy
> destroy
>
> 2014-09-04 17 at org.libvirt.Connect.processError(Unknown Source)
> at org.libvirt.Connect.domainCreateXML(Unknown Source)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1238)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3766)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1332)
> at com.cloud.agent.Agent.processRequest(Agent.java:503)
> at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:810)
> at com.cloud.utils.nio.Task.run(Task.java:84)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> 2014-09-04 17:34:02,207 DEBUG [kvm.storage.KVMStoragePoolManager]
> (agentRequest-Handler-5:null) Disconnecting disk
> 3ddee90e-6037-489c-b4ac-1df9867bf378
> 2014-09-04 17:34:02,208 DEBUG [kvm.storage.LibvirtStorageAdaptor]
> (agentRequest-Handler-5:null) Trying to fetch storage pool
> dfa2ec3c-d133-3284-8583-0a0845aa4424 from libvirt
> 2014-09-04 17:34:02,231 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Seq 1-8326029811101205191: { Ans: , MgmtId:
> 233845178472723, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":5,"name":"i-2-5-VM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"arch":"x86_64","os":"Debian
> GNU/Linux 6(64-bit)","platfo:34:02,207 WARN
> [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-5:null)
> LibvirtException
> org.libvirt.LibvirtException: internal error: guest failed to start: cannot
> find init path '/sbin/init' relative to container root: No such file or
> directory
> at org.libvirt.ErrorHandler.processError(Unknown Source)
> at org.libvirt.Connect.processError(Unknown Source)
> at org.libvirt.Connect.processError(Unknown Source)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
