Not sure IO could be the case. The underlying storage itself is brand new
(nvme) connected with FC and is barely at 10 % capacity with low IOPS and
practically zero latency. There are no IO limitations on the LUN itself. I
would also be able to see any IO problems on the other VMs (none in this

I'm out of ideas on what to do for the time how to stop / complete the
task. Any suggestion welcome.

Shutting down the VM in this state means that It probably wont start back
(snapshots with disks in illegal state). Worst case I plan to restore this
VM from a backup tonight.


On Wed, May 27, 2020 at 4:39 PM Benny Zlotnik <bzlot...@redhat.com> wrote:

> Sorry, by overloaded I meant in terms of I/O, because this is an
> active layer merge, the active layer
> (aabf3788-8e47-4f8b-84ad-a7eb311659fa) is merged into the base image
> (a78c7505-a949-43f3-b3d0-9d17bdb41af5), before the VM switches to use
> it as the active layer. So if there is constantly additional data
> written to the current active layer, vdsm may have trouble finishing
> the synchronization
> On Wed, May 27, 2020 at 4:55 PM David Sekne <david.se...@gmail.com> wrote:
> >
> > Hello,
> >
> > Yes, no problem. XML is attached (I ommited the hostname and IP).
> >
> > Server is quite big (8 CPU / 32 Gb RAM / 1 Tb disk) yet not overloaded.
> We have multiple servers with the same specs with no issues.
> >
> > Regards,
> >
> > On Wed, May 27, 2020 at 2:28 PM Benny Zlotnik <bzlot...@redhat.com>
> wrote:
> >>
> >> Can you share the VM's xml?
> >> Can be obtained with `virsh -r dumpxml <vm_name>`
> >> Is the VM overloaded? I suspect it has trouble converging
> >>
> >> taskcleaner only cleans up the database, I don't think it will help here
> >>
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
List Archives: 

Reply via email to