[Pkg-libvirt-maintainers] Bug#848314: Bug#848314: Further fix for discussion in the scope of smoke-qemu-session

[Christian Ehrhardt]

On Mon, Dec 19, 2016 at 9:29 AM, Christian Ehrhardt <
christian.ehrhardt at canonical.com> wrote:

> I'm now rebasing to integrate on top of your last 5 commits of Friday and
> check again.
> But I assume I'll hit the same.
> Qemu is not yet merged to latest yet, so still at 2.6.1 there - which is
> old, but not terribly old.
>
> Tests take a while every time but I hope to come back with a solution
> later today.
>

Hi again,
so on retesting the following issues are left for me:

TL;DR:
- make vmlinuz/initrd accessible
- make sure vmlinuz/initrd are on the system
- do not use kvm when not needed (qemu instead)


###1 Permissions vs qemu://session
If I run non root I run into all sorts of trouble due to
"Could not access KVM kernel module: Permission denied"

Maybe this is different due to the way Ubuntu does authenticate (via groups
kvm / libvirtd) and Debian via policykit IIRC.
But as our former discussion outlined root+qemu:///session is more or less
= qemu://system - so not a huge reason to go there :-/.

For the time being I fixed that up locally and went on - solution came
later, see #2.


###2 After passing the first hurdle I still crash into:
"host doesn't support requested feature: CPUID.80000001H:ECX.svm" and due
to that "qemu: could not load kernel '/vmlinuz': Permission denied"

That is just as far as I got when I switched from kvm to qemu-system with
TCG :-/
Which made me aware that the cpu feature really just be a warning (until
failing later), but the real issue obviously is the permission denied.
Seems I looked at the wrong thing before :-)

Since I now thought deeper into the first issue that is rather clear:
With permissions of the user due to qemu://session the following file is
hard to access:
lrwxrwxrwx 1 root root 29 Dec 19 11:22 /vmlinuz ->
boot/vmlinuz-4.9.0-11-generic
-rw------- 1 root root 7452448 Dec 12 14:40 /boot/vmlinuz-4.9.0-11-generic

That is just the same on Debian, so I'd expect you to hit that as well.
lrwxrwxrwx 1 root root 26 Dec 19 11:03 /vmlinuz ->
boot/vmlinuz-4.8.0-2-amd64
-rw-r--r-- 1 root root 4153384 Dec  3 15:17 /boot/vmlinuz-4.8.0-2-amd64

Since this is a test env anyway we can mess with it - so why not just
changing the perm to allow access.
Messing around means set isolation level to at least ioslation-container
which it already is.



###3 we can't rely on /vmlinuz and initrd being there - it might not e.g.
in containers

Need to add a proper dependency to have /vmlinuz around.
Sounds trivial but we don't share a meta package for the kernel.
Since the test is amd64 only I picked the Debian meta package for amd64 and
the general Ubuntu kernel meta package.
That should work well in both worlds, and never fail unless we drop the
x86_64 if at the beginning of smoke-qemu-session.


###4 no need for KVM and impossible in some test environments
We discussed that before, the switch from kvm to qemu should fit the needs
for the tests and helps to avoid the following issues in some environments:

error: internal error: process exited while connecting to monitor: Could
not access KVM kernel module: Permission denied
failed to initialize KVM: Permission denied

Fixes attached as patch.

With that in place smoke-qemu-session is passing now again.
After lunch I'll look at the remaining lxc fails (different debbug) and
cross arch tests after that.



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-libvirt-maintainers/attachments/20161219/0fc7092e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: further-smoke-fixes.patch
Type: text/x-patch
Size: 1761 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-libvirt-maintainers/attachments/20161219/0fc7092e/attachment.bin>