similar to: RLIMIT_MEMLOCK in container environment

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

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

(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 Daniel P. Berrangé <berrange@redhat.com> wrote: >>>> >>>> On Wed, Aug 21,

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 libvirtd to manage qemu VMs represented as Kubernetes >>> API resources. In this case, libvirtd is running

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 added to the > pod, needed by libvirtd and other services. > > One of the capabilities libvirtd requires for

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

Hello everyone, First time contributor ... long time listener! Your /FirstnameLastname/ username: ChrisCallegari I am working with Open Source project called KubeVirt. Part of our mission is to ensure that the project can easily be deployed ... this includes host os and Kubernetes. We dev and test on Fedora, CentOS, and RHEL and several Debian derivatives for OS's and minikube for

On 05/10/2018 02:53 PM, Ihar Hrachyshka 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 What is your definition of "becomes ready"? Are you looking at the output of "ip link show" in the guest? Or are you watching "brctl

On Thu, May 10, 2018 at 11:53:23AM -0700, Ihar Hrachyshka 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 for up to 1 minute [2]. If we switch from e1000 to virtio, the > link is

Hi all This is the first time I try and get Xen working, and want to install a few CentOS 5.1 32bit and FreeBSD 6.1 VM's on my CentOS 5.1 x64 server. Trying to get the first one to install is rather trivial, and I keep on running into errors. At fist I wanted to install it fro the cdrom, so I used "virt-install --cdrom=/dev/hdc" It booted up, and I could choose my language, but

Nah, RHEL 5.1+ supports 32-bit domU (PAE and non PAE) on 64-bit dom0. Actually RHEL Xen is 3.1 with the brain damaged 3.0 userland utilities. -Ross ----- Original Message ----- From: centos-bounces at centos.org <centos-bounces at centos.org> To: CentOS mailing list <centos at centos.org> Sent: Fri Feb 29 04:46:42 2008 Subject: Re: [CentOS] error creating Centos 5.1 x32 dum_U

Nah, RHEL 5.1+ supports 32-bit domU (PAE and non PAE) on 64-bit dom0. Actually RHEL Xen is 3.1 with the brain damaged 3.0 userland utilities. -Ross ----- Original Message ----- From: centos-bounces at centos.org <centos-bounces at centos.org> To: CentOS mailing list <centos at centos.org> Sent: Fri Feb 29 04:46:42 2008 Subject: Re: [CentOS] error creating Centos 5.1 x32 dum_U

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 > into the system for pets, templates, etc. > > As part of the project

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

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

We were previously running 5.1 x86_64 and recently updated to 5.2 using yum. Under 5.1 we were having problems when running jobs using torque and the solution had been to add the following items to the files noted "* soft memlock unlimited" in /etc/security/limits.conf "session required pam_limits.so" in /etc/pam.d/{rsh,sshd} This changed the max