Setup:
- Xenial host
- lxd guests with Trusty, Xenial, ...
- add a LXD profile to allow kvm [3] (inspired by stgraber)
- spawn KVM guests in the LXD guests using the different distro release versions
- guests are based on the uvtool default template which has a serial console [4]
Issue:
- guest starting with serial device gets blocked by apparmor and killed on creation
- This affects at least ppc64el and x86 (s390x has no serial concept that would match)
- This appeared in our usual checks on -proposed releases so maybe we can/should stop something?
Last good was "Apr 5, 2017 10:40:50 AM" first bad one "Apr 8, 2017 5:11:22 AM"
Background:
We use this setup for a while and it was working without a change on our end.
Also the fact that it still works in the Trusty LXD makes it somewhat suspicious.
Therefore I'd assume an SRUed change in LXD/Kernel/Apparmor might be the reason and open this bug to get your opinion on it.
You can look into [1] and search for uvt-kvm create in it.
Qemu-log:
2017-04-20T06:55:53.139450Z qemu-system-ppc64: -chardev pty,id=charserial0: Failed to create PTY: No such file or directory
There was a similar issue on qmeu namespacing (which we don't use on any of these releases) [2].
While we surely don't have the "same" issue the debugging on the namespacing might be worth as it could be related.
Workaround for now:
- drop serial section from guest xml
Setup:
- Xenial host
- lxd guests with Trusty, Xenial, ...
- add a LXD profile to allow kvm [3] (inspired by stgraber)
- spawn KVM guests in the LXD guests using the different distro release versions
- guests are based on the uvtool default template which has a serial console [4]
Issue:
- guest starting with serial device gets blocked by apparmor and killed on creation
- This affects at least ppc64el and x86 (s390x has no serial concept that would match)
- This appeared in our usual checks on -proposed releases so maybe we can/should stop something?
Last good was "Apr 5, 2017 10:40:50 AM" first bad one "Apr 8, 2017 5:11:22 AM"
Background:
We use this setup for a while and it was working without a change on our end.
Also the fact that it still works in the Trusty LXD makes it somewhat suspicious.
Therefore I'd assume an SRUed change in LXD/Kernel/Apparmor might be the reason and open this bug to get your opinion on it.
You can look into [1] and search for uvt-kvm create in it.
Deny in dmesg: 3.134:4520) : apparmor="DENIED" operation="open" namespace= "root// lxd-testkvm- xenial- from_<var- lib-lxd> " profile= "libvirt- 668e21f1- fa55-4a30- b325-0ed5cfd55e 5b" name="/ dev/pts/ ptmx" pid=27162 comm="qemu- system- ppc" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
[652759.606218] audit: type=1400 audit(149267135
Qemu-log: 20T06:55: 53.139450Z qemu-system-ppc64: -chardev pty,id=charserial0: Failed to create PTY: No such file or directory
2017-04-
There was a similar issue on qmeu namespacing (which we don't use on any of these releases) [2].
While we surely don't have the "same" issue the debugging on the namespacing might be worth as it could be related.
Workaround for now:
- drop serial section from guest xml
[1]: https:/ /jenkins. ubuntu. com/server/ view/Virt/ job/virt- migration- cross-release- amd64/78/ consoleFull /bugzilla. redhat. com/show_ bug.cgi? id=1421036 /git.launchpad. net/~ubuntu- server/ ubuntu/ +source/ qemu-migration- test/tree/ kvm_profile. yaml /libvirt. org/formatdomai n.html# elementsCharPTY
[2]: https:/
[3]: https:/
[4]: https:/