Checking the code I'd expect that this kind of access is from:
static void qemu_thread_set_name(QemuThread *thread, const char *name) { #ifdef CONFIG_PTHREAD_SETNAME_NP pthread_setname_np(thread->thread, name); #endif }
This is non fatal, just fails to set the thread name (note that the return value is intentionally ignored).
The code itself if rather old (since qemu 2.0) but not enabled by default. You could be enabled by: -name debug-threads=on
Since this change it is enabled by default by libvirt if supported: https://www.redhat.com/archives/libvir-list/2016-March/msg00428.html
So with Yakkety you get e.g. -name guest=testvm1,debug-threads=on While on Xenial you got: -name guest=testvm1
That feature enabled is what triggers the apparmor issues now.
Checking the code I'd expect that this kind of access is from:
static void qemu_thread_ set_name( QemuThread *thread, const char *name) PTHREAD_ SETNAME_ NP setname_ np(thread- >thread, name);
{
#ifdef CONFIG_
pthread_
#endif
}
This is non fatal, just fails to set the thread name (note that the return value is intentionally ignored).
The code itself if rather old (since qemu 2.0) but not enabled by default.
You could be enabled by:
-name debug-threads=on
Since this change it is enabled by default by libvirt if supported: /www.redhat. com/archives/ libvir- list/2016- March/msg00428. html
https:/
So with Yakkety you get e.g. debug-threads= on
-name guest=testvm1,
While on Xenial you got:
-name guest=testvm1
That feature enabled is what triggers the apparmor issues now.