similar to: Re: plug pre-created tap devices to libvirt guests

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

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

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

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

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 Fri, Mar 27, 2020 at 12:31:07PM +0100, Miguel Duarte de Mora Barroso wrote: > 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

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

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 into the system for pets, templates, etc. As part of the project they've defined a format for embedding a disk image into a container (unclear why? perhaps so these can be distributed

Hi, In kubevirt, we discovered [1] that whenever e1000 is used for vNIC, link on the interface becomes ready several seconds after 'ifup' is executed, which for some buggy images like cirros may slow down boot process for up to 1 minute [2]. If we switch from e1000 to virtio, the link is brought up and ready almost immediately. For the record, I am using the following versions: - L0

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

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): > > > > ``` > >

Hi Daniel, thanks for the quick reply we did try to override SMBIOS host_uuid_source = "machine-id" and it didn't work even that nodes have different [root@modi01 kubevirt]# ./cluster-up/ssh.sh kind-1.17.0-worker root@kind-1:/# cat /etc/machine-id [root@modi01 kubevirt]# ./cluster-up/ssh.sh kind-1.17.0-control-plane root@kind-1:/# cat /etc/machine-id

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 Thu, Mar 29, 2018 at 05:26:13PM +0200, Piotr Kliczewski wrote: > Richard, > > Great progress. I really like it!!! > > Here is what I noticed: > > I see that in the yaml file we provide short-id as: > > os: > osinfo: 'rhel7.2' > > whereas kubevirt expects it in metadata: > > metadata: > labels: > kubevirt.io/os: win10 >