Sure, I added that the simplified test is just the user check after fresh install. I can only do as fast as possible - not direct effect to the point release by me. I can ask a few other people thou to advise on it after I put it into the queue.
And thanks for the paperwork on the SRU - if the requester does that it puts some extra weight by confirming it is not just something I want :-) Reviewing the change now (but I don't expect major surprises). ** 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 ... + * Simplified test of the wanted effect: + - install libvirt on a system that didn't have it before and check the + id of libvirt-qemu + $ id libvirt-qemu + [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. <...> -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1637601 Title: UbuntuKVM: migration using NFS mount fails #190 To manage notifications about this bug go to: https://bugs.launchpad.net/libvirt/+bug/1637601/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
