[CentOS-virt] cloud-init log to file not enabled in ec2 image oregon ami-5490ed2c (1804_2)

2018-05-25 Thread Steve Dainard
Hello,

Looks like the cloud-init log settings that write out to
/var/log/cloud-init-output.log have been removed in 1804_2, wondering if
this was a mistake or if there was a reason for this?

Thanks,
Steve
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt


Re: [CentOS-virt] CESA-2018:1655 Important: qemu-kvm-ev security update

2018-05-25 Thread Sandro Bonazzola
2018-05-24 3:18 GMT+02:00 Karanbir Singh :

> On 23/05/18 06:56, Sandro Bonazzola wrote:
> > CentOS Errata and Security Advisory 2018:1655 Important
> >
> > Upstream details at: https://access.redhat.com/errata/RHSA-2018:1655
> >
> > This is the qemu-kvm-ev side of the CVE-2018-3639 mitigation.
> >
> > qemu-kvm-ev-2.10.0-21.el7_5.3.1
> >  has been tagged for
> > release yesterday morning and should land on mirrors this morning.
> > Johnny, Brian, Karanbir, please cross check it's being published, I
> > would have expected it to be already on mirrors.
> >
> > Thanks,
> > --
> >
> > SANDRO BONAZZOLA
> >
> > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
> >
> > Red Hat EMEA 
> >
> > sbona...@redhat.com 
> >
> > 
> > 
> >
>
> With all the noise around this specific package, i went and looked and
> its in the queue for push, should be in the packages for Thu 24th
>

Looks like it's not yet published.
Also altarch is still broken https://bugs.centos.org/view.php?id=14835





>
>
> --
> Karanbir Singh  | London, UK
> Project Lead, The CentOS Project
> Consulting Engineer, https://openshift.io/
>
>


-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

sbona...@redhat.com


___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt


Re: [CentOS-virt] CESA-2018:1655 Important: qemu-kvm-ev security update

2018-05-25 Thread Sandro Bonazzola
2018-05-24 13:38 GMT+02:00 Karanbir Singh :

> On 24/05/18 11:53, Karanbir Singh wrote:
> > On 24/05/18 11:18, Sandro Bonazzola wrote:
> >>
> >>
> >> 2018-05-24 3:18 GMT+02:00 Karanbir Singh  >> >:
> >>
> >> On 23/05/18 06:56, Sandro Bonazzola wrote:
> >> > CentOS Errata and Security Advisory 2018:1655 Important
> >> >
> >> > Upstream details at: https://access.redhat.com/
> errata/RHSA-2018:1655
> >> 
> >> >
> >> > This is the qemu-kvm-ev side of the CVE-2018-3639 mitigation.
> >> >
> >> > qemu-kvm-ev-2.10.0-21.el7_5.3.1
> >> >  >> > has been
> >> tagged for
> >> > release yesterday morning and should land on mirrors this morning.
> >> > Johnny, Brian, Karanbir, please cross check it's being published,
> I
> >> > would have expected it to be already on mirrors.
> >> >
> >> > Thanks,
> >> > --
> >> >
> >> > SANDRO BONAZZOLA
> >> >
> >> > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION
> R
> >> >
> >> > Red Hat EMEA 
> >> >
> >> > sbona...@redhat.com 
> >> >
> >> >
> >> > 
> >> > 
> >> >
> >>
> >> With all the noise around this specific package, i went and looked
> and
> >> its in the queue for push, should be in the packages for Thu 24th
> >>
> >>
> >> Looks like it's not yet published.
> >> Also altarch is still broken https://bugs.centos.org/view.php?id=14835
> >>
> >>
> >>
> >>
> >>
> >
> > yeah, this is down to how the various arch bits were pushed out of sync;
> > we got cut both ways, either if we do x86_64 on its own or we dont,
> >
> > i am working on sig content right now, so let me go look at this as well
> >
> >
>
> the sign runs are now running cleanly for altarch as well, it looks like
> the mirrors caught up in sync with those in the last day or so. its
> going to run for a bit though, I'll keep an eye on things.
>
> w.r.t the CVE note - just want to point out that I've been told that
> lacking the vendor supplied microcode this fix's in this code do not
> really help much. And there is no vendor microcode as yet. Is that an
> accurate state of play ?
>

AFAIK Intel released a beta microcode to OEMs so individual hardware
vendors should be providing it through their support pages after testing
with their hardware.



>
>
> --
> Karanbir Singh  | London, UK
> Project Lead, The CentOS Project
> Consulting Engineer, https://openshift.io/
>
>


-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

sbona...@redhat.com


___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt


Re: [CentOS-virt] libvirtd hang on CentOS6 after latest updates

2018-05-25 Thread Karel Hendrych

Bump. Folks, any ideas?

Cheers
Karel

On 22.5.2018 11:33, Karel Hendrych wrote:
Hi, I am seeing frequent libvirtd hangs (clients not responding) after 
last CentOS6-Xen update :


libvirt-libs-4.1.0-2.xen46.el6.x86_64
libvirt-daemon-4.1.0-2.xen46.el6.x86_64
libvirt-daemon-driver-network-4.1.0-2.xen46.el6.x86_64
libvirt-daemon-driver-nwfilter-4.1.0-2.xen46.el6.x86_64
libgcc-4.4.7-18.el6_9.2.x86_64
2:qemu-img-0.12.1.2-2.503.el6_9.5.x86_64
libvirt-daemon-driver-storage-core-4.1.0-2.xen46.el6.x86_64
libvirt-daemon-driver-secret-4.1.0-2.xen46.el6.x86_64
libvirt-daemon-driver-interface-4.1.0-2.xen46.el6.x86_64
libvirt-daemon-driver-nodedev-4.1.0-2.xen46.el6.x86_64
10:centos-release-xen-common-8-4.el6.x86_64
xen-licenses-4.6.6-12.el6.x86_64
xen-libs-4.6.6-12.el6.x86_64
libvirt-daemon-driver-libxl-4.1.0-2.xen46.el6.x86_64
libvirt-daemon-driver-xen-4.1.0-2.xen46.el6.x86_64
libvirt-daemon-driver-qemu-4.1.0-2.xen46.el6.x86_64
libvirt-daemon-driver-storage-gluster-4.1.0-2.xen46.el6.x86_64
libvirt-daemon-driver-storage-logical-4.1.0-2.xen46.el6.x86_64
libvirt-daemon-driver-storage-mpath-4.1.0-2.xen46.el6.x86_64
libvirt-daemon-driver-storage-disk-4.1.0-2.xen46.el6.x86_64
libvirt-daemon-driver-storage-scsi-4.1.0-2.xen46.el6.x86_64
libvirt-daemon-driver-storage-iscsi-4.1.0-2.xen46.el6.x86_64
libvirt-daemon-driver-storage-4.1.0-2.xen46.el6.x86_64
libstdc++-4.4.7-18.el6_9.2.x86_64
libvirt-daemon-config-nwfilter-4.1.0-2.xen46.el6.x86_64
libvirt-daemon-config-network-4.1.0-2.xen46.el6.x86_64
libvirt-daemon-driver-lxc-4.1.0-2.xen46.el6.x86_64
libvirt-client-4.1.0-2.xen46.el6.x86_64
linux-firmware-20171215-82.git2451bb22.el6.noarch
12:dhcp-common-4.1.1-53.P1.el6.centos.4.x86_64
12:dhclient-4.1.1-53.P1.el6.centos.4.x86_64
libvirt-4.1.0-2.xen46.el6.x86_64
10:centos-release-xen-46-8-4.el6.x86_64
10:centos-release-xen-44-8-4.el6.x86_64
tzdata-2018e-3.el6.noarch
libgomp-4.4.7-18.el6_9.2.x86_64
kernel-4.9.86-30.el6.x86_64
xen-hypervisor-4.6.6-12.el6.x86_64
xen-runtime-4.6.6-12.el6.x86_64
xen-4.6.6-12.el6.x86_64
libvirt-daemon-xen-4.1.0-2.xen46.el6.x86_64

Remedy is to kill -9 libvirtd and start again. Issue can be replicated 
within few domU starts. Usually libvirtd hangs when domU is bringing up 
xen drivers or something around udev, like:


xen_netfront: Initialising Xen virtual ethernet driver

I've been looking into libvirtd strace and debug logs, so far most 
suspicious in libvirtd debug log is this:


libvirtd.log:2018-05-22 08:32:44.760+: 25455: debug : 
udevRemoveOneDevice:1289 : Failed to find device to remove that has udev 
name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-7'
libvirtd.log:2018-05-22 08:32:44.761+: 25455: debug : 
udevRemoveOneDevice:1289 : Failed to find device to remove that has udev 
name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-6'
libvirtd.log:2018-05-22 08:32:44.761+: 25455: debug : 
udevRemoveOneDevice:1289 : Failed to find device to remove that has udev 
name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-4'
libvirtd.log:2018-05-22 08:32:44.762+: 25455: debug : 
udevRemoveOneDevice:1289 : Failed to find device to remove that has udev 
name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-5'
libvirtd.log:2018-05-22 08:32:44.763+: 25455: debug : 
udevRemoveOneDevice:1289 : Failed to find device to remove that has udev 
name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-2'
libvirtd.log:2018-05-22 08:32:44.764+: 25455: debug : 
udevRemoveOneDevice:1289 : Failed to find device to remove that has udev 
name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-3'
libvirtd.log:2018-05-22 08:32:44.765+: 25455: debug : 
udevRemoveOneDevice:1289 : Failed to find device to remove that has udev 
name '/sys/devices/vif-24-0/net/vif24.0/queues/rx-6'
libvirtd.log:2018-05-22 08:32:44.766+: 25455: debug : 
udevRemoveOneDevice:1289 : Failed to find device to remove that has udev 
name '/sys/devices/vif-24-0/net/vif24.0/queues/rx-5'
libvirtd.log:2018-05-22 08:32:44.767+: 25455: debug : 
udevRemoveOneDevice:1289 : Failed to find device to remove that has udev 
name '/sys/devices/vif-24-0/net/vif24.0/queues/rx-4'
libvirtd.log:2018-05-22 08:32:44.767+: 25455: debug : 
udevRemoveOneDevice:1289 : Failed to find device to remove that has udev 
name '/sys/devices/vif-24-0/net/vif24.0/queues/rx-7'
libvirtd.log:2018-05-22 08:32:44.768+: 25455: debug : 
udevRemoveOneDevice:1289 : Failed to find device to remove that has udev 
name '/sys/devices/vif-24-0/net/vif24.0/queues/rx-2'
libvirtd.log:2018-05-22 08:32:44.769+: 25455: debug : 
udevRemoveOneDevice:1289 : Failed to find device to remove that has udev 
name '/sys/devices/vif-24-0/net/vif24.0/queues/rx-3'


I could not get rid of this by reducing amount of driver queues (not 
sure if that applies to PV)


Is someone out there seeing similar issues? Anyone perhaps interested in 
reviewing full debug log / strace ?


Cheers
Karel

___
CentOS-virt mailing list
CentOS-virt@centos.org