[ovirt-users] Re: Constantly XFS in memory corruption inside VMs

2020-11-28 Thread Strahil Nikolov via Users
Are you using "nobarrier" mount options in the VM ? If yes, can you try to remove the "nobarrrier" option. Best Regards, Strahil Nikolov В събота, 28 ноември 2020 г., 19:25:48 Гринуич+2, Vinícius Ferrão написа: Hi Strahil, I moved a running VM to other host, rebooted and no

[ovirt-users] Re: Unable to move or copy disks

2020-11-28 Thread suporte
I really don't understand this. I have 2 glusters same version, 6.10 I can move a disk from gluster2 to gluster1, but cannot move the same disk from gluster1 to gluster2 ovirt version: 4.3.10.4-1.el7 Regards José De: "Strahil Nikolov" Para: supo...@logicworks.pt Cc: users@ovirt.org

[ovirt-users] Re: Constantly XFS in memory corruption inside VMs

2020-11-28 Thread Vinícius Ferrão via Users
Hi Strahil, I moved a running VM to other host, rebooted and no corruption was found. If there's any corruption it may be silent corruption... I've cases where the VM was new, just installed, run dnf -y update to get the updated packages, rebooted, and boom XFS corruption. So perhaps the

[ovirt-users] Re: Constantly XFS in memory corruption inside VMs

2020-11-28 Thread Strahil Nikolov via Users
Can you try with a test vm, if this happens after a Virtual Machine migration ? What are your mount options for the storage domain ? Best Regards, Strahil Nikolov В събота, 28 ноември 2020 г., 18:25:15 Гринуич+2, Vinícius Ferrão via Users написа:    Hello,   I’m trying to

[ovirt-users] Constantly XFS in memory corruption inside VMs

2020-11-28 Thread Vinícius Ferrão via Users
Hello, I'm trying to discover why an oVirt 4.4.3 Cluster with two hosts and NFS shared storage on TrueNAS 12.0 is constantly getting XFS corruption inside the VMs. For random reasons VM's gets corrupted, sometimes halting it or just being silent corrupted and after a reboot the system is

[ovirt-users] Re: Ovirt 4.4.3 - Unable to start hosted engine

2020-11-28 Thread Marco Marino
Ok, I solved and I'm going to expose my idea on what happened. First, *problem resolution procedure:* 1. manual reinitialization of sanlock lockspace: I noticed from /var/log/sanlock.log that function add_lockspace fail: 2020-11-28 09:28:22 54405 [391545]: s72 lockspace