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