[Bug 1637601] Re: UbuntuKVM: migration using NFS mount fails #190

[ChristianEhrhardt]

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
Foundations Bugs, 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 at 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 at tiny:~# virsh list --all
      Id Name State

      12 microg5 running

   * Check whether I/O errors are seen in that guest:

      root at 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