Issue did no more show up on two retries of the test, also what showed up was totally unrelated to the upload we made. That said should be safe to migrate now.
-- 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 Status in base-passwd source package in Xenial: Won't Fix Status in libvirt source package in Xenial: Fix Committed 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 ... * 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. <...> 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
