yes , we do not need to add restrictions on both end.The peer option will only
replace the target device specified by the key word "dev" with its peer end.
For example , the veth pair name is veth-vps1 , and the peer end is eth0 :
tc qdisc add dev veth-vps1 root tbf rate 0.05mbit burst 5kb latency
On 2013/7/3 13:19, Serge Hallyn wrote:
> Quoting Qiang Huang (h.huangqi...@huawei.com):
>> On 2013/7/3 11:23, Serge Hallyn wrote:
>>> Quoting Serge Hallyn (serge.hal...@ubuntu.com):
The lxc configuration file currently supports 'lxc.cap.drop', a list of
capabilities to be dropped (using t
Quoting Serge Hallyn (serge.hal...@ubuntu.com):
> When we start a container, we first block most signals including
> sigchld, then create a signalfd fd for those signals. This leaves
> a tiny tiny window during which signals may be lost.
>
> So swap those.
>
> In theory, AFAICS this *should* fix
Quoting Qiang Huang (h.huangqi...@huawei.com):
> On 2013/7/3 11:23, Serge Hallyn wrote:
> > Quoting Serge Hallyn (serge.hal...@ubuntu.com):
> >> The lxc configuration file currently supports 'lxc.cap.drop', a list of
> >> capabilities to be dropped (using the bounding set) from the container.
> >>
When we start a container, we first block most signals including
sigchld, then create a signalfd fd for those signals. This leaves
a tiny tiny window during which signals may be lost.
So swap those.
In theory, AFAICS this *should* fix any race with container init
exiting before we get to lxc_mai
On 2013/7/3 11:23, Serge Hallyn wrote:
> Quoting Serge Hallyn (serge.hal...@ubuntu.com):
>> The lxc configuration file currently supports 'lxc.cap.drop', a list of
>> capabilities to be dropped (using the bounding set) from the container.
>> The problem with this is that over time new capabilities
Quoting Serge Hallyn (serge.hal...@ubuntu.com):
> The lxc configuration file currently supports 'lxc.cap.drop', a list of
> capabilities to be dropped (using the bounding set) from the container.
> The problem with this is that over time new capabilities are added. So
> an older container configur
On 07/01/2013 04:04 PM, lsmushroom wrote:
> Sorry for the late response. For your question , you could not limit the
> network traffic in that way. Because TC will only limit the traffic send out
> from the target device . And for the device of
> veth type , the device on the host end will “send
Quoting lsmushroom (lsmushr...@126.com):
> Sorry, I really get confused. Can you show me your testing procedure ?
> Below is my testing result , the veth pair name is veth-vps1:
>
>
> 1) Add qdisc on veth-vps1
> tc qdisc add dev veth-vps1 root tbf rate 0.05mbit burst 5kb latency 70ms
> peakrate
Quoting Bogdan Purcareata (bogdan.purcare...@freescale.com):
> Minor typo.
>
> Signed-off-by: Bogdan Purcareata
> ---
> src/tests/startone.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/tests/startone.c b/src/tests/startone.c
> index d781e75..2c1f39b 100644
>
Minor typo.
Signed-off-by: Bogdan Purcareata
---
src/tests/startone.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/tests/startone.c b/src/tests/startone.c
index d781e75..2c1f39b 100644
--- a/src/tests/startone.c
+++ b/src/tests/startone.c
@@ -201,7 +201,7 @@ int mai
Sorry, I really get confused. Can you show me your testing procedure ?
Below is my testing result , the veth pair name is veth-vps1:
1) Add qdisc on veth-vps1
tc qdisc add dev veth-vps1 root tbf rate 0.05mbit burst 5kb latency 70ms
peakrate 1mbit minburst 1540
2) Send packet from the containe
12 matches
Mail list logo
