We have just released a new kernel from the development branch — a shiny new 2.6.16-026test014.4. Aside from the usual bunch of fixes and some performance optimizations, it includes three major features:
- Virtual ethernet device (a.k.a. veth) for a VE
- /proc/meminfo virtualization
- IPv6 virtualization
I will probably describe the other features some time later, now I want to tell you a bit about what veth is.
As each VE is "just like a real server", it needs networking abilities, thus it needs an IP address. For that to happen, there is a special network device implemented in OpenVZ kernel, called venet. Venet appears in a VE, and a physical server admin can set up an IP (or a few) for a VE. Note that IP for a VE should be set from the host system, because the proper route should be added to the host's routing table.
While venet is just fine for most of the purposes, there are some special cases which it just can not handle. For example, since venet has no MAC address, there is no ability to send/receive broadcasts, which makes impossible to run DHCP software in a VE. There is no ability to use multicasts. VE owner can not add a new IP to his system (which is actually good if your VE is untrusted, but in some other cases is a bit inconvenient).
So, to solve the above, here comes yet another virtual network device for a VE called veth. Being a human I am too lazy to repeat the work already done, so let me just quote Kirill Korotaev, our kernel team leader:
Unlike venet, veth is ethernet like adapter with MAC address. Due to this, it can be used in configurations, when veth is bridged to ethX or other device and VPS user fully setups his networking himself, including IPs, gateways etc.
List of differences:
- veth allows broadcasts in VPS, so you can use even dhcp server inside VPS or samba server with domain broadcasts or other such stuff
- veth has some security implications, so is not recommended in untrusted environments like HSP. This is due to broadcasts, traffic sniffing, possible IP collisions etc. i.e. VPS user can actually ruin your ethernet network with such direct access to ethernet layer.
- with venet device, only node administrator can assign IP to VPS. With veth device, network settings can be fully done on VPS side. VPS should setup correct GW, IP/mask etc and node admin then can only choose where your traffic goes.
- veth devices can be bridged together and/or with other devices. For example, in host system admin can bridge veth from 2 VPSs with some VLAN eth0.X. In this case, these 2 VPSs will be connected to this VLAN.
- venet device is a bit faster and more efficient.
- with veth devices IPv6 auto generates an address from MAC.
The brief summary:
| Feature | veth | venet |
|---|---|---|
| MAC address | + | - |
| Broadcasts inside VE | + | - |
| Traffic sniffing | + | - |
| Network security | low* |
high |
| Can be used in bridges | + | - |
| Performance | fast | fastest |
Usage scenarios will be added here soon: wiki: Virtual Ethernet device
So, to conclude, with virtual ethernet device OpenVZ becomes even more powerful and useful in some advanced networking scenarios. As always, the power comes with the responsibility: do not give veth to the untrusted VEs, or you'll be b0rked.


Comments
Do you still stand by your opinions above now in 2016?…