> Digital Data Services LLC.
> *From:* Maton, Brett
> *Sent:* Friday, April 10, 2020 4:53 PM
> *To:* eev...@digitaldatatechs.com
> *Cc:* Ovirt Users
> *Subject:* [ovirt-users] Re: Windows 10 Pro 64 (1909) crashes when
ows 10 Pro 64 (1909) crashes when migrating
The hosts are identical, and yes I'm sure about the 563 terrabytes, which is
obviously wrong, and why I mentioned it. Possibly an overflow?
On Fri, 10 Apr 2020, 21:31 , mailto:eev...@digitaldatatechs.com> > wrote:
I have a Windows 10 guest
The hosts are identical, and yes I'm sure about the 563 terrabytes, which
is obviously wrong, and why I mentioned it. Possibly an overflow?
On Fri, 10 Apr 2020, 21:31 , wrote:
> I have a Windows 10 guest and a Server 2016 guest that migrate without an
> Are your CPU architectures
I have a Windows 10 guest and a Server 2016 guest that migrate without an issue.
Are your CPU architectures comparable between the hosts?
BTW, 56294995342131 bytes is 562 terabytes. Are you sure that's correct?
Users mailing list -- email@example.com
Any other suggestions ?
I'm already running a later version of qemu (qemu-kvm-ev-2.12.0-33.1.el7_7.4)
than the one referenced (qemu-kvm-rhev-2.9.0-16) in
https://access.redhat.com/solutions/3423481 (from what I can see on that
page without a subscription).
On Tue, 7 Apr 2020 at
I haven't got an active RHEL subscription so I can't view that solution
Thanks for the log pointers though, looking in the qemu log I'm not
surprised it's crashing...
tcmalloc: large alloc 562949953421312 bytes == (nil) @ 0x7f93c080b4ef
According to , you can try to update the package qemu-kvm-rhev.
(Or yum update if there're more packages related need to be upgraded).
You may also find some more information about that error on the vdsm log
and the qemu log
Mail list logo