On Sat, Apr 3, 2021 at 1:32 PM Richard Shaw <hobbes1069@xxxxxxxxx> wrote: > > I just setup a Windows 10 to do some debugging of a mingw project. Gnome Boxes made the process very simple but the performance is horrendous. > > Even after the following I still wouldn't consider it usable. > > # chattr +C ~/.local/share/gnome-boxes/images > # cd ~/.local/share/gnome-boxes/images > # mv win10 ../ > # cat ../win10 win10 > > $ lsattr > ---------------C---- ./win10 > > Here's a screenshot showing windows process manager with < 1MB transfer rates but 100% disk busy while installing MinGW w64 in windows, which is not a huge amount of data... > > https://www.dropbox.com/s/2m0p3lptbqwd7lp/Screenshot%20from%202021-04-03%2014-22-02.png > > Any tips? Or do I just need to buy a cheap SSD and format it EXT4 just for virtual machine images? Pretty sure GNOME Boxes creates sparse qcow2 files, and virt-manager creates them with option preallocation=falloc, so this is worth a shot. I'm not sure it can account for all of the performance loss though. Check the configuration 'virsh dumpxml $vmname > vmname.xml' and see if it's using IDE or SATA for the drive. It is possible to use VirtIO for Windows after you've installed the VirtIO drivers for Windows and the performance is much better. I'm reluctant to outright recommend what I use, cache mode unsafe, but it performs a *lot* better. But if the host crashes, the VM image can be damaged beyond repair. If the guest crashes, it should be OK. (I force quit VMs all the time, mainly because I am trying to damage file systems.) I think the default cache mode for GNOME Boxes is none. It is possible to change it via virsh to writeback and see if that's better or worse. And if it's better then that maybe could become the default for Windows guests. I don't expect unsafe could ever be a default. https://documentation.suse.com/sles/11-SP4/html/SLES-kvm4zseries/cha-qemu-cachemodes.html -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure