Use "OVSTunnelxxx" but not "cloudbr1" result exception
In 4.4, Can somebody explain, why use "OVSTunnelxxx" for GRE tunnel device, and
not "cloudbr1" ?
When create VM, this will result an exception:
2014-07-23 21:03:35,886 WARN [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-5:null) LibvirtException
org.libvirt.LibvirtException: Cannot get interface MTU on 'OVSTunnel460': no
such device
at org.libvirt.ErrorHandler.processError(Unknown Source)
at org.libvirt.Connect.processError(Unknown Source)
at org.libvirt.Connect.processError(Unknown Source)
at org.libvirt.Connect.domainCreateXML(Unknown Source)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1239)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3798)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:133
3)
at com.cloud.agent.Agent.processRequest(Agent.java:501)
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808)
at com.cloud.utils.nio.Task.run(Task.java:84)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
I found code as below:
public InterfaceDef plug(NicTO nic, String guestOsType)
} else if (nic.getBroadcastType() == Networks.BroadcastDomainType.Vswitch) {
String vnetId =
Networks.BroadcastDomainType.getValue(nic.getBroadcastUri());
String brName = "OVSTunnel" + vnetId;
Re:Re: Use "OVSTunnelxxx" but not "cloudbr1" result exception
Hi Nguyen,
Should I create OVSTunnelxxx ahead like cloudbr0 and cloud0 ? But how to
confirm the xxx in OVSTunnelxxx, because it's a dynamic value between the vm
creatation.
Regards
At 2014-07-24 06:08:55, "Nguyen Anh Tu" wrote:
>Hi Michael,
>
>The GRE feature on Cloudstack creates OVSTunnelxxx bridges with OpenvSwitch
>to serve tunnel between vms, not cloudbr. Please use ovs-vsctl utility to
>check if OVSTunnel460 is exist. Remember to blacklist module bridge.
>
>This might help:
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/KVM+with+OpenVSwitch
>
>Thanks,
>
>--Tuna
>
>
>On Thu, Jul 24, 2014 at 8:43 AM, Michael Li wrote:
>
>> In 4.4, Can somebody explain, why use "OVSTunnelxxx" for GRE tunnel
>> device, and not "cloudbr1" ?
>> When create VM, this will result an exception:
>>
>> 2014-07-23 21:03:35,886 WARN [kvm.resource.LibvirtComputingResource]
>> (agentRequest-Handler-5:null) LibvirtException
>> org.libvirt.LibvirtException: Cannot get interface MTU on 'OVSTunnel460':
>> no such device
>> at org.libvirt.ErrorHandler.processError(Unknown Source)
>> at org.libvirt.Connect.processError(Unknown Source)
>> at org.libvirt.Connect.processError(Unknown Source)
>> at org.libvirt.Connect.domainCreateXML(Unknown Source)
>> at
>> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1239)
>> at
>> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3798)
>> at
>> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:133
>> 3)
>> at com.cloud.agent.Agent.processRequest(Agent.java:501)
>> at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808)
>> at com.cloud.utils.nio.Task.run(Task.java:84)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>> at java.lang.Thread.run(Thread.java:722)
>>
>> I found code as below:
>> public InterfaceDef plug(NicTO nic, String guestOsType)
>> } else if (nic.getBroadcastType() == Networks.BroadcastDomainType.Vswitch)
>> {String vnetId =
>> Networks.BroadcastDomainType.getValue(nic.getBroadcastUri());
>> String brName = "OVSTunnel" + vnetId;
>>
Re:Re: Re: Use "OVSTunnelxxx" but not "cloudbr1" result exception
Hi Nguyen,
Thanks for your reply. Did u mean when I create a gre network offering use ovs
as service provider for connectity, and then create a guest isolated network
use this offering, at this point a OvsTunnel bridge will be created ?
Regards
At 2014-07-25 10:17:08, "Nguyen Anh Tu" wrote:
>Michael,
>
>OVSTunnelxxx is automatically created by Ovs controller. The xxx value is
>generated between VLAN range you set in the beginning. For each guest
>network you create, Ovs controller will add one OvsTunnel bridge.
>
>Thanks,
>
>--Tuna
>
>
>On Fri, Jul 25, 2014 at 7:46 AM, Michael Li wrote:
>
>> Hi Nguyen,
>> Should I create OVSTunnelxxx ahead like cloudbr0 and cloud0 ? But how to
>> confirm the xxx in OVSTunnelxxx, because it's a dynamic value between the
>> vm creatation.
>>
>>
>> Regards
>>
>>
>>
>>
>> At 2014-07-24 06:08:55, "Nguyen Anh Tu" wrote:
>> >Hi Michael,
>> >
>> >The GRE feature on Cloudstack creates OVSTunnelxxx bridges with
>> OpenvSwitch
>> >to serve tunnel between vms, not cloudbr. Please use ovs-vsctl utility to
>> >check if OVSTunnel460 is exist. Remember to blacklist module bridge.
>> >
>> >This might help:
>> >
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/KVM+with+OpenVSwitch
>> >
>> >Thanks,
>> >
>> >--Tuna
>> >
>> >
>> >On Thu, Jul 24, 2014 at 8:43 AM, Michael Li wrote:
>> >
>> >> In 4.4, Can somebody explain, why use "OVSTunnelxxx" for GRE tunnel
>> >> device, and not "cloudbr1" ?
>> >> When create VM, this will result an exception:
>> >>
>> >> 2014-07-23 21:03:35,886 WARN [kvm.resource.LibvirtComputingResource]
>> >> (agentRequest-Handler-5:null) LibvirtException
>> >> org.libvirt.LibvirtException: Cannot get interface MTU on
>> 'OVSTunnel460':
>> >> no such device
>> >> at org.libvirt.ErrorHandler.processError(Unknown Source)
>> >> at org.libvirt.Connect.processError(Unknown Source)
>> >> at org.libvirt.Connect.processError(Unknown Source)
>> >> at org.libvirt.Connect.domainCreateXML(Unknown Source)
>> >> at
>> >>
>> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1239)
>> >> at
>> >>
>> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3798)
>> >> at
>> >>
>> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:133
>> >> 3)
>> >> at com.cloud.agent.Agent.processRequest(Agent.java:501)
>> >> at
>> com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808)
>> >> at com.cloud.utils.nio.Task.run(Task.java:84)
>> >> at
>> >>
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>> >> at
>> >>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>> >> at java.lang.Thread.run(Thread.java:722)
>> >>
>> >> I found code as below:
>> >> public InterfaceDef plug(NicTO nic, String guestOsType)
>> >> } else if (nic.getBroadcastType() ==
>> Networks.BroadcastDomainType.Vswitch)
>> >> {String vnetId =
>> >> Networks.BroadcastDomainType.getValue(nic.getBroadcastUri());
>> >> String brName = "OVSTunnel" + vnetId;
>> >>
>>
How to config linux native bridge to forward vxlan encapsulated pkts
Does anyone meet this issue: Create VM using vxlan for isolation guest network, both brvx-139 and vxlan139 is created, tcpdump can see the pkts has been encapsulated and forward to cloudbr1, but cloudbr1 does not forward pkts out from eth1, is there some special configuration on eth1, cloudbr1 or routes ? Does the fdb or mdb learn the address automically ? Regards
Re:Re: How to config linux native bridge to forward vxlan encapsulated pkts
I have resolved this issue by disable snooping echo "0" > /sys/devices/virtual/net/cloudbr1/bridge/multicast_snooping sysctl -p Thanks Yitao anyway At 2014-08-06 09:44:46, "Yitao Jiang" wrote: >Do u turned neteork forward on? Sysctl -p can tell you the configuration >On Aug 6, 2014 7:09 PM, "Michael Li" wrote: > >> Does anyone meet this issue: >> Create VM using vxlan for isolation guest network, >> both brvx-139 and vxlan139 is created, >> tcpdump can see the pkts has been encapsulated and forward to cloudbr1, >> but cloudbr1 does not forward pkts out from eth1, is there some special >> configuration on eth1, cloudbr1 or routes ? Does the fdb or mdb learn the >> address automically ? >> >> Regards >>
GRE Tunnel can not decapsulate and forward pkts
Hi all, I have used CS4.4+OVS for GRE tunnel tests, Use two hosts: host1 and host2 create vm1 on host1, vm2 on host2, VR is created on host1 Result: OVSTunnel117 is created on host1 and host2 with gre port and options remote_ip, this is the expectation result But vm2 can not be assigned ip by VR After I assigned the ip and route to this vm2 manually, ping from vm1 on host1 to vm2 on host2 the pkts have been encapsulated and forward to host2's OVSTunnel117, but not decapsulate and forward out to vnet10 which is connected to vm2. Has anyone met this issue ? Is the flow entries in OVS installed automatically ? Thanks
GRE Tunnel can not decapsulate and forward pkts
Hi all, I have used CS4.4+OVS for GRE tunnel tests, Use two hosts: host1 and host2 create vm1 on host1, vm2 on host2, VR is created on host1 Result: OVSTunnel117 is created on host1 and host2 with gre port and options remote_ip, this is the expectation result But vm2 can not be assigned ip by VR After I assigned the ip and route to this vm2 manually, ping from vm1 on host1 to vm2 on host2 the pkts have been encapsulated and forward to host2's OVSTunnel117, but not decapsulate and forward out to vnet10 which is connected to vm2. Has anyone met this issue ? Is the flow entries in OVS installed automatically ? Thanks
Re:Re: Status of ACS and OpenDayLight
Yes, I also eager to know how to use ODL in ACS 4.4.1, is there any docs or anybody can give help, thanks very much Regards. At 2014-12-14 04:47:47, "ilya musayev" wrote: >We also would like to see where its going and what integration there >might be. > >Chiradeep is on the board of ODL, perhaps he can share. > >On 12/11/14, 9:13 AM, Chip Childers wrote: >> On Thu, Dec 11, 2014 at 11:36:43AM +, Mathias Mullins wrote: >>> Hi everyone, >>> >>> Does anyone know the status of CloudStack and OpenDayLight connectivity? I >>> would like to learn how to make them work together to do more work with SDN. >>> >>> Thank you, >>> Matt >> IIRC, Hugo was working on that for a bit. Not sure where it got to >> though. >
