TL;DR; - 4th and final part. - vm1 got new SSDs, no longer times out. - Most items on this list are lower priority and so it may many moons before any of this actually happens.
* One of vm1's hard drive was starting to get bad sectors. Newman replaced it with two SSDs in RAID 1. -> This also fixed the msi:* timeouts on vm1. Yay!
* Not really hardware but still on the hosting side: figure out whether to upgrade the VM hosts to Debian Testing. Or at least the QEmu part. This would get us from QEmu 3.1 to 4.2. Maybe this would help with issues like the wxppro_2scr VM (see part 3) but then the TestBot environment would be less stable.
* Spec out and setup a new VM host to speed up Wine builds and for GPU testing with PCI-passthrough. https://bugs.winehq.org/show_bug.cgi?id=31786 - Ryzen 3900X (lots of threads for Wine builds) - Pick a motherboard that provides sensible IOMMU groupings. - 32 GB of RAM (so we can run up to 6 concurrent VMs). - 1 TB SSD. - Any cheap low power graphics card to run the host's console. - Steal cw-rx460's RX 460 graphics card? - Add a modern Nvidia graphics card later on. - Get a new Windows 10 license so we can set up a new VM dedicated to testing all patches against a 'real' GPU. - Reconfigure the Debian VM to run on this new 'real' GPU too.
* Figure out how to get more than one VM running at a time on the new box without having one VM cause timing issues in the tests running on the others. This also implies: - Making sure we don't try to run to VMs that try to access the same PCI-passthrough graphics card at the same time! - Making sure we don't try to run more VM cores than are available on the host.
* Since the new box will be taking care of the real-AMD GPU tests there will not be much point running WineTest on cw-rx460 anymore. So it could be reconfigured to replace vm2 (i.e overwritten with vm2's backup).
* Retire vm2 - Its CPU is roughly half as fast as the others despite having 8 cores. - For some reason it can no longer run XP (and Vista?) VMs. This followed the Debian 10 upgrade, i.e. it was likely caused by a QEmu upgrade. So it may be that another QEmu upgrade fixes it but it's not really worth bothering.