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
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.
As it emulates a switch port there is no routing as such. (At least nothing different from the regular eth interfaces).
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.
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 ...)
In fact, not setting this at all, or setting to the empty value, works just as well.
(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.
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.
(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
Created attachment 369372 [details, diff] /usr/lib/systemd/system/vde@.service Vde service template. Activate by `systemctl start vde@<instance>.service`
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.
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.
Created attachment 369378 [details, diff] /usr/lib/systemd/system/vde@.service Forgot to modify the Documentation= entry, this is the correct one
If Unit files are accepted I will write the docs in the wiki as per link in the files.
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.
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.
(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.
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.
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.
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.
I don't see how the users would actually set the IP address using that unit file. Maybe some Exec=... line is missing?
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.
OK, this looks more-or-less sane, but I have to test it. Will do that later today.
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.
(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.
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.
(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.
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
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".
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.
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.
What are you exactly trying to achieve here? Reinvent a network configuration framework to support a single network device?
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.
Actually there is an alternative - backport networkd from the unreleased systemd-209, but I am not sure you would welcome that.
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.
Please reopen. The ifconfig part may be invalid, but the "start vde_switch" part is definitely valid.
(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.
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
Created attachment 369954 [details, diff] /etc/systemd/system/vde@.service.d/00gentoo.conf New config file to fit the new unit file.
Created attachment 369956 [details] /etc/systemd/system/vde@qemu.service.d/00gentoo.conf Example / default config to use vde with qemu
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.
