← Back to team overview

group.of.nepali.translators team mailing list archive

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

 

** Also affects: base-passwd (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Changed in: base-passwd (Ubuntu Xenial)
       Status: New => Won't Fix

** Changed in: libvirt (Ubuntu Xenial)
       Status: New => Triaged

** Changed in: libvirt (Ubuntu Xenial)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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:
  Triaged

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