search for: virnetdevtapcr

...> > Our ultimate goal In kubevirt is to consume a pre-created tap device > by a kubernetes pod that doesn't have the NET_ADMIN capability. > > After looking at the current libvirt code, I don't think that is > currently supported, since we'll *always* enter the > `virNetDevTapCreate` function in [1] (I'm interested in the *tap* > scenario). > > The tap device is effectively created in that function - [2] - by > opening the clone device (/dev/net/tun), and calling `ioctl(fd, > TUNSETIFF,...)` in it. AFAIK, both of those operations *require* the > NET_...

...nsume a pre-created tap device > > > by a kubernetes pod that doesn't have the NET_ADMIN capability. > > > > > > After looking at the current libvirt code, I don't think that is > > > currently supported, since we'll *always* enter the > > > `virNetDevTapCreate` function in [1] (I'm interested in the *tap* > > > scenario). > > > > > > The tap device is effectively created in that function - [2] - by > > > opening the clone device (/dev/net/tun), and calling `ioctl(fd, > > > TUNSETIFF,...)` in it. AFAIK,...

On 4/6/20 9:54 AM, Daniel P. Berrangé wrote: > On Mon, Apr 06, 2020 at 03:47:01PM +0200, Miguel Duarte de Mora Barroso wrote: >> Hi all, >> >> I'm aware that it is possible to plug pre-created macvtap devices to >> libvirt guests - tracked in RFE [0]. >> >> My interpretation of the wording in [1] and [2] is that it is also >> possible to plug

...e wonder about a couple of things. Our ultimate goal In kubevirt is to consume a pre-created tap device by a kubernetes pod that doesn't have the NET_ADMIN capability. After looking at the current libvirt code, I don't think that is currently supported, since we'll *always* enter the `virNetDevTapCreate` function in [1] (I'm interested in the *tap* scenario). The tap device is effectively created in that function - [2] - by opening the clone device (/dev/net/tun), and calling `ioctl(fd, TUNSETIFF,...)` in it. AFAIK, both of those operations *require* the NET_ADMIN capability. If I'm c...

2015-03-02 23:41 GMT+03:00 Brian Rak <brak@gameservers.com>: > In IRC, I was directed to this patch: > https://www.redhat.com/archives/libvir-list/2015-February/msg01212.html ... > which does exactly what I was looking for. It doesn't build cleanly in that > state, but it's pretty trivial fix (needs actualType added to the function > definition for

...etween the tap0 device in the hypervisor and the ethX device in the VM will totally different . so I think that libvirt must do something about the mac address handling, could you please kindly tell me something about this ? I have found a function in libvirt-0.10.2.8\src\util\ virnetdevtap.c int virNetDevTapCreateInBridgePort(const char *brname, char **ifname, const virMacAddrPtr macaddr, const unsigned char *vmuuid, int *tapfd, vir...