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

Mauricio Faria de Oliveira mauricfo at linux.vnet.ibm.com
Wed Jan 18 12:57:49 UTC 2017


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 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 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 at micro:~# virsh migrate --live --domain microg5 qemu+ssh://tiny/system
-                  --verbose --undefinesource --persistent --timeout 60
-    Migration: [100 %]
+    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
+  * Check whether the guest is now listed in the destination KVM host
  system:
  
-     root at tiny:~# virsh list --all
-     Id Name State
+     root at 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 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 starting block 1135541)
+     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 ...
  
+ [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
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

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 ...

  [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



More information about the foundations-bugs mailing list