[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