New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Experiences with OpenVZ veth (Virtual Ethernet device)?
I just ran across this on the OpenVZ wiki: http://wiki.openvz.org/Veth
Apparently OpenVZ does actually offer proper ethernet device virtualization and this simply isn't implemented in existing panels. I'm considering implementing it in CVM, but before I do that I'm curious if anyone here has any experiences with this method, and whether there are any caveats to be aware of.
Do you have any experience with veth, and if yes, what was it like?
Comments
Veth works great.. no problems with it on about five proxmox servers w/approx 10-15 containers on each.. the reason we used it is that it works nicely with tagged vlans within proxmox.. here is an example netif line from a container conf:
NETIF="ifname=eth0,bridge=vmbrXX,mac=xx:xx:xx:xx:xx:xx,host_ifname=veth16747.0,host_mac=xx:xx:xx:xx:xx:xx"
veth works OK, it is not popular because solusvm doesn't support it.
If you are going to provision VPSes for customers with veth make sure to implement your own reverse path filtering.
from memory veth interfaces also allow much more abuse, i.e. sniffing your neighbours packets.
They would also allow better VPN support.
Not only solus doesnt support it, also ovz-web-panel lacks support.
veth is a good idea, but it is probably not supported because of extra overhead and misguided security concerns. Any eth interface can allow sniffing, in theory, extra steps are needed to block that.
Thought that wouldn't apply to a configuration as described here, right? Seeing as you're only routing a particular subnet to the veth.
Can you elaborate on this?
veth is a good idea, but it is probably not supported because of extra overhead and misguided security concerns. Any eth interface can allow sniffing, in theory, extra steps are needed to block that.
Do you have an idea what kind of performance hit it incurs?
If you just put a veth interface inside each VPS and bridge all these interfaces on the node then VPS customers would be able to spoof IPs. You would need to do ebtables matches by MAC/IPs and only allow the "authorized" MAC/IP pairs (similar to what solusvm does for KVM VPSes i guess). Of course you could always do a separate hostnode interface per customer with it's own /30, but this would probably be considered a waste of IPs.
For huge traffic, I saw DDoS working at half the speed on virtio KVM interfaces, same hw setup as venet OVZ, considering other issues, I would say it will be about 20-25% loss of speed on heavy traffic due to extra overhead and a high CPU usage.
This is in extreme cases, regular traffic should not be really felt, especially on hosts which dont give much BW to the VPSes and/or 100 mbps or below ports.
Do you see http://wiki.openvz.org/Differences_between_venet_and_veth ?
I played with it on a local box years ago, trying to get IP broadcast to work from insider a container (for DHCP and a samba master). Followed all the openvz guides but never did succeed....
Yes, but that page did not exactly shed any light on the situation. Especially since they didn't say anything more than "it's slower, but not that much" without specifying how much slower.
Alright, but veth itself worked fine? As in, stable and properly functional connection otherwise?
Yes i can confirm that veth is properly functioning and working fine, i did some testing of it some weeks ago @joepie91
I can also confirm that is working. Can also set up nice routing if you put up more interfaces, i didnt see yet a difference between veth and similar emulated ifs for example in Xen-PV.
It is sad it is not more widely supported, a lot of problems would be solved this way.