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
