Ask Your Question
0

Console.log permission error in libvirt after changing instances_path in nova.conf

asked 2018-03-02 12:04:42 -0600

tracks345 gravatar image

Running Openstack Newton on RHEL

I’ve seen a bug on github that resembles this behavior, but it has a different scenario for occurring and it’s not this exact behavior.

Issue: After changing the instances_path variable in nova.conf, instances become corrupted by libvirtd when they are restarted.

When you try to restart any instance it fails with message that it can’t access the console.log. The file remains owned by root.root. If the instance is in the default location, the console.log file (which is owned by root after suspend) is switched by libvirtd to be owned by qemu or sometimes nova.

The instances can be deployed from Glance just fine and I can bring them up, pause and resume without issue.

The error message in horizon matches the one in nova-compute.log: libvirtError: Unable to open file: /home/instances/ a3…e1/console.log: Permission denied

Based on some other questions and answers I tried setting set the qemu.conf to: user = "nova" group = "nova" dynamic_ownership = 1 I also tired “qemu” instead of “nova” and got the same result. We don’t need qemu in our setup.

$ systemctl status libvirtd returns no problems or errors. It’s just humming along screwing up the file permissions. Turned on libvirtd debug logging and I don’t see anything odd. The only error in the libvirt logs is this: Unable to open file: /home/instances/a3…e1/console.log: Permission denied

So I’m wondering if this a libvirt issue, a selinux issue or configuration issue. Checked the directory permissions on /home/instances and they match the default path for instances.

Any help would be greatly appreciated.

edit retag flag offensive close merge delete

1 answer

Sort by » oldest newest most voted
1

answered 2018-03-02 15:50:37 -0600

I experienced the same behavior on Ubuntu, not RHEL, but maybe the solution will help solve your case as well.

The problem was not the file modes or permissions - it was AppArmor, the policy enforcing "engine" similar to SELinux on Red Hat-based systems. So if you changed your instances_path, you'd automatically have to add an entry to AppArmor's policy file, basically stating that "libvirt can work with files under this directory".

In my case, the AppArmor rules file is located at /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper and you have to look for /var/lib/nova/instances-like lines. Then you had to add your instances_path directory pattern and reload.

I'm sorry I can't provide you with the exact steps for SELinux, but I think the same principle applies.

edit flag offensive delete link more

Comments

Thanks I'm digging into selinux.

tracks345 gravatar imagetracks345 ( 2018-03-12 08:09:16 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2018-03-02 12:04:42 -0600

Seen: 607 times

Last updated: Mar 02 '18