[
https://issues.apache.org/jira/browse/CLOUDSTACK-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14585688#comment-14585688
]
Wilder Rodrigues commented on CLOUDSTACK-4690:
----------------------------------------------
Hi [[email protected]],
I was looking into this issue and trying to get it fixed. After 1 week and
being able to reproduce the problem, I haven't found a way to get it done yet.
I discussed with some colleagues and we are inclined to stop working on it,
since there is no evidence that it has even worked or even if someone is still
trying to use it.
Before I go on and share the conclusions we had, I have a couple of questions:
1. Are you still trying to get it working?
2. Would you actually use OVS + GRE in your setup?
Below the notes I team to our team:
After spending a week on this problem and going through the current
implementation, we decided that it out of the scope to get this bug fixed. The
point below should clarify our decision:
1. In order to get the OVSTunnels configured manual interaction is needed;
2. During VMs creation, GreTunnelException are thrown but VMs are still created;
- This occurs in the OVSTunnelManagerImple, when the getGreEndpointIP is
bring retrieved.
3. Many cases/tasks treated in the same method leading to misbehaviour;
- When Creating a VM, exceptions will say something like: failed to do this,
but doing that succeeded. Although the VM is created and can be reached, adding
a second VM won't work 100% because they cannot see each other
4. The current implementation support only GRE, adding all the other isolation
methods will be a huge project. In addition, OVS is already used under Nicira
NVP
5. The code is too brittle and poor. No maintainability/extensibility in place;
no tests and no prove it ever worked.
My conclusion and suggestion is: we remove the whole OVS/GRE implementation
from the source base. If we want to add that in the future, we rewrite the
whole thing.
Looking to hear from you.
Cheers,
Wilder
> KVM Router - to many ethernet devices created
> ---------------------------------------------
>
> Key: CLOUDSTACK-4690
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4690
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
> Affects Versions: 4.1.1
> Environment: Centos 6.4
> Reporter: Paul Edwards
> Assignee: Wilder Rodrigues
> Priority: Critical
> Attachments: 20141001-agent.log, 20141001-management-server.log,
> management-server.log, router.log
>
>
> We have setup cloudstack with advanced networking. We have a network created
> 172.16.24.0/23, called news preprod. This has a number of vms created under
> it. When we initially set this up, we noticed that the router we created with
> 4 ethernet interfaces. This was unexpected, but didn't seem to be effecting
> the running of the router, so we didn't worry about it. The interfaces were:
> eth0 172.16.24.14, eth1 169.254.1.91, and both eth2 and eth2 were given the
> external ip (xxx.xxx.245.59). We investigated why we were getting 2
> externals, but couldn't figure it out. We also configured the router to have
> a redundant, with keepalived. They were working fine.
> Now I needed to add another external ip to the network. Did that, and
> restarted the network. I now have 8 (eight) eth interfaces. The new external
> ip is NOT one of them. Heres the ifconfig output:
> root@r-235-VM:~# ifconfig
> eth0 Link encap:Ethernet HWaddr 02:00:68:e1:00:1a
> inet addr:172.16.24.14 Bcast:172.16.25.255 Mask:255.255.254.0
> inet6 addr: fe80::68ff:fee1:1a/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:5485 errors:0 dropped:0 overruns:0 frame:0
> TX packets:21101 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:325618 (317.9 KiB) TX bytes:1581746 (1.5 MiB)
> eth1 Link encap:Ethernet HWaddr 0e:00:a9:fe:01:5b
> inet addr:169.254.1.91 Bcast:169.254.255.255 Mask:255.255.0.0
> inet6 addr: fe80::c00:a9ff:fefe:15b/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:22118 errors:0 dropped:0 overruns:0 frame:0
> TX packets:21148 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:3942785 (3.7 MiB) TX bytes:4287970 (4.0 MiB)
> eth2 Link encap:Ethernet HWaddr 06:16:06:00:01:03
> inet addr:xxx.xxx.245.59 Bcast:xxx.xxx.245.255 Mask:255.255.255.0
> inet6 addr: fe80::416:6ff:fe00:103/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:17331 errors:0 dropped:0 overruns:0 frame:0
> TX packets:3930 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:1063053 (1.0 MiB) TX bytes:234546 (229.0 KiB)
> eth3 Link encap:Ethernet HWaddr 06:d7:ec:00:01:03
> inet addr:xxx.xxx.245.59 Bcast:xxx.xxx.245.255 Mask:255.255.255.0
> inet6 addr: fe80::4d7:ecff:fe00:103/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:13603 errors:0 dropped:0 overruns:0 frame:0
> TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:792907 (774.3 KiB) TX bytes:704 (704.0 B)
> eth4 Link encap:Ethernet HWaddr 06:8b:5a:00:01:03
> inet addr:xxx.xxx.245.59 Bcast:xxx.xxx.245.255 Mask:255.255.255.0
> inet6 addr: fe80::48b:5aff:fe00:103/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:13319 errors:0 dropped:0 overruns:0 frame:0
> TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:779753 (761.4 KiB) TX bytes:704 (704.0 B)
> eth5 Link encap:Ethernet HWaddr 06:7e:68:00:01:03
> inet addr:xxx.xxx.245.59 Bcast:xxx.xxx.245.255 Mask:255.255.255.0
> inet6 addr: fe80::47e:68ff:fe00:103/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:13080 errors:0 dropped:0 overruns:0 frame:0
> TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:762111 (744.2 KiB) TX bytes:704 (704.0 B)
> eth6 Link encap:Ethernet HWaddr 06:7e:68:00:01:03
> inet addr:xxx.xxx.245.59 Bcast:xxx.xxx.245.255 Mask:255.255.255.0
> inet6 addr: fe80::47e:68ff:fe00:103/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:13086 errors:0 dropped:0 overruns:0 frame:0
> TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:762655 (744.7 KiB) TX bytes:774 (774.0 B)
> eth7 Link encap:Ethernet HWaddr 06:27:a8:00:01:03
> inet addr:xxx.xxx.245.59 Bcast:xxx.xxx.245.255 Mask:255.255.255.0
> inet6 addr: fe80::427:a8ff:fe00:103/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:13064 errors:0 dropped:0 overruns:0 frame:0
> TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:761153 (743.3 KiB) TX bytes:704 (704.0 B)
> eth8 Link encap:Ethernet HWaddr 06:27:a8:00:01:03
> inet addr:xxx.xxx.245.59 Bcast:xxx.xxx.245.255 Mask:255.255.255.0
> inet6 addr: fe80::427:a8ff:fe00:103/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:13043 errors:0 dropped:0 overruns:0 frame:0
> TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:759287 (741.4 KiB) TX bytes:704 (704.0 B)
> lo Link 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:6 errors:0 dropped:0 overruns:0 frame:0
> TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:414 (414.0 B) TX bytes:414 (414.0 B)
> The cloudstack management browser still shows the router as only supposed to
> have 3 nics.
> The agent log on the physical host has nothing in it (I was tailing that log
> when I did this, as I would have thought that the agent has to create the
> devices for the vm to get them).
> I have attached the management log from just before to just after. (Time of
> change was 9:39am). I do not know why the router timestamp is not the same as
> the host.
> I have also attached the log of the router restart.
> The physical server is Centos 6.4, and all the vms that we have created are
> Centos 6.4. KVM is the hypervisor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
