[jira] [Created] (CLOUDSTACK-9549) Error running database migration scripts with mysql 5.7+
Diogo Monteiro created CLOUDSTACK-9549:
--
Summary: Error running database migration scripts with mysql 5.7+
Key: CLOUDSTACK-9549
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9549
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Diogo Monteiro
The following exception is raised when executing the migration scripts against
a mysql server version 5.7
2016-10-18 19:07:01,064 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
UPDATE `cloud`.`ntwk_offering_service_map` SET Provider='VpcVirtualRouter'
WHERE network_offering_id IN (SELECT id from `cloud`.`network_offerings` WHERE
name IN ('DefaultIsolatedNetworkOfferingForVpcNetworks',
'DefaultIsolatedNetworkOfferingForVpcNetworksNoLB'))
2016-10-18 19:07:01,073 DEBUG [c.c.u.d.Upgrade410to420] (main:null) (logid:)
Updating network ACLs
2016-10-18 19:07:01,074 DEBUG [c.c.u.d.Upgrade410to420] (main:null) (logid:)
Done updating network ACLs
2016-10-18 19:07:01,074 DEBUG [c.c.u.d.Upgrade410to420] (main:null) (logid:)
Checking if host_details index exists, if not we will add it
2016-10-18 19:07:01,085 ERROR [c.c.u.DatabaseUpgradeChecker] (main:null)
(logid:) Unable to upgrade the database
com.cloud.utils.exception.CloudRuntimeException: Failed to check/update the
host_details index
at
com.cloud.upgrade.dao.Upgrade410to420.addHostDetailsIndex(Upgrade410to420.java:1304)
at
com.cloud.upgrade.dao.Upgrade410to420.performDataMigration(Upgrade410to420.java:91)
at
com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:359)
at
com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:482)
at
org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.checkIntegrity(CloudStackExtendedLifeCycle.java:65)
at
org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55)
at
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167)
at
org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51)
at
org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339)
at
org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:143)
at
org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:108)
at
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:947)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:145)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:122)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:233)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSet.java:117)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:79)
at
org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:71)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:58)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:62)
at
org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized(CloudStackContextLoaderListener.java:52)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4244)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4743)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
at
[jira] [Created] (CLOUDSTACK-9548) PVLAN: VM migrate commands fails due to wrong casting
Murali Reddy created CLOUDSTACK-9548:
Summary: PVLAN: VM migrate commands fails due to wrong casting
Key: CLOUDSTACK-9548
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9548
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Murali Reddy
In VirtualRouterElement, prepareMigration, rollbackMigration, commitMigration
methods cast VirtualMachineV0 to DomainRouterVO/UserVmVO resulting in below
excpetion.
2016-10-18 09:08:16,806 INFO [c.c.v.VirtualMachineManagerImpl]
(Work-Job-Executor-4:ctx-106e3bb4 job-64/job-65 ctx-a9571590) Migrating
VM[User|i-2-10-VM] to
Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))]
: Dest[Zone(1)-Pod(1)-Cluster(1)-Host(1)-Storage()]
2016-10-18 09:08:16,817 DEBUG [c.c.n.NetworkModelImpl]
(Work-Job-Executor-4:ctx-106e3bb4 job-64/job-65 ctx-a9571590) Service
SecurityGroup is not supported in the network id=205
2016-10-18 09:08:16,827 DEBUG [c.c.n.NetworkModelImpl]
(Work-Job-Executor-4:ctx-106e3bb4 job-64/job-65 ctx-a9571590) Service
SecurityGroup is not supported in the network id=205
2016-10-18 09:08:16,831 ERROR [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-4:ctx-106e3bb4 job-64/job-65 ctx-a9571590) Invocation
exception, caused by: java.lang.ClassCastException:
com.cloud.vm.VMInstanceVO$$EnhancerByCGLIB$$b0e71f6 cannot be cast to
com.cloud.vm.UserVmVO
2016-10-18 09:08:16,836 INFO [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-4:ctx-106e3bb4 job-64/job-65 ctx-a9571590) Rethrow exception
java.lang.ClassCastException:
com.cloud.vm.VMInstanceVO$$EnhancerByCGLIB$$b0e71f6 cannot be cast to
com.cloud.vm.UserVmVO
2016-10-18 09:08:16,836 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-4:ctx-106e3bb4 job-64/job-65) Done with run of VM work job:
com.cloud.vm.VmWorkMigrate for VM 10, job origin: 64
2016-10-18 09:08:16,836 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-4:ctx-106e3bb4 job-64/job-65) Unable to complete AsyncJobVO
{id:65, userId: 2, accountId: 2, instanceType: null, instanceId: null, cmd:
com.cloud.vm.VmWorkMigrate, cmdInfo:
rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIACnQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAnNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXEAfgAJcQB-AAlwcQB-AAk,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7607964207021, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Tue Oct 18 09:08:16 BST 2016}, job origin:64
java.lang.ClassCastException:
com.cloud.vm.VMInstanceVO$$EnhancerByCGLIB$$b0e71f6 cannot be cast to
com.cloud.vm.UserVmVO
at
com.cloud.network.element.VirtualRouterElement.prepareMigration(VirtualRouterElement.java:1159)
at
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNicForMigration(NetworkOrchestrator.java:1413)
at
com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1930)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:1882)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:4604)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9357) DHCP DNS option is incorrect for Redundant Router config
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15585043#comment-15585043 ] Wei Zhou commented on CLOUDSTACK-9357: -- [~javier.ayllon] is that a Windows VM ? > DHCP DNS option is incorrect for Redundant Router config > > > Key: CLOUDSTACK-9357 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9357 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.8.0 >Reporter: Aaron Brady >Priority: Minor > > With two redundant system routers, my guests are given DNS option 6 > containing the *system* IP (not the virtual IP) of whichever router is master > as their first DNS server entry. > This means that if one router is down or stopped, DNS requests are slowed > until it moves on to the external secondaries I've supplied. > It looks like the `cloud-early-config` script does the right thing with > dnsmasq.conf, but then the cloud.conf put in /etc/dnsmasq.d/ is incorrect. > I've had a look through the code and that appear to be written by > `systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py`, but I've been > unable to find where it's being passed the incorrect, non-redundant, IP > information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-9547) ACS 4.9 + VMware: Unable to remove one of the NICs of a multi-nic guest VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584950#comment-15584950
]
Mani Prashanth Varma Manthena edited comment on CLOUDSTACK-9547 at 10/18/16
9:12 AM:
-
I am only hitting this issue for guest VMs (i.e. not with VPC VRs) created in
ACS 4.9 (i.e. not in ACS 4.7) with VMware setups.
Moreover, I get the same error when I am trying to remove the NIC (i.e. network
adapter) directly from VMware's Vcenter.
There is a possible workaround for this issue from VMware on Internet, which
doesn't work in this scenario both from CloudStack and VMware:
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US=displayKC=2081503
Most likely, this issue has something to do with how we deploy (multi-nic)
guest VMs in ACS 4.9 with VMware setups.
However, installing vmware tools (not easy in our built-in templates) made the
problem go away. With the tools installed the removal was pretty much instant.
Doesn't explain the difference between 4.7 and 4.9 that we are seeing on the
same VMware setup regarding this issue.
was (Author: prashanth varma manthena):
I am only hitting this issue for guest VMs (i.e. not with VPC VRs) created in
ACS 4.9 (i.e. not in ACS 4.7) with VMware setups.
Moreover, I get the same error when I am trying to remove the NIC (i.e. network
adapter) directly from VMware's Vcenter.
There is a possible workaround for this issue from VMware on Internet, which
doesn't work in this scenario both from CloudStack and VMware:
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US=displayKC=2081503
Most likely, this issue has something to do with how we deploy (multi-nic)
guest VMs in ACS 4.9 with VMware setups.
However, installing vmware tools (not easy in our built-in templates) made the
problem go away. With the tools installed the removal was pretty much instant.
Doesn't explain the difference 4.7 and 4.9 that we are seeing though on the
same VMware setup.
> ACS 4.9 + VMware: Unable to remove one of the NICs of a multi-nic guest VM
> --
>
> Key: CLOUDSTACK-9547
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9547
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, VMware
>Affects Versions: 4.9.0
>Reporter: Mani Prashanth Varma Manthena
>Priority: Critical
> Labels: vmware
>
> Steps to reproduce:
> 1) Deploy a multi-nic guest VM (or) add a nic to a single-nic guest VM
> 2) Remove the non-default nic from the multi-nic guest VM, which fails with
> the following error/exception in the management server log:
> {noformat}
> 2016-10-05 06:13:28,251 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-14:ctx-f8dc6bd0 ctx-ee610e01) (logid:58e9cf98) ===END===
> 10.31.52.95 -- GET
> command=queryAsyncJobResult=9ad66ce9-6e1b-4c25-bd2e-763f4586dd86=json&_=1475673245452
> 2016-10-05 06:13:29,787 ERROR [c.c.h.v.r.VmwareResource]
> (DirectAgent-302:ctx-78a58d67 10.31.56.178, job-171/job-172, cmd:
> UnPlugNicCommand) (logid:9ad66ce9) Unexpected exception:
> java.lang.RuntimeException: The guest operating system did not respond to a
> hot-remove request for device ethernet1 in a timely manner.
> at
> com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:354)
> at
> com.cloud.hypervisor.vmware.mo.VirtualMachineMO.configureVm(VirtualMachineMO.java:949)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:1103)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:469)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:315)
> 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
>
[jira] [Commented] (CLOUDSTACK-9547) ACS 4.9 + VMware: Unable to remove one of the NICs of a multi-nic guest VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584950#comment-15584950
]
Mani Prashanth Varma Manthena commented on CLOUDSTACK-9547:
---
I am only hitting this issue for guest VMs (i.e. not with VPC VRs) created in
ACS 4.9 (i.e. not in ACS 4.7) with VMware setups.
Moreover, I get the same error when I am trying to remove the NIC (i.e. network
adapter) directly from VMware's Vcenter.
There is a possible workaround for this issue from VMware on Internet, which
doesn't work in this scenario both from CloudStack and VMware:
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US=displayKC=2081503
Most likely, this issue has something to do with how we deploy (multi-nic)
guest VMs in ACS 4.9 with VMware setups.
However, installing vmware tools (not easy in our built-in templates) made the
problem go away. With the tools installed the removal was pretty much instant.
Doesn't explain the difference 4.7 and 4.9 that we are seeing though on the
same VMware setup.
> ACS 4.9 + VMware: Unable to remove one of the NICs of a multi-nic guest VM
> --
>
> Key: CLOUDSTACK-9547
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9547
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, VMware
>Affects Versions: 4.9.0
>Reporter: Mani Prashanth Varma Manthena
>Priority: Critical
> Labels: vmware
>
> Steps to reproduce:
> 1) Deploy a multi-nic guest VM (or) add a nic to a single-nic guest VM
> 2) Remove the non-default nic from the multi-nic guest VM, which fails with
> the following error/exception in the management server log:
> {noformat}
> 2016-10-05 06:13:28,251 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-14:ctx-f8dc6bd0 ctx-ee610e01) (logid:58e9cf98) ===END===
> 10.31.52.95 -- GET
> command=queryAsyncJobResult=9ad66ce9-6e1b-4c25-bd2e-763f4586dd86=json&_=1475673245452
> 2016-10-05 06:13:29,787 ERROR [c.c.h.v.r.VmwareResource]
> (DirectAgent-302:ctx-78a58d67 10.31.56.178, job-171/job-172, cmd:
> UnPlugNicCommand) (logid:9ad66ce9) Unexpected exception:
> java.lang.RuntimeException: The guest operating system did not respond to a
> hot-remove request for device ethernet1 in a timely manner.
> at
> com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:354)
> at
> com.cloud.hypervisor.vmware.mo.VirtualMachineMO.configureVm(VirtualMachineMO.java:949)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:1103)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:469)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:315)
> 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:745)
> 2016-10-05 06:13:29,788 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-302:ctx-78a58d67) (logid:9ad66ce9) Seq 4-1440588930805137508:
> Response Received:
> 2016-10-05 06:13:29,788 DEBUG [c.c.a.m.ClusteredAgentManagerImpl]
> (DirectAgent-302:ctx-78a58d67) (logid:9ad66ce9) Seq 4-1440588930805137508:
> MgmtId 275619427423488: Resp: Routing to peer
> 2016-10-05 06:13:29,789 DEBUG [c.c.a.m.AgentAttache]
> (DirectAgent-302:ctx-78a58d67) (logid:9ad66ce9) Seq 4-1440588930805137508: No
> more commands found
> 2016-10-05 06:13:31,120 DEBUG [o.s.b.f.s.DefaultListableBeanFactory]
> (API-Job-Executor-8:ctx-a6e36538 job-171 ctx-446c510f)
[jira] [Created] (CLOUDSTACK-9547) ACS 4.9 + VMware: Unable to remove one of the NICs of a multi-nic guest VM
Mani Prashanth Varma Manthena created CLOUDSTACK-9547:
-
Summary: ACS 4.9 + VMware: Unable to remove one of the NICs of a
multi-nic guest VM
Key: CLOUDSTACK-9547
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9547
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server, VMware
Affects Versions: 4.9.0
Reporter: Mani Prashanth Varma Manthena
Priority: Critical
Steps to reproduce:
1) Deploy a multi-nic guest VM (or) add a nic to a single-nic guest VM
2) Remove the non-default nic from the multi-nic guest VM, which fails with the
following error/exception in the management server log:
{noformat}
2016-10-05 06:13:28,251 DEBUG [c.c.a.ApiServlet] (catalina-exec-14:ctx-f8dc6bd0
ctx-ee610e01) (logid:58e9cf98) ===END=== 10.31.52.95 -- GET
command=queryAsyncJobResult=9ad66ce9-6e1b-4c25-bd2e-763f4586dd86=json&_=1475673245452
2016-10-05 06:13:29,787 ERROR [c.c.h.v.r.VmwareResource]
(DirectAgent-302:ctx-78a58d67 10.31.56.178, job-171/job-172, cmd:
UnPlugNicCommand) (logid:9ad66ce9) Unexpected exception:
java.lang.RuntimeException: The guest operating system did not respond to a
hot-remove request for device ethernet1 in a timely manner.
at
com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:354)
at
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.configureVm(VirtualMachineMO.java:949)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:1103)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:469)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:315)
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:745)
2016-10-05 06:13:29,788 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-302:ctx-78a58d67) (logid:9ad66ce9) Seq 4-1440588930805137508:
Response Received:
2016-10-05 06:13:29,788 DEBUG [c.c.a.m.ClusteredAgentManagerImpl]
(DirectAgent-302:ctx-78a58d67) (logid:9ad66ce9) Seq 4-1440588930805137508:
MgmtId 275619427423488: Resp: Routing to peer
2016-10-05 06:13:29,789 DEBUG [c.c.a.m.AgentAttache]
(DirectAgent-302:ctx-78a58d67) (logid:9ad66ce9) Seq 4-1440588930805137508: No
more commands found
2016-10-05 06:13:31,120 DEBUG [o.s.b.f.s.DefaultListableBeanFactory]
(API-Job-Executor-8:ctx-a6e36538 job-171 ctx-446c510f) (logid:9ad66ce9)
Returning cached instance of singleton bean 'messageBus'
2016-10-05 06:13:31,127 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-8:ctx-a6e36538 job-171) (logid:9ad66ce9) Unexpected exception
while executing
org.apache.cloudstack.api.command.admin.vm.RemoveNicFromVMCmdByAdmin
com.cloud.utils.exception.CloudRuntimeException: Unable to remove
Ntwk[205|Guest|16] from VM[User|i-2-3-VM]
at
com.cloud.vm.UserVmManagerImpl.removeNicFromVirtualMachine(UserVmManagerImpl.java:1291)
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.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
[jira] [Comment Edited] (CLOUDSTACK-9357) DHCP DNS option is incorrect for Redundant Router config
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584810#comment-15584810 ] Javier Ayllon edited comment on CLOUDSTACK-9357 at 10/18/16 8:33 AM: - Hi, I've found that even with useextdns=true the local IP is sent as a dns server in dhcp responses. I'ts added in dnsmasq.d/cloud.conf when it shoudn't. was (Author: javier.ayllon): Hi, I've found that even with useextdns=true the local IP is sent as a dns server in dhcp responses. It seems that the DNS option 6 configuration is broken. > DHCP DNS option is incorrect for Redundant Router config > > > Key: CLOUDSTACK-9357 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9357 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.8.0 >Reporter: Aaron Brady >Priority: Minor > > With two redundant system routers, my guests are given DNS option 6 > containing the *system* IP (not the virtual IP) of whichever router is master > as their first DNS server entry. > This means that if one router is down or stopped, DNS requests are slowed > until it moves on to the external secondaries I've supplied. > It looks like the `cloud-early-config` script does the right thing with > dnsmasq.conf, but then the cloud.conf put in /etc/dnsmasq.d/ is incorrect. > I've had a look through the code and that appear to be written by > `systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py`, but I've been > unable to find where it's being passed the incorrect, non-redundant, IP > information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-9357) DHCP DNS option is incorrect for Redundant Router config
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584810#comment-15584810 ] Javier Ayllon edited comment on CLOUDSTACK-9357 at 10/18/16 8:10 AM: - Hi, I've found that even with useextdns=true the local IP is sent as a dns server in dhcp responses. It seems that the DNS option 6 configuration is broken. was (Author: javier.ayllon): Hi, I've found that even with useextdns=true the local IP is sent as a dns server. It seems that the DNS option 6 configuration is broken. > DHCP DNS option is incorrect for Redundant Router config > > > Key: CLOUDSTACK-9357 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9357 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.8.0 >Reporter: Aaron Brady >Priority: Minor > > With two redundant system routers, my guests are given DNS option 6 > containing the *system* IP (not the virtual IP) of whichever router is master > as their first DNS server entry. > This means that if one router is down or stopped, DNS requests are slowed > until it moves on to the external secondaries I've supplied. > It looks like the `cloud-early-config` script does the right thing with > dnsmasq.conf, but then the cloud.conf put in /etc/dnsmasq.d/ is incorrect. > I've had a look through the code and that appear to be written by > `systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py`, but I've been > unable to find where it's being passed the incorrect, non-redundant, IP > information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9357) DHCP DNS option is incorrect for Redundant Router config
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584810#comment-15584810 ] Javier Ayllon commented on CLOUDSTACK-9357: --- Hi, I've found that even with useextdns=true the local IP is sent as a dns server. It seems that the DNS option 6 configuration is broken. > DHCP DNS option is incorrect for Redundant Router config > > > Key: CLOUDSTACK-9357 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9357 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.8.0 >Reporter: Aaron Brady >Priority: Minor > > With two redundant system routers, my guests are given DNS option 6 > containing the *system* IP (not the virtual IP) of whichever router is master > as their first DNS server entry. > This means that if one router is down or stopped, DNS requests are slowed > until it moves on to the external secondaries I've supplied. > It looks like the `cloud-early-config` script does the right thing with > dnsmasq.conf, but then the cloud.conf put in /etc/dnsmasq.d/ is incorrect. > I've had a look through the code and that appear to be written by > `systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py`, but I've been > unable to find where it's being passed the incorrect, non-redundant, IP > information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
