similar to: consume existing tap device when libvirt / qemu run as different users

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

> On Tue, Jun 30, 2020 at 04:02:05PM +0100, Daniel P. Berrangé wrote: > > On Tue, Jun 30, 2020 at 12:59:03PM +0200, Miguel Duarte de Mora Barroso wrote: > > > On Mon, Apr 6, 2020 at 4:03 PM Laine Stump <lstump redhat com> wrote: > > > > > > > > On 4/6/20 9:54 AM, Daniel P. Berrangé wrote: > > > > > On Mon, Apr 06, 2020 at 03:47:01PM

On Tue, Jun 30, 2020 at 12:59:03PM +0200, Miguel Duarte de Mora Barroso wrote: > On Mon, Apr 6, 2020 at 4:03 PM Laine Stump <lstump@redhat.com> wrote: > > > > 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

Hello, On KubeVirt, we are trying to pre-create a tap device, then instruct libvirt to consume it (via the type=ethernet , managed='no' attributes). It works as expected, **unless** when we create a multi-queue tap device. The difference when creating the tap device is that we set the multi-queue flag; libvirt throws the following error when consuming it: ``` LibvirtError(Code=38,

On Tue, Sep 22, 2020 at 01:48:08PM +0200, Miguel Duarte de Mora Barroso wrote: > Hello, > > On KubeVirt, we are trying to pre-create a tap device, then instruct > libvirt to consume it (via the type=ethernet , managed='no' > attributes). > > It works as expected, **unless** when we create a multi-queue tap device. > > The difference when creating the tap

On Mon, Apr 6, 2020 at 4:03 PM Laine Stump <lstump@redhat.com> wrote: > > 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]. >

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 pre-created tap devices into libvirt guests - that would be a requirement to allow kubevirt to run with less capabilities in the pods that encapsulate the VMs. I took a look at the libvirt code

On Wed, Sep 23, 2020 at 05:44:28PM +0100, Daniel P. Berrangé wrote: > On Tue, Sep 22, 2020 at 01:48:08PM +0200, Miguel Duarte de Mora Barroso wrote: > > Hello, > > > > On KubeVirt, we are trying to pre-create a tap device, then instruct > > libvirt to consume it (via the type=ethernet , managed='no' > > attributes). > > > > It works as

Currently, LogLevel must be set to VERBOSE to see the fingerprint of an accepted key, and the default LogLevel is INFO. Since this is useful security information, I would like to propose that the 'Accepted publickey' message be modified to include the fingerprint of the accepted key. Is this a reasonable solution? Here is an example log snippet with LogLevel VERBOSE: Oct 1 15:23:24

I am seeing these in the log of one of our off-site NX hosts running CentOS-6.6. type=AVC msg=audit(1421683972.786:4372): avc: denied { create } for pid=22788 comm="iptables" scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=rawip_socket Was caused by: Missing type enforcement (TE) allow rule. You can use

On Mon, January 19, 2015 11:50, James B. Byrne wrote: > I am seeing these in the log of one of our off-site NX hosts running > CentOS-6.6. > > type=AVC msg=audit(1421683972.786:4372): avc: denied { create } for > pid=22788 comm="iptables" scontext=system_u:system_r:fail2ban_t:s0 > tcontext=system_u:system_r:fail2ban_t:s0 tclass=rawip_socket > Was caused by:

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 pre-created tap devices into libvirt guests - that > would be a requirement to

https://bugzilla.netfilter.org/show_bug.cgi?id=1757 Bug ID: 1757 Summary: Alpine 3.19: iptables: Bad rule (does a matching rule exist in that chain?). Product: iptables Version: 1.8.x Hardware: All OS: other Status: NEW Severity: normal Priority: P5 Component:

Guus Sliepen, I am working in a zeroconf setup for tinc called tzk, that could allow you to make this easily https://github.com/NebTex/tzk/ it will make better readme this weekend but you need a public machine with a public domain - subdomain pointed to it, the script will install tinc, consul (that is used for coordinate the vpn), and caddy a small reverse proxy for expose consul to the public

Add raw network backend option which uses a packet socket to provide raw networking access. Once the socket is opened it's bound to a provided host interface, such that packets received on the interface are delivered to the VM and packets sent by the VM are sent to the interface. This is functionally similar to the existing pcap network backend, with the same advantages and problems.

Add raw network backend option which uses a packet socket to provide raw networking access. Once the socket is opened it's bound to a provided host interface, such that packets received on the interface are delivered to the VM and packets sent by the VM are sent to the interface. This is functionally similar to the existing pcap network backend, with the same advantages and problems.

Hi all, Heketi v6.0.0 is now available [1]. This is the new stable version of Heketi. Older versions are discontinued. The main additions in this release are the block-volume API, a great deal of stabilization to prevent inconsistent database and out-of-sync situations, and tooling to do disaster recovery when the database is bad. Changelog * Add support for gluster-block volumes * Add device

Fixes some of the more egregious problems with v1, and also applies properly to the head of git without needing any other patches. Rich.

"rake test" runs all the tests as it should... but "rake test:units" C:\...\...>rake test:units (in C:/.../...) rake aborted! FATAL C3D000 Mdatabase "postgres" does not exist Fpostinit.c L274 RInitPostgres (See full trace by running task with --trace) Small part of the trace: C:\...\...>rake test:units --trace (in C:/.../...) ** Invoke test:units

On Sun, Jul 12, 2020 at 11:16:01PM +0300, Nir Soffer wrote: > On Sat, Jul 11, 2020 at 11:18 AM Richard W.M. Jones <rjones@redhat.com> wrote: > > > > KubeVirt is a custom resource (a kind of plugin) for Kubernetes which > > adds support for running virtual machines. As part of this they have > > the same problems as everyone else of how to import large disk images