KVM+QEMU железо через vt-d

Есть истории успеха?

Да. Юз поиск, Люк.

Кстати инстерстную тему затронул. Если ли в это лажовой x86 виртуализации путь, позоволяющий прокинуть блок девайс, без потерь в производительности?

Виртуальный контроллер vmware pvscsi практически без потерь прокидывает, меряли. А так можно и RAID контроллер в ВМ пробросить.

Угу, знаю я эти сказки про vmware. Каждый месяц находится клиент, который говорит: а давайте на vmware поставим. Мы говорим, давайте, но покажите нам, что это работает. Не один ещё не показал. Либо латенси высокий, либо иопсы не держит, либо ещё какая беда. Пока я не увидел живой инсталяции, которая была бы годной.

Можешь сравнительные тесты показать: сколько было без гипервизора и сколько с ним, на одной и тойже машине. Можно orion'ом например погонять.

Ну, у меня кластер из 10 хостов отлично уже года 4 работает. Обновлялось еще кажется с 4.0->4.1->5.0->5.1.

Хранилища пока по iSCSI 10Gb, будем переходить на FCOE в будущем. Нареканий никаких нет, всё работает как часы. Физических серверов вообще нет, всё вертится в ВМ.

Померять могу попробовать когда новая полка приедет и будет свободный массив чтобы сравнить скорость напрямую и изнутри виртуалки через Raw Disk Mapping. Меряю обычно через fio.

Ну, у меня кластер из 10 хостов отлично уже года 4 работает. Обновлялось еще кажется с 4.0->4.1->5.0->5.1.

Во-во, каждый раз это слышу, а как до цифр доходит, так не один ещё не показал.

Померять могу попробовать когда новая полка приедет и будет свободный массив чтобы сравнить скорость напрямую и изнутри виртуалки.

Было бы круто, а старых данных нет, получается?

Меряю обычно через fio.

Хрен редьки не слаще, но orion под бд изначально заточен, особенно под ту, что у тебя в нике.

Хранилища пока по iSCSI 10Gb.

Это ещё веселее. Программная виртуализация scsi в программно виртуализированном ethernet'е - каменный век.

будем переходить на FCOE в будущем.

Зачем, если не секрет? Свич fcoe стоит как свич fc + обычный свич. Зачем ежа с ужом скрещивать?

Старых данных нет, это делалось давно, на заре появления pvscsi в гипервизоре.

Каменный век не каменный век, а работает и весьма успешно. И на момент внедрения оно было в разы дешевле FC, а FCoE тогда и не было на рынке.

По поводу свичей ты что-то путаешь, для поддержки FCoE, по сути, нужна поддержка компонент Data Center Ethernet, в частности выделенного Flow Control отдельно для FCoE траффика.

А это поддерживает практически любой 10G свитч. Я планирую брать Cisco Nexus 5548UP, они достаточно недороги для своего кол-ва портов, в базе порядка 350т за штуку в свободной продаже.

ЗЫ: По поводу тестов - у меня есть древненький Proliant DL320 G5 с сата дисками, погоняю на нем.

ЗЫ: По поводу тестов - у меня есть древненький Proliant DL320 G5 с сата дисками, погоняю на нем.

Вполне годно, а то мне обычно приходится общаться с теми, кто в vmware нефига не понимает, но наслушался маркетинга. А я в ней тоже ничего не понимаю и протестить сейчас не на чем фактически.

По поводу свичей ты что-то путаешь, для поддержки FCoE

Возможно.

Для поддержки FCoE, по сути, нужна поддержка компонент Data Center Ethernet, в частности выделенного Flow Control отдельно для FCoE траффика.

Может я чего не понимаю, но FCoE идет не по IP, а по своему протоколу, поверх L2 Соответственно, если ты хочешь зонирование, то тебе его где-то надо делать.

Зонирование делается средствами Fabric Manager встроенного в свич. Без него тоже будет работать. но все всех будут видеть :)

Вот об этом и говорю, что свич должен поддерживать fcoe, а то ерунда выйдет.

vmware

Мне нужно в kvm+qemu, vmware это, во-первых, оффтоп, во-вторых, малоюзабельная вещь.

Да. Юз поиск, Люк.

Твой поиск, однозначно, лучше моего, ибо я не нахожу ничего конкретного.

Тогда попробуй www.linux.org.ru/tag/qemu

Вторая сверху тема.

Сенкс.

Ну, смотря что считать юзабельной вещью. Я вот как-то юзаю. Да и отвечал я не тебе, а тов. zloelamo, по другому вопросу.

Ну, смотря что считать юзабельной вещью.

Всё познаётся в сравнении.

Мне нужно в kvm+qemu, vmware это, во-первых, оффтоп, во-вторых, малоюзабельная вещь.

Разницы никакой - это все vt-x/vt-d.

Разницы никакой - это все vt-x/vt-d.

Ничего что конфиги разные? Мне нужна конкретика, что и как делать, рабочие конфиги посмотреть. А то что оно через vt-d/iommu работает, ну так им больше не через чего на x86_64.

Разницы никакой - это все vt-x/vt-d

Во-первых, ты б сначала разобрался в чем разница: не все процы держат обе технологии. Во-вторых, таже vmware из винды не может нормально пробрасывать видеокарточку (во всяком случае у меня оптимус на ноуте). Пляски с бубном имеются, но я так и не осилил :( Девайсы прокидываются без проблем, только они не очень юзабельные.

Вобщем все слишком специфично: проц + видяха + материнка должны быть какой-то специальной конфигурации.

И да, у ТС надо было уточнить какая видяха: встроенная или внешняя, ибо как раз тут-то и возникает разница между vt-x и vt-d.

Кстати инстерстную тему затронул. Если ли в это лажовой x86 виртуализации путь, позоволяющий прокинуть блок девайс, без потерь в производительности?

есть косвенный путь, если кто-то сделает, например sata контроллер с sr-iov, то всё может получиться. Только он должен ещё драйверы проапгрейдить(написать) для физической функции и виртуальной.

например сетевые карты есть такие, которые так умеют. скажем intel 82576, 82580, 82599, x540 и прочие на похожих чипсетах.

только конечно биос ещё должен правильно pci express мосты настраивать.

например sata контроллер с sr-iov

Ооо! Не знал, что до x86 добрались подобные технологии! Спасибо, надо погуглить. Но понимать, что на мейнстримовых hp и ibm этого пока нет?

Ну как нет, есть.

Например: http://h20000.www2.hp.com/bc/docs/support/SupportManual/c03679850/c03679850.pdf

И FCoE можно через эти адаптеры запихнуть?

Через конкретно эти - хз.

Но если взять полноценный Converged Network Adapter, то он будет выглядеть как несколько PCI-E функций для ОС, таких как HBA, сетевые адаптеры и т.п. Не уверен, совсместимо ли это с SR-IOV, не проверял, мне оно без надобности.

Протестил.

- HP Proliant DL320s G1

- HP Smart Array P400 256Mb

- Массив из 2x36GB SAS 15k - RAID0

- Ubuntu 13.04 Server x64 (как на железе, так и в ВМ, все апдейты)

- Тестировал random write

- ESXi 5.1u1 build 1065491

Конфиг fio:

[writetest]
size=8589934592
blocksize=4k
filename=/dev/cciss/c0d1
rw=randwrite
direct=1
buffered=0
ioengine=libaio
iodepth=16

Тесты проводил по 2 раза, различия были в пределах погрешности.

Результаты на голом железе:

writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=16
2.0.8
Starting 1 process
Jobs: 1 (f=1): [w] [100.0% done] [0K/4928K /s] [0 /1232  iops] [eta 00m:00s]
writetest: (groupid=0, jobs=1): err= 0: pid=30567
  write: io=8192.0MB, bw=6587.4KB/s, iops=1646 , runt=1273452msec
    slat (usec): min=6 , max=1154 , avg=11.50, stdev= 3.87
    clat (usec): min=129 , max=62028 , avg=9700.39, stdev=21686.28
     lat (usec): min=138 , max=62034 , avg=9712.38, stdev=21686.12
    clat percentiles (usec):
     |  1.00th=[  298],  5.00th=[  330], 10.00th=[  338], 20.00th=[  346],
     | 30.00th=[  358], 40.00th=[  374], 50.00th=[  398], 60.00th=[  426],
     | 70.00th=[  470], 80.00th=[  516], 90.00th=[60160], 95.00th=[60672],
     | 99.00th=[61184], 99.50th=[61184], 99.90th=[61696], 99.95th=[61696],
     | 99.99th=[61696]
    bw (KB/s)  : min= 3500, max=83968, per=100.00%, avg=6588.92, stdev=1837.81
    lat (usec) : 250=0.24%, 500=77.32%, 750=6.88%, 1000=0.02%
    lat (msec) : 2=0.01%, 50=0.01%, 100=15.54%
  cpu          : usr=0.86%, sys=2.31%, ctx=998333, majf=0, minf=22
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=2097152/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=8192.0MB, aggrb=6587KB/s, minb=6587KB/s, maxb=6587KB/s, mint=1273452msec, maxt=1273452msec

Disk stats (read/write):
  cciss!c0d1: ios=91/2096957, merge=0/0, ticks=80/20324232, in_queue=20324212, util=100.00%

Под гипервизором:

writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=16
2.0.8
Starting 1 process
Jobs: 1 (f=1): [w] [100.0% done] [0K/5430K /s] [0 /1357  iops] [eta 00m:00s]
writetest: (groupid=0, jobs=1): err= 0: pid=1937
  write: io=8192.0MB, bw=6487.6KB/s, iops=1621 , runt=1293031msec
    slat (usec): min=5 , max=881 , avg=11.11, stdev=21.93
    clat (usec): min=117 , max=64540 , avg=9849.94, stdev=21065.79
     lat (usec): min=161 , max=64545 , avg=9861.44, stdev=21065.77
    clat percentiles (usec):
     |  1.00th=[  342],  5.00th=[  454], 10.00th=[  516], 20.00th=[  620],
     | 30.00th=[  708], 40.00th=[  780], 50.00th=[  804], 60.00th=[  828],
     | 70.00th=[  844], 80.00th=[  932], 90.00th=[58112], 95.00th=[59136],
     | 99.00th=[60160], 99.50th=[60160], 99.90th=[60672], 99.95th=[61184],
     | 99.99th=[61184]
    bw (KB/s)  : min= 3824, max=81965, per=100.00%, avg=6490.73, stdev=1779.63
    lat (usec) : 250=0.30%, 500=8.48%, 750=26.13%, 1000=47.14%
    lat (msec) : 2=2.13%, 4=0.03%, 10=0.01%, 20=0.01%, 50=0.01%
    lat (msec) : 100=15.78%
  cpu          : usr=1.01%, sys=3.07%, ctx=248606, majf=0, minf=22
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=2097152/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=8192.0MB, aggrb=6487KB/s, minb=6487KB/s, maxb=6487KB/s, mint=1293031msec, maxt=1293031msec

Disk stats (read/write):
  sdb: ios=91/2096841, merge=0/0, ticks=44/20427344, in_queue=20427232, util=99.92%

Как видно, иопсов столько же примерно (1646 vs. 1621), латентность немного выше: на голом железе 77% латенси укладывалось в 0.5мсек, под гипервизором оно уже 0.5-1мсек по большей части, но это, на мой взгяд, не критично, на иопсы влияет слабо, что собственно и видно. Скачки до 100мсек в 15% случаев есть и там и там, это, наверное, особенность массива и контроллера.

иопсов столько же примерно (1646 vs. 1621)

Не-не-не, Дэвид Блейн. Это ты протестировал кеш :). Два 15K диска способны в теории потянуть 350-400 IOPs (учитывая RAID0 почти без потерь один диск+другой), поэтому ты тестировал в одном случае кеш массива, а в другом наверно ещё и кеш vmware.

Чтоб этого избежать надо тестировать на большом объеме данных, так, чтоб в кеш гарантировано не влезало. И это не синтетика получится, а эмуляция работы вполне такой нормальной базы данных.

И какая разница? Тест идет в direct io, значит мы исключаем page cache операционки. А что там дальше творится - дело уже не гипервизора. У вмваре нет кэша своего, массив передан виртуалке напрямую.

Так что с т.з. сравнения работы с гипервизором и без тест вполне корректен.

Тест идет в direct io, значит мы исключаем page cache операционки.

Операционки да, а ты уверен, что Варя не кеширует? Я нет, исходники то закрытые.

Тест идет в direct io, значит мы исключаем page cache операционки.

Той операционки, что внутри виртуалки?

непринуждённо пробрасывать видеокарты

С видеокартами все не так просто. За подробностями можешь сходить в вики Xen.

Уверен. Сторонники теории заговора могут думать иначе :)

Прочитать можно, например, тут: http://www.yellow-bricks.com/2011/04/07/mythbusters-esxesxi-caching-io/

Source Satyam Vaghani (VMware Engineering)

ESX(i) does not cache guest OS writes. This gives a VM the same crash consistency as a physical machine: i.e. a write that was issued by the guest OS and acknowledged as successful by the hypervisor is guaranteed to be on disk at the time of acknowledgement. In other words, there is no write cache on ESX to talk about, and so disabling it is moot. So that’s one thing out of our way.

Source – Knowledge Base

VMware ESX acknowledges a write or read to a guest operating system only after that write or read is acknowledged by the hardware controller to ESX. Applications running inside virtual machines on ESX are afforded the same crash consistency guarantees as applications running on physical machines or physical disk controllers.

Да.

Повторюсь, маркетинг меня не интересует. На заборе тоже написано, а там дрова. Цифры нужны.

Пока видно лишь то, что ты протестил кеш. Какой, черт его знает.

Я еще раз говорю - сторонники теории заговора думают всегда свое :) Меня тест вполне устраивает. Если я отключу кеш на рейде, иопсы просто упадут и там и там, о наличии кеша в гипервизоре это ничего не скажет.

А в VMWare не дураки сидят, которые будут копать себе такую опасную яму, которая может привести к потере данных и куче говна со стороны клиентов.

Это как использование рейд-контроллера с включенным writeback кэшем без BBU.

Так что в этом плане я склонен им верить.

А кэш хост-системы? Если VMware переводит операции В/В в обычные операции над файлами, в дело вступает кэш хоста.

Тратишь деньги конторы, основываясь на маркетинговой бумашке? Ок, наверное тогда ты прав.

Если я отключу кеш на рейде, иопсы просто упадут и там и там, о наличии кеша в гипервизоре это ничего не скажет.

И не надо отключать. Задуши память гипервизора (выдай все в клиента) и тестируй на большом файле, этого будет достаточно чтоб задушить оба кеша.

В ESXi нет хост системы как таковой, это bare metal hypervisor.

Есть вещи, которые вызывают подозрения и которые имеет смысл маркетологам приукрашивать, а есть вещи достаточно очевидные. Так вот write-through i/o через гипервизор это как раз вещь очевидная.

А деньги конторы я трачу чтобы система работала как часы. Я пробовал XEN/RHEV и, прости госпади, Hyper-V и мне не понравилось. Меня вполне устраивает простота в настройке, фичи, стабильность и производительность VMWare, да и тесты как видно это подтверждают, хотя кое-кто и придумывает мифические кэши :)

да и тесты как видно это подтверждают

Чтож ты боишься ещё одного теста, раз все подтвеждается?

В ESXi нет хост системы как таковой, это bare metal hypervisor.

Чего?

Ок, спецательно для неверующих. Выделил максимум памяти гостю и залочил ее (предотвращает свап VM):

# fio fio.write
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=16
2.0.8
Starting 1 process
Jobs: 1 (f=1): [w] [100.0% done] [0K/5546K /s] [0 /1386  iops] [eta 00m:00s]
writetest: (groupid=0, jobs=1): err= 0: pid=1547
  write: io=8192.0MB, bw=6477.4KB/s, iops=1619 , runt=1295079msec
    slat (usec): min=5 , max=13350 , avg=12.92, stdev=20.09
    clat (usec): min=116 , max=67608 , avg=9862.70, stdev=21243.83
     lat (usec): min=150 , max=67614 , avg=9876.18, stdev=21243.28
    clat percentiles (usec):
     |  1.00th=[  334],  5.00th=[  422], 10.00th=[  466], 20.00th=[  532],
     | 30.00th=[  596], 40.00th=[  652], 50.00th=[  716], 60.00th=[  772],
     | 70.00th=[  812], 80.00th=[  876], 90.00th=[58624], 95.00th=[59648],
     | 99.00th=[60160], 99.50th=[60672], 99.90th=[61184], 99.95th=[61184],
     | 99.99th=[61696]
    bw (KB/s)  : min= 3744, max=84809, per=100.00%, avg=6480.12, stdev=1822.61
    lat (usec) : 250=0.25%, 500=14.50%, 750=41.56%, 1000=26.83%
    lat (msec) : 2=1.02%, 4=0.03%, 10=0.01%, 20=0.01%, 50=0.01%
    lat (msec) : 100=15.80%
  cpu          : usr=1.04%, sys=3.07%, ctx=309548, majf=0, minf=22
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=2097152/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=8192.0MB, aggrb=6477KB/s, minb=6477KB/s, maxb=6477KB/s, mint=1295079msec, maxt=1295079msec

Disk stats (read/write):
  sdb: ios=91/2096862, merge=0/0, ticks=12/20462108, in_queue=20461248, util=99.95%

Я нашел интерестную стать о том как это работает: http://www.virtualinsanity.com/index.php/2010/02/05/vmware-pvscsi-when-and-wh...

Это соответствует цитате, которую ты приводил, что варя, подтверждает запись, только после подтверждения от железа. Но беда в том, что она запись буферизует.

Т.е. что присходит. Гость говорит запиши блок с адресом A, но варька этого не делает сразу, а ждет, не скажет ли гость следом, запиши мне A+1. Если сказал, то мы в шеколаде, т.к. запись на реальный диск идет довольно большими блоками, заведом большими чем блоки fs или базы данных, она может за одну транзакцию сразу записать и A, и A+1. Т.е. iops растут, но ценой увеличения latency.

А вот теперь вопрос, а что будет если мы имеем OLTP базу данных, которая все время говорит, запиши мне A и A+100500 - в одну транзакци это не умещается и iops падают, но latency не падает, т.к. варька все равно ждет некоторое время A+1.

Именно эту ерунду я и наблюдаю у клиентов часто.

Все вышесказанное теоретика, т.к. не знаю я как оно внутри, вижу только паршивые эффекты.

Ок, согласен, термин немного маркетинговый, но тем не менее.

В данном случае он работает как Xen, который запускается до ОС, которой там является dom0, а тут сервисная консоль.

Hyper-V и KVM работают по другому - сначала грузится ОС, а в ней уже всё остальное.

Ок, спецательно для неверующих.

Спасибо. Я не то, чтобы сволочь, я просто пытаюсь понять, почему у наших клиентов вечные проблемы с варей и нагруженными базами.

Ну разница не велика, насколько я понимаю. Xen загружается вроде так, как ты сказал, но дальше начинает брать ресурсы, которые виртуализированы в Dom0, через всякие blk<что-то> процессы.

Это относится только конкретно к pvSCSI драйверу, который делает активный I/O Coalesce, а не к гипервизору в целом.

Если такое положение не устраивает, то можно юзать LSI драйвер, кто ж мешает.

Кстати, сетевые и рейд контроллеры многие тоже делают I/O coalesce. И отключение его обычно приводит только к снижению latency, но не увеличению производительности и снижению cpu load.