incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Sorensen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-1078) Not able to start System Vms on Rhel 6.3 KVM host
Date Wed, 30 Jan 2013 17:31:13 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13566666#comment-13566666
] 

Marcus Sorensen commented on CLOUDSTACK-1078:
---------------------------------------------

Well, there are two things at play here. One is that the code in
LibvirtComputingResource sets private.network.device to cloudbr1 if
none is found in agent.properties, and the other is what is in your
agent.properties.  It looks like private.network.device was changed to
cloudbr1 in agent.properties file in August
(5238a836880951d4cf3024a433358bad8c0fa9e4), but it's always been
commented out, that's just an example. I've gone all the way back to
the 2.x code and LibvirtComputingResource has always set the default
to cloubr1 if none was found in agent.properties.

One question, how are you guys installing?  Without RPM packaging
working, it seems like maybe you're installing a 4.0 build and then
compiling master, manually copying things, and running it? The reason
I ask is because as mentioned, by default the agent.properties is
commented out, and I believe it gets written to what it should be on
agent joining the cluster. So if you're upgrading an existing, working
cluster, the agent.properties should already be configured. If you
accidentally install a new agent.properties then this problem will
occur.

Can we at least verify that with an agent.properties that is properly configured
for the system, everything works? And then perhaps someone can do an install,
however it's being done, and look at the agent.properties before and after the host
joins, seeing how it is changed?

This is one of the issues with having had the packaging system broken
all these months. If one can't easily do a fresh install of the code
(or a scripted upgrade that everyone will be using in the case of a
package upgrade), it's hard to get a baseline to work from.
                
> Not able to start System Vms on Rhel 6.3 KVM host
> -------------------------------------------------
>
>                 Key: CLOUDSTACK-1078
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1078
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server
>    Affects Versions: 4.1.0
>         Environment: Build from IPv6 branch
>            Reporter: Sangeetha Hariharan
>            Assignee: edison su
>            Priority: Critical
>             Fix For: 4.1.0
>
>
> I am testing with build from IPv6 branch.
> I am trying to bring up an advanced zone using rhel6.3 KVM hosts. 
> System Vms are not able to start.
> I see the following exceptions in agent logs:
> 2013-01-28 22:10:02,576 WARN  [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-5:null)
Exception
> com.cloud.exception.InternalErrorException: Failed to create vnet 1363: Set name-type
for VLAN subsystem. Should be visible in /proc/net/vlan/configERROR: trying to add VLAN #1363
to IF -:br-1363:-  error: No such deviceFailed to create vlan 1363 on pif: br-1363.
>         at com.cloud.hypervisor.kvm.resource.BridgeVifDriver.createVnet(BridgeVifDriver.java:170)
>         at com.cloud.hypervisor.kvm.resource.BridgeVifDriver.createVlanBr(BridgeVifDriver.java:156)
>         at com.cloud.hypervisor.kvm.resource.BridgeVifDriver.plug(BridgeVifDriver.java:119)
>         at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.createVif(LibvirtComputingResource.java:3301)
>         at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.createVifs(LibvirtComputingResource.java:3069)
>         at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3093)
>         at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1174)
>         at com.cloud.agent.Agent.processRequest(Agent.java:525)
>         at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)
>         at com.cloud.utils.nio.Task.run(Task.java:83)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>         at java.lang.Thread.run(Thread.java:679)
> 2013-01-28 22:10:02,577 WARN  [cloud.agent.Agent] (agentRequest-Handler-5:null) Caught:
> java.lang.NullPointerException
>         at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.cleanupVMNetworks(LibvirtComputingResource.java:4223)
>         at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.handleVmStartFailure(LibvirtComputingResource.java:2992)
>         at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3116)
>         at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1174)
>         at com.cloud.agent.Agent.processRequest(Agent.java:525)
>         at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)
>         at com.cloud.utils.nio.Task.run(Task.java:83)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>         at java.lang.Thread.run(Thread.java:679)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message