hint000

А почему iptables не пробрасывает порт?

Давайте по аналогии. Например, у вас есть ПК, есть провайдер, предоставляющий доступ в интернет, и есть роутер между провайдером и вашим ПК. Вы спрашиваете: "А почему провайдер не может пробросить порт на мой ПК?"
Потому что провайдер не видит ваш ПК и ничего о нём не знает,. Зато на роутере вы можете пробросить порт на ПК.
В вашей схеме: ПК - это ваша виртуалка; провайдер - это ваш хост; роутер - это сетевая часть гипервизора qemu. Таким образом, пробросить порт в режиме сети "user" вы можете только средствами гипервизора, что вам и описал zlo1 в первом комментарии.

сервер имеет статичный белый ip и подключен напрямую без маршрутизаторов

На сервере только один физический сетевой интерфейс? Очень легко настраивается, когда на сервере есть WAN и LAN, тогда бридж поднимается на LAN и на этот бридж цепляются виртуальные машины.

Вот не буду врать, я не пробовал руками поднимать бридж без привязки к физическому NIC (не было такой задачи), но по идее можно создать tap-интерфейс и навесить бридж на него. Уже с tap можно будет работать средствами хоста, а не гипервизора. Только надо сначала разрешить ip-forward, чтобы между WAN и tap в принципе могли летать пакеты. Потом разрулить маршруты между хостом и гостем (с обеих сторон), и только после этого смотреть на iptables (теперь сможете пробросить порт).
Короче, да, мост подходит, должен подходить. :)

какие показатели лучше?

Лучше для кого\чего? Цель-то не указана, какую из множества характеристик системы вы хотите улучшить. Во многих случаях, улучшая одно, приходится мириться с ухудшением другого.

В первом случае можно предположить чтение большими кусками, во втором случае маленькими кусками.
Объём записи пренебрежимо мал, на него можно вообще не смотреть.
TPS, вероятно, означает "транзакций в секунду"
Дисковая производительность в первом случае лучше.
Возможно, что "отзывчивость" системы несколько лучше во втором случае (если смотреть на IO Wait).

как задебажить средсвами хоста

Настроить VNC для этой виртуалки на уровне KVM. Это не задействует ресурсы виртуалки, только ресурсы хоста. И нужно заранее залогиниться через этот VNC и открыть диспетчер задач и т.п., чтобы во время фриза только смотреть в окно VNC.

htop в такие моменты на хосте показывает все ядра этой ВМ загружены на 100%.

Ещё в такие моменты на хосте iotop посмотрите. Не исключено, что процессор занят IO wait.

если без libvirt, то элементарно
qemu-system-x86_64 ... -vnc 77 ...
с таким параметром будет назначен этой VM порт VNC 5977

Плохая идея. Если уж хотите делать хранилище, то делайте через iSCSI, а не через Samba.
iSCSI работает на блочном уровне, Samba работает на файловом уровне.

В общем случае - указать количество ядер и пусть хост сам их выделяет. Это нормально.

В частном случае у вас могут быть какие-то хитрые нестандартные причины, чтобы отдавать фиксированные номера ядер. Тогда можно стартовать KVM через taskset. (Но количество ядер всё равно придётся указывать, помимо их номеров. Номера указываете в параметрах taskset, а количество в параметрах KVM - одно от другого не зависит.) В порядке теста я пробовал через taskset - да, работает, но особого смысла в этом не нашел. Отдельные процессы KVM всё равно по разным ядрам прыгают, в пределах выделенных. Так что смысл вижу только когда ровно одно ядро выделяется виртуалке, чтобы оно исполнялось всегда на одном и том же физическом ядре.