search for: ihrachi

Hi, try to use virtio instead... Atte. Daniel Romero P. On Thu, May 10, 2018 at 3:53 PM, Ihar Hrachyshka <ihrachys@redhat.com> wrote: > 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

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

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 added to the pod, needed by libvirtd and other services. One of the capabilities libvirtd requires for successful startup inside a pod is SYS_RESOURCE. This capability is used to adjust RLIMIT_MEMLOCK ulimit

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