Hi Christian, Here's the patch for libvirt in Xenial. It's the very minimal changes required from Zesty/Debian in order to set the UID (and document the change in the NEWS file). I didn't backport the debconf warning stuff as it's not essentially required. Hopefully this is simple/conservative enough for the SRU to occur more safely. :)
I'll now add the SRU template and testing with this patch. ** Patch added: "xenial_libvirt_uid_v4.debdiff" https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1637601/+attachment/4805811/+files/xenial_libvirt_uidgid_v4.debdiff ** Description changed: <...> - Please see comments for the problem description, and summary of - originally bridged comments in the description. + Please see comment #8 for the problem description, and summary of + originally bridged comments in the description in later comments. Sorry about the inconvenience. <...> ** Description changed: + + [Impact] + + * Users performing live migration of guests with image files + shared over NFS between the source and target host systems + may experience I/O errors in the guests if user id of the + libvirt-qemu user differs between the host systems, due to + permission errors when accessing the image files. + + * The 16.04 LTS is an important stream for KVM (at least on + Power), and guest live migration over NFS is an important + feature on it. + + * The proposed fix (a minimal backport from what is applied + on Zesty/Debian, so to be very conservative for the LTS) + simply tries to use the reserved uid for the libvirt-qemu + user on new installations (when the user is created) if + the reserved uid is not taken by another user (no failures + occur if the libvirt-qemu user already exists or the uid + is taken.) + + [Test Case] + + * Setup 2x systems with Ubuntu 16.04 LTS as KVM hosts (e.g., micro and tiny) + (check whether the libvirt-qemu uid differs between them; + e.g. # id libvirt-qemu ) + + * Create a guest in the source KVM host system (e.g, microg5) + + * Live migrate the guest to the destination KVM host system (e.g., + tiny) + + root@micro:~# virsh migrate --live --domain microg5 qemu+ssh://tiny/system + --verbose --undefinesource --persistent --timeout 60 + Migration: [100 %] + + * Check whether the guest is now listed in the destination KVM host + system: + + root@tiny:~# virsh list --all + Id Name State + + 12 microg5 running + + * Check whether I/O errors are seen in that guest: + + root@microg5:~# dmesg + ... + [ 60.818955] blk_update_request: I/O error, dev vdc, sector 96749232 + [ 60.819113] Aborting journal on device vdc2-8. + [ 60.820121] blk_update_request: I/O error, dev vdc, sector 9084320 + [ 60.820643] EXT4-fs warning (device vdc2): ext4_end_bio:329: I/O error + -5 writing to inode 393279 (offset 0 size 0 starting block 1135541) + + + [Regression Potential] + + * On installations in which the libvirt-qemu user does not exist + (e.g., first time installation of libvirt-bin) its assigned uid + might be different from what the user previously expected, since + now it's assigned a number from the reserved range. + + * Overall, the fix is very conservative (the uid assignment only + happens in case: 1) the libvirt-qemu user is being created, and + 2) if the desired uid is not taken by another user, e.g. LDAP). + + [Other Info] + + * None at this time. + + <...> Please see comment #8 for the problem description, and summary of originally bridged comments in the description in later comments. Sorry about the inconvenience. <...> ** Description changed: + [Impact] - [Impact] + * Users performing live migration of guests with image files + shared over NFS between the source and target host systems + may experience I/O errors in the guests if user id of the + libvirt-qemu user differs between the host systems, due to + permission errors when accessing the image files. - * Users performing live migration of guests with image files - shared over NFS between the source and target host systems - may experience I/O errors in the guests if user id of the - libvirt-qemu user differs between the host systems, due to - permission errors when accessing the image files. + * The 16.04 LTS is an important stream for KVM (at least on + Power), and guest live migration over NFS is an important + feature on it. - * The 16.04 LTS is an important stream for KVM (at least on - Power), and guest live migration over NFS is an important - feature on it. - - * The proposed fix (a minimal backport from what is applied - on Zesty/Debian, so to be very conservative for the LTS) - simply tries to use the reserved uid for the libvirt-qemu - user on new installations (when the user is created) if - the reserved uid is not taken by another user (no failures - occur if the libvirt-qemu user already exists or the uid - is taken.) + * The proposed fix (a minimal backport from what is applied + on Zesty/Debian, so to be very conservative for the LTS) + simply tries to use the reserved uid for the libvirt-qemu + user on new installations (when the user is created) if + the reserved uid is not taken by another user (no failures + occur if the libvirt-qemu user already exists or the uid + is taken.) [Test Case] - * Setup 2x systems with Ubuntu 16.04 LTS as KVM hosts (e.g., micro and tiny) - (check whether the libvirt-qemu uid differs between them; - e.g. # id libvirt-qemu ) + * Setup 2x systems with Ubuntu 16.04 LTS as KVM hosts (e.g., micro and tiny) + (check whether the libvirt-qemu uid differs between them; + e.g. # id libvirt-qemu ) - * Create a guest in the source KVM host system (e.g, microg5) + * Create a guest in the source KVM host system (e.g, microg5) - * Live migrate the guest to the destination KVM host system (e.g., + * Live migrate the guest to the destination KVM host system (e.g., tiny) - root@micro:~# virsh migrate --live --domain microg5 qemu+ssh://tiny/system - --verbose --undefinesource --persistent --timeout 60 - Migration: [100 %] + root@micro:~# virsh migrate --live --domain microg5 qemu+ssh://tiny/system + --verbose --undefinesource --persistent --timeout 60 + Migration: [100 %] - * Check whether the guest is now listed in the destination KVM host + * Check whether the guest is now listed in the destination KVM host system: - root@tiny:~# virsh list --all - Id Name State + root@tiny:~# virsh list --all + Id Name State - 12 microg5 running + 12 microg5 running - * Check whether I/O errors are seen in that guest: + * Check whether I/O errors are seen in that guest: - root@microg5:~# dmesg - ... - [ 60.818955] blk_update_request: I/O error, dev vdc, sector 96749232 - [ 60.819113] Aborting journal on device vdc2-8. - [ 60.820121] blk_update_request: I/O error, dev vdc, sector 9084320 - [ 60.820643] EXT4-fs warning (device vdc2): ext4_end_bio:329: I/O error - -5 writing to inode 393279 (offset 0 size 0 starting block 1135541) + root@microg5:~# dmesg + ... + [ 60.818955] blk_update_request: I/O error, dev vdc, sector 96749232 + [ 60.819113] Aborting journal on device vdc2-8. + [ 60.820121] blk_update_request: I/O error, dev vdc, sector 9084320 + [ 60.820643] EXT4-fs warning (device vdc2): ext4_end_bio:329: I/O error + -5 writing to inode 393279 (offset 0 size 0 ... + [Regression Potential] - [Regression Potential] + * On installations in which the libvirt-qemu user does not exist + (e.g., first time installation of libvirt-bin) its assigned uid + might be different from what the user previously expected, since + now it's assigned a number from the reserved range. - * On installations in which the libvirt-qemu user does not exist - (e.g., first time installation of libvirt-bin) its assigned uid - might be different from what the user previously expected, since - now it's assigned a number from the reserved range. - - * Overall, the fix is very conservative (the uid assignment only - happens in case: 1) the libvirt-qemu user is being created, and - 2) if the desired uid is not taken by another user, e.g. LDAP). + * Overall, the fix is very conservative (the uid assignment only + happens in case: 1) the libvirt-qemu user is being created, and + 2) if the desired uid is not taken by another user, e.g. LDAP). [Other Info] - - * None at this time. + * None at this time. <...> Please see comment #8 for the problem description, and summary of originally bridged comments in the description in later comments. Sorry about the inconvenience. <...> -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to base-passwd in Ubuntu. https://bugs.launchpad.net/bugs/1637601 Title: UbuntuKVM: migration using NFS mount fails #190 Status in libvirt: Fix Released Status in base-passwd package in Ubuntu: Fix Released Status in libvirt package in Ubuntu: Fix Released Bug description: [Impact] * Users performing live migration of guests with image files shared over NFS between the source and target host systems may experience I/O errors in the guests if user id of the libvirt-qemu user differs between the host systems, due to permission errors when accessing the image files. * The 16.04 LTS is an important stream for KVM (at least on Power), and guest live migration over NFS is an important feature on it. * The proposed fix (a minimal backport from what is applied on Zesty/Debian, so to be very conservative for the LTS) simply tries to use the reserved uid for the libvirt-qemu user on new installations (when the user is created) if the reserved uid is not taken by another user (no failures occur if the libvirt-qemu user already exists or the uid is taken.) [Test Case] * Setup 2x systems with Ubuntu 16.04 LTS as KVM hosts (e.g., micro and tiny) (check whether the libvirt-qemu uid differs between them; e.g. # id libvirt-qemu ) * Create a guest in the source KVM host system (e.g, microg5) * Live migrate the guest to the destination KVM host system (e.g., tiny) root@micro:~# virsh migrate --live --domain microg5 qemu+ssh://tiny/system --verbose --undefinesource --persistent --timeout 60 Migration: [100 %] * Check whether the guest is now listed in the destination KVM host system: root@tiny:~# virsh list --all Id Name State 12 microg5 running * Check whether I/O errors are seen in that guest: root@microg5:~# dmesg ... [ 60.818955] blk_update_request: I/O error, dev vdc, sector 96749232 [ 60.819113] Aborting journal on device vdc2-8. [ 60.820121] blk_update_request: I/O error, dev vdc, sector 9084320 [ 60.820643] EXT4-fs warning (device vdc2): ext4_end_bio:329: I/O error -5 writing to inode 393279 (offset 0 size 0 ... [Regression Potential] * On installations in which the libvirt-qemu user does not exist (e.g., first time installation of libvirt-bin) its assigned uid might be different from what the user previously expected, since now it's assigned a number from the reserved range. * Overall, the fix is very conservative (the uid assignment only happens in case: 1) the libvirt-qemu user is being created, and 2) if the desired uid is not taken by another user, e.g. LDAP). [Other Info] * None at this time. <...> Please see comment #8 for the problem description, and summary of originally bridged comments in the description in later comments. Sorry about the inconvenience. <...> To manage notifications about this bug go to: https://bugs.launchpad.net/libvirt/+bug/1637601/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
