Markus,
So all CPU threads are blocked by the main loop. The main loop is busy draining IO
requests from all drives while there are other block commit jobs active... It looks like
currently QEMU just can't live merge more than one drive simultaneously without
blocking VCPUs.
As workaround you can delete disk snapshots one-by-one, and then delete disk-less VM
snapshot. The Storage tab has Disk Snapshots sub tab where you can remove a specific
snapshot of a specific disk.
On 12/04/16 21:39, "Markus Stockhausen" <stockhausen(a)collogia.de> wrote:
> Von: Pavel Gashev [Pax(a)acronis.com]
> Gesendet: Dienstag, 12. April 2016 16:15
> An: Markus Stockhausen; users
> Betreff: Re: [ovirt-users] stalls during live Merge Centos 7 / qemu 2.3
>
> Markus,
>
> I saw similar issues. Looks like it's related to multidisk VMs under high disk
load. No relations with guest OS. No relations with IO threads.
>
>
> I didn't debug it. Can you please show a backtrace of a thread in __lll_lock_wait
?
Hi Pavel.
thanks for your response. I dont even need high disk load to
reproduce the issue. Just a simple script that writes 8k blocks
every 0.5 secs. I added the required info to the BZ.
https://bugzilla.redhat.com/show_bug.cgi?id=1319400
Markus
>
>
> On 11/04/16 18:13, "users-bounces(a)ovirt.org on behalf of Markus
Stockhausen" <users-bounces(a)ovirt.org on behalf of stockhausen(a)collogia.de>
wrote:
>
> >Hi there,
> >
> >I'm getting slowly mad about our new Centos 7 cluster. Whenever
> >I start a live merge the machine completely freezes. It seems to be
> >independent of the Guest OS (tried SLES 11 SP3, SLES11 SP4 and
> >SLES12). I already opened BZ1319400 because I'm clueless.
> >
> >Doing the same in our Fedora 20 cluster (qemu 2.1.3) we only see
> >small hiccups of 1-3 seconds at the start of the live merge but no
> >complete stall. Its the same VM!
> >
> >Just to be sure that it is not a specific problem of our topology
> >or SLES I would like to receive some feedback of the list if anyone
> >observes similar lockups in their environment.
> >
> >Thanks in advance.
> >
> >Markus
> >