GNOME Bugzilla – Bug 670777
Better disk performance
Last modified: 2016-03-31 13:59:05 UTC
Boxes can really do much better at disk performance. Legend has it that with right disk configuration, one can bring down the win7 installation time from 12 hours to 30 mins. Lets try to achieve that.
Created attachment 208384 [details] [review] Unset cache on disk driver for main storage Haven't really measured but there is a visible performance gain from this.
Created attachment 208385 [details] [review] WIP: Use virtio disk for OSs that support it out of the box This doesn't seem to work: I get a unrecoverable "not enough storage space" error from F16 Anaconda during express installation. Without this change, it works just fine.
Created attachment 208386 [details] [review] Add more debug to post-installation code
Created attachment 208411 [details] [review] Use virtio disk for OSs that support it out of the box This version works. Just needed to adjust the device name in the kickstart file.
(In reply to comment #0) > Boxes can really do much better at disk performance. Legend has it that with > right disk configuration, one can bring down the win7 installation time from 12 > hours to 30 mins. Lets try to achieve that. For the record, win7 installation is 12 hours slow (to be honest, it's more 4 hours than 12 :) on my fedora laptop using virt-manager/libvirt from git, and it's 20 minutes fast using virt-manager/libvirt from RHEL 6.2 on my workstation. Lots of differences between the 2 boxes so it's hard to pinpoint exactly what explains the speed difference, but I wouldn't necessarily focus on changes in gnome-boxes at this point to try to get some more speed.
(In reply to comment #5) > (In reply to comment #0) > > Boxes can really do much better at disk performance. Legend has it that with > > right disk configuration, one can bring down the win7 installation time from 12 > > hours to 30 mins. Lets try to achieve that. > > For the record, win7 installation is 12 hours slow (to be honest, it's more 4 > hours than 12 :) on my fedora laptop using virt-manager/libvirt from git, and > it's 20 minutes fast using virt-manager/libvirt from RHEL 6.2 on my > workstation. Lots of differences between the 2 boxes so it's hard to pinpoint > exactly what explains the speed difference, but I wouldn't necessarily focus on > changes in gnome-boxes at this point to try to get some more speed. I started with these small patches and saw a significant improvement in case of F16 installation (it now takes about 10mins on my machine) hence the reason I believe that much could be achieved with just disk I/O performance tuning. Most probably, thats not the only ingredient for faster win7 installs but I'm betting this is significant part of it.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #0) > > > Boxes can really do much better at disk performance. Legend has it that with > > > right disk configuration, one can bring down the win7 installation time from 12 > > > hours to 30 mins. Lets try to achieve that. > > > > For the record, win7 installation is 12 hours slow (to be honest, it's more 4 > > hours than 12 :) on my fedora laptop using virt-manager/libvirt from git, and > > it's 20 minutes fast using virt-manager/libvirt from RHEL 6.2 on my > > workstation. Lots of differences between the 2 boxes so it's hard to pinpoint > > exactly what explains the speed difference, but I wouldn't necessarily focus on > > changes in gnome-boxes at this point to try to get some more speed. > > I started with these small patches and saw a significant improvement in case of > F16 installation (it now takes about 10mins on my machine) hence the reason I > believe that much could be achieved with just disk I/O performance tuning. You were correct, F16 installation doesn't speed-up much because of these patches. I clearly remember it being much slower so I guess I never really paid attention to how long it takes after I started using SSD drive on this machine.
patches looks fine The virtio patch should take into account the virtio capability once the driver for Windows is auto-installed (which can hopefully happen soon).
(In reply to comment #8) > patches looks fine > > The virtio patch should take into account the virtio capability once the driver > for Windows is auto-installed (which can hopefully happen soon). Would that imply that we can boot the machine with virtio disk from start? IIRC that is not true so IMO those patches should take care of enabling virtio disk for windows at the appropriate time and we should already merge this one.
(In reply to comment #9) > (In reply to comment #8) > > patches looks fine > > > > The virtio patch should take into account the virtio capability once the driver > > for Windows is auto-installed (which can hopefully happen soon). > > Would that imply that we can boot the machine with virtio disk from start? IIRC > that is not true so IMO those patches should take care of enabling virtio disk > for windows at the appropriate time and we should already merge this one. It can be enabled from the start for the hard disk when we have driver autoinstall
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > patches looks fine > > > > > > The virtio patch should take into account the virtio capability once the driver > > > for Windows is auto-installed (which can hopefully happen soon). > > > > Would that imply that we can boot the machine with virtio disk from start? IIRC > > that is not true so IMO those patches should take care of enabling virtio disk > > for windows at the appropriate time and we should already merge this one. > > It can be enabled from the start for the hard disk when we have driver > autoinstall For all windows (XP and 7) ?
I've only tested XP for now, hopefully I'll try 7 soon.
I did it with win7 install. (win7 vm boots in 10s here btw, really)
(In reply to comment #13) > I did it with win7 install. Driver autoinstall? > (win7 vm boots in 10s here btw, really) Cool, What are the secret ingredients? :)
(In reply to comment #14) > Cool, What are the secret ingredients? :) - stock f17 host (host has an encrypted ext4 partition on SSD) - all latest virt* drivers, agents etc.. - cache none, virtio controller - prealloc metadata on qcow2 - 4 vCPU (imho the guest should by default get whatever the host has for desktop usage, I don't really see the point in limiting number of cpu, mine is a i5)
I didn't measure the time for installation, but I am quite sure it was ~20 minutes, perhaps less.
(In reply to comment #16) > I didn't measure the time for installation, but I am quite sure it was ~20 > minutes, perhaps less. Cool! Even if its 1 hours thats already a big improvement over several hours.
(In reply to comment #8) > patches looks fine > > The virtio patch should take into account the virtio capability once the driver > for Windows is auto-installed (which can hopefully happen soon). Instead of waiting on that, lets make sure windows driver autoinstall patches enables virtio disk. I'll merge these now..
Attachment 208384 [details] pushed as 9d8760e - Unset cache on disk driver for main storage Attachment 208386 [details] pushed as 23f60cc - Add more debug to post-installation code Attachment 208411 [details] pushed as dbb4452 - Use virtio disk for OSs that support it out of the box Seems unattended installation for Fedora 17 is broken. I first thought its because of attachment#208411 [details] but I was able to reproduce the issue even without any of these patches.