| 2023-03-14 08:40:21 |
Takashi Kajinami |
bug |
|
|
added bug |
| 2023-03-14 08:40:51 |
Takashi Kajinami |
summary |
nova can't access instance data because now the file is chowned to kvm group |
nova can't access instance image file because the file is now chowned to the kvm group by default |
|
| 2023-03-15 16:47:09 |
Corey Bryant |
nova (Ubuntu): status |
New |
Triaged |
|
| 2023-03-15 16:47:11 |
Corey Bryant |
nova (Ubuntu): importance |
Undecided |
Critical |
|
| 2023-03-15 16:47:17 |
Corey Bryant |
nominated for series |
|
Ubuntu Lunar |
|
| 2023-03-15 16:47:17 |
Corey Bryant |
bug task added |
|
nova (Ubuntu Lunar) |
|
| 2023-03-15 16:47:17 |
Corey Bryant |
nominated for series |
|
Ubuntu Kinetic |
|
| 2023-03-15 16:47:17 |
Corey Bryant |
bug task added |
|
nova (Ubuntu Kinetic) |
|
| 2023-03-15 16:47:23 |
Corey Bryant |
nova (Ubuntu Kinetic): status |
New |
Triaged |
|
| 2023-03-15 16:47:25 |
Corey Bryant |
nova (Ubuntu Kinetic): importance |
Undecided |
Critical |
|
| 2023-03-15 16:59:50 |
Corey Bryant |
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 |
[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. |
|
| 2023-03-15 17:05:42 |
Corey Bryant |
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. |
[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. |
|
| 2023-03-15 23:07:42 |
Launchpad Janitor |
nova (Ubuntu Lunar): status |
Triaged |
Fix Released |
|
| 2023-03-17 20:07:24 |
Steve Langasek |
nova (Ubuntu Kinetic): status |
Triaged |
Fix Committed |
|
| 2023-03-17 20:07:26 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2023-03-17 20:07:27 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2023-03-17 20:07:30 |
Steve Langasek |
tags |
|
verification-needed verification-needed-kinetic |
|
| 2023-04-10 14:54:18 |
Corey Bryant |
bug task added |
|
cloud-archive |
|
| 2023-04-10 14:54:27 |
Corey Bryant |
nominated for series |
|
cloud-archive/zed |
|
| 2023-04-10 14:54:27 |
Corey Bryant |
bug task added |
|
cloud-archive/zed |
|
| 2023-04-10 14:54:33 |
Corey Bryant |
cloud-archive: status |
New |
Fix Released |
|
| 2023-04-10 14:54:38 |
Corey Bryant |
cloud-archive/zed: status |
New |
Fix Committed |
|
| 2023-04-10 14:54:41 |
Corey Bryant |
cloud-archive/zed: importance |
Undecided |
Critical |
|
| 2023-04-10 14:55:35 |
Corey Bryant |
tags |
verification-needed verification-needed-kinetic |
verification-done verification-done-kinetic verification-zed-done |
|
| 2023-04-11 14:47:16 |
Corey Bryant |
cloud-archive/zed: status |
Fix Committed |
Fix Released |
|
| 2023-04-11 21:24:19 |
Launchpad Janitor |
nova (Ubuntu Kinetic): status |
Fix Committed |
Fix Released |
|
