Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 498322 - net-misc/vde-2.3.1: please add a systemd service file
Summary: net-misc/vde-2.3.1: please add a systemd service file
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: NP-Hardass
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: install-systemd-unit
  Show dependency tree
 
Reported: 2014-01-17 06:28 UTC by Alexander E. Patrakov
Modified: 2017-10-03 07:58 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
/usr/lib/systemd/system/vde@.service (file_498322.txt,289 bytes, patch)
2014-02-02 18:17 UTC, Tim Mohlmann
Details | Diff
/usr/lib/systemd/system/vde-ifconfig@.service (file_498322.txt,551 bytes, patch)
2014-02-02 18:23 UTC, Tim Mohlmann
Details | Diff
/etc/systemd/system/vde@.service.d/00gentoo.conf (file_498322.txt,1.31 KB, patch)
2014-02-02 18:32 UTC, Tim Mohlmann
Details | Diff
/usr/lib/systemd/system/vde@.service (file_498322.txt,296 bytes, patch)
2014-02-02 18:34 UTC, Tim Mohlmann
Details | Diff
/usr/lib/systemd/system/vde@.service (file_498322.txt,260 bytes, patch)
2014-02-03 09:43 UTC, Tim Mohlmann
Details | Diff
/usr/lib/systemd/system/vde-tap-config@.service (file_498322.txt,378 bytes, patch)
2014-02-03 09:55 UTC, Tim Mohlmann
Details | Diff
/etc/systemd/system/vde-tap-config@.service.d/00gentoo.conf (file_498322.txt,725 bytes, patch)
2014-02-03 10:03 UTC, Tim Mohlmann
Details | Diff
/etc/systemd/system/vde@.service.d/00gentoo.conf (file_498322.txt,627 bytes, patch)
2014-02-03 10:06 UTC, Tim Mohlmann
Details | Diff
/etc/systemd/system/vde-tap-config@.service.d/00gentoo.conf (file_498322.txt,728 bytes, patch)
2014-02-05 20:13 UTC, Tim Mohlmann
Details | Diff
/etc/systemd/system/vde-tap-config@.service.d/00gentoo.conf (file_498322.txt,823 bytes, patch)
2014-02-08 09:03 UTC, Tim Mohlmann
Details | Diff
/usr/lib/systemd/system/vde@.service (file_498322.txt,245 bytes, patch)
2014-02-09 14:31 UTC, Tim Mohlmann
Details | Diff
/etc/systemd/system/vde@.service.d/00gentoo.conf (file_498322.txt,692 bytes, patch)
2014-02-09 14:35 UTC, Tim Mohlmann
Details | Diff
/etc/systemd/system/vde@qemu.service.d/00gentoo.conf (file_498322.txt,212 bytes, text/plain)
2014-02-09 14:36 UTC, Tim Mohlmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander E. Patrakov 2014-01-17 06:28:02 UTC
net-misc/vde-2.3.1 has an init script but not a systemd service file. Please add a service file that would allow bringing the daemon (and the interface) up and setting up IP addresses/routing. A separate script is needed for the second task, because the traditional Gentoo method for setting up networking (that was part of openrc until recently) depends on openrc.

Reproducible: Always
Comment 1 Nico Baggus 2014-01-18 00:49:22 UTC
Something along these lines?


---
[Unit]
Description=vde emulates a virtual switch.
After=networki.${VDE_TAP}.target

[Service]
Type=forking
PIDFile=/var/run/vde.pid
ExecStartPre=modprobe tun
ExecStart=/usr/bin/vde_switch -daemin -tap ${VDE_TAP} ${VDE_OPTS}
ExecStartPost=chmod -R ${VDE_SOCK_CHMOD:770} /var/run/vde.ctl ; chown -R ${VDE_SOCK_CHOWN:qemu} /var/run/vde.ctl

ExecStop=
ExecStopPost=modprobe -r tun

[Install]
WantedBy=multi-user.target
---

I dont use systemd yet, so i can't test atm.
Not sure about the After= lines or the WantedBy lines though.
Comment 2 Nico Baggus 2014-01-18 00:56:11 UTC
As it emulates a switch port there is no routing as such.
(At least nothing different from the regular eth interfaces).
Comment 3 Alexander E. Patrakov 2014-01-18 14:41:23 UTC
About your unit file: it cannot work. ExecStart* lines are parsed by systemd, not by bash, and thus constructions like ${VDE_SOCK_CHMOD:770} are unsupported. And in fact, a separate chmod/chown is not needed (even in the traditional init script), because vde has built-in functionality to do so. I have hard-coded these parameters in the service file below, not sure if it is suitable.

About "modprobe tun" and "modprobe -r tun": this is in fact bad. Systemd's preferred interface for non-hardware module loading is /etc/modules-load.d, and it is sufficient to put a file (e.g. vde.conf) there containing a single line:

tun

As for unloading, just don't do it at all (including the traditional init script). The tun module may be needed for other things, e.g. for openvpn, and not all kernels support module unloading.

About the description: please bear in mind that systemd will display it after words "Starting", "Started", "Stopping" or "Stopped". Your description doesn't fit the bill.

For the ifconfig line: unfortunately, something configurable is needed here (or in a separate unit), because openrc networking (where users typically configure the IP address for their tap interface) cannot work with systemd. And there is no network.???.target in Gentoo. Users are currently limited to NetworkManager (which always ignores vde, i.e. does not work at all) or dhcpcd (which can be made to work in some, but not all cases, and this is a very non-obvious choice for configuring a static IP). Some users need to assign a static IP here, and other users will bridge the vde interface with one of their network cards. I don't know a good way to deal with it besides allowing arbitrary shell commands to be specified. My suggestion is thus:

[Unit]
Description=Virtual Distributed Ethernet

[Service]
Type=forking
EnvironmentFile=-/etc/conf.d/vde2
ExecStart=/usr/bin/vde_switch --tap vde --mode 0660 --dirmode 0750 --group qemu --daemon $VDE_OPTS
ExecStartPost=-/bin/sh -c ${VDE_POSTUP_CMD}
ExecStop=-/bin/sh -c ${VDE_PREDOWN_CMD}
# ... and we rely on systemd to kill vde_switch by itself after that

[Install]
WantedBy=multi-user.target


Tested with the following /etc/conf.d/vde2 (renamed to avoid incompatibility with the traditional init script, and some migration is necessary anyway because the existing file uses constructions that cannot be parsed by systemd):

VDE_OPTS=--hub
VDE_POSTUP_CMD="ifconfig vde 192.168.5.1/24"
VDE_PREDOWN_CMD="echo 'Too Bad'"

Of course, this can be further improved, e.g. turned into a templated service for the benefit of people who need more than one vde_switch. But let's sort out the basics first.
Comment 4 Nico Baggus 2014-01-18 15:32:10 UTC
First, i have no experience with systemd, in fact i try to avoid it. Although i am preparing to become a victim of it in the future as IMHO, systemd + integrating /usr into / sucks, i am currently in the process of rebuilding various systems because the rootfs is far too small to accomodate the /usr that is now needed. 

That said, If shell expands can't be used it be so, the support for a different user from qemu and different mods are when other machine simulators are used.
That's why they were variables in the first place.

One of the use case is where you need connections between VM's without having the VM's connecting to the real network in those cases the ifconfig is unwanted.
That also is one of the examples where you may have multiple vde's to f.e. test routing setups in a lab environment. (that my major use case).

So the example conf should mention the alternative...
VDE_POST_CMD="/bin/true"

(Expensive way to do nothing ...)
Comment 5 Alexander E. Patrakov 2014-01-18 17:51:38 UTC
In fact, not setting this at all, or setting to the empty value, works just as well.
Comment 6 Alexander E. Patrakov 2014-01-18 18:00:53 UTC
(In reply to Nico Baggus from comment #4)
> That said, If shell expands can't be used it be so, the support for a
> different user from qemu and different mods are when other machine
> simulators are used.

The qemu group is created in the vde ebuild and has no relation whatsoever to any virtual machine emulation package. Very misleading. I understand that it was also used by the kqemu ebuild, but it is long gone.
Comment 7 Nico Baggus 2014-01-18 22:12:25 UTC
It was also used & needed for qemu without kvm. just to let a plain user access the vde endpoints.
Indeed the current qemu doesn't have the qemu user anymore. Wonder how a plain user would be able to start a VM using vde... Somewhere along the way that got lost.
Comment 8 Tim Mohlmann 2014-02-02 18:14:01 UTC
(In reply to Alexander E. Patrakov from comment #3)

> For the ifconfig line: unfortunately, something configurable is needed here
> (or in a separate unit), because openrc networking (where users typically
> configure the IP address for their tap interface) cannot work with systemd.

True. Use a seperate unit Type=oneshot with the an ifconfig command

> [Service]
> Type=forking
> EnvironmentFile=-/etc/conf.d/vde2
 ExecStart=/usr/bin/vde_switch --tap vde --mode 0660 --dirmode 0750 --group
> qemu --daemon $VDE_OPTS
> ExecStartPost=-/bin/sh -c ${VDE_POSTUP_CMD}
> ExecStop=-/bin/sh -c ${VDE_PREDOWN_CMD}

Ouch! First of all, whenever possible don't use type=forking. Let Systemd handle the forking. Loose the --daemon option on the command line and use Type=simple.

Second: Systemd uses configuration directories itself, like /etc/conf.d, but in a different location. Those setting get purged automaticly, like /etc/conf.d does for /etc/init.d scripts. Use /etc/systemd/system/<unit>.service.d/<name>.conf (Usually 00gentoo.conf for packaged config)

> [Install]
> WantedBy=multi-user.target

vde and it's possible tap interface is network related. In virtual servers setups, services might exist which will depend on vde to be initialised as part of the network stack. (Eg using iptables or something like that). network.target would be a better place, but this is discussable.

> Of course, this can be further improved, e.g. turned into a templated
> service for the benefit of people who need more than one vde_switch. But
> let's sort out the basics first.

:D See attached after this post
Comment 9 Tim Mohlmann 2014-02-02 18:17:42 UTC
Created attachment 369372 [details, diff]
/usr/lib/systemd/system/vde@.service

Vde service template. Activate by `systemctl start vde@<instance>.service`
Comment 10 Tim Mohlmann 2014-02-02 18:23:04 UTC
Created attachment 369374 [details, diff]
/usr/lib/systemd/system/vde-ifconfig@.service

Configures IP address for vde's tap interface. includes same config file as vde@.service, to have single file configure, because interface names should always match between services.

To always appoint an IP address to the vde tap interface, whenever it is started:
`systemctl enable vde-ifconfig@<instance>.service`
To appoint an IP address to an already running vde tap:
`systemctl start vde-ifconfig@<instance>.service`

You cannot run this unit on it's own and it will fail on dependency if you try to.
Comment 11 Tim Mohlmann 2014-02-02 18:32:09 UTC
Created attachment 369376 [details, diff]
/etc/systemd/system/vde@.service.d/00gentoo.conf

Config for vde@.service and vde-ifconfig@.service. Makes running multiple instances possible.

It already includes config for vde@qemu.service. Qemu uses an override for the "dynamic" communication socket, to create the default one, so that qemu users don't have to convert their commands to point to the right socket.

All qemu users have to do is enable or start this services using
`systemctl enable vde-ifconfig@qemu.service`
`systemctl enable vde@qemu.service` and / or `systemctl start vde@qemu.service`

And they will end up with a vde_switch, connected to tap0 configured on IP 10.0.0.1/24.

Other users have freedom to configure whatever they want, as per examples.
Comment 12 Tim Mohlmann 2014-02-02 18:34:15 UTC
Created attachment 369378 [details, diff]
/usr/lib/systemd/system/vde@.service

Forgot to modify the Documentation= entry, this is the correct one
Comment 13 Tim Mohlmann 2014-02-02 18:35:47 UTC
If Unit files are accepted I will write the docs in the wiki as per link in the files.
Comment 14 Alexander E. Patrakov 2014-02-02 19:00:46 UTC
Unfortunately, I cannot accept the attached units, but the wanted changes are mostly related to documentation.

Type = forking was put there for a reason: we need vde to indicate its readiness before doing the ifconfig stuff. An alternative would be a dependency of the ifconfig unit on the actual tap interface, but I could not figure out the needed syntax.

As for the ifconfig unit, it needs some documentation for the users who don't want the ifconfig and, instead, want another command (e.g. some form of brctl) to run.

As for Before=dnsmasq.service, this assumes suitable dnamasq configuration. This assumption should be documented.
Comment 15 Alexander E. Patrakov 2014-02-02 19:09:13 UTC
OTOH, after stracing vde_switch, I am now convinced that its startup is inherently racy, and Type = forking doesn't actually help. It opens /dev/net/tun after daemonizing, which is Too Bad and needs to be patched.
Comment 16 Tim Mohlmann 2014-02-03 09:02:11 UTC
(In reply to Alexander E. Patrakov from comment #14)
> Unfortunately, I cannot accept the attached units, but the wanted changes
> are mostly related to documentation.
> 
> Type = forking was put there for a reason: we need vde to indicate its
> readiness before doing the ifconfig stuff. An alternative would be a
> dependency of the ifconfig unit on the actual tap interface, but I could not
> figure out the needed syntax.

Did you actually run into any problems using the proposed units? I've been using the same approach quite some time and never ended up with non-existing device errors for ifconfig and the interface always configured as I wanted. But... different systems different behaviour.

Is use After=vde@%i.service in vde-ifconfig@%i.service, to make sure the order is in the correct way.

If you really run into the race problem against the interface, there is a possibility to use device unit files. 

> As for the ifconfig unit, it needs some documentation for the users who
> don't want the ifconfig and, instead, want another command (e.g. some form
> of brctl) to run.

Uhm.. maybe I was a bit forthcoming with writing an ifconfig script. Basicly, the responsibility of the vde package is to deliver a unit which start vde_switch. Not to configure network interfaces related to it. That should go somewhere else, but I have no idea where. Like you said, systemd doesn't provide any networking configuration.

It's just that I wrote the units for my own system and wanted to share it with you guys after finding this bug report.

I could move vde-ifconfig@.service to vde-tap-config@.service and provide means for the user to choose which program to use in vde-tap-config@.service.d/00gentoo.conf.

However, this will split the config in two files, which gives the user the responsibility to make sure interface naming is consistent between the two units. OR interface names will have to automaticly follow instance names. So if you start vde@foo.service you will get a tap interface called "foo". This is not a lot of work for me.

> As for Before=dnsmasq.service, this assumes suitable dnamasq configuration.
> This assumption should be documented.

You are right, this should not be in the Unit file, but should be as a comment in the config file, so that the user knows that they can play with dependencies. It was inherited from my own system where I needed this dependency.
Comment 17 Tim Mohlmann 2014-02-03 09:43:24 UTC
Created attachment 369414 [details, diff]
/usr/lib/systemd/system/vde@.service

Removed Before=dnsmasq.service statement

Tap names are now automaticly assigned using the instance name. This is the only way to provide the user the option of using different configuration commands. This is also necessary for interface waiting for the vde-tap-config@.service.
Comment 18 Alexander E. Patrakov 2014-02-03 09:49:24 UTC
I have not tested the unit files that you provided. I have only audited them and straced vde_switch, and that's another (also valid) way to find problems.

So, even though I have not triggered the race (that exists even in my unit files), it is not a reason to write it off.

As for "That [ifconfig/brctl/whatever] should go somewhere else, but I have no idea where" - I also have no idea.
Comment 19 Tim Mohlmann 2014-02-03 09:55:04 UTC
Created attachment 369416 [details, diff]
/usr/lib/systemd/system/vde-tap-config@.service

Replaces /usr/lib/systemd/system/vde-ifconfig@.service

Unit now waits for the tap device to show up: BindsTo=sys-devices-virtual-net-%i.device

RemainAfterExit is changed to yes. Unit will be de-activated if the tap interface disappears when vde@<instance>.service is stopped.

Users can still choose if they want to configure anything, by using:
* `systemctl enable vde-tap-config@<instance>.service` to configure the interface every time vde@<instance>.service is started
* `systemctl start vde-tap-config@<instance>.service` to configure the interface one time, once vde@<instance>.service is started
* `systemctl disable vde-tap-config@<instance>.service` unset the above enable.
Comment 20 Alexander E. Patrakov 2014-02-03 09:57:40 UTC
I don't see how the users would actually set the IP address using that unit file. Maybe some Exec=... line is missing?
Comment 21 Tim Mohlmann 2014-02-03 10:03:09 UTC
Created attachment 369418 [details, diff]
/etc/systemd/system/vde-tap-config@.service.d/00gentoo.conf

Additional config file for vde-tap-config@.service. Here the command and its options can be specified. Also the possibility to use Before=dnsmasq.service is explained here.
Comment 22 Alexander E. Patrakov 2014-02-03 10:05:41 UTC
OK, this looks more-or-less sane, but I have to test it. Will do that later today.
Comment 23 Tim Mohlmann 2014-02-03 10:06:01 UTC
Created attachment 369420 [details, diff]
/etc/systemd/system/vde@.service.d/00gentoo.conf

Config made matching to other changes. It is no longer used for vde-ifconfig@.service. (Nor its replacement).

IP should not be configured here anymore and tap interface is no longer configurable.
Comment 24 Tim Mohlmann 2014-02-03 10:09:21 UTC
(In reply to Alexander E. Patrakov from comment #20)
> I don't see how the users would actually set the IP address using that unit
> file. Maybe some Exec=... line is missing?

Patience, my friend I was still busy posting them ;). All done now. Units already tested by me and found working.

Please make some brctl examples in /etc/systemd/system/vde-tap-config@.service.d/00gentoo.conf, I am not familiar with it.
Comment 25 Alexander E. Patrakov 2014-02-04 19:08:20 UTC
Sorry for the delay with testing your units.

They do work, and I have customized them for bridging. Unfortunately, some more work is needed, but it is rather trivial and thus I pre-approve the results. Here is how you can reproduce my setup. I assume that you have NetworkManager, using the keyfile plugin (which is the default), and have a system connection for your Ethernet card. If you don't, then make your own service files out of the following example commands (some of which are already covered by the attached examples):

brctl addbr br0
brctl stp br0 off
brctl addif br0 eno1
brctl addif br0 qemu
dhcpcd br0

Back to the NetworkManager case.

First, disable your existing Ethernet connection in NetworkManager. You can do it by adding autoconnect=false into its [connection] section. We will reconfigure this device as a bridge port in the next paragraph.

Then, create two configuration files: one for the bridge itself, and one for the Ethernet card that will become the part of the bridge. In these examples, 94:de:80:6f:9a:d4 should be replaced with the MAC address of your card, and UUIDs generated anew with uuidgen.

# cat /etc/NetworkManager/system-connections/Bridge
[connection]
id=Bridge
uuid=0cddff7e-3d51-4886-b8d5-cd3d3ea237b0
interface-name=br0
type=bridge

[bridge]
interface-name=br0
stp=false
# duplicate interface-name is needed due to a bug in NetworkManager
# stp=fasle is required because otherwise DHCP will time out

# Copy the [ipv4] and [ipv6] sections from your old connection
[ipv6]
method=auto

[ipv4]
method=auto

# cat /etc/NetworkManager/system-connections/BridgePort 
[connection]
id=BridgePort
uuid=04fc297c-e6f1-4af3-bf5f-fe930ddb73d3
type=802-3-ethernet
master=0cddff7e-3d51-4886-b8d5-cd3d3ea237b0
slave-type=bridge

[802-3-ethernet]
mac-address=94:de:80:6f:9a:d4

With that in place, after restarting NetworkManager, you will have a bridge interface "br0" with one port, and a working internet connection with the old settings.

The goal now is to add the vde tap interface as another port of that bridge. That's simple. Install all the service files and configurations that you have already attached to this bug, without modifications. Then create the missing config:

# cat /etc/systemd/system/vde-tap-config@qemu.service.d/50my.conf 
[Unit]
BindsTo=sys-devices-virtual-net-%i.device sys-devices-virtual-net-br0.device
After=vde@%i.service sys-devices-virtual-net-%i.device sys-devices-virtual-net-br0.device

[Service]
ExecStart=/bin/ifconfig %i hw ether $%i_MAC
ExecStart=/sbin/brctl addif br0 %i

Environment="qemu_IP=up"
Environment="qemu_MAC=94:de:80:6f:9a:d4"

That's all. You can boot a livecd in qemu as follows:

qemu-system-x86_64 -sdl -enable-kvm -m 1024 -vga std -cdrom livecd.iso -net nic,model=e1000 -net vde

...and it will appear in your wired network and will hopefully get an IP address from the same router as your PC uses.

As you see, I have stubbed out the assignment of an IP address, because it is not useful for bridge ports. But still, the interface has to be brought up explicitly.

Also, I want to be able to set a static MAC address on the tap interface (even in the non-bridged case), because otherwise it is random. As you see, I have set it to the same MAC address as my Ethernet card has. This is needed in order to ensure that the bridge consistently gets the same MAC address on each boot (by default, it clones the MAC address of the first added port (which is, randomly, either eno1 or qemu), and NetworkManager, due to a bug, cannot override this).

So, the "trivial work" that I referenced above is:

 * Document how to disable IP address assignment to the tap interface.
 * Devise a standard method to set the MAC address of the tap interface.
Comment 26 Tim Mohlmann 2014-02-05 19:29:09 UTC
(In reply to Alexander E. Patrakov from comment #25)
> They do work, and I have customized them for bridging. Unfortunately, some
> more work is needed, but it is rather trivial and thus I pre-approve the
> results. Here is how you can reproduce my setup. I assume that you have
> NetworkManager, using the keyfile plugin (which is the default), and have a
> system connection for your Ethernet card. If you don't, then make your own
> service files out of the following example commands (some of which are
> already covered by the attached examples):

I use NetworkManager only with user connections. I use a dnsmasq + iptables NAT setup, to give my VDE network access to the outside world. This is more convenient for me, because I travel a lot and I do not want to expose my virtual machines to the (untrusted) LANs I connect to.

No need to reproduce your issue, I see what you mean.

> The goal now is to add the vde tap interface as another port of that bridge.
> That's simple. Install all the service files and configurations that you
> have already attached to this bug, without modifications. Then create the
> missing config:
> 
> # cat /etc/systemd/system/vde-tap-config@qemu.service.d/50my.conf 
> [Unit]
> BindsTo=sys-devices-virtual-net-%i.device sys-devices-virtual-net-br0.device
> After=vde@%i.service sys-devices-virtual-net-%i.device sys-devices-virtual-net-br0.device

No need to include redundant fields from 00gentoo.conf. Loose sys-devices-virtual-net-%i.device and vde@%i.service

> [Service]
> ExecStart=/bin/ifconfig %i hw ether $%i_MAC
> ExecStart=/sbin/brctl addif br0 %i
> 
> Environment="qemu_IP=up"
If you want to get rid of a previous statement, use a blank Execute= field

> Environment="qemu_MAC=94:de:80:6f:9a:d4"
Since this config is for a single instance, you can pas this directly in the ExecStart= field.

Are you familiar with the systemd man pages?
man systemd.unit, systemd.service and systemd.exec

If you are using a setup like yours, I would make 50my.conf as follows:

[Unit]
BindsTo=sys-devices-virtual-net-br0.device
After=sys-devices-virtual-net-br0.device

[Service]
ExecStart=
ExecStart=/bin/ifconfig %i hw ether 94:de:80:6f:9a:d4 up
ExecStart=/sbin/brctl addif br0 %i

> As you see, I have stubbed out the assignment of an IP address, because it
> is not useful for bridge ports. But still, the interface has to be brought
> up explicitly.

You can do this with a single ifconfig command, see my suggestion above.

The above was just for sake of the discussion / education. Back to on-topic:


> So, the "trivial work" that I referenced above is:
> 
>  * Document how to disable IP address assignment to the tap interface.
>  * Devise a standard method to set the MAC address of the tap interface.

What about changing $%i_IP to $%i_IFCONFIG_OPTS? It doesn't change much in how it works, just to point that you can put *anything* in there that ifconfig accepts. You could put the `hw ether 94:de:80:6f:9a:d4 up` in 00gentoo.conf then. I will upload a new proposal in a few minutes.
Comment 27 Tim Mohlmann 2014-02-05 20:13:33 UTC
Created attachment 369646 [details, diff]
/etc/systemd/system/vde-tap-config@.service.d/00gentoo.conf

Changed $%i_IP to $%i_IFCONFIG_OPTS and fixed MAC address setting is now default
Comment 28 Alexander E. Patrakov 2014-02-06 03:46:49 UTC
Your config works as it should. So some final touches of the comments, and I think it can be uploaded.

1. Typo fix: separete -> separate
2. Maybe add some more constructive text near the "no daemons!" phrase? E.g.: "Do not run daemons here. Instead, put them in a separate service file and declare dependencies, as illustrated by the dnsmasq example above".
Comment 29 Tim Mohlmann 2014-02-08 09:03:11 UTC
Created attachment 369852 [details, diff]
/etc/systemd/system/vde-tap-config@.service.d/00gentoo.conf

Corrected spelling error in comment and explained the use of multiple commands and not daemons better.
Comment 30 Alexander E. Patrakov 2014-02-08 12:05:17 UTC
As I have already said, the attached files are good. This setup works now, and I see no reason why it would stop working after any upgrade. Ship it.

As for the fact that systemd 209 will ship with networkd - yes, that's an alternative. But it is in the unknown future, so let's use what we have.
Comment 31 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-02-08 15:28:31 UTC
What are you exactly trying to achieve here? Reinvent a network configuration framework to support a single network device?
Comment 32 Alexander E. Patrakov 2014-02-08 15:39:19 UTC
Yes, exactly, because there are no alternatives. Because systemd-208 does not provide that yet, openrc network scripts are not available, dhcpcd covers only one of the two discussed use cases, and NetworkManager purposely ignores vde devices.
Comment 33 Alexander E. Patrakov 2014-02-08 15:40:45 UTC
Actually there is an alternative - backport networkd from the unreleased systemd-209, but I am not sure you would welcome that.
Comment 34 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-02-08 16:00:27 UTC
Then vde is completely not a place to invent special solutions. If any of the generic solutions (like netcfg) does not work, work on one. If you really miss OpenRC network scripts, netifrc is waiting for someone to add systemd support. Providing a local custom magic script for vde is definitely wrong. Sorry.
Comment 35 Alexander E. Patrakov 2014-02-08 16:24:58 UTC
Please reopen. The ifconfig part may be invalid, but the "start vde_switch" part is definitely valid.
Comment 36 Tim Mohlmann 2014-02-09 14:27:31 UTC
(In reply to Tim Mohlmann from comment #16)
 
> Uhm.. maybe I was a bit forthcoming with writing an ifconfig script.
> Basicly, the responsibility of the vde package is to deliver a unit which
> start vde_switch. Not to configure network interfaces related to it. That
> should go somewhere else, but I have no idea where. Like you said, systemd
> doesn't provide any networking configuration.

Apparently I had the right feeling about this and wasted too much time on the requests of a single person, of whom I assumed to be a proxy maintainer or something.

I will drop the ifconfig unit and go back to the basics with the vde@.service unit. But this will be my last effort on this matter, so use it or not, I am done with it.
Comment 37 Tim Mohlmann 2014-02-09 14:31:44 UTC
Created attachment 369952 [details, diff]
/usr/lib/systemd/system/vde@.service

Dropped vde-tap-config and ifconfig related stuff. Simplified unit file, to only support strict systemd configuration syntax:
/etc/systemd/system/vde@.service.d/00gentoo.conf: configuration for all instances
/etc/systemd/system/vde@<instance>.service.d/<foo>.conf: configuration for a particular instance
Comment 38 Tim Mohlmann 2014-02-09 14:35:14 UTC
Created attachment 369954 [details, diff]
/etc/systemd/system/vde@.service.d/00gentoo.conf

New config file to fit the new unit file.
Comment 39 Tim Mohlmann 2014-02-09 14:36:55 UTC
Created attachment 369956 [details]
/etc/systemd/system/vde@qemu.service.d/00gentoo.conf

Example / default config to use vde with qemu
Comment 40 Alexander E. Patrakov 2014-02-09 15:35:46 UTC
Sorry for wasting your time, but I have to disagree with the unit (or, more precisely, with commented-out lines in it), for the reasons that I and Michał Górny have already mentioned.

There is still a genuine need to configure the interface created by vde_switch. Michał Górny correctly wants this to be done by a well-established and generic framework, not by local hacks.

Apparently because of this need, you have put ExecStartPre= and ExecStartPost= commented-out lines in the default configuration. However, I think this is still contrary to to the wish of Michał Górny, as this still amounts to a local micro-framework for configuring the interface. And a bad one, for this point: it does not wait for the interface to be actually created before attempting to configure it.

So, thanks for your units. I just have to find a working (as in: supporting both static-IP and port-of-bridge configurations) interface configuration system that does not conflict with NetworkManager, and change the comments to point the users to it instead of the ExecStartPre and ExecStartPost lines.