similar to: macvlan interfaces.

On Wed, Dec 05, 2018 at 02:43:45PM +0300, mxs kolo wrote: > Hi all > > After upgrade from Centos 7.5 to Centos 7.6, our test environment > geted new version of libvirt 4.5.0 > In which our old containers have broken config and can't start: > 2018-12-05 10:38:32.634+0000: 18010: debug : > virLXCControllerGetNICIndexes:368 : Getting nic indexes > 2018-12-05

On Wed, Mar 13, 2019 at 11:40:51PM +0100, Lars Lindstrom wrote: > >On 3/13/19 2:26 PM, Martin Kletzander wrote: >> IIUC, you are using the tap0 device, but it is not plugged anywhere. >> By that I >> mean there is one end that you created and passed through into the VM, >> but there >> is no other end of that.  I can think of some complicated ways how to

Hi, I'm currently looking into the VMAC options that Keepalived had to offer. This all looks very nice, but now I heard that the VMAC driver in the linux kernel is not really stable if you are not on a 3.2 kernel or later. Can anyone here tell me some more about this? Is this really true? Should I wait with the VMAC options until Centos / RHEL are on a 3.2 kernel? Jan Hugo Prins

Since we now have support for software CRC32c offload, turn it on for macvlan and macvtap devices so that guests can take advantage of offload SCTP checksums to the host or host hardware. Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> --- drivers/net/macvlan.c | 5 +++-- drivers/net/tap.c | 8 +++++--- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git

Since we now have support for software CRC32c offload, turn it on for macvlan and macvtap devices so that guests can take advantage of offload SCTP checksums to the host or host hardware. Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> --- drivers/net/macvlan.c | 5 +++-- drivers/net/tap.c | 8 +++++--- include/uapi/linux/if_tun.h | 1 + 3 files changed, 9

On 05/01/2018 11:24 PM, Michael S. Tsirkin wrote: > On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: >> Since we now have support for software CRC32c offload, turn it on >> for macvlan and macvtap devices so that guests can take advantage >> of offload SCTP checksums to the host or host hardware. >> >> Signed-off-by: Vladislav Yasevich

Hi all After upgrade from Centos 7.5 to Centos 7.6, our test environment geted new version of libvirt 4.5.0 In which our old containers have broken config and can't start: 2018-12-05 10:38:32.634+0000: 18010: debug : virLXCControllerGetNICIndexes:368 : Getting nic indexes 2018-12-05 10:38:32.634+0000: 18010: error : virLXCControllerGetNICIndexes:400 : unsupported configuration: Unsupported

Hi, libvirt (0.9.11) refuses to start KVM based virtual machines on my system when changing the network connection from "host bridge" to "direct" (macvtap/macvlan), neither in "bridge" nor in "vepa" mode: "Cannot create macvlan devices on this platform" That's astonishing because I can easily setup working macvlan devices using the

On 05/02/2018 09:46 AM, Michael S. Tsirkin wrote: > On Wed, May 02, 2018 at 09:27:00AM -0400, Vlad Yasevich wrote: >> On 05/01/2018 11:24 PM, Michael S. Tsirkin wrote: >>> On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: >>>> Since we now have support for software CRC32c offload, turn it on >>>> for macvlan and macvtap devices so that

Hello, I'm in a bit of a loss at the moment. We have the following situation, we are running Samba for a lot of small companies that need fileservices for there Windows Terminal Servers that they use through a thin client on a Fiber / Lan extention to our datacentre. We have this samba running on 2 linux hosts (Fedora Core 5 and Fedora 7) with a ldap backend for all the domains. This works

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > Since we now have support for software CRC32c offload, turn it on > for macvlan and macvtap devices so that guests can take advantage > of offload SCTP checksums to the host or host hardware. > > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- > drivers/net/macvlan.c | 5 +++-- >

On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > Since we now have support for software CRC32c offload, turn it on > for macvlan and macvtap devices so that guests can take advantage > of offload SCTP checksums to the host or host hardware. > > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- > drivers/net/macvlan.c | 5 +++-- >

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

On 3/13/19 2:26 PM, Martin Kletzander wrote: > IIUC, you are using the tap0 device, but it is not plugged anywhere. > By that I > mean there is one end that you created and passed through into the VM, > but there > is no other end of that.  I can think of some complicated ways how to > do what > you are trying to, but hopefully the above explanation will move you > forward

Ben Greear wrote: > Well, it seems we could and should fix veth to work, but it will have > to do equivalent work of copying an skb most likely, so either way > you'll probably get a big performance hit. Using the same pktgen script (i.e with clone=0) I see that a veth-->bridge-->veth configuration gives about 400K PPS forwarding performance where