On Wed, Apr 27, 2011 at 11:59 AM, Mauras Olivier wrote:
>
>
> On Tue, Apr 26, 2011 at 6:03 PM, Mauras Olivier
> wrote:
>
>>
>>
>> On Sat, Apr 23, 2011 at 12:40 PM, Mauras Olivier > > wrote:
>>
>>> Hi Geordy,
>>>
>>> Thanks for your reply. The first one is actually already set here. I
>>> asked ES
On Tue, Apr 26, 2011 at 6:03 PM, Mauras Olivier wrote:
>
>
> On Sat, Apr 23, 2011 at 12:40 PM, Mauras Olivier
> wrote:
>
>> Hi Geordy,
>>
>> Thanks for your reply. The first one is actually already set here. I asked
>> ESX folks to create me my own vswitch with promisc mode enabled.
>> I saw the
On Sat, Apr 23, 2011 at 12:40 PM, Mauras Olivier wrote:
> Hi Geordy,
>
> Thanks for your reply. The first one is actually already set here. I asked
> ESX folks to create me my own vswitch with promisc mode enabled.
> I saw the second one coming, but didn't think that could make something...
> Ther
Hi Geordy,
Thanks for your reply. The first one is actually already set here. I asked
ESX folks to create me my own vswitch with promisc mode enabled.
I saw the second one coming, but didn't think that could make something...
There's also a setting like "mac.verify" that can be set to false direct
On Sun, Apr 17, 2011 at 8:39 AM, Geordy Korte wrote:
> Thought about it some more and i think it might be an advanced esx feature
> that restricts this. Basically a couple of adv features block spoofing and
> mac changes on a vhost. I will try to find the specific command you need to
> run on an
On 04/18/2011 08:08 PM, Mauras Olivier wrote:
> So some more testing today. Here's what happens:
> When i have one container up with my host network restart trick,
> everything's fine, i can download gigas of data without problem.
> Starting a second one, redo the network trick to have network in t
So some more testing today. Here's what happens:
When i have one container up with my host network restart trick,
everything's fine, i can download gigas of data without problem.
Starting a second one, redo the network trick to have network in this one
either, everything looks ok.
About 5minutes la
Thanks, help is really appreciated.
Cheers,
Olivier
On Sun, Apr 17, 2011 at 8:39 AM, Geordy Korte wrote:
> Hi,
>
> Thought about it some more and i think it might be an advanced esx feature
> that restricts this. Basically a couple of adv features block spoofing and
> mac changes on a vhost. I
On Sun 2011-04-17 (08:39), Geordy Korte wrote:
> Thought about it some more and i think it might be an advanced esx
> feature that restricts this.
Then the first rename (eth1 --> dev3) should also fail.
But this works and the container starts und runs perfectly.
What fails is the renaming back (
Hi,
Thought about it some more and i think it might be an advanced esx feature that
restricts this. Basically a couple of adv features block spoofing and mac
changes on a vhost. I will try to find the specific command you need to run on
an esx host tomorrow, or maybee someone can google it. I a
Would using macvlan bridge mode the solution?
Didn't find a way to make it work...
Ulli Horlacher wrote:
On Sat 2011-04-16 (22:24), Geordy Korte wrote: > Due to the architecter of esx
it will only permit 1 mac per vswitch port. > If they would allow more then
security would be comprimised. Sol
On Sat 2011-04-16 (22:24), Geordy Korte wrote:
> Due to the architecter of esx it will only permit 1 mac per vswitch port.
> If they would allow more then security would be comprimised. Solution
> would be to have each lxc bound to a vnic.
I have had the same problem with lxc on ESX last week. I
The problem is that kernel 2.6.32 doesn't allow moving physical eth to the lxc
namespace so can't use phys mode...
Olivier
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Geordy Korte wrote:
Due to the architecter of esx it will only permit 1 mac per vswitch port. If
t
Due to the architecter of esx it will only permit 1 mac per vswitch port. If
they would allow more then security would be comprimised. Solution would be to
have each lxc bound to a vnic.
Mvg
Geordy Korte
(Sent via iphone so shorter then normal)
On 16 apr. 2011, at 15:55, Mauras Olivier wrote
On Sat, Apr 16, 2011 at 3:45 PM, Serge Hallyn wrote:
> > As you see in this example, before issuing the network restart, my veth
> MAC
> > was already higher than the eth0 MAC but the guest hadn't a working
> network
> > connection.
>
> Thanks for the info.
>
> > After restarting network on the ho
> As you see in this example, before issuing the network restart, my veth MAC
> was already higher than the eth0 MAC but the guest hadn't a working network
> connection.
Thanks for the info.
> After restarting network on the host while the guest is still running, as
> you can see my MACs haven't
Missed the list in copy. sorry.
On Fri, Apr 15, 2011 at 3:20 PM, Serge Hallyn wrote:
> Quoting Mauras Olivier (oliver.mau...@gmail.com):
> > Hello,
> >
> > I'm struggling for two days now with some completely weird network
> > behaviours.
> > My host is a virtual machine hosted on an ESX farm. I
17 matches
Mail list logo
