On Wed, Jan 13, 2016 at 04:25:14PM +0100, Martin Kletzander wrote:
For each of the kernels, libvirt labels them (with both DAC and
selinux
labels), then proceeds to launching qemu. If this is done parallel, the
race is pretty obvious. Could you remind me why you couldn't use
<seclabel model='none'/> or <seclabel relabel='no'/> or
something that
would mitigate this?
We value having sVirt :-)
However I'm just about to rerun the tests with <seclabel type='none'/>
to see if the problem goes away. Will let you know tomorrow once they
have run again.
If we cannot use this, then we need to implement
the <seclabel/> element for kernel and initrd.
Right, that could work for us I think.
>19 of the failures (4%) were of the form:
>
> process exited while connecting to monitor: fread() failed
>
>which I believe is a previously unknown bug. I have filed it as
>https://bugzilla.redhat.com/1298122
>
I think even this one might be the case, maybe selinux stops qemu from
reading the kernel/initrd.
>Finally there was 1 failure:
>
> Unable to read from monitor: Connection reset by peer
>
>which I believe is also a new bug. I have filed it as
>https://bugzilla.redhat.com/1298124
>
This, I believe, means QEMU exited (as in the previous one), just at
different point in time.
OK - let's see if they go away when we get the kernel
thing fixed.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top