sts-sponsors team mailing list archive

[Mauricio Faria de Oliveira <1994002@xxxxxxxxxxxxxxxxxx>]

The sbuild autopkgtest failure on the 'unshare' test
is indeed fixed w/ sbuild in lunar-proposed; however,
now the test 'unshare-qemuwrapper' timed out.

autopkgtest [23:36:43]: @@@@@@@@@@@@@@@@@@@@ summary
build-procenv        PASS
unshare-qemuwrapper  FAIL timed out
unshare              PASS

It timed out on the 'guestfish' command, so I enabled
`export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1` there,
and run autopkgtests against its build in a PPA [1].

Then it finished successfully w/out timing out! x)

autopkgtest [16:17:39]: @@@@@@@@@@@@@@@@@@@@ summary
build-procenv        PASS
unshare-qemuwrapper  PASS
unshare              PASS

Not a very useful result, but it did show that an
step in guestfish took ~25 minutes; 30 mins total:

autopkgtest [15:22:52]: test unshare-qemuwrapper: [-----------------------
...
+ export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
+ guestfish <...>
...
libguestfs: trace: tar_in "/tmp/.../ubuntu-lunar-host.tar" "/"
...
tar -C /sysroot/ -xf - 2> /tmp/tarSfYHJX
...
guestfsd: => tar_in (0x45) took 1489.08 secs
...
autopkgtest [15:52:27]: test unshare-qemuwrapper: -----------------------]
unshare-qemuwrapper  PASS

So, well, it might have been due to load in the
autopkgtest infrastructure at the time tests ran,
so just triggered retries on sbuild and sbuild+qemu.

Hopefully they will pass and unblock proposed migration
for both sbuild & qemu.

[1] https://autopkgtest.ubuntu.com/results/autopkgtest-lunar-mfo-
build/lunar/amd64/s/sbuild/20221215_161801_a2772@/log.gz

-- 
You received this bug notification because you are a member of SE SRU
("STS") Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1994002

Title:
  [SRU] migration was active, but no RAM info was set

Status in Ubuntu Cloud Archive:
  New
Status in Ubuntu Cloud Archive ussuri series:
  New
Status in qemu package in Ubuntu:
  In Progress
Status in qemu source package in Bionic:
  In Progress
Status in qemu source package in Focal:
  In Progress
Status in qemu source package in Jammy:
  In Progress
Status in qemu source package in Kinetic:
  In Progress

Bug description:
  [Impact]

   * While live-migrating many instances concurrently, libvirt sometimes
  return `internal error: migration was active, but no RAM info was
  set:`

   * Effects of this bug are mostly observed in large scale clusters
  with a lot of live migration activity.

   * Has second order effects for consumers of migration monitor such as
  libvirt and openstack.

  [Test Case]
  Steps to Reproduce:
  1. live evacuate a compute
  2. live migration of one or more instances fails with the above error

  N.B Due to the nature of this bug it is difficult consistently reproduce.
  In an environment where it has been observed it is estimated to occur approximately 1/1000 migrations.

  [Where problems could occur]
   * In the event of a regression the migration monitor may report an inconsistent state.

  [Original Bug Description]

  While live-migrating many instances concurrently, libvirt sometimes return internal error: migration was active, but no RAM info was set:
  ~~~
  2022-03-30 06:08:37.197 7 WARNING nova.virt.libvirt.driver [req-5c3296cf-88ee-4af6-ae6a-ddba99935e23 - - - - -] [instance: af339c99-1182-4489-b15c-21e52f50f724] Error monitoring migration: internal error: migration was active, but no RAM info was set: libvirt.libvirtError: internal error: migration was active, but no RAM info was set
  ~~~

  From upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2074205

  [Other Information]
  Related bug: https://bugs.launchpad.net/nova/+bug/1982284

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1994002/+subscriptions