On Thu, 04/12 21:45, David Lee wrote:
> On Thu, Apr 12, 2018 at 10:16 AM, David Lee <live4t...@gmail.com> wrote:
> >> > My team caught this issue too after switching to CentOS 7.4 with qemu-img
> >> > 2.9.0
> >> > gdb shows exactly the same backtrace when the convert stuck, and we are 
> >> > on
> >> > NFS.
> >> >
> >> > Later we found the following:
> >> > 1. The stuck can happen on local storage, too.
> >> > 2. Replace qemu-img 2.9.0 with 2.6.0 and everything works smoothly again.
> >> >
> >> > BTW, we use "qemu-img convert" to convert qcow2 and its backing files 
> >> > into
> >> > a single qcow2 image.
> >>
> >> Maybe it is RHBZ 1508886?
> >>
> >> Fam
> >
> >
> >
> > Thanks, Fam.  We just tracked down to this BZ too and are about to trying
> > the commit ef6dada8b44e1e7c4bec5c1115903af9af415b50
> 
> We tested qemu-kvm-ev-2.9.0-16.el7_4.14.1 - where from the source RPM we
> verified it does contain ef6dada8b44e1e7c4bec5c1115903af9af415b50
> 
> But the issue still exists.  The convert got stuck if one of the old
> active overlay
> had been 'vol-resize'd  with qemu monitor command to a larger size.  This 
> looks
> like a prerequisite but not sufficient condition to trigger this badness.

So it is a separate issue. Did you try upstream master as well?

Fam

Reply via email to