[Bug 2011535] Re: nova can't access instance image file because the file is now chowned to the kvm group by default

[Takashi Kajinami]

Thanks. The fix sounds quite reasonable to me.

If you can backport the fix to UCA zed then that would be nice.
This is what we are using in the jobs in Puppet OpenStack project and
where I found the issue initially.

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to nova in Ubuntu.
https://bugs.launchpad.net/bugs/2011535

Title:
  nova can't access instance image file because the file is now chowned
  to the kvm group by default

Status in nova package in Ubuntu:
  Fix Released
Status in nova source package in Kinetic:
  Triaged
Status in nova source package in Lunar:
  Fix Released

Bug description:
  [Impact]
  This affects the nova package for kinetic and lunar. It is a side-effect of the changes made in https://bugs.launchpad.net/charm-nova-compute/+bug/1967956, specifically (1) and (3) described in https://bugs.launchpad.net/charm-nova-compute/+bug/1967956/comments/10. We tightened the mode of directories under /var/lib/nova from 755 to 750, and the mode of files under /var/lib/nova from 644 to 640. As a result, adding nova to the kvm group was required for nova to be able to access vm disks. We did that for nova-compute-kvm package but failed to do so for the nova-compute-qemu package.

  == original bug description ==

  It seems libvirt package in Ubuntu 22.04 uses the kvm group instead of the libvirt-qemu group when launching a qemu process.
  Because of this change and the default behavior of libvirt which makes all image files chowned by the group/user to run qemu process, the instance files are owned by the kvm group, instead of the libvirt-qemu group.

  However currently the nova user is still added to the libvirt-qemu
  group instead of the kvm group.

  Because of this inconsistency nova can't access to instance image once
  the files are chowned to the kvm group.

  nova 3:26.1.0-0ubuntu1~cloud0
  libvirt 8.0.0-1ubuntu7.4

  I've found the problem in puppet jobs. (example https://zuul.opendev.org/t/openstack/build/d6f2fb2e92ad4ece86bcd3d8793bf920 )
  Example error in nova can be found here: https://2e4f6457af6d4bb29c73-cc818d493c2a52ef4d37701157d67702.ssl.cf2.rackcdn.com/877214/2/check/puppet-openstack-integration-7-scenario002-tempest-ubuntu-jammy/d6f2fb2/logs/nova/nova-compute.txt

  I've tested adding the nova user to the kvm group and confirmed this fixes the error.
  https://review.opendev.org/c/openstack/puppet-openstack-integration/+/877338

  [Test Case]
  At the most basic level we can install the nova-compute-qemu package on a machine, and install the nova-compute-kvm package on another machine, and compare the directory and file modes under the /var/lib/nova/ tree.

  I'm sure Takashi will be able to give feedback on the fix as well.

  [Regression Potential]
  This is fixing a regression. We already add the nova user to the kvm group as part of the nova-compute-kvm postinst script, and this fix is doing the same for the nova-compute-qemu postinst script. I don't foresee any new regressions as a result of this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nova/+bug/2011535/+subscriptions