I was facing same issue with master build. Then re-created same environment with network-refactor build (HEAD is at 93a89b1 CLOUDSTACK-995: fix failed to detect centos 6.2), system vms are coming up without updating /etc/cloud/agent/agent.properties
private.network.device=cloudbr0 was in /etc/cloud/agent/agent.properties by default. Looks like, it's a regression. Regards, Rayees -----Original Message----- From: Marcus Sorensen [mailto:shadow...@gmail.com] Sent: Tuesday, January 29, 2013 5:46 PM To: cloudstack-dev@incubator.apache.org Subject: RE: Not able to start System Vms on KVM host OK, I will look and see when that changed to cloudbr1 as default. On Jan 29, 2013 6:08 PM, "Sangeetha Hariharan" < sangeetha.hariha...@citrix.com> wrote: > Thanks Marcus. > > When I added private.network.device=cloubr0 in > /etc/cloud/agent/agent.properties and restarted the cloud-agent , I > see the system Vms being launched successfully. > We did not have to do these changes in the past. I don't think we did > any of these changes when we tested RHEL 6.3 host with a build from > "networkrefactor" branch sometime back. > > -Thanks > Sangeetha > > -----Original Message----- > From: Marcus Sorensen [mailto:shadow...@gmail.com] > Sent: Tuesday, January 29, 2013 4:45 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: Not able to start System Vms on KVM host > > This is because if there is no private.network.device config in your > /etc/cloud/agent/agent.properties file, LibvirtComputingResource.java > defaults to 'cloudbr1'. I would suggest setting all of your traffic > labels to cloudbr0, or setting private.network.device to cloubr0. I'm > assuming it was set up this way because of the recommendation that > management and public be on different physical networks, but I can't > really say for sure what the intention was. I think the default > agent.properties file has it defined as cloudbr1 as well. > > I suppose this is broken since the default in the ui says 'use default > gateway', which it's not doing, but I don't think it's a regression or > new bug, I think it's been that way since I started using cloudstack. > > On Tue, Jan 29, 2013 at 4:57 PM, Sangeetha Hariharan < > sangeetha.hariha...@citrix.com> wrote: > > Marcus, > > > > I tried with the patch you have provided on IPV6 branch. > > > > Now I see the the public interface being programed correctly. But > > there > are issues with 'cloudbr1' and system Vms are still not coming up. > > The same issue is also seen when testing with master branch. > > > > > > [root@Rack3Host4 agent]# brctl show > > bridge name bridge id STP enabled interfaces > > brem1-1363 8000.bc305bd41f86 no em1.1363 > > cloud0 8000.000000000000 no > > cloudbr0 8000.bc305bd41f86 no em1 > > virbr0 8000.525400463d1f yes virbr0-nic > > > > > > [root@Rack3Host4 agent]# ls /sys/devices/virtual/net > > brem1-1363 cloud0 cloudbr0 em1.1363 lo virbr0 virbr0-nic > > > > Following exception seen in agent.log: > > > > 2013-01-29 18:40:55,451 WARN > > [kvm.resource.LibvirtComputingResource] > > (agentRequest-Handler-2:null) Failed to start domain: v-2-VM: Cannot > > get interface MTU on 'cloudbr1': No such device > > 2013-01-29 18:40:55,452 WARN > > [kvm.resource.LibvirtComputingResource] > > (agentRequest-Handler-2:null) Exception > > org.libvirt.LibvirtException: Cannot get interface MTU on > > 'cloudbr1': No > such device > > at org.libvirt.ErrorHandler.processError(Unknown Source) > > at org.libvirt.Connect.processError(Unknown Source) > > at org.libvirt.Domain.processError(Unknown Source) > > at org.libvirt.Domain.create(Unknown Source) > > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startDomain > (LibvirtComputingResource.java:1049) > > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(Lib > virtComputingResource.java:3096) > > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequ > est(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.j > ava:1110) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor. > java:603) > > at java.lang.Thread.run(Thread.java:679) > > 2013-01-29 18:40:55,452 WARN [cloud.agent.Agent] > (agentRequest-Handler-2:null) Caught: > > java.lang.NullPointerException > > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.cleanupVMNe > tworks(LibvirtComputingResource.java:4223) > > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.handleVmSta > rtFailure(LibvirtComputingResource.java:2992) > > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(Lib > virtComputingResource.java:3116) > > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequ > est(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.j > ava:1110) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor. > java:603) > > at java.lang.Thread.run(Thread.java:679) > > > > Thanks > > Sangeetha > > > > >
