qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-discuss] Corruption on Windows VMs when running 4.10+ kernel


From: Rene Bakkum
Subject: [Qemu-discuss] Corruption on Windows VMs when running 4.10+ kernel
Date: Thu, 3 May 2018 16:34:48 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

Hi,

Sorry if I miss any information. If possible I'll try to add as much information as I can.

Problem:
Running Windows VMs with MSSQL on KVM causes SQL log corruption when running on Kernel 4.10 or higher.

Setup:
- Host OS: Ubuntu 16.04 LTS
- Host kernel: 4.13.0-39-generic #44~16.04.1-Ubuntu SMP
- QEMU/KVM version: 1:2.5+dfsg-5ubuntu10.25
- Virtual Disks in LVM
- Guest OS: Windows 2016 + SQL 2016
*included xml of a VM configuration*

Reproduce:
Running above setup (default Ubuntu 16.04 with hwe kernel installed) and a Windows VM running and run an SQL benchmark (we used Benchmark Factory Trail 8.0.1). After a couple of minutes the SQL logs will become corrupt.

Workaround:
- Change the disk cache from 'none' to 'writethrough'
- Revert back to 4.4 / 4.8 kernel

Background information:
We've done some testing and when we are running the 4.8 kernel from the Ubuntu repo, all is fine and we can run large tests on the SQL servers. When we upgrade to a 4.10, 4.13 or 4.15 kernel it breaks after generating roughly 500Mb of logs, than SQL servers start to report the ldf files are corrupt and SQL mirrors start to fail. We also see more often that SQL servers are putting databases in Suspect mode. However this is harder to reproduce and could be something else. However we believe the problems are related to each other. With changing the disk cache from none to writethrough seems to solve the problem, but the side effect is that live migrations are not safe anymore to do. Reverting to a 4.4 (lts) or 4.8 (16.10 kernel) seems also to solve the issue, but with some hardware choices we can't really stay behind on the kernel versions that long.

We've done some testing on 18.04 as well, and the problem seems to be there as well. In that case we were running the 4.15 kernel.

Questions:
- Am I on the right list? ;)
- Does anyone else experience the same behavior?
- Better yet, does anyone have a better solution?

Thanks in advanced!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]