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

Corey Bryant 2011535 at bugs.launchpad.net
Wed Mar 15 16:59:50 UTC 2023


** Description changed:

+ [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.
+ 
+ == 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.

-- 
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:
  Triaged
Status in nova source package in Kinetic:
  Triaged
Status in nova source package in Lunar:
  Triaged

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.

  == 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




More information about the Ubuntu-openstack-bugs mailing list