On Thursday 20 Mar 2014 11:07:55 arnaud gaboury wrote:
> I decided, when writing the wiki, to setup the container network
> static IP (example given) INSIDE the container.
> This approach solves the interfaces being DOWN issue for any
network
> profile and sounds in fact a more best-practice.
> T
>
> I don't get this: it seems normal to me that the interface would be down
> until it's
> configured by the container, pretty much like on a normal machine. The only
> situation
> in which you can expect an interface to be up already is in a network-booting
> situation,
> in which the initramf
On Monday 17 Mar 2014 12:00:10 Mauro Santos wrote:
> I suspect we might have been talking about 2 different things all along.
> What I and Arnaud have been talking about is the tap interface on the
> host, not the interface inside the container, which of course should be
> properly configured by th
On 17-03-2014 10:01, Paul Gideon Dann wrote:
> I don't get this: it seems normal to me that the interface would be down
> until it's
> configured by the container, pretty much like on a normal machine. The only
> situation
> in which you can expect an interface to be up already is in a network-
On 17-03-2014 08:55, arnaud gaboury wrote:
> After I related this issue (interfaces not being UP) on the
> systemd-devel mailing list, Tom Gundersen did a commit yesterday nite
> to change this behavior. So if you run systemd-git, just upgrade and
> interfaces will now be UP, and you will be able
On Monday 17 Mar 2014 09:55:11 arnaud gaboury wrote:
> > I guess someone will have to ask about it, either in the mailing list or
> > irc, I haven't done so before because systemd-{nspawn,networkd} have
> > lots of new functionality and I'm not sure I understand them all.
>
> After I related this
> I guess someone will have to ask about it, either in the mailing list or
> irc, I haven't done so before because systemd-{nspawn,networkd} have
> lots of new functionality and I'm not sure I understand them all.
>
After I related this issue (interfaces not being UP) on the
systemd-devel mailing
On 12-03-2014 18:40, arnaud gaboury wrote:
> This sounds to me a potential bug in fact, as your vb-veth.network has
> no reason to exist.
> But as I am far from catching every part of workability of networkd, I
> will keep myself from filling a bug report.
>
> Maybe shall you post on the devel-sys
On Wed, Mar 12, 2014 at 3:00 PM, arnaud gaboury
wrote:
>>
>> If you are running systemd-networkd on
>>> the host then you can do that easily with a network file. I've called
>>> mine vb-veth.network and it contains:
>>>
>>> [Match]
>>> Name=vb-*
>>
> Very good indeed.
> /etc/systemd/network/80-co
On Wed, Mar 12, 2014 at 6:02 PM, Paul Gideon Dann wrote:
> On Wednesday 12 Mar 2014 17:32:27 arnaud gaboury wrote:
>> It was UP before I brought vb down. So you have your answer : yes.
>
> OK, so in that case, I'd recommend not doing anything special on the host to
> bring the vb-
> dahlia interf
On Wednesday 12 Mar 2014 17:32:27 arnaud gaboury wrote:
> It was UP before I brought vb down. So you have your answer : yes.
OK, so in that case, I'd recommend not doing anything special on the host to
bring the vb-
dahlia interface up. It's behaving just like a normal interface would on a real
>
> It was UP before I brought vb down.
sorry for typo : before I brought host0 down
>
> In that case, I'm curious to find out if you find that setting the host0
> interface up in
> the container also brings the vb-dahlia interface up on the host?
On container :
gab@dahlia ➤➤ ~ % ip addr
2: host0: mtu 1500 qdisc
pfifo_fast state UP group default qlen 1000
link/ether 56:84:f
On Wednesday 12 Mar 2014 16:01:00 arnaud gaboury wrote:
> See my previous post : I want to learn. Then, the container will one day be
> a production server. So my idea is to test now everything, then take a
> snapshot and build a prod server with much more complicated network
> services and setting
> Yeah, that sounds like a sensible reason; thank you. I believe Arnaud's
usecase
> is a single container with no particularly special connectivity
requirements (as
> far as I can tell). I'm worried that he's making his setup a lot more
complicated
> than it needs to be.
>
See my previous post : I
>
> After I saw that systemd-nspawn now has more network isolation features
> I just used the setup I had.
>
> It's possible this is overkill for what I want but it was the solution I
> came up with at the time.
>
Same same here. I have been a long time user of libvirt for VM, and I
decided to have
On Wednesday 12 Mar 2014 14:21:05 Mauro Santos wrote:
> > Can I ask you both why you chose this route of creating a private network?
> > As far as I can tell, by default systemd-spawn will allow the container
> > to use the host's interface. I would have thought that would be adequate
> > for most
On Wednesday 12 Mar 2014 15:20:01 arnaud gaboury wrote:
> > Can I ask you both why you chose this route of creating a private network?
> > As far as I can tell, by default systemd-spawn will allow the container
> > to use the host's interface. I would have thought that would be adequate
> > for mos
On 12-03-2014 14:11, Paul Gideon Dann wrote:
> On Wednesday 12 Mar 2014 14:06:30 Mauro Santos wrote:
>> No netctl here :)
>>
>> I systemd-networkd enabled on boot and 3 files in /etc/systemd/network
>>
>>> cat brkvm.netdev
>>
>> [NetDev]
>> Name=brkvm
>> Kind=bridge
>>
>>> cat brkvm.network
>>
>> [
> Can I ask you both why you chose this route of creating a private network? As
> far as I can
> tell, by default systemd-spawn will allow the container to use the host's
> interface. I would
> have thought that would be adequate for most usecases?
>
> Paul
My first tests with nspwan/networkd, w
On 12-03-2014 13:48, arnaud gaboury wrote:
>> Right now on the host side I have everything being handled only by
>> systemd-{networkd,nspawn},
> I don't add any physical interfaces to the
>> bridge
> Ah? I have two netctl profiles, one for my physical eth (enp7s0) with
> no ip, one for bridge (br0)
>
> No netctl here :)
>
> I systemd-networkd enabled on boot and 3 files in /etc/systemd/network
>
>> cat brkvm.netdev
> [NetDev]
> Name=brkvm
> Kind=bridge
>
>> cat brkvm.network
> [Match]
> Name=brkvm
>
> [Network]
> Description=Bride for use with virtual machines and containers
> Address=192.168
On Wednesday 12 Mar 2014 14:06:30 Mauro Santos wrote:
> No netctl here :)
>
> I systemd-networkd enabled on boot and 3 files in /etc/systemd/network
>
> > cat brkvm.netdev
>
> [NetDev]
> Name=brkvm
> Kind=bridge
>
> > cat brkvm.network
>
> [Match]
> Name=brkvm
>
> [Network]
> Description=Brid
On Wednesday 12 Mar 2014 14:48:38 arnaud gaboury wrote:
> Right. I am left after I boot my machine (the host) with this :
>
> 4: vb-dahlia: mtu 1500 qdisc noop master br0
> state DOWN group default qlen 1000
> link/ether 62:a2:6b:f4:0f:87 brd ff:ff:ff:ff:ff:ff
>
> I have to manually
> # ip l
>
> If you are running systemd-networkd on
>> the host then you can do that easily with a network file. I've called
>> mine vb-veth.network and it contains:
>>
>> [Match]
>> Name=vb-*
>
Very good indeed.
/etc/systemd/network/80-container-host0.network
[Match]
Name=vb-dahlia
[Network]
DHCP=no
DNS=
> I have found that you will need to bring the virtual interface up (the
> one handled by systemd-nspawn).
Right. I am left after I boot my machine (the host) with this :
4: vb-dahlia: mtu 1500 qdisc noop master br0
state DOWN group default qlen 1000
link/ether 62:a2:6b:f4:0f:87 brd ff:ff:ff
On 12-03-2014 10:43, Paul Gideon Dann wrote:
> On Tuesday 11 Mar 2014 18:03:20 arnaud gaboury wrote:
>>> OK, so you really just need basic internet connectivity; you don't
>>> have any special filtering requirements. When you boot the
>>> container, can it see the enp7s0 interface? That is, is the
On Tuesday 11 Mar 2014 18:03:20 arnaud gaboury wrote:
> > OK, so you really just need basic internet connectivity; you don't
> > have any special filtering requirements. When you boot the
> > container, can it see the enp7s0 interface? That is, is the enp7s0
> > interface visible both from the host
>
> OK, so you really just need basic internet connectivity; you don't
> have any special filtering requirements. When you boot the
> container, can it see the enp7s0 interface? That is, is the enp7s0
> interface visible both from the host and from the container?
>
no. On container, I just see hos0
On Tuesday 11 Mar 2014 15:45:19 arnaud gaboury wrote:
> The container is dedicated to be a test server for months
before I set
> up a production server (not on my machine this time !). A lot
of web
> services will be hosted on the container.
> The container is a way to test my settings for web a
> I'm not sure what you mean by zero network config. Do you mean you want to
> set up the
> tap interface entirely on the host, along with a static IP, and then the
> container simply
> attaches to that tap device when it boots? I guess that's possible.
yes. But I have a static IP now on contain
On Tuesday 11 Mar 2014 13:06:23 arnaud gaboury wrote:
> > systemd-networkd is still really new. If you're having difficulty with it,
> > I recommend simply using netctl, which is a bit more mature.
>
> I do for part of the setup on host. I am trying to do zero network
> config on container, thus t
>
> systemd-networkd is still really new. If you're having difficulty with it, I
> recommend simply
> using netctl, which is a bit more mature.
I do for part of the setup on host. I am trying to do zero network
config on container, thus the use of networkd. But I can use netctl
inside the contain
On Tuesday 11 Mar 2014 11:06:32 arnaud gaboury wrote:
> > Hi Arnaud, I don't think you need the /etc/netctl/ethernet profile at all.
> > The enp7s0 interface is being absorbed into the bridge, and so should not
> > be considered on its own any more. Otherwise, this looks OK. Are you
> > seeing any
> Hi Arnaud, I don't think you need the /etc/netctl/ethernet profile at all.
> The enp7s0
> interface is being absorbed into the bridge, and so should not be considered
> on its own any
> more. Otherwise, this looks OK. Are you seeing any connectivity problems?
Thank you.
Btw, as I was thinking
On Monday 10 Mar 2014 18:57:38 arnaud gaboury wrote:
> Hi,
>
> I am setting up a network for a container.
>
> I have a bridge br0 with a eth adapter "enp7s0" and a tap device "tap0"
>
>
> ***
> /etc/netctl/bridge
> Description="Bridge connection"
> Interface=br0
> Co
> what do you want to accomplish? do you perhaps need a veth device?
>
I want to create a network for a linux container managed by systemd-nspawn.
As Jakub mentioned, the interface is DOWN, thus NO-CARRIER.
On 10.03.14 at 23:30, Damjan Georgievski wrote:
> > 3: tap0: mtu 1500 qdisc
> >
> ...
>
> > I do not understand why the tap0 profile is listed as DOWN. (# ip link
> > set dev tap0 up does nothing more)
> >
>
> it's not down. it's UP, only NO-CARRIER. but for a tap device you also need
> a user-s
> 3: tap0: mtu 1500 qdisc
>
...
> I do not understand why the tap0 profile is listed as DOWN. (# ip link
> set dev tap0 up does nothing more)
>
it's not down. it's UP, only NO-CARRIER. but for a tap device you also need
a user-space program to handle it.
what do you want to accomplish? do you p
Hi,
I am setting up a network for a container.
I have a bridge br0 with a eth adapter "enp7s0" and a tap device "tap0"
***
/etc/netctl/bridge
Description="Bridge connection"
Interface=br0
Connection=bridge
BindsToInterfaces=(enp7s0 tap0)
IP=static
Address='192.168.1.
40 matches
Mail list logo
