FYI, I just tried it with direct lun. it is as bad or worse. I dont know about that sg io vs qemu initiator, but here is the results.
15223: 62.824: IO Summary: 83751 ops, 1387.166 ops/s, (699/681 r/w), 2.7mb/s, 619us cpu/op, 281.4ms latency 15761: 62.268: IO Summary: 77610 ops, 1287.908 ops/s, (649/632 r/w), 2.5mb/s, 686us cpu/op, 283.0ms latency 16397: 61.812: IO Summary: 94065 ops, 1563.781 ops/s, (806/750 r/w), 3.0mb/s, 894us cpu/op, 217.3ms latency ----- Original Message ----- From: "Paolo Bonzini" <pbonz...@redhat.com> To: "Nir Soffer" <nsof...@redhat.com> Cc: "Philip Brown" <pbr...@medata.com>, "users" <us...@ovirt.org>, "qemu-block" <qemu-block@nongnu.org>, "Stefan Hajnoczi" <stefa...@redhat.com>, "Sergio Lopez Pascual" <s...@redhat.com>, "Mordechai Lehrer" <mleh...@redhat.com> Sent: Monday, July 20, 2020 3:46:39 PM Subject: Re: [ovirt-users] very very bad iscsi performance Il lun 20 lug 2020, 23:42 Nir Soffer <nsof...@redhat.com> ha scritto: > I think you will get the best performance using direct LUN. Is direct LUN using the QEMU iSCSI initiator, or SG_IO, and if so is it using /dev/sg or has that been fixed? SG_IO is definitely not going to be the fastest, especially with /dev/sg. Storage > domain is best if you want > to use features provided by storage domain. If your important feature > is performance, you want > to connect the storage in the most direct way to your VM. > Agreed but you want a virtio-blk device, not SG_IO; direct LUN with SG_IO is only recommended if you want to do clustering and other stuff that requires SCSI-level access. Paolo