similar to: 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

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

> 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 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]. >

Hello, I'm having some doubts about consuming an existing - already configured - tap device from libvirt (with `managed='no' ` attribute set). In KubeVirt, we want to have the consumer side of the tap device run without the NET_ADMIN capability, which requires the UID / GID of the tap creator / opener to match, as per the kernel code in [0]. As such, we create the tap device (with

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

Hi, I've seen that in the past, libvirt couldn't start VMs when the disk image was stored on a file system that doesn't support direct I/O having the 'cache=none' configuration [0]. On the KubeVirt project, we have some storage tests on a particular provider which does just that - try to create / start a VM whose disk is on tmpfs and whose definition features

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

On Mon, Apr 06, 2020 at 10:03:41AM -0400, Laine Stump wrote: > On 4/6/20 9:54 AM, Daniel P. Berrangé wrote: > > > Would you be able to shed some light into this ? Is it possible on > > > libvirt-5.6.0 to plug pre-created tap devices to libvirt guests ? > > > > > > [0] - https://bugzilla.redhat.com/show_bug.cgi?id=1723367 > > This links to the following

Hi, I'm seeing the following issue when attempting to update the guest's clock on a running fc32 guest (using guest agent): ``` [root@virt-launcher-vmi-masquerade-mh2xm /]# virsh domtime 1 --pretty Time: 2020-04-30 23:27:29 [root@virt-launcher-vmi-masquerade-mh2xm /]# virsh domtime 1 --sync error: internal error: unable to execute QEMU agent command 'guest-set-time': hwclock

On Thu, Apr 30, 2020 at 2:15 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Thu, Apr 30, 2020 at 01:52:12PM +0200, Miguel Duarte de Mora Barroso wrote: > > Hi, > > > > I'm seeing the following issue when attempting to update the guest's > > clock on a running fc32 guest (using guest agent): > > > > ``` > >

On Thu, Aug 22, 2019 at 2:24 AM Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Wed, Aug 21, 2019 at 01:37:21PM -0700, Ihar Hrachyshka wrote: > > Hi all, > > > > KubeVirt uses libvirtd to manage qemu VMs represented as Kubernetes > > API resources. In this case, libvirtd is running inside an > > unprivileged pod, with some host mounts / capabilities

On Wed, 10 Jun 2020 11:31:33 +0100 "Richard W.M. Jones" <rjones@redhat.com> wrote: > I finally got access to the container. This is how it's configured: > > * / => an overlay fs. > > There is sufficient space here, and there are no "funny" restrictions, > to be able to create the libguestfs appliance. I proved this by > setting TMPDIR to a

On Thu, Aug 22, 2019 at 12:01 PM Laine Stump <laine@redhat.com> wrote: > > On 8/22/19 10:56 AM, Ihar Hrachyshka wrote: > > On Thu, Aug 22, 2019 at 2:24 AM Daniel P. Berrangé <berrange@redhat.com> wrote: > >> > >> On Wed, Aug 21, 2019 at 01:37:21PM -0700, Ihar Hrachyshka wrote: > >>> Hi all, > >>> > >>> KubeVirt uses

Hi, In kubevirt we are running into a strange permission problem on libvirt-5.0. We see transient "Permission Denied" errors when "virAuditSend" wants to send an audit log. [1] shows the logs of one of these containers. Here an example: {"component":"virt-launcher","level":"warning","msg":"Failed to send audit message

On Fri, 23 Aug 2019, 0:27 Laine Stump, <laine@redhat.com> wrote: > (Adding Alex Williamson to Cc so he can correct any mistakes) > > On 8/22/19 4:39 PM, Ihar Hrachyshka wrote: > > On Thu, Aug 22, 2019 at 12:01 PM Laine Stump <laine@redhat.com> wrote: > >> > >> On 8/22/19 10:56 AM, Ihar Hrachyshka wrote: > >>> On Thu, Aug 22, 2019 at 2:24 AM

Hi, We are updating KubeVirt to libvirt 5.6.0. Before that we were running on 5.0.0. It seems like something regarding setting xattrs on files has changed, because with libvirt 5.6.0 we are getting the following error: ``` Unable to set XATTR trusted.libvirt.security.dac on /var/lib/libvirt/qemu/domain-410-default_vmi-fedora: Operation not permitted') ``` The main problem is for us is that

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

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