Re: [systemd-devel] systemd-nspawn: cannot join existing macvlan
Lennart Poettering schrieb: > On Sat, 30.05.15 19:55, Kai Krakow (hurikha...@gmail.com) wrote: > >> The next issue with your argument is: AFAIR nspawn doesn't create a >> macvlan interface based on the machine name. You have to pass the name of >> a physical interface which transports this macvlan. The man page at least >> states that you use an existing physical interface: > > True, I was a bit confused there... :-) Fine. I thought I was totally wrong. >> So your assumption about macvlan seems to be incorrect. The other network >> types may be based off the machine name but it doesn't work this way with >> macvlan. > > Yeah, nspawn creates a n interface "mv-foo" from a network interface > "foo" on the host. Yes, it creates it on the host. In the guest, AFAIR (I cannot currently try this), it creates host0 as interface. Correct me if I'm wrong, but I see macvlan as a sort of peer-to-peer level2 LAN. The host endpoint is mv-foo, each guest has its own endpoint host0, spanning a virtual switch accross all peers, thus between mv-foo and each host0. >> I think the logic is wrong here in systemd-nspawn. Instead of trying to >> create the host-side macvlan itself it should insist of it being there >> already (to have one well-defined state to start with, and only >> optionally create it by itself). Then, it can join multiple machines to >> the same macvlan. > > I don't grok this? > > "the same macvlan"? Well, the level2 peer-to-peer LAN... So, in this context, mv-foo should only be created once. Successive guests should only be joined to the existing macvlan. > I have the suspicion that the confusion here stems from the fact that > nspawn creates the macvlan iface on the host first, then moves it into > the container. but if you already have an iface by that name on the > host, then it cannot create the macvlan under that name. I don't think this is how it worked as far as I remember, but as already pointed out: I still have to try that again. Currently my setup refuses to run the machines, I need to reconfigure the system first to get one machine up and running. In this context: I think when it worked, it created mv-foo on the host (so you are true here), but it won't move it into the container. It creates a companion device there called host0. This is a level2 peer-to-peer network in the kernel. So maybe host0 is created in the host, then moved into the container - I'm not sure. Other peers could be joined. The mv-foo interface is a virtual MAC address on the host. If you created it manually, you would join more virtual interfaces to the physical interface, i.e. host0 from the container. Each peer interface can communicate with the others but not with the physical interface directly, except your switch has packet mirroring capabilities and would send packages back to the port they originated from - this is usually not encouraged by the ethernet switch specification. The kernel's MACVLAN implementation won't pass packets to the physical interface directly but always through the medium connecting to the switch, and the switch won't pass it back on the same physical port by sane reasoning. However, the kernel would pass packets between MACVLAN peers it locally knows without touching the physical interface. The physical interface is only a transport medium for non-local (from view of MACVLAN known MACs) packets. To overcome this issue, I need to configure mv-foo to receive my DHCP lease instead of the physical interface. Now each peer can communicate with my LAN and each other MACVLAN peer of my physical interface (which now includes my host mv-foo on layer3). The ḾAC address of the physical interface is more or less unused. > I figure we can fix that by creating the iface under a random name > first on the host, then move it into the container, and then rename it > to the right name afterwarads. The problem is with the interface that stays in the host, not with the interface in the container. This fix may be for a second problem I did not yet observe. > A work-around would be to name the .netdev iface of yours something > else than "mv-enp5s0", call it "waldi" or so, so that it doesn't > conflict with the name for the contaainer in the short time-frame that > the iface nspawn creates exists on the host... I need to create this manually with networkd and configure it as DHCP client for the above reasons. Otherwise my host communicates through the physical interface "foo" instead of "mv-foo", which effectively disables communication with the MACVLAN peers for the above outlined reasons. > Can you verify if such a change fixes your issue? If so, we can > randomoize the name initially, as sugegsted above. I'll first restore a configuration which gets one container up and running again with working MACVLAN, then we can figure out where the problem is. I somehow believe your guess about the source of the issue is currently not quite right. Such a machine cou
Re: [systemd-devel] systemd-nspawn: cannot join existing macvlan
On Thu, Jun 18, 2015 at 9:10 PM, Lennart Poettering
wrote:
> On Sat, 30.05.15 19:55, Kai Krakow (hurikha...@gmail.com) wrote:
>
>> The next issue with your argument is: AFAIR nspawn doesn't create a macvlan
>> interface based on the machine name. You have to pass the name of a physical
>> interface which transports this macvlan. The man page at least states that
>> you use an existing physical interface:
>
> True, I was a bit confused there...
>
>>
>> --network-macvlan=
>> Create a "macvlan" interface of the specified Ethernet network
>> interface and add it to the container. A "macvlan" interface is a
>> virtual interface that adds a second MAC address to an existing
>> physical Ethernet link. The interface in the container will be named
>> after the interface on the host, prefixed with "mv-". Note that
>> --network-macvlan= implies --private-network. This option may be
>> used more than once to add multiple network interfaces to the
>> container.
>>
>> Trying to nspawn a macvlan without giving a physical device results in "no
>> such device":
>>
>> # systemd-nspawn --boot --link-journal=try-guest --machine=gentoo-mysql-base
>> --network-macvlan=
>> systemd-nspawn: option '--network-macvlan' requires an argument
>>
>> # systemd-nspawn --boot --link-journal=try-guest --machine=test --network-
>> macvlan=test
>> Spawning container test on /var/lib/machines/test.
>> Press ^] three times within 1s to kill container.
>> Failed to resolve interface test: No such device
>>
>> So your assumption about macvlan seems to be incorrect. The other network
>> types may be based off the machine name but it doesn't work this way with
>> macvlan.
>
> Yeah, nspawn creates a n interface "mv-foo" from a network interface
> "foo" on the host.
>
>> So I wonder what the purpose of macvlan is if you can only create one
>> machine using macvlan on my single physical link - and that's it?
>
> I am not sure I follow. The mv-foo interface will be part of the
> container, not the host. That means if you run 10 containers, all with
> --network-macvlan=foo, then they each will have an interface called
> "mv-foo", but with a different ifindex each. Or are you suggesting
> that that's currently broken?
>
>> I think the logic is wrong here in systemd-nspawn. Instead of trying to
>> create the host-side macvlan itself it should insist of it being there
>> already (to have one well-defined state to start with, and only optionally
>> create it by itself). Then, it can join multiple machines to the same
>> macvlan.
>
> I don't grok this?
>
> "the same macvlan"?
>
>> I'm using the following networkd config on the host to define this "well-
>> defined state", enabling the host to also communicate through macvlan:
>>
>> # cat /etc/systemd/network/10-macvlan.{netdev,network}
>> [NetDev]
>> Name=mv-enp5s0
>> Kind=macvlan
>>
>> [MACVLAN]
>> Mode=bridge
>> #
>> [Match]
>> Name=en*
>>
>> [Network]
>> MACVLAN=mv-enp5s0
>> LinkLocalAddressing=no
>> DHCP=no
>>
>> If I remove this I am able to start one of the containers, but not two or
>> more. If I use this I am not able to start any macvlan container.
>
> I have the suspicion that the confusion here stems from the fact that
> nspawn creates the macvlan iface on the host first, then moves it into
> the container.
Hm, you sure about this? I thought we create the macvlan device
directly in the network namespace. There should be no possible
name-conflict with devices on the host...
> but if you already have an iface by that name on the
> host, then it cannot create the macvlan under that name.
>
> I figure we can fix that by creating the iface under a random name
> first on the host, then move it into the container, and then rename it
> to the right name afterwarads.
>
> A work-around would be to name the .netdev iface of yours something
> else than "mv-enp5s0", call it "waldi" or so, so that it doesn't
> conflict with the name for the contaainer in the short time-frame that
> the iface nspawn creates exists on the host...
>
> Can you verify if such a change fixes your issue? If so, we can
> randomoize the name initially, as sugegsted above.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: cannot join existing macvlan
On Sat, 30.05.15 19:55, Kai Krakow (hurikha...@gmail.com) wrote:
> The next issue with your argument is: AFAIR nspawn doesn't create a macvlan
> interface based on the machine name. You have to pass the name of a physical
> interface which transports this macvlan. The man page at least states that
> you use an existing physical interface:
True, I was a bit confused there...
>
> --network-macvlan=
> Create a "macvlan" interface of the specified Ethernet network
> interface and add it to the container. A "macvlan" interface is a
> virtual interface that adds a second MAC address to an existing
> physical Ethernet link. The interface in the container will be named
> after the interface on the host, prefixed with "mv-". Note that
> --network-macvlan= implies --private-network. This option may be
> used more than once to add multiple network interfaces to the
> container.
>
> Trying to nspawn a macvlan without giving a physical device results in "no
> such device":
>
> # systemd-nspawn --boot --link-journal=try-guest --machine=gentoo-mysql-base
> --network-macvlan=
> systemd-nspawn: option '--network-macvlan' requires an argument
>
> # systemd-nspawn --boot --link-journal=try-guest --machine=test --network-
> macvlan=test
> Spawning container test on /var/lib/machines/test.
> Press ^] three times within 1s to kill container.
> Failed to resolve interface test: No such device
>
> So your assumption about macvlan seems to be incorrect. The other network
> types may be based off the machine name but it doesn't work this way with
> macvlan.
Yeah, nspawn creates a n interface "mv-foo" from a network interface
"foo" on the host.
> So I wonder what the purpose of macvlan is if you can only create one
> machine using macvlan on my single physical link - and that's it?
I am not sure I follow. The mv-foo interface will be part of the
container, not the host. That means if you run 10 containers, all with
--network-macvlan=foo, then they each will have an interface called
"mv-foo", but with a different ifindex each. Or are you suggesting
that that's currently broken?
> I think the logic is wrong here in systemd-nspawn. Instead of trying to
> create the host-side macvlan itself it should insist of it being there
> already (to have one well-defined state to start with, and only optionally
> create it by itself). Then, it can join multiple machines to the same
> macvlan.
I don't grok this?
"the same macvlan"?
> I'm using the following networkd config on the host to define this "well-
> defined state", enabling the host to also communicate through macvlan:
>
> # cat /etc/systemd/network/10-macvlan.{netdev,network}
> [NetDev]
> Name=mv-enp5s0
> Kind=macvlan
>
> [MACVLAN]
> Mode=bridge
> #
> [Match]
> Name=en*
>
> [Network]
> MACVLAN=mv-enp5s0
> LinkLocalAddressing=no
> DHCP=no
>
> If I remove this I am able to start one of the containers, but not two or
> more. If I use this I am not able to start any macvlan container.
I have the suspicion that the confusion here stems from the fact that
nspawn creates the macvlan iface on the host first, then moves it into
the container. but if you already have an iface by that name on the
host, then it cannot create the macvlan under that name.
I figure we can fix that by creating the iface under a random name
first on the host, then move it into the container, and then rename it
to the right name afterwarads.
A work-around would be to name the .netdev iface of yours something
else than "mv-enp5s0", call it "waldi" or so, so that it doesn't
conflict with the name for the contaainer in the short time-frame that
the iface nspawn creates exists on the host...
Can you verify if such a change fixes your issue? If so, we can
randomoize the name initially, as sugegsted above.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: cannot join existing macvlan
Lennart Poettering schrieb:
> On Mon, 25.05.15 16:26, Kai Krakow (hurikha...@gmail.com) wrote:
>
>> Lennart Poettering schrieb:
>>
>> > On Fri, 08.05.15 20:53, Kai Krakow (hurikha...@gmail.com) wrote:
>> >
>> >> > # systemd-nspawn -b --link-journal=try-guest
>> >> > # --network-macvlan=enp4s0 --
>> >> > bind=/usr/portage --bind-ro=/usr/src --machine=test
>> >> > Spawning container test on /var/lib/machines/test.
>> >> > Press ^] three times within 1s to kill container.
>> >> > Failed to add new macvlan interfaces: File exists
>> >> >
>> >> > I still don't think that systemd-nspawn should insist on creating
>> >> > the host- side macvlan bridge and fail, if it cannot. It should just
>> >> > accept that it is already there.
>> >>
>> >> My findings show that it actually does accept this case. But I had to
>> >> explicitly order the machines after network.target to successfully
>> >> start at boot time.
>> >
>> > I changed git now to order nspawn units by default after
>> > network.target now. In the long run we should replace this by calling
>> > into networkd though, without waiting for "all" networking, for
>> > whatever that means...
>>
>> Well, now, with v220, we are back to the original problem:
>>
>> machines # systemd-nspawn --boot --link-journal=try-guest --machine=test
>> -- network-macvlan=enp5s0
>> Spawning container test on /var/lib/machines/test.
>> Press ^] three times within 1s to kill container.
>> Failed to add new macvlan interfaces: File exists
>>
>> If mv-enp5s0 is already there (maybe by means of another machine), it no
>> longer starts any other machine on the same macvlan. I don't think this
>> is how it should work.
>
> Well, there can only be one machine with the same name, and we use
> that name in the macvlan interface name. Please assign different names
> to your containers so that they will also get differently named
> macvlan names, and all should be good.
But what is the purpose of macvlan if you cannot merge different containers
into the same LAN segment? One feature of macvlan is that all virtual MAC
addresses can communicate with each other. That's why I also joined my host
machine into that macvlan (by creating it with networkd).
The next issue with your argument is: AFAIR nspawn doesn't create a macvlan
interface based on the machine name. You have to pass the name of a physical
interface which transports this macvlan. The man page at least states that
you use an existing physical interface:
--network-macvlan=
Create a "macvlan" interface of the specified Ethernet network
interface and add it to the container. A "macvlan" interface is a
virtual interface that adds a second MAC address to an existing
physical Ethernet link. The interface in the container will be named
after the interface on the host, prefixed with "mv-". Note that
--network-macvlan= implies --private-network. This option may be
used more than once to add multiple network interfaces to the
container.
Trying to nspawn a macvlan without giving a physical device results in "no
such device":
# systemd-nspawn --boot --link-journal=try-guest --machine=gentoo-mysql-base
--network-macvlan=
systemd-nspawn: option '--network-macvlan' requires an argument
# systemd-nspawn --boot --link-journal=try-guest --machine=test --network-
macvlan=test
Spawning container test on /var/lib/machines/test.
Press ^] three times within 1s to kill container.
Failed to resolve interface test: No such device
So your assumption about macvlan seems to be incorrect. The other network
types may be based off the machine name but it doesn't work this way with
macvlan.
So I wonder what the purpose of macvlan is if you can only create one
machine using macvlan on my single physical link - and that's it?
I think the logic is wrong here in systemd-nspawn. Instead of trying to
create the host-side macvlan itself it should insist of it being there
already (to have one well-defined state to start with, and only optionally
create it by itself). Then, it can join multiple machines to the same
macvlan.
I'm using the following networkd config on the host to define this "well-
defined state", enabling the host to also communicate through macvlan:
# cat /etc/systemd/network/10-macvlan.{netdev,network}
[NetDev]
Name=mv-enp5s0
Kind=macvlan
[MACVLAN]
Mode=bridge
#
[Match]
Name=en*
[Network]
MACVLAN=mv-enp5s0
LinkLocalAddressing=no
DHCP=no
If I remove this I am able to start one of the containers, but not two or
more. If I use this I am not able to start any macvlan container.
--
Replies to list only preferred.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: cannot join existing macvlan
On Mon, 25.05.15 16:26, Kai Krakow (hurikha...@gmail.com) wrote: > Lennart Poettering schrieb: > > > On Fri, 08.05.15 20:53, Kai Krakow (hurikha...@gmail.com) wrote: > > > >> > # systemd-nspawn -b --link-journal=try-guest --network-macvlan=enp4s0 > >> > # -- > >> > bind=/usr/portage --bind-ro=/usr/src --machine=test > >> > Spawning container test on /var/lib/machines/test. > >> > Press ^] three times within 1s to kill container. > >> > Failed to add new macvlan interfaces: File exists > >> > > >> > I still don't think that systemd-nspawn should insist on creating the > >> > host- side macvlan bridge and fail, if it cannot. It should just accept > >> > that it is already there. > >> > >> My findings show that it actually does accept this case. But I had to > >> explicitly order the machines after network.target to successfully start > >> at boot time. > > > > I changed git now to order nspawn units by default after > > network.target now. In the long run we should replace this by calling > > into networkd though, without waiting for "all" networking, for > > whatever that means... > > Well, now, with v220, we are back to the original problem: > > machines # systemd-nspawn --boot --link-journal=try-guest --machine=test -- > network-macvlan=enp5s0 > Spawning container test on /var/lib/machines/test. > Press ^] three times within 1s to kill container. > Failed to add new macvlan interfaces: File exists > > If mv-enp5s0 is already there (maybe by means of another machine), it no > longer starts any other machine on the same macvlan. I don't think this is > how it should work. Well, there can only be one machine with the same name, and we use that name in the macvlan interface name. Please assign different names to your containers so that they will also get differently named macvlan names, and all should be good. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: cannot join existing macvlan
Lennart Poettering schrieb: > On Fri, 08.05.15 20:53, Kai Krakow (hurikha...@gmail.com) wrote: > >> > # systemd-nspawn -b --link-journal=try-guest --network-macvlan=enp4s0 >> > # -- >> > bind=/usr/portage --bind-ro=/usr/src --machine=test >> > Spawning container test on /var/lib/machines/test. >> > Press ^] three times within 1s to kill container. >> > Failed to add new macvlan interfaces: File exists >> > >> > I still don't think that systemd-nspawn should insist on creating the >> > host- side macvlan bridge and fail, if it cannot. It should just accept >> > that it is already there. >> >> My findings show that it actually does accept this case. But I had to >> explicitly order the machines after network.target to successfully start >> at boot time. > > I changed git now to order nspawn units by default after > network.target now. In the long run we should replace this by calling > into networkd though, without waiting for "all" networking, for > whatever that means... Well, now, with v220, we are back to the original problem: machines # systemd-nspawn --boot --link-journal=try-guest --machine=test -- network-macvlan=enp5s0 Spawning container test on /var/lib/machines/test. Press ^] three times within 1s to kill container. Failed to add new macvlan interfaces: File exists If mv-enp5s0 is already there (maybe by means of another machine), it no longer starts any other machine on the same macvlan. I don't think this is how it should work. -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: cannot join existing macvlan
On Fri, 08.05.15 20:53, Kai Krakow (hurikha...@gmail.com) wrote: > > # systemd-nspawn -b --link-journal=try-guest --network-macvlan=enp4s0 -- > > bind=/usr/portage --bind-ro=/usr/src --machine=test > > Spawning container test on /var/lib/machines/test. > > Press ^] three times within 1s to kill container. > > Failed to add new macvlan interfaces: File exists > > > > I still don't think that systemd-nspawn should insist on creating the > > host- side macvlan bridge and fail, if it cannot. It should just accept > > that it is already there. > > My findings show that it actually does accept this case. But I had to > explicitly order the machines after network.target to successfully start at > boot time. I changed git now to order nspawn units by default after network.target now. In the long run we should replace this by calling into networkd though, without waiting for "all" networking, for whatever that means... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: cannot join existing macvlan
Kai Krakow schrieb: > Kai Krakow schrieb: > > Hello again! And again... > Amended below... > >> I'm not sure about this but I suspect that I cannot start a second nspawn >> container with --network-macvlan when another nspawn instance has created >> it before: >> >> # systemd-nspawn -b --network-macvlan=enp4s0 >> Spawning container gentoo-mysql-base on >> /var/lib/machines/gentoo-mysql-base. Press ^] three times within 1s to >> kill container. Failed to add new macvlan interfaces: File exists >> >> To my surprise it works when adding machines to machines.target. While >> you cannot start them through means of systemd because of the same error, >> it works during boot of the whole system: All containers boot up properly >> - but stop one and you cannot restart it. >> >> So it looks like there's an unintentional race condition during boot >> which allows to create this interface but when the system is up, it no >> longer works because the race condition is no longer present. >> >> systemd-nspawn should probably just allow joining existing macvlan >> bridges. I would fix it in the code but I don't know the implications why >> this check is in there in the first place. >> >> A second fix should maybe do something about such race conditions if it >> is such one. I suspect there are cases where the interface presence check >> makes actually sense. > > I installed something which is called a stable v219 snapshot, I could not > find out which changes are included, tho: > > *systemd-219_p112 (26 Apr 2015) > > 26 Apr 2015; Mike Gilbert +systemd-219_p112.ebuild: > Add a snapshot from the v219-stable branch upstream. > > The behavior described above has changed with this snapshot: Machines > using macvlan no longer start, even not a boot-up (which worked before). > > The error is still the same: > > # systemd-nspawn -b --link-journal=try-guest --network-macvlan=enp4s0 -- > bind=/usr/portage --bind-ro=/usr/src --machine=test > Spawning container test on /var/lib/machines/test. > Press ^] three times within 1s to kill container. > Failed to add new macvlan interfaces: File exists > > I still don't think that systemd-nspawn should insist on creating the > host- side macvlan bridge and fail, if it cannot. It should just accept > that it is already there. My findings show that it actually does accept this case. But I had to explicitly order the machines after network.target to successfully start at boot time. It looks fine so far. The stable snapshot of v219 mentioned above seems to actually have fixed a few issues. -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: cannot join existing macvlan
Kai Krakow schrieb: Hello again! Amended below... > I'm not sure about this but I suspect that I cannot start a second nspawn > container with --network-macvlan when another nspawn instance has created > it before: > > # systemd-nspawn -b --network-macvlan=enp4s0 > Spawning container gentoo-mysql-base on > /var/lib/machines/gentoo-mysql-base. Press ^] three times within 1s to > kill container. Failed to add new macvlan interfaces: File exists > > To my surprise it works when adding machines to machines.target. While you > cannot start them through means of systemd because of the same error, it > works during boot of the whole system: All containers boot up properly - > but stop one and you cannot restart it. > > So it looks like there's an unintentional race condition during boot which > allows to create this interface but when the system is up, it no longer > works because the race condition is no longer present. > > systemd-nspawn should probably just allow joining existing macvlan > bridges. I would fix it in the code but I don't know the implications why > this check is in there in the first place. > > A second fix should maybe do something about such race conditions if it is > such one. I suspect there are cases where the interface presence check > makes actually sense. I installed something which is called a stable v219 snapshot, I could not find out which changes are included, tho: *systemd-219_p112 (26 Apr 2015) 26 Apr 2015; Mike Gilbert +systemd-219_p112.ebuild: Add a snapshot from the v219-stable branch upstream. The behavior described above has changed with this snapshot: Machines using macvlan no longer start, even not a boot-up (which worked before). The error is still the same: # systemd-nspawn -b --link-journal=try-guest --network-macvlan=enp4s0 -- bind=/usr/portage --bind-ro=/usr/src --machine=test Spawning container test on /var/lib/machines/test. Press ^] three times within 1s to kill container. Failed to add new macvlan interfaces: File exists I still don't think that systemd-nspawn should insist on creating the host- side macvlan bridge and fail, if it cannot. It should just accept that it is already there. Actually I even created this device in the host with networkd because by design macvlan and parent device cannot communicate with each other without switch support and won't communicate directly locally either. Thus, you need to attach a host-side macvlan device to your physical parent device to communicate with the other virtual MAC addresses on the same host, and then setup your IP configuration on this device. Of course one could argue that this is a security feature of nspawn to isolate containers and hosts from each other. So maybe, put an option to allow nspawn to join an existing macvlan, maybe "--network-join-macvlan". -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-nspawn: cannot join existing macvlan
Hello! I'm not sure about this but I suspect that I cannot start a second nspawn container with --network-macvlan when another nspawn instance has created it before: # systemd-nspawn -b --network-macvlan=enp4s0 Spawning container gentoo-mysql-base on /var/lib/machines/gentoo-mysql-base. Press ^] three times within 1s to kill container. Failed to add new macvlan interfaces: File exists To my surprise it works when adding machines to machines.target. While you cannot start them through means of systemd because of the same error, it works during boot of the whole system: All containers boot up properly - but stop one and you cannot restart it. So it looks like there's an unintentional race condition during boot which allows to create this interface but when the system is up, it no longer works because the race condition is no longer present. systemd-nspawn should probably just allow joining existing macvlan bridges. I would fix it in the code but I don't know the implications why this check is in there in the first place. A second fix should maybe do something about such race conditions if it is such one. I suspect there are cases where the interface presence check makes actually sense. -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
