** Description changed:

  [Impact]
  
-  * The impact is log flooding with warnings for every guest start/stop
+  * The impact is log flooding with warnings for every guest start/stop
  
-  * Maybe the impact also has in some cases worse effects due to the bad RC 
-    of the function e.g. blocking other actions - that could be happening in 
-    the CI run it was reported with.
+  * Maybe the impact also has in some cases worse effects due to the bad RC
+    of the function e.g. blocking other actions - that could be happening in
+    the CI run it was reported with.
  
-  * Upstream has added a fix and this is backporting it (applies cleanly as-
-    is)
+  * Upstream has added a fix that fixes the warning.
+    We worked on and upstreamed another fix that also corrects the internal 
+    error we were seeing.
+    Both are easily backportd and apply as-is.
  
  [Test Case]
  
-  * Run this in one console
-      $ journalctl -f -u libvirtd | grep -i meta
-  * and in the other spawn a guest (e.g. via uvtool-libvirt or any other) 
-    and shut it down. Shutdown will pass qemuBlockRemoveImageMetadata -> 
-    qemuSecurityMoveImageMetadata ... which will trigger the issue.
+  * Run this in one console
+      $ journalctl -f -u libvirtd | grep -i meta
+  * In the other console spawn a guest (e.g. via uvtool-libvirt or
+    any other and shut it down. Shutdown will pass:
+     qemuBlockRemoveImageMetadata ->
+       qemuSecurityMoveImageMetadata 
+    ... which will trigger the issue.
  
-    Without a fix the log will all the time get an entry like:
+    Without a fix the log will all the time get an entry like:
  
  Mai 20 07:10:12 Keschdeichel libvirtd[2638]: this function is not supported 
by the connection driver: virSecurityManagerMoveImageMetadata
  Mai 20 07:10:12 Keschdeichel libvirtd[2638]: internal error: child reported 
(status=125): this function is not supported by the connection driver: 
virSecurityManagerMoveImageMetadata
  Mai 20 07:10:12 Keschdeichel libvirtd[2638]: Unable to remove disk metadata 
on vm focal from /var/lib/uvtool/libvirt/images/focal.qcow (disk target vda)
  Mai 20 07:10:12 Keschdeichel libvirtd[2638]: this function is not supported 
by the connection driver: virSecurityManagerMoveImageMetadata
  Mai 20 07:10:12 Keschdeichel libvirtd[2638]: internal error: child reported 
(status=125): this function is not supported by the connection driver: 
virSecurityManagerMoveImageMetadata
  Mai 20 07:10:12 Keschdeichel libvirtd[2638]: Unable to remove disk metadata 
on vm focal from 
/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MjAuMDQ6YW1kNjQgMjAyMDAzMjk=
 (disk target vda)
  Mai 20 07:10:12 Keschdeichel libvirtd[2638]: this function is not supported 
by the connection driver: virSecurityManagerMoveImageMetadata
  Mai 20 07:10:12 Keschdeichel libvirtd[2638]: internal error: child reported 
(status=125): this function is not supported by the connection driver: 
virSecurityManagerMoveImageMetadata
  Mai 20 07:10:12 Keschdeichel libvirtd[2638]: Unable to remove disk metadata 
on vm focal from /var/lib/uvtool/libvirt/images/focal-ds.qcow (disk target vdb)
  
- 
  [Regression Potential]
  
-  * It is a check on a function that doesn't need to exist for apparmor.
-    Hence making that check not a fail does not have a huge regression 
-    potential - it is not that "now" it would do more. It just no more 
-    complains about it and thereby avoids log flooding.
+  * It is a check on a function that doesn't need to exist for apparmor.
+    Hence making that check not a fail does not have a huge regression
+    potential - it is not that "now" it would do more. It just no more
+    complains about it and thereby avoids log flooding.
+    Regressions could happen if we'd have silenced other warnings by that, 
+    but I don't see that in code or tests.
+  * The other change converts a bad RC into a good RC for a given set of 
+    condition that applies either when built without libattr or when working 
+    on an FS that does not support XATTR.
+    The same change of behavior we have in Ubuntu (built without libattr) 
+    would now also be dependent on the FS type (no error on such FS 
+    anymore). But that isn't true for Ubuntu builds and therefore doesn't 
+    matter for the SRU considerations.
+    A regression could be if there would be another low level fail that is 
+    mis-detected and masked to be "ok" by the code. But the API is rather 
+    clear on -1 = fail, -2 = the kind we mask 0 = ok. So this seems not to 
+    be an issue.
+ 
  
  [Other Info]
-  
-  * n/a
  
+  * n/a
  
  ---
- 
  
  We can reproduce this 100% in our CI (upstream Openstack Ironic)
  using Ubuntu 20.04 LTS Focal Fossa with libvirt 6.0.0
  
  2020-05-15 10:05:50.626+0000: 96089: error : 
virSecurityManagerMoveImageMetadata:476 : this function is not supported by the 
connection driver: virSecurityManagerMoveImageMetadata
  2020-05-15 10:05:50.628+0000: 96089: error : virProcessRunInFork:1159 : 
internal error: child reported (status=125): this function is not supported by 
the connection driver: virSecurityManagerMoveImageMetadata
  2020-05-15 10:05:50.628+0000: 96089: warning : 
qemuBlockRemoveImageMetadata:2629 : Unable to remove disk metadata on vm node-0 
from /var/lib/libvirt/images/node-0.qcow2 (disk target vda)
  
  complete libvirt logs:
  
https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_688/716889/26/check/ironic-tempest-ipa-partition-uefi-pxe-grub2/688814a/controller/logs/libvirt/libvirtd_log.txt
  
  This was filed upstream and fixed by:
  
https://gitlab.com/libvirt/libvirt/-/commit/cc8c297e473afd55e5d8e35e18345d8df176059d

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1879325

Title:
  Unable to remove disk metadata on vm

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1879325/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to