gt; Eric Evans
>
> Digital Data Services LLC.
>
> 304.660.9080
>
>
>
> *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
> mig
virt-users] Re: Windows 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:
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
> issue.
> Are your CPU architectures compar
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 -- users@ovirt.org
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).
Regards,
Brett
On Tue, 7 Apr 2020 at 11:
I haven't got an active RHEL subscription so I can't view that solution
unfortunately.
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
0x7f93c082b367 0x7f93d8310736 0x55efa0670ac
Hi Brett,
According to [1], 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
(/var/log/vdsm/vdsm.log)
and the qemu log (/var/log/libvirt/qemu/vm_name.log)
7 matches
Mail list logo