[jira] [Created] (CLOUDSTACK-5671) vhd-util isn't compatible with cloudstack
Nathan Rich created CLOUDSTACK-5671: --- Summary: vhd-util isn't compatible with cloudstack Key: CLOUDSTACK-5671 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5671 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Environment: CloudStack 4.2, XenServer 6.2SP1 Reporter: Nathan Rich Priority: Critical From SMlog: Dec 29 00:46:49 xs03 SM: [14296] ['/usr/bin/vhd-util', 'create', '--debug', '-n', '/dev/VG_XenStorage-8ae79926-f5b3-f7f4-3e2f-3ba33d9aea21/VHD-8d8ed01d-62a2-498e-9069-83b1f3be84f8', '-s', '20480', '-S', '2097152'] Dec 29 00:46:49 xs03 SM: [14296] FAILED in util.pread: (rc 22) stdout: 'options: -n name -s size (MB) [-r reserve] [-h help] Turns out there's no -S flag for the vhd-util which the install docs say to install: [root@xs03 ~]# wget http://download.cloud.com.s3.amazonaws.com/tools/vhd-util --2013-12-29 01:18:00-- http://download.cloud.com.s3.amazonaws.com/tools/vhd-util Resolving download.cloud.com.s3.amazonaws.com... 207.171.187.118 Connecting to download.cloud.com.s3.amazonaws.com|207.171.187.118|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 318977 (312K) [binary/octet-stream] Saving to: `vhd-util' 100%[===] 318,977 572K/s in 0.5s 2013-12-29 01:18:01 (572 KB/s) - `vhd-util' saved [318977/318977] [root@xs03 ~]# chmod +x vhd-util [root@xs03 ~]# ./vhd-util create -S create: invalid option -- S options: -n name -s size (MB) [-r reserve] [-h help] [root@xs03 ~]# -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5640) [Automation] sequence item 0: expected string, NoneType found
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858350#comment-13858350 ] ASF subversion and git services commented on CLOUDSTACK-5640: - Commit 6ad27d903b1ccfd0aac6cb1f304aabe7af1275e1 in branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6ad27d9 ] CLOUDSTACK-5640: Correcting imports in test cases [Automation] sequence item 0: expected string, NoneType found - Key: CLOUDSTACK-5640 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5640 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: xenserver 62 advanced zone Reporter: Srikanteswararao Talluri Assignee: Gaurav Aradhye Fix For: 4.3.0 Creating this bug as a place holder for the following failures, needs further analysis, i have been hitting this issue after the recent marvin changes, we need to get to bottom of the issue sequence item 0: expected string, NoneType found -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5640) [Automation] sequence item 0: expected string, NoneType found
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858351#comment-13858351 ] ASF subversion and git services commented on CLOUDSTACK-5640: - Commit 278b2b1b6661f8c77d5e583fd64137702dd13240 in branch refs/heads/4.3 from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=278b2b1 ] CLOUDSTACK-5640: Correcting imports in test cases [Automation] sequence item 0: expected string, NoneType found - Key: CLOUDSTACK-5640 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5640 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: xenserver 62 advanced zone Reporter: Srikanteswararao Talluri Assignee: Gaurav Aradhye Fix For: 4.3.0 Creating this bug as a place holder for the following failures, needs further analysis, i have been hitting this issue after the recent marvin changes, we need to get to bottom of the issue sequence item 0: expected string, NoneType found -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5672) [Automation]Failed to add new nic to vm; error Unable to serialize observed
Rayees Namathponnan created CLOUDSTACK-5672:
---
Summary: [Automation]Failed to add new nic to vm; error Unable
to serialize observed
Key: CLOUDSTACK-5672
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5672
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server, Network Controller
Affects Versions: 4.3.0
Environment: KVM
branch 4.3
Reporter: Rayees Namathponnan
Priority: Blocker
Fix For: 4.3.0
Steps to reproduce
Step 1 : Create advanced zone
Step 2 : Depoy and vm VM-QA1
Step 3 : Create new network
Step 4 : Add new nic to VM-QA1
Result
Failed to add new nic to the vm, below error observed
nstanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.user.vm.AddNicToVMCmd, cmdInfo:
{response:json,sessionkey:ZZ4QXAUZwIPe83MSDipOFbHVpwo\u003d,virtualmachineid:751ac91a-9a63-4d75-9700-70e269b539a4,cmdEventType:NIC.CREATE,ctxUserId:2,httpmethod:GET,_:1388332341748,ctxAccountId:2,networkid:ac35a773-08d1-4f55-9a57-bf0b78111698,ctxStartEventId:16101},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 29066118877352, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2013-12-29 07:49:06,291 DEBUG [c.c.u.d.T.Transaction]
(Job-Executor-29:ctx-f5b59752 ctx-fbfc6d7f) Rolling back the transaction: Time
= 91 Name = Job-Executor-29; called by
-TransactionLegacy.rollback:896-TransactionLegacy.removeUpTo:839-TransactionLegacy.close:663-Transaction.execute:41-Transaction.execute:46-VirtualMachineManagerImpl.addVmToNetworkThroughJobQueue:4525-VirtualMachineManagerImpl.addVmToNetwork:3112-UserVmManagerImpl.addNicToVirtualMachine:1038-GeneratedMethodAccessor813.invoke:-1-DelegatingMethodAccessorImpl.invoke:43-Method.invoke:616-AopUtils.invokeJoinpointUsingReflection:317
2013-12-29 07:49:06,324 ERROR [c.c.a.ApiAsyncJobDispatcher]
(Job-Executor-29:ctx-f5b59752) Unexpected exception while executing
org.apache.cloudstack.api.command.user.vm.AddNicToVMCmd
com.cloud.utils.exception.CloudRuntimeException: Unable to serialize:
com.cloud.vm.VmWorkAddVmToNetwork@57ca10b0
at
org.apache.cloudstack.framework.jobs.impl.JobSerializerHelper.toObjectSerializedString(JobSerializerHelper.java:118)
at com.cloud.vm.VmWorkSerializer.serialize(VmWorkSerializer.java:63)
at
com.cloud.vm.VirtualMachineManagerImpl$10.doInTransactionWithoutResult(VirtualMachineManagerImpl.java:4554)
at
com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25)
at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49)
at com.cloud.utils.db.Transaction.execute(Transaction.java:37)
at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
at
com.cloud.vm.VirtualMachineManagerImpl.addVmToNetworkThroughJobQueue(VirtualMachineManagerImpl.java:4525)
at
com.cloud.vm.VirtualMachineManagerImpl.addVmToNetwork(VirtualMachineManagerImpl.java:3112)
at
com.cloud.vm.UserVmManagerImpl.addNicToVirtualMachine(UserVmManagerImpl.java:1038)
at sun.reflect.GeneratedMethodAccessor813.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy169.addNicToVirtualMachine(Unknown Source)
at
org.apache.cloudstack.api.command.user.vm.AddNicToVMCmd.execute(AddNicToVMCmd.java:110)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161)
at
com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109)
at
com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
[jira] [Created] (CLOUDSTACK-5673) [Hyper-V] Default IP address never configured on eth0 with default CentOS template
Sowmya Krishnan created CLOUDSTACK-5673: --- Summary: [Hyper-V] Default IP address never configured on eth0 with default CentOS template Key: CLOUDSTACK-5673 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5673 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup, Template Affects Versions: 4.3.0 Environment: Hyper-V Reporter: Sowmya Krishnan Fix For: 4.3.0 Deploy VM with the default CentOS 6.4 template that comes for Hyper-V. Observe that default IP never gets configured on eth0. While this doesn't seem to impact anything directly, it may have issues while configuring multiple IPs for a VM. There may some workarounds needed to get multiple IPs to work on the non-default interface. It is instead desirable to have the default IP configured on eth0 itself like the default templates for other hypervisors. here's a sample of ifconfig from the deployed VM: [root@VM1 ~]# ifconfig eth2 Link encap:Ethernet HWaddr 02:00:74:88:00:01 inet addr:10.0.17.2 Bcast:10.0.31.255 Mask:255.255.240.0 inet6 addr: fe80::74ff:fe88:1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13925 errors:0 dropped:0 overruns:0 frame:0 TX packets:14043 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:838100 (818.4 KiB) TX bytes:851899 (831.9 KiB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:240 (240.0 b) TX bytes:240 (240.0 b) [root@VM1 ~]# ls /etc/sysconfig/network-scripts/ ifcfg-eth0 ifdown-isdnifup-aliases ifup-plusb init.ipv6-global ifcfg-lo ifdown-postifup-bnep ifup-post net.hotplug ifdown ifdown-ppp ifup-eth ifup-ppp network-functions ifdown-bnep ifdown-routes ifup-ippp ifup-routesnetwork-functions-ipv6 ifdown-eth ifdown-sit ifup-ipv6 ifup-sit ifdown-ippp ifdown-tunnel ifup-isdn ifup-tunnel ifdown-ipv6 ifup ifup-plip ifup-wireless -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5334) [Automation] Failed to create template from snapshot while executing copy command, observed NPE In SSVM log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan closed CLOUDSTACK-5334.
---
Verified with latest build
[Automation] Failed to create template from snapshot while executing copy
command, observed NPE In SSVM log
---
Key: CLOUDSTACK-5334
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5334
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Template
Affects Versions: 4.3.0
Environment: KVM
Branch 4.3
Reporter: Rayees Namathponnan
Assignee: edison su
Priority: Blocker
Fix For: 4.3.0
Attachments: CLOUDSTACK-5334.rar
Steps to reproduce
Step 1 : snapshot root volume
Step 2 : Create template from snapshot
Result
Failed to create template from snapshot, observed below copy command failure
and NPE in MS log and SSVM log
MS log
2013-12-02 08:28:49,406 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
(Job-Executor-140:ctx-62f776d6 ctx-120aa5f1) copyAsync inspecting src type
SNAPSHOT copy
Async inspecting dest type TEMPLATE
2013-12-02 08:28:49,418 DEBUG [c.c.a.t.Request]
(Job-Executor-140:ctx-62f776d6 ctx-120aa5f1) Seq 8-1124074796: Sending { Cmd
, MgmtId: 29066118877352, via:
8(s-5-VM), Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{pa
th:snapshots/282/589/d2b20627-b60e-489b-9eee-9f4705331a72,dataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.223.110.232:/export/home/rayees/S
C_QA_AUTO4/secondary,_role:Image}},name:VM-f9e129c2-8d62-4b70-8105-abd304bf7605_ROOT-526_20131202080509,hypervisorType:KVM,id:20,quiescevm:
false}},destTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/282/236,uuid:1e48c6bf-388e-4184-93f5-28a21b12329c,id:236
,format:RAW,accountId:282,hvm:true,displayText:raytemp,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.223.110.232:/export/ho
me/rayees/SC_QA_AUTO4/secondary,_role:Image}},name:2c497573e-38cc-3f4d-a73a-49c7b63bbb6c,hypervisorType:KVM}},executeInSequence:false,wait:
10800}}] }
2013-12-02 08:28:49,655 DEBUG [c.c.a.t.Request]
(AgentManager-Handler-14:null) Seq 8-1124074796: Processing: { Ans: ,
MgmtId: 29066118877352, via: 8, Ver:
v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:false,details:java.lang.NullPointerException\n\tat
org.apache.cloudstack.storage.resource.NfsSeco
ndaryStorageResource.copySnapshotToTemplateFromNfsToNfs(NfsSecondaryStorageResource.java:449)\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStora
geResource.createTemplateFromSnapshot(NfsSecondaryStorageResource.java:546)\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute
(NfsSecondaryStorageResource.java:625)\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.j
ava:236)\n\tat
com.cloud.storage.resource.PremiumSecondaryStorageResource.defaultAction(PremiumSecondaryStorageResource.java:63)\n\tat
com.cloud.storage.res
ource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:59)\n\tat
com.cloud.agent.Agent.processRequest(Agent.java:498)\n\t
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:806)\n\tat
com.cloud.utils.nio.Task.run(Task.java:83)\n\tat
java.util.concurrent.ThreadPoolEx
ecutor.runWorker(ThreadPoolExecutor.java:1146)\n\tat
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat
java.lang.Thread.
run(Thread.java:679)\n,wait:0}}] }
2013-12-02 08:28:49,656 DEBUG [c.c.a.t.Request]
(Job-Executor-140:ctx-62f776d6 ctx-120aa5f1) Seq 8-1124074796: Received: {
Ans: , MgmtId: 29066118877352, v
ia: 8, Ver: v1, Flags: 10, { Answer } }
2013-12-02 08:28:49,663 DEBUG [c.c.t.TemplateManagerImpl]
(Job-Executor-140:ctx-62f776d6 ctx-120aa5f1) Failed to create
templatejava.lang.NullPointerExcepti
on
at
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.copySnapshotToTemplateFromNfsToNfs(NfsSecondaryStorageResource.java:449)
at
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.createTemplateFromSnapshot(NfsSecondaryStorageResource.java:546)
at
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:625)
at
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:236)
at
com.cloud.storage.resource.PremiumSecondaryStorageResource.defaultAction(PremiumSecondaryStorageResource.java:63)
[jira] [Commented] (CLOUDSTACK-5613) CloudStack 4.2.0 - Usage server is running but tables remain empty
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858400#comment-13858400 ] Guy Beaupré commented on CLOUDSTACK-5613: - Ok...I found the solution...Eureka Here it is. 1) Copy or ln /etc/cloudstack/management/db.properties to /etc/cloudstack/usage/db.properties Note: Apparently, you need db.cloud.username and db.cloud.password in addition to db.usage.username / db.usage.password. P.S.: Remember that the passwords need to be encrypted. 2) The ownership of /etc/cloudstack/usage/db.properties need to be changed to root:cloud as in /etc/cloudstack/management/db.properties P.S.: I did it also for /var/log/cloudstack/usage Note: Everything works fine nowwith the only exception that that /var/log/cloudstack/usage is still emptyI can live with that:-) CloudStack 4.2.0 - Usage server is running but tables remain empty -- Key: CLOUDSTACK-5613 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5613 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.2.0 Environment: Ubuntu 12.04.03 LTS Reporter: Guy Beaupré Priority: Blocker CloudStack Usage service is installed and reported as running by Ubuntu 12.04.03 LTS but usage tables remains empty. I have tried to install cloudstack-usage from the source and the provided package ( .deb ) but I get the same issue. CloudStack event manager report the following even if Ubuntu is showing running: No usage server process running An internet colleague reported the same issue with Ubuntu 12.04.03 and confirmed that it is working with CentOS. Supplemental Information: 1. Usage server is running: service cloudstack-usage status * cloudstack-usage is running 2. Management log shows: [cloud.ha.HighAvailabilityManagerImpl] (HA-1:null) checking health of usage server [cloud.ha.HighAvailabilityManagerImpl] (HA-1:null) usage server running? false, heartbeat: null [apache.cloudstack.alerts] (HA-1:null) alertType: : 13 // dataCenterId:: 0 // podId:: 0 // clusterId:: null // message:: No usage server process running -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5447) [Automation] Volume migration failing with NullPointerException in vmware and KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858514#comment-13858514
]
Sateesh Chodapuneedi commented on CLOUDSTACK-5447:
--
Injection of VolumeOrchestrationService is failing yielding _volMgr as NULL.
Due to this, the following snippet is failing with NullPointerException.
final String vmName = volMgr.getVmNameFromVolumeId(cmd.getVolumeId());
[Automation] Volume migration failing with NullPointerException in vmware and
KVM
-
Key: CLOUDSTACK-5447
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5447
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, VMware, Volumes
Affects Versions: 4.3.0
Environment: vmware 5.0
branch 4.3
Reporter: Rayees Namathponnan
Assignee: Sateesh Chodapuneedi
Priority: Blocker
Fix For: 4.3.0
Attachments: management-server.rar
Steps to reproduce
Step 1 : Deploy advanced zone in vm ware with two primary storage in a cluster
Step 2 : Deploy VM vm1
Step 3 : migrate volume of vm to second primary storage
Actual result
Migration failed with below error
2013-12-10 11:39:20,642 DEBUG [c.c.a.t.Request]
(DirectAgent-320:ctx-47dcbdc1) Seq 2-34478645: Executing: { Cmd , MgmtId:
90928106758026, via: 2(10.223.250.130), Ver: v1, Flags: 100111,
[{com.cloud.agent.api.storage.MigrateVolumeCommand:{volumeId:374,volumePath:ROOT-324,pool:{id:1,uuid:6cfb1cb3-1909-3295-a4d3-8920e5cf0b00,host:10.223.240.164,path:/home/common/automation/SC-CLOUD-QA03/primary1,port:2049,type:NetworkFilesystem},wait:0}}]
}
2013-12-10 11:39:20,643 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-75:ctx-5c8b7163) Seq 2-34478645: Executing request
2013-12-10 11:39:20,643 INFO [c.c.h.v.r.VmwareResource]
(DirectAgent-75:ctx-5c8b7163 10.223.250.130) Executing resource
MigrateVolumeCommand:
{volumeId:374,volumePath:ROOT-324,pool:{id:1,uuid:6cfb1cb3-1909-3295-a4d3-8920e5cf0b00,host:10.223.240.164,path:/home/common/automation/SC-CLOUD-QA03/primary1,port:2049,type:NetworkFilesystem},wait:0}
2013-12-10 11:39:20,643 WARN [c.c.a.m.DirectAgentAttache]
(DirectAgent-75:ctx-5c8b7163) Seq 2-34478645: Exception Caught while
executing command
java.lang.NullPointerException
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4347)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:457)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
2013-12-10 11:39:20,643 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-75:ctx-5c8b7163) Seq 2-34478645: Response Received:
2013-12-10 11:39:20,643 DEBUG [c.c.a.t.Request] (DirectAgent-75:ctx-5c8b7163)
Seq 2-34478645: Processing: { Ans: , MgmtId: 90928106758026, via: 2, Ver:
v1, Flags: 110,
[{com.cloud.agent.api.Answer:{result:false,details:java.lang.NullPointerException,wait:0}}]
}
2013-12-10 11:39:20,643 DEBUG [c.c.a.t.Request]
(Job-Executor-142:ctx-1d4fa953 ctx-f2be2981) Seq 2-34478645: Received: {
Ans: , MgmtId: 90928106758026, via: 2, Ver: v1, Flags: 110, { Answer } }
2013-12-10 11:39:20,644 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
(Job-Executor-142:ctx-1d4fa953 ctx-f2be2981) copy failed
com.cloud.utils.exception.CloudRuntimeException: Failed to migrate volume
[jira] [Updated] (CLOUDSTACK-5422) Changing XenServer Tools Version 6.1 + doesnt work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-5422: --- Assignee: Sanjay Tripathi (was: Anshul Gangwar) Changing XenServer Tools Version 6.1 + doesnt work Key: CLOUDSTACK-5422 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5422 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.1 Environment: CloudStack 4.2.1 Reporter: Tomasz Zieba Assignee: Sanjay Tripathi Priority: Blocker Fix For: 4.3.0 The situation is very similar to CLOUDSTACK-3806 and refers to the option XenServer Tools Version 6.1 + in Instances menu. Checking / unchecking this option when Instance does not affect the operation of the system. The problem identical to CLOUDSTACK-3806. The database does not change the corresponding field. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5422) Changing XenServer Tools Version 6.1 + doesnt work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858554#comment-13858554 ] Ram Ganesh commented on CLOUDSTACK-5422: Sanjay Can you help with this bug? Changing XenServer Tools Version 6.1 + doesnt work Key: CLOUDSTACK-5422 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5422 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.1 Environment: CloudStack 4.2.1 Reporter: Tomasz Zieba Assignee: Sanjay Tripathi Priority: Blocker Fix For: 4.3.0 The situation is very similar to CLOUDSTACK-3806 and refers to the option XenServer Tools Version 6.1 + in Instances menu. Checking / unchecking this option when Instance does not affect the operation of the system. The problem identical to CLOUDSTACK-3806. The database does not change the corresponding field. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5673) [Hyper-V] Default IP address never configured on eth0 with default CentOS template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858561#comment-13858561 ] Rajesh Battala commented on CLOUDSTACK-5673: its the network manager that configures the eth devices inside the guest os. VR will serve the dhcp request for the guest os and network manager will configure the eth device. its the issue in centos 6.4 http://zee.linxsol.com/system-administration/qdevice-eth0-does-not-seem-to-be-presentq-after-moving-or-cloning-a-rhelcentos-64-virtual-machine-in-vsphere.html [Hyper-V] Default IP address never configured on eth0 with default CentOS template -- Key: CLOUDSTACK-5673 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5673 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Template Affects Versions: 4.3.0 Environment: Hyper-V Reporter: Sowmya Krishnan Labels: hyper-v Fix For: 4.3.0 Deploy VM with the default CentOS 6.4 template that comes for Hyper-V. Observe that default IP never gets configured on eth0. While this doesn't seem to impact anything directly, it may have issues while configuring multiple IPs for a VM. There may some workarounds needed to get multiple IPs to work on the non-default interface. It is instead desirable to have the default IP configured on eth0 itself like the default templates for other hypervisors. here's a sample of ifconfig from the deployed VM: [root@VM1 ~]# ifconfig eth2 Link encap:Ethernet HWaddr 02:00:74:88:00:01 inet addr:10.0.17.2 Bcast:10.0.31.255 Mask:255.255.240.0 inet6 addr: fe80::74ff:fe88:1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13925 errors:0 dropped:0 overruns:0 frame:0 TX packets:14043 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:838100 (818.4 KiB) TX bytes:851899 (831.9 KiB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:240 (240.0 b) TX bytes:240 (240.0 b) [root@VM1 ~]# ls /etc/sysconfig/network-scripts/ ifcfg-eth0 ifdown-isdnifup-aliases ifup-plusb init.ipv6-global ifcfg-lo ifdown-postifup-bnep ifup-post net.hotplug ifdown ifdown-ppp ifup-eth ifup-ppp network-functions ifdown-bnep ifdown-routes ifup-ippp ifup-routes network-functions-ipv6 ifdown-eth ifdown-sit ifup-ipv6 ifup-sit ifdown-ippp ifdown-tunnel ifup-isdn ifup-tunnel ifdown-ipv6 ifup ifup-plip ifup-wireless -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-5667) Shared Network - fails to launch router due to Multiple generic soure NAT IPs provided for network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy reassigned CLOUDSTACK-5667: Assignee: Murali Reddy Shared Network - fails to launch router due to Multiple generic soure NAT IPs provided for network - Key: CLOUDSTACK-5667 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5667 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.3.0 Environment: Advanced zone shared network Reporter: Sowmya Krishnan Assignee: Murali Reddy Priority: Blocker Fix For: 4.3.0 Attachments: cloud.dmp.gz, mslog.gz Steps: Create a shared network as admin and allocate it to a domain user (scope) Provide necessary details for network CIDR As user, try to deploy a VM Fails to launch router due to the following issue (didn't find this issue when I created another shared network with scope set to all and launched VM as admin) Following is the exception: 2013-12-28 09:47:07,151 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (Job-Executor-42:ctx-1537409c ctx-2faefd2e) Boot Args for VM[DomainRouter|r-26-VM]: template=domP name=r-26-VM eth2ip=10.102.196.240 eth2mask=255.255.255.0 gateway=10.102.196.1 eth0ip=10.102.198.129 eth0mask=255.255.255.128 domain=cs3cloud.internal dhcprange=10.102.198.129 eth1ip=10.102.195.16 eth1mask=255.255.252.0 mgmtcidr=10.102.192.0/22 localgw=10.102.192.1 type=router disable_rp_filter=true dns1=10.140.50.5 2013-12-28 09:47:07,171 ERROR [c.c.v.VirtualMachineManagerImpl] (Job-Executor-42:ctx-1537409c ctx-2faefd2e) Failed to start instance VM[DomainRouter|r-26-VM] com.cloud.utils.exception.CloudRuntimeException: Multiple generic soure NAT IPs provided for network at com.cloud.network.NetworkModelImpl.getIpToServices(NetworkModelImpl.java:291) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.getPublicIpsToApply(VirtualNetworkApplianceManagerImpl.java:2504) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.finalizeIpAssocForNetwork(VirtualNetworkApplianceManagerImpl.java:2456) at com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.finalizeIpAssocForNetwork(VpcVirtualNetworkApplianceManagerImpl.java:1021) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.finalizeCommandsOnStart(VirtualNetworkApplianceManagerImpl.java:2208) at com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.finalizeCommandsOnStart(VpcVirtualNetworkApplianceManagerImpl.java:719) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.finalizeDeployment(VirtualNetworkApplianceManagerImpl.java:2173) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:927) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:713) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2676) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:1767) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouters(VirtualNetworkApplianceManagerImpl.java:1867) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1845) 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:616) 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) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5557) [UI] Invalid UI for Network-Guest Network-AnyVPCN/w.Able to see all configuration(FW/PF/LB)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] manasaveloori updated CLOUDSTACK-5557: -- Summary: [UI] Invalid UI for Network-Guest Network-AnyVPCN/w.Able to see all configuration(FW/PF/LB) (was: [UI] Invalid UI for Network-Guest Network-AnyVPCN/w] When the only sg is default, it should be selected automatically.) [UI] Invalid UI for Network-Guest Network-AnyVPCN/w.Able to see all configuration(FW/PF/LB) --- Key: CLOUDSTACK-5557 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5557 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: manasaveloori Priority: Critical Fix For: 4.3.0 Attachments: VPCTierNW.jpg Steps: 1. Create a VPC. 2. Create a tier network and VM using that network. 3. Acquire IP and enable PF/LB rule. Obseravation: Under Network-GuestNetworks-Click on VPC tier network-IPaddresses. Able to view the IP address and all the configurable items in UI(firewall,PF,LB)like for normal networks. Also user is allowed to configure the rules which results in exception Attaching the SC -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5631) [Automation]setup related failures in tests
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Girish Shilamkar updated CLOUDSTACK-5631:
-
Priority: Critical (was: Major)
[Automation]setup related failures in tests
---
Key: CLOUDSTACK-5631
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5631
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.3.0
Environment: xenserver 62
advanced zone
Reporter: Srikanteswararao Talluri
Priority: Critical
Fix For: 4.3.0
Creating this bug as a place holder for the following failures, needs further
analysis,
1 .ContextSuite context=TestVMLifeCycleDiffHosts:setup FAILED
Warning: Exception during setup : Execute cmd: asyncquery failed, due to:
{errorcode : 533, errortext : u'Unable to create a deployment for
VM[User|QA-a6fff610-f343-4a6f-8a9f-c220b6ae075c]'}
2. ContextSuite context=TestBaseImageUpdate:setupFAILED Execute cmd:
asyncquery failed, due to: {errorcode : 530, errortext : u'Unable to start a
VM due to insufficient capacity'}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5393) [Automation] Failed to create snapshot from ROOT volume in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudha Ponnaganti updated CLOUDSTACK-5393:
-
Priority: Critical (was: Major)
[Automation] Failed to create snapshot from ROOT volume in KVM
--
Key: CLOUDSTACK-5393
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5393
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Snapshot
Affects Versions: 4.3.0
Environment: KVM (RHEL 6.3)
Branch : 4.3
Reporter: Rayees Namathponnan
Assignee: Min Chen
Priority: Critical
Fix For: 4.3.0
Attachments: agent1.rar, agent2.rar, management-server.rar, ssvm.rar
Steps to reproduce
1) Create advanced zone in KVM
2) Deploy VM
3 ) Stop VM
4 ) Create snapshot from root volume
Snapshot creation failed with below exception
2013-12-05 15:39:44,194 DEBUG [c.c.a.t.Request] (Job-Executor-64:ctx-1b710e00
ctx-3cf3df4e) Seq 1-1244399478: Received: { Ans: , MgmtId: 29066118877352,
via: 1, Ver: v1, Flags: 10, { CreateObjectAnswer } }
2013-12-05 15:39:44,284 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
(Job-Executor-64:ctx-1b710e00 ctx-3cf3df4e) copyAsync inspecting src type
SNAPSHOT copyAsync inspecting dest type SNAPSHOT
2013-12-05 15:39:44,332 DEBUG [c.c.a.t.Request] (Job-Executor-64:ctx-1b710e00
ctx-3cf3df4e) Seq 2-332864214: Sending { Cmd , MgmtId: 29066118877352, via:
2(Rack2Host12.lab.vmops.com), Ver: v1, Flags: 100011, [{org.apache.cl
oudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215/8f7d268f-1a96-4d70-9c48-cb7f6cc935a8
,volume:{uuid:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesyst
em,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08
ca01d9}},name:ROOT-919,size:8589934592,path:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeId:988,vmName:i-2-919-QA,accountId:2,format:QCOW2,id:988,deviceId:0,hypervisorType:KVM},parentSnapshotPath
:/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215/d43b61bc-4ade-4753-b1d9-c0398388147d,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},vmName:i-2-919-QA,name:QA-eb54bbfa-12d5-49b5-808f-864dddedc1fd_ROOT-919_20131205233943,hypervisorType:KVM,id:54,quiescevm:false}},destTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:snapshots/2/988,volume:{uuid:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},name:ROOT-919,size:8589934592,path:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeId:988,vmName:i-2-919-QA,accountId:2,format:QCOW2,id:988,deviceId:0,hypervisorType:KVM},dataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.223.110.232:/export/home/rayees/SC_QA_AUTO4/secondary,_role:Image}},vmName:i-2-919-QA,name:QA-eb54bbfa-12d5-49b5-808f-864dddedc1fd_ROOT-919_20131205233943,hypervisorType:KVM,id:54,quiescevm:false}},executeInSequence:false,wait:21600}}]
}
2013-12-05 15:39:44,501 DEBUG [c.c.a.t.Request]
(StatsCollector-3:ctx-3ac54662) Seq 1-1244399477: Received: { Ans: , MgmtId:
29066118877352, via: 1, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
2013-12-05 15:39:44,900 DEBUG [c.c.a.t.Request] (AgentManager-Handler-1:null)
Seq 2-332864214: Processing: { Ans: , MgmtId: 29066118877352, via: 2, Ver:
v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{result:false,details:/usr/share/cloudstack-common/scripts/storage/qcow2/managesnapshot.sh:
line 178: 26840 Floating point exception(core dumped) $qemu_img convert -f
qcow2 -O qcow2 -s $snapshotname $disk $destPath/$destName /dev/nullFailed
to backup 8f7d268f-1a96-4d70-9c48-cb7f6cc935a8 for disk
/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215
to
[jira] [Commented] (CLOUDSTACK-5626) [Automation] migrate instance tests are failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858579#comment-13858579
]
Girish Shilamkar commented on CLOUDSTACK-5626:
--
I have not been able to recreate this problem:
test_07_migrate_instance_in_network (test_vpc_vm_life_cycle.TestVMLifeCycleVPC)
Test migrate an instance in VPC networks ... ok
[Automation] migrate instance tests are failing
---
Key: CLOUDSTACK-5626
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5626
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.3.0
Environment: xenserver 62
advanced zone
Reporter: Srikanteswararao Talluri
Fix For: 4.3.0
Creating this bug as a place holder for the following failures, needs further
analysis,
test_07_migrate_instance_in_network REGRESSION Failed to migrate
instance, Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext
: u'Cannot migrate VM, VM is already presnt on this host, please specify
valid destination host to migrate the VM'}
test_07_migrate_instance_in_network REGRESSION Failed to migrate
instance, Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext
: u'Cannot migrate VM, VM is already presnt on this host, please specify
valid destination host to migrate the VM'}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-3471) Provide an API to extract the log statements of a given jobid
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858584#comment-13858584 ] Saurav Lahiri commented on CLOUDSTACK-3471: --- As per Chiradeep: == Hi Saurav, It looks like the feature is a little orthogonal to ACS. It is more an adjunct. The only reason to add an API to CloudStack is to re-use the authentication layer. Otherwise, the feature does not interact with other parts of ACS at all. If there was a way for a service to re-use the API layer, that would work? So, the LogSearchAsaService service would be exposed on say a different port, and run as a different app/service/servlet Provide an API to extract the log statements of a given jobid - Key: CLOUDSTACK-3471 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3471 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: pre-4.0.0, 4.0.0, 4.1.0 Reporter: Prasanna Santhanam Fix For: Future With the job-id in the logs having no link to the external world that is interacting with the cloudstack API it is not easy to correlate a failure with a specific job. With the inclusion of uuids in the management server logs it would be nice to provide an API extractJobLog that takes a jobid = uuid as parameter so as to extract all log statements of the job. This will be an admin only API and ideally a plugin that can be turned off in favour of better log monitoring/analyis systems. Having the log makes is useful to link our automated test failures with the log from the management server using a simple API call. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5196) SSH to VM fails when done through public ip associated through NAT Rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-5196: - Summary: SSH to VM fails when done through public ip associated through NAT Rule (was: SSH to VM fails when done through portable public ip associated through NAT Rule) SSH to VM fails when done through public ip associated through NAT Rule --- Key: CLOUDSTACK-5196 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5196 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.3.0 Reporter: Ashutosk Kelkar Assignee: Murali Reddy Priority: Critical Fix For: 4.3.0 Deploy a VM Acquire a portable IP in the network of VM and open the firewall and create NAT rule associating the portable ip with the VM. Try to SSH to the VM through portable ip. SSH fails. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5196) SSH to VM fails when done through public ip associated through NAT Rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858587#comment-13858587 ] Murali Reddy commented on CLOUDSTACK-5196: -- its not specific to portable ip, but happening with both public ip and portable public ip's. SSH to VM fails when done through public ip associated through NAT Rule --- Key: CLOUDSTACK-5196 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5196 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.3.0 Reporter: Ashutosk Kelkar Assignee: Murali Reddy Priority: Critical Fix For: 4.3.0 Deploy a VM Acquire a portable IP in the network of VM and open the firewall and create NAT rule associating the portable ip with the VM. Try to SSH to the VM through portable ip. SSH fails. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5659) [Hyper-V] Creation of VM from ISO failing with wrong file format for volume
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858596#comment-13858596
]
ASF subversion and git services commented on CLOUDSTACK-5659:
-
Commit 5551724a2efce0cc4893f375bae469fe051f3f44 in branch refs/heads/4.3 from
[~devdeep]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5551724 ]
CLOUDSTACK-5659: Creation of vm from iso failing with wrong file format.
The agent was always creating a disk with image format vhdx, but the
cloudstack management server defaults to image format vhd for hyperv.
Updated the agent code to be consistent with what cs expects. All disks
are now created with image format vhd.
[Hyper-V] Creation of VM from ISO failing with wrong file format for volume
---
Key: CLOUDSTACK-5659
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5659
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Environment: Hyper V,Advanced zone, deploy from ISO
Reporter: Sowmya Krishnan
Assignee: Devdeep Singh
Priority: Blocker
Labels: hyper-V,
Fix For: 4.3.0
Attachments: mslog
Register an ISO and try to deploy from the ISO. Fails due to mismatch between
expected and actual format with the following exception:
2013-12-27 15:47:29,461 DEBUG [c.c.a.t.Request] (Job-Executor-29:ctx-23b39e0f
ctx-b0f1432e) Seq 1-89129059: Received: { Ans: , MgmtId: 280320865129348,
via: 1, Ver: v1, Flags: 10, { StartA
nswer } }
2013-12-27 15:47:29,464 INFO [c.c.v.VirtualMachineManagerImpl]
(Job-Executor-29:ctx-23b39e0f ctx-b0f1432e) Unable to start VM on
Host[-1-Routing] due to com.cloud.agent.api.StartCommand fa
il on exceptioni-3-7-VM: non-existent volume, missing
\\smb19\HYPERV-SMB\abhinav-hyperv-ps1\ROOT-7.vhd for drive {
data: {
org.apache.cloudstack.storage.to.VolumeObjectTO: {
uuid: 08911ffa-e90c-4f71-80ad-995b47669865,
volumeType: ROOT,
dataStore: {
org.apache.cloudstack.storage.to.PrimaryDataStoreTO: {
uuid: b183fb1d-c446-3a6f-b7ee-ec18507f39ae,
id: 1,
poolType: NetworkFilesystem,
host: SMB19,
path:
/HYPERV-SMB/abhinav-hyperv-ps1?user=abhinavpassword=freebsd@123domain=BLR,
port: 445,
url:
NetworkFilesystem://SMB19//HYPERV-SMB/abhinav-hyperv-ps1?user=abhinavpassword=freebsd@123domain=BLR/?ROLE=PrimarySTOREUUID=b183fb1d-c446-3a6f-b7ee-ec18507f39ae
}
},
name: ROOT-7,
size: 5368709120,
volumeId: 7,
vmName: i-3-7-VM,
accountId: 3,
format: VHD,
id: 7,
deviceId: 0,
hypervisorType: Hyperv
}
},
diskSeq: 0,
type: ROOT,
_details: {
managed: false,
storagePort: 445,
storageHost: SMB19,
volumeSize: 5368709120
}
}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5659) [Hyper-V] Creation of VM from ISO failing with wrong file format for volume
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858597#comment-13858597
]
ASF subversion and git services commented on CLOUDSTACK-5659:
-
Commit 069f8aeed581c3f972f58c44b765175a8cba80e6 in branch refs/heads/master
from [~devdeep]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=069f8ae ]
CLOUDSTACK-5659: Creation of vm from iso failing with wrong file format.
The agent was always creating a disk with image format vhdx, but the
cloudstack management server defaults to image format vhd for hyperv.
Updated the agent code to be consistent with what cs expects. All disks
are now created with image format vhd.
[Hyper-V] Creation of VM from ISO failing with wrong file format for volume
---
Key: CLOUDSTACK-5659
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5659
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Environment: Hyper V,Advanced zone, deploy from ISO
Reporter: Sowmya Krishnan
Assignee: Devdeep Singh
Priority: Blocker
Labels: hyper-V,
Fix For: 4.3.0
Attachments: mslog
Register an ISO and try to deploy from the ISO. Fails due to mismatch between
expected and actual format with the following exception:
2013-12-27 15:47:29,461 DEBUG [c.c.a.t.Request] (Job-Executor-29:ctx-23b39e0f
ctx-b0f1432e) Seq 1-89129059: Received: { Ans: , MgmtId: 280320865129348,
via: 1, Ver: v1, Flags: 10, { StartA
nswer } }
2013-12-27 15:47:29,464 INFO [c.c.v.VirtualMachineManagerImpl]
(Job-Executor-29:ctx-23b39e0f ctx-b0f1432e) Unable to start VM on
Host[-1-Routing] due to com.cloud.agent.api.StartCommand fa
il on exceptioni-3-7-VM: non-existent volume, missing
\\smb19\HYPERV-SMB\abhinav-hyperv-ps1\ROOT-7.vhd for drive {
data: {
org.apache.cloudstack.storage.to.VolumeObjectTO: {
uuid: 08911ffa-e90c-4f71-80ad-995b47669865,
volumeType: ROOT,
dataStore: {
org.apache.cloudstack.storage.to.PrimaryDataStoreTO: {
uuid: b183fb1d-c446-3a6f-b7ee-ec18507f39ae,
id: 1,
poolType: NetworkFilesystem,
host: SMB19,
path:
/HYPERV-SMB/abhinav-hyperv-ps1?user=abhinavpassword=freebsd@123domain=BLR,
port: 445,
url:
NetworkFilesystem://SMB19//HYPERV-SMB/abhinav-hyperv-ps1?user=abhinavpassword=freebsd@123domain=BLR/?ROLE=PrimarySTOREUUID=b183fb1d-c446-3a6f-b7ee-ec18507f39ae
}
},
name: ROOT-7,
size: 5368709120,
volumeId: 7,
vmName: i-3-7-VM,
accountId: 3,
format: VHD,
id: 7,
deviceId: 0,
hypervisorType: Hyperv
}
},
diskSeq: 0,
type: ROOT,
_details: {
managed: false,
storagePort: 445,
storageHost: SMB19,
volumeSize: 5368709120
}
}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-5673) [Hyper-V] Default IP address never configured on eth0 with default CentOS template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reassigned CLOUDSTACK-5673: -- Assignee: Rajesh Battala [Hyper-V] Default IP address never configured on eth0 with default CentOS template -- Key: CLOUDSTACK-5673 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5673 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Template Affects Versions: 4.3.0 Environment: Hyper-V Reporter: Sowmya Krishnan Assignee: Rajesh Battala Labels: hyper-v Fix For: 4.3.0 Deploy VM with the default CentOS 6.4 template that comes for Hyper-V. Observe that default IP never gets configured on eth0. While this doesn't seem to impact anything directly, it may have issues while configuring multiple IPs for a VM. There may some workarounds needed to get multiple IPs to work on the non-default interface. It is instead desirable to have the default IP configured on eth0 itself like the default templates for other hypervisors. here's a sample of ifconfig from the deployed VM: [root@VM1 ~]# ifconfig eth2 Link encap:Ethernet HWaddr 02:00:74:88:00:01 inet addr:10.0.17.2 Bcast:10.0.31.255 Mask:255.255.240.0 inet6 addr: fe80::74ff:fe88:1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13925 errors:0 dropped:0 overruns:0 frame:0 TX packets:14043 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:838100 (818.4 KiB) TX bytes:851899 (831.9 KiB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:240 (240.0 b) TX bytes:240 (240.0 b) [root@VM1 ~]# ls /etc/sysconfig/network-scripts/ ifcfg-eth0 ifdown-isdnifup-aliases ifup-plusb init.ipv6-global ifcfg-lo ifdown-postifup-bnep ifup-post net.hotplug ifdown ifdown-ppp ifup-eth ifup-ppp network-functions ifdown-bnep ifdown-routes ifup-ippp ifup-routes network-functions-ipv6 ifdown-eth ifdown-sit ifup-ipv6 ifup-sit ifdown-ippp ifdown-tunnel ifup-isdn ifup-tunnel ifdown-ipv6 ifup ifup-plip ifup-wireless -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-5605) [Hyper-V] Fix GetStorageStatsCommand for Hyper-V
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Devdeep Singh reassigned CLOUDSTACK-5605:
-
Assignee: Devdeep Singh
[Hyper-V] Fix GetStorageStatsCommand for Hyper-V
Key: CLOUDSTACK-5605
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5605
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller
Affects Versions: 4.3.0
Environment: Hyper-V setup, Advanced zone
Reporter: Sowmya Krishnan
Assignee: Devdeep Singh
Priority: Critical
Labels: Hyper-V, hyper-V,, hyperv
Fix For: 4.3.0
Create an advanced zone set up with Hyper-V.
Logs keep showing the following exceptions during Stats collection for
Storage:
2013-12-22 21:52:05,122 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-387:ctx-bb8cfa79) POST request
tohttp://10.102.192.14:8250/api/HypervResou
rce/com.cloud.agent.api.GetStorageStatsCommand with
contents{id:ce50406b-9038-37ba-9b72-6228d5eb0858,localPath:/HYPERV-SMB/abhinav-hyperv-ps1?user\u00
3dabhinav\u0026password\u003dfreebsd@123\u0026domain\u003dBLR,pooltype:NetworkFilesystem,contextMap:{},wait:0}
2013-12-22 21:52:05,122 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-387:ctx-bb8cfa79) Sending cmd to
http://10.102.192.14:8250/api/HypervResou
rce/com.cloud.agent.api.GetStorageStatsCommand cmd
data:{id:ce50406b-9038-37ba-9b72-6228d5eb0858,localPath:/HYPERV-SMB/abhinav-hyperv-ps1?user\u003dab
hinav\u0026password\u003dfreebsd@123\u0026domain\u003dBLR,pooltype:NetworkFilesystem,contextMap:{},wait:0}
2013-12-22 21:52:05,131 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-387:ctx-bb8cfa79) POST response
is[{com.cloud.agent.api.GetStorageStatsAn
swer:{result:false,details:com.cloud.agent.api.GetStorageStatsCommand
failed on exceptionIllegal characters in
path.,capacity:0,used:0,contextMap
:{}}}]
2013-12-22 21:52:05,131 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-387:ctx-bb8cfa79) executeRequest received response
[{com.cloud.agent.api.
GetStorageStatsAnswer:{used:0,capacity:0,result:false,details:com.cloud.agent.api.GetStorageStatsCommand
failed on exceptionIllegal characters in p
ath.,contextMap:{},wait:0}}]
Following are the agent side logs:
2013-12-18 12:18:57,596 [42] INFO HypervResource.HypervResourceController
[06b343ed-9619-4af0-b80a-e3f96b9bc53d] -
com.cloud.agent.api.GetStorageStatsCommand{
id: ce50406b-9038-37ba-9b72-6228d5eb0858,
localPath:
/HYPERV-SMB/abhinav-hyperv-ps1?user=abhinavpassword=freebsd@123domain=BLR,
pooltype: NetworkFilesystem,
contextMap: {},
wait: 0
}
2013-12-18 12:18:57,596 [42] ERROR HypervResource.HypervResourceController
[06b343ed-9619-4af0-b80a-e3f96b9bc53d] -
com.cloud.agent.api.GetStorageStatsCommand failed on exceptionIllegal
characters in path.
System.ArgumentException: Illegal characters in path.
at System.IO.Path.CheckInvalidPathChars(String path, Boolean
checkAdditional)
at
System.Security.Permissions.FileIOPermission.CheckIllegalCharacters(String[]
str)
at
System.Security.Permissions.FileIOPermission.AddPathList(FileIOPermissionAccess
access, AccessControlActions control, String[] pathListOrig, Boolean
checkForDuplicates, Boolean needFullPath, Boolean copyPathList)
at
System.Security.Permissions.FileIOPermission..ctor(FileIOPermissionAccess
access, String[] pathList, Boolean checkForDuplicates, Boolean needFullPath)
at System.IO.Path.GetFullPath(String path)
at HypervResource.HypervResourceController.GetCapacityForLocalPath(String
localStoragePath, Int64 capacityBytes, Int64 availableBytes) in
c:\source_code\cloudstack\plugins\hypervisors\hyperv\DotNet\ServerResource\HypervResource\HypervResourceController.cs:line
1798
at HypervResource.HypervResourceController.GetStorageStatsCommand(Object
cmd) in
c:\source_code\cloudstack\plugins\hypervisors\hyperv\DotNet\ServerResource\HypervResource\HypervResourceController.cs:line
1497
2013-12-18 12:18:57,596 [42] INFO HypervResource.HypervResourceController
[06b343ed-9619-4af0-b80a-e3f96b9bc53d] - {
com.cloud.agent.api.GetStorageStatsAnswer: {
result: false,
details: com.cloud.agent.api.GetStorageStatsCommand failed on
exceptionIllegal characters in path.,
capacity: 0,
used: 0,
contextMap: {}
}
}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5659) [Hyper-V] Creation of VM from ISO failing with wrong file format for volume
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Devdeep Singh resolved CLOUDSTACK-5659.
---
Resolution: Fixed
[Hyper-V] Creation of VM from ISO failing with wrong file format for volume
---
Key: CLOUDSTACK-5659
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5659
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Environment: Hyper V,Advanced zone, deploy from ISO
Reporter: Sowmya Krishnan
Assignee: Devdeep Singh
Priority: Blocker
Labels: hyper-V,
Fix For: 4.3.0
Attachments: mslog
Register an ISO and try to deploy from the ISO. Fails due to mismatch between
expected and actual format with the following exception:
2013-12-27 15:47:29,461 DEBUG [c.c.a.t.Request] (Job-Executor-29:ctx-23b39e0f
ctx-b0f1432e) Seq 1-89129059: Received: { Ans: , MgmtId: 280320865129348,
via: 1, Ver: v1, Flags: 10, { StartA
nswer } }
2013-12-27 15:47:29,464 INFO [c.c.v.VirtualMachineManagerImpl]
(Job-Executor-29:ctx-23b39e0f ctx-b0f1432e) Unable to start VM on
Host[-1-Routing] due to com.cloud.agent.api.StartCommand fa
il on exceptioni-3-7-VM: non-existent volume, missing
\\smb19\HYPERV-SMB\abhinav-hyperv-ps1\ROOT-7.vhd for drive {
data: {
org.apache.cloudstack.storage.to.VolumeObjectTO: {
uuid: 08911ffa-e90c-4f71-80ad-995b47669865,
volumeType: ROOT,
dataStore: {
org.apache.cloudstack.storage.to.PrimaryDataStoreTO: {
uuid: b183fb1d-c446-3a6f-b7ee-ec18507f39ae,
id: 1,
poolType: NetworkFilesystem,
host: SMB19,
path:
/HYPERV-SMB/abhinav-hyperv-ps1?user=abhinavpassword=freebsd@123domain=BLR,
port: 445,
url:
NetworkFilesystem://SMB19//HYPERV-SMB/abhinav-hyperv-ps1?user=abhinavpassword=freebsd@123domain=BLR/?ROLE=PrimarySTOREUUID=b183fb1d-c446-3a6f-b7ee-ec18507f39ae
}
},
name: ROOT-7,
size: 5368709120,
volumeId: 7,
vmName: i-3-7-VM,
accountId: 3,
format: VHD,
id: 7,
deviceId: 0,
hypervisorType: Hyperv
}
},
diskSeq: 0,
type: ROOT,
_details: {
managed: false,
storagePort: 445,
storageHost: SMB19,
volumeSize: 5368709120
}
}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5515) #cpu ,cpuspeed and ram is set to NULL in usage db(usage_vm_instance table) after vm stop and start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858606#comment-13858606 ] ASF subversion and git services commented on CLOUDSTACK-5515: - Commit 662383e24b824c0622360435ad596a8307d67fee in branch refs/heads/4.3 from [~harikrishna.patnala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=662383e ] CLOUDSTACK-5515: #cpu ,cpuspeed and ram is set to NULL in usage db(usage_vm_instance table) after vm stop and start Fixed populating usage event details in usage db on vm start/upgrade/dynamic_scale #cpu ,cpuspeed and ram is set to NULL in usage db(usage_vm_instance table) after vm stop and start -- Key: CLOUDSTACK-5515 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5515 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.3.0 Reporter: prashant kumar mishra Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.3.0 Attachments: Logs_Db.rar Steps to reproduce - 1-prapare a CS setup + install usage server 2-create a dynamic compute offering say d1 3-deploy a vm using d1 4-stop and start vm Actual #cpu , cpuspeed, memory is set to null after stop start Expected - after vm stop-start #cpu , cpuspeed and memory should get updated according to CO -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5640) [Automation] sequence item 0: expected string, NoneType found
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye resolved CLOUDSTACK-5640. Resolution: Fixed [Automation] sequence item 0: expected string, NoneType found - Key: CLOUDSTACK-5640 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5640 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: xenserver 62 advanced zone Reporter: Srikanteswararao Talluri Assignee: Gaurav Aradhye Fix For: 4.3.0 Creating this bug as a place holder for the following failures, needs further analysis, i have been hitting this issue after the recent marvin changes, we need to get to bottom of the issue sequence item 0: expected string, NoneType found -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5515) #cpu ,cpuspeed and ram is set to NULL in usage db(usage_vm_instance table) after vm stop and start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858612#comment-13858612 ] ASF subversion and git services commented on CLOUDSTACK-5515: - Commit 95fa931ff2ecabc88cbcc3b9f717a5287c1c25f4 in branch refs/heads/master from [~harikrishna.patnala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=95fa931 ] CLOUDSTACK-5515: #cpu ,cpuspeed and ram is set to NULL in usage db(usage_vm_instance table) after vm stop and start Fixed populating usage event details in usage db on vm start/upgrade/dynamic_scale #cpu ,cpuspeed and ram is set to NULL in usage db(usage_vm_instance table) after vm stop and start -- Key: CLOUDSTACK-5515 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5515 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.3.0 Reporter: prashant kumar mishra Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.3.0 Attachments: Logs_Db.rar Steps to reproduce - 1-prapare a CS setup + install usage server 2-create a dynamic compute offering say d1 3-deploy a vm using d1 4-stop and start vm Actual #cpu , cpuspeed, memory is set to null after stop start Expected - after vm stop-start #cpu , cpuspeed and memory should get updated according to CO -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5515) #cpu ,cpuspeed and ram is set to NULL in usage db(usage_vm_instance table) after vm stop and start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala resolved CLOUDSTACK-5515. - Resolution: Fixed #cpu ,cpuspeed and ram is set to NULL in usage db(usage_vm_instance table) after vm stop and start -- Key: CLOUDSTACK-5515 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5515 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.3.0 Reporter: prashant kumar mishra Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.3.0 Attachments: Logs_Db.rar Steps to reproduce - 1-prapare a CS setup + install usage server 2-create a dynamic compute offering say d1 3-deploy a vm using d1 4-stop and start vm Actual #cpu , cpuspeed, memory is set to null after stop start Expected - after vm stop-start #cpu , cpuspeed and memory should get updated according to CO -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5342) Add NIC to virtual machine fails in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858625#comment-13858625
]
Girish Shilamkar commented on CLOUDSTACK-5342:
--
I discussed this issue with Saksham and here are the details:
It seems to be qemu bug
https://www.redhat.com/archives/libvirt-users/2012-July/msg00110.html
And we can get around it by adding 2/3 sec wait before each plug/unplug nic
operation.
We will add wait in the testcase and confirm the above findings.
Add NIC to virtual machine fails in KVM
---
Key: CLOUDSTACK-5342
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5342
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.3.0
Environment: KVM advanced
Reporter: Gaurav Aradhye
Assignee: Saksham Srivastava
Priority: Blocker
Fix For: 4.3.0
Add network to VM test cases fail in KVM with following error.
Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
u'Unable to add NIC to VM[User|VM-e9350ee5-bf2e-418c-91d6-1535dcb4d488]'}
The same test cases execute successfully on XenServer. As per the feature
specification (see
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Add+Remove+Networks+to+VMs),
Add network to VM feature should be supported on KVM too.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5144) [Automation]: Basic Zone Security Groups - SSH to VM is allowed even when there is no ingress rule defined for the security group
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13858642#comment-13858642 ] Wei Zhou commented on CLOUDSTACK-5144: -- I will have a look [Automation]: Basic Zone Security Groups - SSH to VM is allowed even when there is no ingress rule defined for the security group - Key: CLOUDSTACK-5144 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5144 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.3.0 Reporter: Gaurav Aradhye Assignee: Wei Zhou Priority: Critical Labels: automation Fix For: 4.3.0 Attachments: MS-Log.txt, agent.log, ipset-L output.txt, iptables-rules.txt In Basic Zone Setup: 1. Create an account 2. Deploy a VM in that account 3. Verify that any ingress rule is not defined for the security group belonging to the account 4. Try SSH to VM using the nic ipaddress from external client SSH is successful to the VM where as it should fail when the ingress rule is not defined. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
