similar to: Cannot create macvlan devices on this platform

Hi, it is possible to define a domain along with several usb host controllers, e.g. <controller type='usb' index='0' model='ich9-ehci' /> <controller type='usb' index='1' model='ich9-uhci' /> How to distinguish between those controllers/busses when adding input or host devices such as <input type='tablet'

Hi, I'm running some Windows clients inside KVM virtual maschines managed by libvirt. These clients are managed by a Samba 3 PDC. Therefore the DHCP needs so supply corresponding WINS server (dhcp option 44) not only IP address and DNS server. Is it possible to make dnsmasq driven by libvirt to supply custom dhcp options? I would appreciate something like this in the network.xml: [...]

Hi, I'm trying to passthrough legacy PCI ISDN controller to a KVM based virtual machine: <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00'

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

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

This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others have found out

This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others have found out

This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others have found out

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 +++-- >

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

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

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 guests can take advantage > >> of offload SCTP checksums to

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 guests can take advantage > >> of offload SCTP checksums to

On Wed, May 02, 2018 at 10:00:14AM -0400, Vlad Yasevich wrote: > 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

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