Haven't heard any more noise about this so I assume it was some transient error. Please reopen if you can still reproduce.

I have this problem when creating a new guest in Fedora 20 beta.

I have one user account (which is an administrator, as specified during F20 install) on this machine (the F20 host) and am logged in and running virt-manager using that account.  (I mention this because of recent changes in Fedora which discourage logging in as root -- is it even possible?)

Running virt-manager as my user, I'm prompted for the root password at virt-manager start as per default system policy.

SELinux is enabled.

After the final step of creating a virtual machine, virt-manager reports this error:

Unable to complete install: 'internal error: process exited while connecting to monitor: /usr/bin/qemu-system-x86_64: error while loading shared libraries: libGL.so.1: failed to map segment from shared object: Permission denied
'

Details:

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 1959, in do_install
    guest.start_install(meter=meter)
  File "/usr/share/virt-manager/virtinst/guest.py", line 389, in start_install
    noboot)
  File "/usr/share/virt-manager/virtinst/guest.py", line 454, in _create_guest
    dom = self.conn.createLinux(start_xml or final_xml, 0)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2897, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: internal error: process exited while connecting to monitor: /usr/bin/qemu-system-x86_64: error while loading shared libraries: libGL.so.1: failed to map segment from shared object: Permission denied

Please provide the guest XML configuration for your guest. Also check if there are any AVCs from SELinux in /var/log/audit/audit.log, and check if it succeeds when SELinux is switched to permissive mode.

rmichael, are you using nvidia proprietary drivers?

Indeed, it succeeds when SElinux is disabled.

In /var/log/audit/audit.log, there is one AVC.  I didn't verify the timestamp, but the 'execmem' is suspicious.

type=AVC msg=audit(1384880682.254:547): avc:  denied  { execmem } for  pid=2915 comm="qemu-system-x86" scontext=system_u:system_r:svirt_t:s0:c328,c388 tcontext=system_u:system_r:svirt_t:s0:c328,c388 tclass=process


Cole Robinson, Yes, I am using proprietary drivers installed via rpmfusion.

xorg-x11-drv-nvidia-304xx-libs-304.108-1.fc20.x86_64
kmod-nvidia-304xx-3.11.8-300.fc20.x86_64-304.108-4.fc20.x86_64
akmod-nvidia-304xx-304.108-4.fc20.x86_64
xorg-x11-drv-nvidia-304xx-304.108-1.fc20.x86_64

Could there be an SElinux issue with the files installed by those packages?

(Apologies, I am not particularly experienced with SElinux configuration.)

(In reply to Richard Michael from comment #5)
> Indeed, it succeeds when SElinux is disabled.
> 
> In /var/log/audit/audit.log, there is one AVC.  I didn't verify the
> timestamp, but the 'execmem' is suspicious.
> 
> type=AVC msg=audit(1384880682.254:547): avc:  denied  { execmem } for 
> pid=2915 comm="qemu-system-x86"
> scontext=system_u:system_r:svirt_t:s0:c328,c388
> tcontext=system_u:system_r:svirt_t:s0:c328,c388 tclass=process

Ah ha. That explains the previously bizarre report we had of QEMU needing execmem in bug 1029328

> Cole Robinson, Yes, I am using proprietary drivers installed via rpmfusion.
> 
> xorg-x11-drv-nvidia-304xx-libs-304.108-1.fc20.x86_64
> kmod-nvidia-304xx-3.11.8-300.fc20.x86_64-304.108-4.fc20.x86_64
> akmod-nvidia-304xx-304.108-4.fc20.x86_64
> xorg-x11-drv-nvidia-304xx-304.108-1.fc20.x86_64
> 
> Could there be an SElinux issue with the files installed by those packages?
> 
> (Apologies, I am not particularly experienced with SElinux configuration.)

We intentionally block 'execmem' since is a very bad thing to allow from a security POV. It is really awful that nvidia's proprietary drivers require this, and I would not want SELinux to allow this.

(It's always a fun time with proprietary Nvidia, this has been biting me in various ways for years. This is in fact old hardware, but the Nouveau driver does not yet seem to support it.  I'll never buy another motherboard or Nvida card for linux again.)

On the security issue, understood.

Though, I suppose many people will be affected by this.

At the moment, I simply disabled SELinux, which obviously not ideal.  Can I refine the policy to allow 'execmem' only for 'qemu-system-x86' and with respect to 'libGL.so'?  (Then possibly the nvidia RPMs could incorporate that small refinement and inform the user at install time.)

You should be able to keep selinux enabled, but do:

sudo setsebool -P virt_use_execmem=on

Can you confirm that fixes things?

Yes, that works, thanks Cole.

[In fact, I re-enabled SELinux and generated a failure to be sure it was "broken" again and this time the SELinux notification pop-up (at the bottom of the screen) appeared.  Launching the "troubleshooter" revealed setsebool work-around as well.  If I'd seen the notification the first time, I wouldn't have filed here.. I really don't think it popped up, however ; I'm sitting at the console without anything else on the screen.]

Anyway, thanks again and sorry for the time waste.  I'll suggest 'sesetbool' be added to the nvidia RPMs.

I blogged about it here:

http://blog.wikichoon.com/2013/11/qemu-system-x8664-error-while-loading.html

Hopefully that adds some visibility

*** Bug 1029328 has been marked as a duplicate of this bug. ***

(In reply to Richard Michael from comment #7)
> Though, I suppose many people will be affected by this.
> 

Just ran into this problem and found this thread while looking to report... Nevermind.

Just want to add for other people who search about this issue that it is not just the proprietary Nvidia drivers that cause this, I am running the latest AMD proprietary fglrx video driver and get this same error with the same denied { execmem } in audit.log. Using the above metioned setsebool command fixes the issue in this case too though.

fedora-20, 3.13.6-200.fc20.x86_64, NVidia proprietary driver

The solution below help

>> sudo setsebool -P virt_use_execmem=on

I hit this today too.  Thanks for virt_use_execmem, though I wish nouveau wouldn't crash my system repeatedly which is what has forced me into using the nvidia driver instead.

execmem is caused by several rpath in fedora packages.

for f in *.so.*.* ; do chrpath -d ${f} ; done
That will break pulseaudio that is not able to run anymore.

http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath

Here is a list of shared objects available on a virt-manager install
Exept for pulseaudio, others have RPATH on /usr/lib64.

libcogl-pango.so.15.3.0
libdcerpc-atsvc.so.0.0.1
libdcerpc-binding.so.0.0.1
libdcerpc.so.0.0.1
libfbembed.so.2.5
libfbembed.so.2.5.2
libfolks-eds.so.25.16.1
libfolks-telepathy.so.25.16.1
libgdbm_compat.so.4.0.0
libgensec.so.0.0.1
libgnutls-dane.so.0.4.1
libgnutls-xssl.so.0.0.0
libgrlpls-0.2.so.0.0.1
libgstaudio-0.10.so.0.25.0
libgstbase-0.10.so.0.30.0
libgstcdda-0.10.so.0.25.0
libgstriff-0.10.so.0.25.0
libgupnp-dlna-gst-2.0.so.3.0.0
libndr-krb5pac.so.0.0.1
libndr-nbt.so.0.0.1
libndr.so.0.0.2
libndr-standard.so.0.0.1
libpulse-mainloop-glib.so.0.0.5 RPATH=/usr/lib64/pulseaudio (OK)
libpulse-simple.so.0.1.0 RPATH=/usr/lib64/pulseaudio (OK)
libpulse.so.0.17.3 RPATH=/usr/lib64/pulseaudio (OK)
libregistry.so.0.0.1
librygel-renderer-2.0.so.1.0.0
librygel-renderer-gst-2.0.so.1.0.0
librygel-server-2.0.so.1.0.0
libsamba-credentials.so.0.0.1
libsamba-hostconfig.so.0.0.1
libsamba-policy.so.0.0.1
libsamba-util.so.0.0.1
libsamdb.so.0.0.1
libserf-1.so.0.3.0
libsmbclient-raw.so.0.0.1
libsmbclient.so.0.2.1
libtevent-util.so.0.0.1
libwbclient.so.0.11

Here is a list of sources package currently installed on my system, having rpath set
cogl-1.16.0-2.fc20.src.rpm
firebird-2.5.2.26539.0-8.fc20.src.rpm
folks-0.9.6-2.fc20.src.rpm
gdbm-1.10-7.fc20.src.rpm
gnutls-3.1.25-1.fc20.src.rpm
grilo-0.2.9-2.fc20.src.rpm
gstreamer-0.10.36-6.fc20.src.rpm
gstreamer-plugins-base-0.10.36-6.fc20.src.rpm
gupnp-dlna-0.10.2-2.fc20.src.rpm
libserf-1.3.4-1.fc20.src.rpm
rygel-0.20.3-1.fc20.src.rpm
samba-4.1.9-4.fc20.src.rpm

Given the bug affect this component I would keep it as a tracker for the ones that are actually dependency of virt-manager. (such as cogl)

Nicolas, I can't really understand what you are getting at... the execmem violation seems to be an issue with using the proprietary nvidia drivers and does not happen when starting VMs on stock f20.

If you are hitting an issue with stock packages, please open a new bug and post the exact error message you are seeing

(In reply to Cole Robinson from comment #18)
> Nicolas, I can't really understand what you are getting at... the execmem
> violation seems to be an issue with using the proprietary nvidia drivers and
> does not happen when starting VMs on stock f20.
Altought there is nothing to be fixed with this issue in qemu itself (not even in the nvidia package) the problem is seen with qemu because some qemu dependencies are using rpath hence the process load the mesa-libGL from /usr/lib(64) instead of the libGL found by the linker at runtime.

Fixing every rpathes on a given system was enought to make the selinux denial to disappear. (So it wasn't a Selinux issue either).

Given that rpath in standard library path is forbidden in fedora and that some fedora packages are affected (altought remotely for qemu) I think it's fair for users to consider the issue unfixed until every qemu dependencies are fixed. (only fixed cogl so far)

Why don't we see this with stock fedora then? What is nvidia doing that tickles the rpath issue, yet isn't an issue for nvidia to fix?

(How did you fix the rpath issue for cogl, can you provide a commit link?)

(In reply to Cole Robinson from comment #20)
> Why don't we see this with stock fedora then? What is nvidia doing that
> tickles the rpath issue, yet isn't an issue for nvidia to fix?
no, this is fedora breaking fedora's rules (no rpath), it's dead easy.
> (How did you fix the rpath issue for cogl, can you provide a commit link?)
git show 487559a84b53d6f8e2d429fd6d4c81957c0a06d9 in cogl's fedora package.
Altought I prefer patching libtool between %configure and make at the %build step

# remove rpath from libtool
sed -i.rpath 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
sed -i.rpath 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool

Really?  So, you actually found the bug with patch and still no joy?

Thanks for posting here, Nicolas.  I would have been lost and had no idea it could be fixed.  So, did you just build cogl from srpm (with your fix)?  Doesn't look too hard on the surface.  Any caveats?