search for: virnetdevtapcreate

Displaying 6 results from an estimated 6 matches for "virnetdevtapcreate".

2020 Jun 30
1
Re: plug pre-created tap devices to libvirt guests
...> > 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_ADMI...
2020 Aug 30
1
Re: plug pre-created tap devices to libvirt guests
...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, bot...
2020 Apr 06
4
Re: plug pre-created tap devices to libvirt guests
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
2020 Jun 30
0
Re: plug pre-created tap devices to libvirt guests
...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 corre...
2015 Mar 03
1
Re: QEMU interface type=ethernet
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
2015 Apr 26
3
How does the libvirt deal with the vnet mac address
...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, virNetD...