libvirt won't start a VM with serial or console

[Serge Hallyn]

I get the error:

Error starting domain: internal error Process exited while reading console log output: chardev: opening backend "pty" failed

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 814, in run_domain
    vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 1296, in startup
    self._backend.create()
  File "/usr/lib/python2.6/dist-packages/libvirt.py", line 333, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error Process exited while reading console log output: chardev: opening backend "pty" failed

It was originally thought that turning off apparmor fixes it, and re-enabling apparmor stops libvirt from creating VMs again. Later reports claim this is not the case.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: libvirt-bin 0.8.3-1ubuntu9
ProcVersionSignature: Ubuntu 2.6.35-19.28-generic 2.6.35.3
Uname: Linux 2.6.35-19-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Tue Sep 7 16:05:19 2010
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Alpha amd64 (20100820)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: libvirt

[Serge Hallyn (serge-hallyn)]

This is the 'virsh dumpxml' output for one of the VMs. (All VMs refuse to start).

The VM disks are under /srv/libvirt-storage-pool-1 (which was created using the
virt-manager interface), but the apparmor config files seem to account for that.

[Serge Hallyn (serge-hallyn)]

This is a tarfile of all the /etc/apparmor.d/libvirt/ files.

[Jamie Strandboge (jdstrand)]

This is probably due to the serial and console in the xml. Can you try to start the machine without them? Also, please attach the apparmor denied message from /var/log/kern.log.

[Serge Hallyn (serge-hallyn)]

Sample results from 'grep denied /var/log/kern.log':

Sep 7 15:41:57 sergelap kernel: [30930.845626] type=1400 audit(1283892117.360:30): apparmor="DENIED" operation="open" parent=17387 profile="libvirt-a991f316-eebc-e584-72c2-857666db8606" name="/proc/17396/fd/" pid=17396 comm="kvm" requested_mask="r" denied_mask="r" fsuid=117 ouid=117
Sep 7 15:41:57 sergelap kernel: [30930.845736] type=1400 audit(1283892117.360:31): apparmor="DENIED" operation="exec" parent=17387 profile="libvirt-a991f316-eebc-e584-72c2-857666db8606" name="/usr/lib/pt_chown" pid=17396 comm="kvm" requested_mask="x" denied_mask="x" fsuid=117 ouid=0
Sep 7 15:42:20 sergelap kernel: [30954.413408] type=1400 audit(1283892140.950:34): apparmor="DENIED" operation="open" parent=17990 profile="libvirt-27f9f30c-5632-2504-5006-e329fcf24d32" name="/proc/17994/fd/" pid=17994 comm="kvm" requested_mask="r" denied_mask="r" fsuid=117 ouid=117
Sep 7 15:42:20 sergelap kernel: [30954.413532] type=1400 audit(1283892140.950:35): apparmor="DENIED" operation="exec" parent=17990 profile="libvirt-27f9f30c-5632-2504-5006-e329fcf24d32" name="/usr/lib/pt_chown" pid=17994 comm="kvm" requested_mask="x" denied_mask="x" fsuid=117 ouid=0
Sep 7 15:42:59 sergelap kernel: [30992.430445] type=1400 audit(1283892179.000:38): apparmor="DENIED" operation="open" parent=19012 profile="libvirt-27f9f30c-5632-2504-5006-e329fcf24d32" name="/proc/19017/fd/" pid=19017 comm="kvm" requested_mask="r" denied_mask="r" fsuid=117 ouid=117
Sep 7 15:42:59 sergelap kernel: [30992.430571] type=1400 audit(1283892179.000:39): apparmor="DENIED" operation="exec" parent=19012 profile="libvirt-27f9f30c-5632-2504-5006-e329fcf24d32" name="/usr/lib/pt_chown" pid=19017 comm="kvm" requested_mask="x" denied_mask="x" fsuid=117 ouid=0
Sep 7 15:56:14 sergelap kernel: [31787.351880] type=1400 audit(1283892974.630:66): apparmor="DENIED" operation="open" parent=4601 profile="libvirt-27f9f30c-5632-2504-5006-e329fcf24d32" name="/proc/4611/fd/" pid=4611 comm="kvm" requested_mask="r" denied_mask="r" fsuid=117 ouid=117
Sep 7 15:56:14 sergelap kernel: [31787.351977] type=1400 audit(1283892974.630:67): apparmor="DENIED" operation="exec" parent=4601 profile="libvirt-27f9f30c-5632-2504-5006-e329fcf24d32" name="/usr/lib/pt_chown" pid=4611 comm="kvm" requested_mask="x" denied_mask="x" fsuid=117 ouid=0
Sep 7 15:58:30 sergelap kernel: [31923.244075] type=1400 audit(1283893110.640:94): apparmor="DENIED" operation="open" parent=7942 profile="libvirt-27f9f30c-5632-2504-5006-e329fcf24d32" name="/proc/7947/fd/" pid=7947 comm="kvm" requested_mask="r" denied_mask="r" fsuid=117 ouid=117
Sep 7 15:58:30 sergelap kernel: [31923.244251] type=1400 audit(1283893110.640:95): apparmor="DENIED" operation="exec" parent=7942 profile="libvirt-27f9f30c-5632-2504-5006-e329fcf24d32" name="/usr/lib/pt_chown" pid=7947 comm="kvm" requested_mask="x" denied_mask="x" fsuid=117 ouid=0
Sep 7 16:07:56 sergelap kernel: [32488.497495] type=1400 audit(1283893676.410:98): apparmor="DENIED" operation="open" parent=19911 profile="libvirt-27f9f30c-5632-2504-5006-e329fcf24d32" name="/proc/19915/fd/" pid=19915 comm="kvm" requested_mask="r" denied_mask="r" fsuid=117 ouid=117
Sep 7 16:07:56 serge...

[Jamie Strandboge (jdstrand)]

Thanks, can you also try to start the VM without the <serial> and <console>?

[Jamie Strandboge (jdstrand)]

If the VM works, can you then add the ,serial> and <console> back, then add the following to /etc/apparmor.d/abstractions/libvirt-qemu:
  /usr/lib/pt_chown ix,
  owner ${PROC}/[0-9]*/fd/ r,
  owner ${PROC}/[0-9]*/fd/3 r,

then try starting the virtual machine.

[Serge Hallyn (serge-hallyn)]

Quoting Jamie Strandboge (<email address hidden>):
> This is probably due to the serial and console in the xml. Can you try
> to start the machine without them?

Yup, when I take those out the vm starts.

[Jamie Strandboge (jdstrand)]

err, that should have been:
  /usr/lib/pt_chown ix,
  owner @{PROC}/[0-9]*/fd/ r,
  owner @{PROC}/[0-9]*/fd/3 r,

[Serge Hallyn (serge-hallyn)]

Quoting Jamie Strandboge (<email address hidden>):
> If the VM works, can you then add the ,serial> and <console> back, then add the following to /etc/apparmor.d/abstractions/libvirt-qemu:
> /usr/lib/pt_chown ix,
> owner ${PROC}/[0-9]*/fd/ r,
> owner ${PROC}/[0-9]*/fd/3 r,
>
> then try starting the virtual machine.

fails:

Sep 7 16:48:25 sergelap kernel: [34915.565965] type=1400 audit(1283896105.650:140): apparmor="DENIED" operation="open" parent=7384 profile="libvirt-4b49b0f2-18e7-ef59-f9c6-d37703a6ca21" name="/proc/7389/fd/" pid=7389 comm="kvm" requested_mask="r" denied_mask="r" fsuid=117 ouid=117
Sep 7 16:48:25 sergelap kernel: [34915.566156] type=1400 audit(1283896105.650:141): apparmor="DENIED" operation="exec" parent=7384 profile="libvirt-4b49b0f2-18e7-ef59-f9c6-d37703a6ca21" name="/usr/lib/pt_chown" pid=7389 comm="kvm" requested_mask="x" denied_mask="x" fsuid=117 ouid=0

[Jamie Strandboge (jdstrand)]

Can you attach your /etc/apparmor.d/abstractions/libvirt-qemu file?

[Jamie Strandboge (jdstrand)]

I cannot reproduce with the m2.xml file using qemu:///system on the local machine. I used virt-manager to create the /srv/libvirt-storage-pool-1/maverick2.img image (but I had to 'chmod 750 /srv/libvirt-storage-pool-1 ; chgrp kvm /srv/libvirt-storage-pool-1' to make this work).

Can you provide exact steps to reproduce, including any non-default configuration for libvirt (ie, /etc/libvirt/*)?

[Serge Hallyn (serge-hallyn)]

Quoting Jamie Strandboge (<email address hidden>):
> I cannot reproduce with the m2.xml file using qemu:///system on the
> local machine. I used virt-manager to create the /srv/libvirt-storage-
> pool-1/maverick2.img image (but I had to 'chmod 750 /srv/libvirt-
> storage-pool-1 ; chgrp kvm /srv/libvirt-storage-pool-1' to make this
> work).
>
> Can you provide exact steps to reproduce, including any non-default
> configuration for libvirt (ie, /etc/libvirt/*)?

Hm, today it's working fine... FWIW here is my
/etc/libvirt/storage/libvirt-storage-pool-1.xml:

<pool type='dir'>
  <name>libvirt-storage-pool-1</name>
  <uuid>088fb527-21da-5cfe-899c-0c785342fffe</uuid>
  <capacity>0</capacity>
  <allocation>0</allocation>
  <available>0</available>
  <source>
  </source>
  <target>
    <path>/srv/libvirt-storage-pool-1</path>
    <permissions>
      <mode>0700</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>

but

# ls -dl /srv/libvirt-storage-pool-1/
drwxr-xr-x 2 root root 4096 2010-09-03 09:45 /srv/libvirt-storage-pool-1/

Since I can't reproduce at the moment, I've got no problem with
marking this Invalid for the moment, and I'll re-open if (when)
it happens again?

Weird. (Especially since I did not apt-get update today)

[Jamie Strandboge (jdstrand)]

Serge, do you still have the following in your /etc/apparmor.d/abstractions/libvirt-qemu:
  /usr/lib/pt_chown ix,
  owner @{PROC}/[0-9]*/fd/ r,
  owner @{PROC}/[0-9]*/fd/3 r,

I didn't see it in your attached libvirt-qemu file either, so I am slightly confused. Updating that file will require a full shutdown of the guest with the profile unloaded on guest shutdown (use 'sudo aa-status' to see). If you do have the above, then that could be why you aren't seeing the issue today (though, like I said, I could not reproduce).

[Serge Hallyn (serge-hallyn)]

Quoting Jamie Strandboge (<email address hidden>):
> Serge, do you still have the following in your /etc/apparmor.d/abstractions/libvirt-qemu:
> /usr/lib/pt_chown ix,
> owner @{PROC}/[0-9]*/fd/ r,
> owner @{PROC}/[0-9]*/fd/3 r,

Right, I pulled those out since they weren't working anyway.

> I didn't see it in your attached libvirt-qemu file either, so I am
> slightly confused. Updating that file will require a full shutdown of
> the guest with the profile unloaded on guest shutdown (use 'sudo aa-
> status' to see). If you do have the above, then that could be why you
> aren't seeing the issue today (though, like I said, I could not
> reproduce).

When I added those lines, I then shut down the VMs, and did

 /etc/init.d/apparmor restart
 restart libvirt-bin

and then restarted the VMs. So pretty sure I was testing the
rules.

[Serge Hallyn (serge-hallyn)]

Fascinating, today the problem is back.

[Serge Hallyn (serge-hallyn)]

I chowned and chmoded /srv/libvirt-storage-pool-1 to be

serge@sergelap:~/ $ ls -ld /srv/libvirt-storage-pool-1/
drwxr-x--- 2 root kvm 4096 2010-09-03 09:45 /srv/libvirt-storage-pool-1/

and made sure to be in the kvm group, but this still did not suffice. The errors
in the log are as usual:

[ 2844.242158] type=1400 audit(1284123328.335:34): apparmor="DENIED" operation="open" parent=1006 profile="libvirt-4b49b0f2-18e7-ef59-f9c6-d37703a6ca21" name="/proc/1011/fd/" pid=1011 comm="kvm" requested_mask="r" denied_mask="r" fsuid=117 ouid=117
[ 2844.242322] type=1400 audit(1284123328.335:35): apparmor="DENIED" operation="exec" parent=1006 profile="libvirt-4b49b0f2-18e7-ef59-f9c6-d37703a6ca21" name="/usr/lib/pt_chown" pid=1011 comm="kvm" requested_mask="x" denied_mask="x" fsuid=117 ouid=0

I did an apt-get dist-upgrade yesterday, don't know if that's what re-caused the error.

I re-added the 3 lines to /etc/apparmor.d/abstractions/libvirt-qemu
and did 'sudo /etc/init.d/apparmor restart; sudo restart libvirt-bin', after which it still
failed but with the error:

[ 3056.875668] type=1400 audit(1284123541.145:53): apparmor="DENIED" operation="capable" parent=6063 profile="libvirt-4b49b0f2-18e7-ef59-f9c6-d37703a6ca21" pid=6065 comm="pt_chown" capability=3 capname="fowner"

It's not clear to me if there is an easy (and safe) way to hand cap_fowner to pt_chown there?

[Jamie Strandboge (jdstrand)]

We can create a child profile for pt_chown so only it would get cap_fowner. Can you try the following in /etc/apparmor.d/abstractions/libvirt-qemu:

  owner @{PROC}/[0-9]*/fd/ r,
  owner @{PROC}/[0-9]*/fd/3 r,
  /usr/lib/pt_chown cix -> libvirt_pt_chown,

  profile libvirt_pt_chown {
    capability fowner,
  }

[Serge Hallyn (serge-hallyn)]

Quoting Jamie Strandboge (<email address hidden>):
> We can create a child profile for pt_chown so only it would get
> cap_fowner. Can you try the following in /etc/apparmor.d/abstractions
> /libvirt-qemu:
>
> owner @{PROC}/[0-9]*/fd/ r,
> owner @{PROC}/[0-9]*/fd/3 r,
> /usr/lib/pt_chown cix -> libvirt_pt_chown,
>
> profile libvirt_pt_chown {
> capability fowner,
> }

I had rebooted (no choice, having to reboot frequently). This time,
even before adding this ruleset, I could start the hosts.

So either the recipe:

 /etc/init.d/apparmor restart
 restart libvirt-bin

does not suffice to clear out the rules, or this is a very funky
random bug that only happens sometimes. I'll try to get some time
dedicated to testing this this afternoon.

[Serge Hallyn (serge-hallyn)]

I've not been able to reproduce this since the ninth, so I'd like to mark
it invalid. Jamie, is that ok with you?

[Jamie Strandboge (jdstrand)]

I have never been able to reproduce. I've certainly known libvirt to right itself after a full reboot, so maybe something weird was going on. Feel free to re-open if you can reproduce.

[Mark A. Hershberger (hexmode)]

I just began running into this after upgrading to Maverick

[Cody A.W. Somerville (cody-somerville)]

I've ran into this issue twice now today. I can be creating VMs just fine and then go to create another one and it fails with this error. Rebooting fixed the issue the first time and I was able to create VMs again like normal but then for seemingly no reason I started getting the error again.

[Thomas Schweikle (tps)]

I see this error since today. Even stopping apparmor, then tearing down all profiles, trying to start a kvm host gives:

root@vh01:~# service apparmor stop
 * Clearing AppArmor profiles cache [ OK ]
All profile caches have been cleared, but no profiles have been unloaded.
Unloading profiles will leave already running processes permanently
unconfined, which can lead to unexpected situations.

To set a process to complain mode, use the command line tool
'aa-complain'. To really tear down all profiles, run the init script
with the 'teardown' option."
root@vh01:~# service apparmor teardown
 * Unloading AppArmor profiles [ OK ]
root@vh01:~# virsh start ns1
error: Failed to start domain ns1
error: internal error Process exited while reading console log output: chardev: opening backend "pty" failed

Looks like this is related to latest apparmor updates, but these do not fix the error.

[Thomas Schweikle (tps)]

After a few further test, I am quite sure:

It is a conflict between lxc/kvm (at least in my case). Could you please confirm kvm not allocating pty dynamicaly? As lxc not doing it dynamicaly? Raising conflicts if kvm-guests where started, after them lxc-guest are started, then kvm-guests are stoped , then started again, trying the next pty, but this being occupied by an lxc host?

[Thomas Schweikle (tps)]

Looks like it is fixed with libvirt 0.8.8. Unfortunately this package is only available from a testing ppa

[Serge Hallyn (serge-hallyn)]

@Thomas,

could you tell us which testing ppa version of kvm fixes it? Do you knwo which upstream commit fixes it? We should be able to push this fix back into maverick.

[Thomas Schweikle (tps)]

The only real fix is not to use lxc/kvm on one hardware in parallel. As long as you use *only* kvm/lxc you'll not see this error any more. This is because most lxc-tools do not use libvirtd for operations.

At least with version 0.8.8-1ubuntu6.5 (available from the mainline repositories) some other errors are fixed &mdash; this one is not.

[Jamie Strandboge (jdstrand)]

Based on Thomas' assessment, should the title of this bug be adjusted and the apparmor tag removed?

[Serge Hallyn (serge-hallyn)]

Quoting Jamie Strandboge (<email address hidden>):
> Based on Thomas' assessment, should the title of this bug be adjusted
> and the apparmor tag removed?

Since disabling apparmor works around the problem, I don't think so.

I'm going to have to install a maverick partition on a physical laptop to test
several bugs, and will try to reproduce and get to the bottom of this one then.

[Jamie Strandboge (jdstrand)]

Serge, but comment #25 by Thomas said he is having the problem even with AppArmor disabled...

[Serge Hallyn (serge-hallyn)]

Jamie,

sorry, I thought his latest comment mentioned that as a working workaround, but I must have seen it in the description.

So yes, removing the tag seems good.

[Andrea Corbellini (andrea.corbellini)]

I've just encountered this bug today for the first time. The symptoms are exactly the same: <serial> and <console> in the domain xml, apparmor="DENIED" messages in kern.log and a reboot fixed the problem.

I'd like to nominate this bug for Oneiric and Precise, however Launchpad is OOPSing.

[Thomas Schweikle (tps)]

The problem seems gone with libvirt-bin 0.9.2-4ubuntu15.1 (Ubuntu 11.10).

[Tom (teeks99)]

This bug seems to have slipped into libvirt-bin 0.9.2-4ubuntu15.2 for Ubuntu 11.10 :-(

[Serge Hallyn (serge-hallyn)]

@Andrea,

were you saying that you've seen this happen on Precise?

[Fjodor (sune-molgaard)]

Seeing this in Oneiric stock, as well as Oneiric with libvirt etc. from Precise.

Even tried ln -s /etc/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disabled to no avail.

Seems to focus on opening a fd and pt_chown'ing it:

Mar 19 16:03:51 jekaterina kernel: [ 2029.039478] type=1400 audit(1332169431.325:106): apparmor="DENIED" operation="open" parent=9225 profile="libvirt-61355106-f13f-4964-0054-72f8c8eeaf7e" name="/proc/9226/fd/" pid=9226 comm="kvm" requested_mask="r" denied_mask="r" fsuid=123 ouid=123
Mar 19 16:03:51 jekaterina kernel: [ 2029.039549] type=1400 audit(1332169431.325:107): apparmor="DENIED" operation="exec" parent=9225 profile="libvirt-61355106-f13f-4964-0054-72f8c8eeaf7e" name="/usr/lib/pt_chown" pid=9226 comm="kvm" requested_mask="x" denied_mask="x" fsuid=123 ouid=0

Remedy would probably be massaging apparmor, but I lack the fu to do so :-$

[Mandar Vaze (mandarvaze)]

I'm facing similar problem in openstack/nova-compute context
We are using libvirt as default KVM to spawn the instances.

I faced the problem ONLY when the directory where it creates the console.log was nfs mounted (Not local disk path)
Indeed I too have <serial> in the XML file -which is where the problem occurs.

But when using local file system, everything works OK.

[Hanno Foest (hurga-launch)]

Having the same issue in Ubuntu 11.10. What I don't get is that I still see apparmor="DENIED" errors in my kern.log even after doing /etc/init.d/apparmor restart ; /etc/init.d/apparmor teardown

Maybe I'm missing something about how apparmor works, but I don't have the time to find out right now. So I disabled apparmor with "apparmor=0" on the kernel command line and now I'm able to use virt-install.

Not sure why this bug is listed as "invalid" though. It looks very real to me.

[Serge Hallyn (serge-hallyn)]

Hanno,

thanks for that info.

So booting with 'apparmor=0' stops the failure for you. Do you have the console.log location as nfs mounted as Mandar did?

Can either Hanno or Mandar confirm that you have seen this on 12.04 precise?

[Hanno Foest (hurga-launch)]

Serge,

sorry for the late answer, I wasn't subscribed to this bug before, I'll answer more quickly in the future.

As for NFS - no NFS on this machine, and no console.log either. It seems I was confusingly brief in my comment, I wasn't replying to Mandar really, but to the original bug report.

Adding some context... Ubuntu 11.10, running Xubuntu and disk encryption, quite standard otherwise.

I encountered this bug when trying to install windows using the command

virt-install --name winxp --ram 1024 --vcpus=1 --disk path=/dev/mapper/wdgreen-win1 --os-type=windows --os-variant=winxp --cdrom=/media/dumptemp/winxp_orig_sp2.img

which failed very soon. Don't have the original error message anymore, but it was the "chardev: opening backend "pty" failed" one as far as I remember.

I tried the things suggested in the comments of this bug with apparmor, but was unable to get rid of apparmor "DENIED" messages referring to libvirt. I was reluctant to simply reboot because according to some comments this makes the problem disappear (temporarily) without any other action, and I prefer to fix it for good. Running out of time, I finally booted with 'apparmor=0' which helped.

I'll reboot without 'apparmor=0' to see if the problem reappears. I'm happy to try any other suggestions you might have to get rid of the apparmor error messages in case the problem reappears, now that I have some time to experiment.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[JC Hulce (soaringsky)]

This bug affects Ubuntu 10.10, Maverick Meerkat. Maverick has reached end-of-life and is no longer supported, so I am closing the bug task for Maverick. Please upgrade to a newer version of Ubuntu.
More information here: https://lists.ubuntu.com/archives/ubuntu-announce/2012-April/000158.html

[Thomas Schweikle (tps)]

Not only Maverik, Ubuntu 10.10, also later versions, as 11.04, 11.10, and partly 12.04.
It is a variety of things triggering this bug:
- Apparmor
- Kernel-Version, kernel-release (maybe it is triggered by compiling modules in different ways)
- libvirtd-version
- maybe even filesystem dependent

I did see it shortly on Ubuntu 12.04 poping up again. After carefully looking at apparmor files, libvirtd. I could not find why it was again there. After upgrading to a plain vanilla kernel (3.2.16) it was gone again.

[krag (krag)]

I also had this behaviour on 12.10 (upgraded from 12.04)

virt-install was repeatedly not working
sudo virt-install --name=lin01 --ram 1024 --disk path=/var/lib/libvirt/images/disk1.img,format=raw,bus=virtio,cache=none,size=2 --disk path=/var/lib/libvirt/images/disk2.img,format=raw,bus=virtio,cache=none,size=1 --network network=default,model=virtio --nographics --accelerate --os-type=linux --os-variant=debiansqueeze -x 'DEBIAN_FRONTEND=text console=ttyS0,115200n8' --location=http://ftp.debian.org/debian/dists/squeeze/main/installer-amd64/

same errors as above

I took @jdstrand's suggestion from https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/632696/comments/19
and came up with the following (I am new to apparmor so I do not know all implications of this change)

--- libvirt-qemu 2013-02-10 00:00:04.909238467 +0100
+++ /etc/apparmor.d/abstractions/libvirt-qemu 2013-02-09 23:41:53.241265822 +0100
@@ -126,3 +126,17 @@

   # for rbd
   /etc/ceph/ceph.conf r,
+
+
+ owner @{PROC}/[0-9]*/fd/ r,
+ owner @{PROC}/[0-9]*/fd/3 r,
+ /usr/lib/pt_chown rCx -> libvirt_pt_chown,
+
+ profile libvirt_pt_chown {
+ #include <abstractions/base>
+ #include <abstractions/consoles>
+ capability fowner,
+ capability chown,
+ /etc/nsswitch.conf r,
+ /etc/group r,
+ }

[Ben Stanley (ben-stanley)]

I had a similar problem, but the cause turned out to be different for me.

I had changed the GID of group tty from 5 to 11. I later found out that this contravenes the Ubuntu standard GID policy.

The symptom was similar to the above
chardev: opening backend "pty" failed: Exec format error

It turns out that "Exec format error" is the string given by errno=ENOEXEC.

After some investigation of my problem, it turns out that (in my case) the failure was occurring at
qemu-char.c:997 if (openpty(&master_fd, &slave_fd, pty_name, NULL, NULL) < 0) {

The call to openpty was failing because the directory /dev/pts had a gid of 11 instead of a gid of 5.
The error was issued because the directory /dev/pts did not have the appropriate exec permission to be able to create a new device file within it.

I changed around my GIDs to match the standard values, and that was enough to fix the problem (for me).

Note that /dev/pts is a MOUNTED filesystem of type devpts. The gid of the mount can be found by typing mount.
In my case, kvm fails when set as follows
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=11,mode=0620)
GOOD: kvm works:
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)

I acknowledge that this problem is a bit different from the subject of this bug, but this is the closest bug I found to my problem when I initially came across it.

[Rolf Leggewie (r0lf)]

oneiric has seen the end of its life and is no longer receiving any updates. Marking the oneiric task for this ticket as "Won't Fix".

[Serge Hallyn (serge-hallyn)]

Marking this as a dup of #1342083 (because this bug is probably both valid, and due to the same cause).