Also some source: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Tuning_and_Optimization_Guide/chap-Virtualization_Tuning_Optimization_Guide-BlockIO.html
I really couldnt find the exact one i read but it basically says to do Raw with what i said above. I'd give most of that a good read because it does give you some small things to tune etc On Sun, Mar 26, 2017 at 4:47 PM, Zachary Boley <[email protected]> wrote: > Just normal virtio, I have it set to that, don't know how I would go about > setting virtio scsi or if I would need too > > On Mar 26, 2017 12:45 PM, "Nick Sarnie" <[email protected]> wrote: > >> Sorry, is that a SCSI controller set to virtio type, or the virtio option >> selected for the disk instead of SCSI? I've seen both recommended. >> >> Thanks, >> Sarnex >> >> On Sun, Mar 26, 2017 at 12:58 PM, Zachary Boley <[email protected]> >> wrote: >> >>> From what I've read Red Hat recommends virtio with raw on no cache with >>> io thread due to the reasons listed above. Not sure about LVM but they did >>> also say (or someone did) do not use BTRFS for keeping the image. >>> >>> The only optimization I would immediately recommended is to do >>> host-passthrough as the CPU option in your guests xml. It's noticeably >>> different assuming you haven't already done it >>> >>> On Mar 26, 2017 11:13 AM, "Bronek Kozicki" <[email protected]> wrote: >>> >>>> On 26/03/2017 15:31, Alex Williamson wrote: >>>> >>>>> On Sun, Mar 26, 2017 at 4:33 AM, Patrick O'Callaghan <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> On Sun, 2017-03-26 at 10:58 +0100, Bronek Kozicki wrote: >>>>> > Assuming you use libvirt, make sure to use vCPU pinning. For >>>>> disk access, try cache='writeback' io='threads'. If you switch to >>>>> scsio-vfio, this will give you the ability to define queue length which >>>>> might additionally improve IO. Also, try QCOW2 format for guest disk, it >>>>> might enable some additional optimizations. However given you host seem to >>>>> have little spare capacity, YMMV >>>>> >>>>> Thanks. I'm already using CPU pinning as I said. The disk options >>>>> are >>>>> both set to "hypervisor default" so I'll try changing them. I'd >>>>> configured the guest disk as 'raw' assuming that would be faster >>>>> than >>>>> QCOW2 but I'll look into it. >>>>> >>>>> >>>>> >>>>> Generally the recommendation is to use raw (not sparse), LVM, or a >>>>> block >>>>> device for the best performance. QCOW is never going to be as fast as >>>>> these at writing unused blocks since it needs to go out and allocate >>>>> new >>>>> blocks from the underlying file system when this happens. >>>>> >>>> >>>> I am not going to argue with your experience here, only wanted to note >>>> that QCOW2 can be created with preallcation=falloc (or full, which is not >>>> very useful) which means there will no extra allocations in the rutime. >>>> Everything will be allocated at the moment of disk creation with qemu-img >>>> create -f qcow2 -o preallcation=falloc .... >>>> >>>> >>>> >>>> B. >>>> >>>> _______________________________________________ >>>> vfio-users mailing list >>>> [email protected] >>>> https://www.redhat.com/mailman/listinfo/vfio-users >>>> >>> >>> _______________________________________________ >>> vfio-users mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/vfio-users >>> >>> >>
_______________________________________________ vfio-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/vfio-users
