Pull to refresh

Comments 31

Конечно можно. Из него даже десктопную систему сделать можно.
Но:
— в его основе debian-stable, и хорошо еще что не oldstable. А это значит deb-multimedia.org, это квест собери крыску из двух сотен пакетов, это жди пока обновят то, что в некоторых дистрибутивах давно вошло в mainline (кстати, dvbsnoop x64 в debian все еще с багом подсчета crc?) и прочие недостатки стабильных дистрибутивов в домашнем применении.
— управление zvol. По умолчанию blocksize=8K, опций в нем я так и не нашел где задать — значит лезем в консоль или организуем дополнительное хранилище
— iscsi. Не знаю, какой там по умолчанию таргет, но пока настраивался trim, выяснилось, что его в iscsi минимум три вида — Unmap, WriteSame, и CompareAndWrite. Проверять что там и как и донастраивать пришлось бы обратно ручками
— как Proxmox относится к бэкапу zvol с нестандартными свойствами и сможет ли восстановить — тоже требует исследований ручками, и никто не гарантирует что в будущем поведение не поломают

Итого из всех двух преимуществ Proxmox (легкая настройка из морды и простая живая миграция из коробки) первого не видно, второе для домашней системы неактуально, а бонусом идет когнитивный диссонанс от использования stable на десктопе (HTPC же).

Ну а если бы у меня был домашний ДЦ — то это была бы совершенно другая история, в которой Proxmox занял бы достойное место.
Возможно я смогу ответить на некоторые ваши вопросы:

> это значит deb-multimedia.org, это квест собери крыску из двух сотен пакетов
А зачем вам мультимедия на гипервизоре? — запустите контейнер и делайте внутри все чего душе угодно, не опасаясь при этом за хостовую систему.

> управление zvol. По умолчанию blocksize=8K, опций в нем я так и не нашел где задать
Размер блока — тут, thin provisioning там-же, другие опции только ручками.
Скрытый текст


> iscsi
iscsi там только в качестве клиента для внешних стораджей, и зачем вам дома iscsi?

> как Proxmox относится к бэкапу zvol
Бекап там идет только данных и конфига, то есть как zfs send или dd if=... и пайпом передается в lzo архив. Разворачивается так же, но в обратном направлении.

Для 2 и 3 вопроса, возможно вам будет интересно почитать мою статью:
All-In-One: Proxmox + OpenMediaVault или ещё одна идея для домашнего NAS

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


А зачем вам мультимедия на гипервизоре?

Тут какая штука… По тексту не раз упоминалась аббревиатура HTPC, прямо под катом сказано, что в моей семье он тоже появился, а тремя абзацами ниже упомянуто, что подходящим решением оказалась миграция игровых машин в виртуалки, и Сервер-HTPC получил поддерживающий VT-x процессор (i5-3470), память и наибольший из имевшихся SSD.
А у HTPC свои законы жанра. Это mini-ITX, редко micro-ATX, иногда встроенный WiFi, практически всегда низкопрофильный Desktop-корпус, в котором даже если и есть поддержка micro-ATX — то нет места для установки платы полной ширины, могущей нести на себе четыре слота памяти и два слота x16 под видео (и даже если бы он был — там же еще второй ПК на очереди в переезд). Вот и у меня оказалась GA-H77N-WIFI, mini-ITX, с единственным слотом PCI-E, в который, как вы несомненно помните, должна встать 1050Ti. Интеловские встройки в принципе стало возможно пробрасывать относительно недавно, а жаловаться на них народ прекратил и вовсе всего-то в прошлом году (уже на Sky Lake), и мой Ivy так не умеет.
Так что единственным вариантом было оставить встройку хосту, а значит и мультимедию тоже на нем поднимать.


Размер блока — тут

А за это — отдельное спасибо. Когда я гонял только вышедший Proxmox 5.0 — обыскался этого поля. Тем не менее, за dedup и compression все равно придется лазить в консоль.


Бекап...

Но тут есть ньюанс: zfs send делает dump stream, а zfs send -Rreplication stream, включающий в себя и свойства zfs. При выполнении zfs recv в первом варианте от исходного zvol будет взят только blocksize и sparce, а остальное унаследовано от родительского датасета; а в случае replication stream восстановится оригинальный zvol со всеми заданными свойствами.
Бекап же sparce zvol с помощью dd, это вообще сюр.
У меня сейчас на пуле в 236GB свободно 118ГБ, при этом выделено около 600ГБ. Неправильное восстановление банально исчерпает место на пуле, отчего работающая виртуалка получит отказ на запись в системный том и упадет.


зачем вам дома iscsi

Windows очень отвратно работает с большим количеством рандомных запросов как с smb так и с nfs шарами, об этом я упомянул в первом же абзаце "Дедуплицировать Steam". И это при том, что практически SSD насытить запросами так, чтобы скорость упала ниже 112 МБ/с (1ГБит) можно только полностью случайными запросами.
Конечно, всегда можно чего-нибудь потюнить, но связку zvol + iscsi я опробовал годом ранее на FreeBSD 10 — и она просто работает и не проседает. Оставалось придумать трюк, чтобы заработала дедупликация как между zvol так и с библиотекой в датасете на хосте.
Жаль только, что в targetcli, в отличие от ctld unmap настраивается не так тривиально.


Кстати, статью вашу я прочёл сразу как она вышла, на хабре я зависал еще до эпопеи с мегамозгом. Но сборка копонент вручную и пересборка пакетов ведут ко вполне естественным последствиям, а дома (@home вынесено аж в заголовок) меньше всего хочется разбираться что там опять сломалось. Хотя на производстве, где обновления контролируются, где есть резервный узел, на который можно переехать в случае неудачи, пожалуй стоило бы применить.

Мультимедия

DaylightIsBurning описывал способ проброса аппаратного ускорения в lxc-контейнер, а если ничего кроме этого вас на хосте больше не держит, почему бы не переехать в контейнер?


Бекап...

К сожалению свойства в бекап не включаются, снапшоты удаляются. Если галочкой отмечен "Thin provisioning" бекап будет восстанавливаться как разреженный том.
Кстати в случае если у вас контейнер а не виртуальная машина, будут забекапленны только файлы а не весь volume.


Хотя на производстве… пожалуй стоило бы применить.

Поверьте не стоит :)
В производстве лучше вообще не допускать all-in-one установок под страхом жизни.
Либо отдельная железка, либо отдельная виртуалка — не иначе.


Тем не менее спасибо за статью, очень ждем продолжения :)

а какие проблемы с all-in-one в production? Я уже несколько раз об этом слышал, но объяснений нигде не встречал.
Ну в production, чем надёжнее тем лучше. All-in-one установки по определю не могут быть более стабильными чем отдельно взятые компоненты в изолированных окружениях. В случае чего достаточно просто заменить отдельный компонент без ущерба для всей системы.
Второе качество — это воспроизводимость установки и простота обновления. Никому не хочется возиться с патчами и со сборкой кастомных пакетов если того действительно не требуется. Чем проще — тем лучше.
Это не говоря ещё о live-migration и high availability.
А можно поподробнее о пробросе видеокарты? Какие задачи это позволяет выполнять? Ведь даже если у вас гигабитный Ethernet, это на порядки медленнее скорости шины PCI-E.
по-моему имеется ввиду проброс видеокарты из гипервизора в гостевую ос для игр, к которой пользователь подключается по rdp\vnc\…
Вот с пробросом в гостевую ОС понятно. Непонятно, чего дальше можно добиться. По RDP / Teamviewer играть же невозможно.
У меня ещё с детства была мечта, чтобы был в доме один мощный комп, к которому могли бы подключаться тонкие клиенты (таких терминов я тогда не знал, но идея уже оформилась). И вот если для работы в обычных приложениях действительно можно зайти удалённо с ноутбука / планшета (хотя всё равно Teamviewer притормаживает, полного комфорта нет), то для удалённого запуска игры я до сих пор технологий не видел. Хотя технически это уже должно быть посильно, внутри одного дома так точно.
А, тут все просто — монитор живой, по HDMI/DP отлично передается звук и картинка.
Основная проблема в квартире — USB, он по прежнему не любит длинных кабелей.
Удаленный запуск игр это nVidia GRID, у AMD тоже что-то есть, но цены не домашние. У Steam есть «домашняя трансляция», но это не совсем то…
Спасибо за советы! Тоже думал об этом, но, во-первых, кабели, а во-вторых, в планшет или ноутбук HDMI не воткнёшь. То есть это тоже неплохой выход в некоторых условиях, но мне не подходит.
Вот все не доходят руки потестить вытянет ли spice по гигабиту приемлимую картинку или нет. Судя по ощущениям должен, т.к. работает он уж точно быстрее RDP. Кстати USB он тоже умеет пробрасывать. Обязательно отпишитесь если попробуете :)

А есть информация как steam стримит? Уж очень уж интересно они как они так хитро картинку жмут что им удалось от тормозов избавиться?

Для spice нужен QXL, разве нет? А видео будет на железной видеокарте.


Только что попробовал стимовскую трансляцию — кодит оно на видюхе, используя аппаратный блок для захвата и кодирования, так что тормозов там минимум. У меня это должен быть nvenc, на радеонах тоже довольно давно есть что-то подходящее. В особо динамичных сценах, особенно с глобальным изменением яркости, картинка рассыпается в квадратики, но в целом — отлично. И в Divinity Original Sin EE (RPG с пошаговой боевкой) и в Borderlands 2 (мясной шутер) с Гарольда отлично попадаю. При должном навыке можно и поснайперить за Зер0.

QXL нужен только для вывода картинки, оставить обсчитывать можно ту же самую nvidia. В linux это можно сделать через Bumblebee, в Windows вроде так умеет стандартный драйвер, технология называется Nvidia Optimus.
Это чаще используеься для переключения интегрированной/дескретной графики на ноутбуках, но, я думаю, должно сработать и в данном случае.

По steam: Спасибо за инфу, в принципе со стороны разработчиков это и правда было логично вынести кодирование на уровень железки, почему нет?
SteamLink отличная штука, качество изображения по езернет кабелю практически не теряется, по 5ГГц вайфаю чуть похуже, но все равно отличное.
А вот проблему Error 43 я побороть так и не смог. Дрова нвидии хорошо научиилсь детектить гипервизоры. Есть патч в общем-то, можно распаковать драйвера, пропатчить, подписать самоподписаной цифровой подписью, включить в винде режим девелопера и установить такой драйвер. Но патч работает с довольно старыми версиями драйверов, 1060 мне с ним завести не удалось, к сожалению.
Покупал для этих целей райзен7, 32Гб рам и 1060 прямо перед криптовалютным бумом. А когда понял, что надо было брать радеон 580 для этого кейса, цены на них уже взлетели до облаков.

У меня получилось с 1050Ti без патча, архитектурно они — один и тот же Pascal.
Какая хост система?
Чистый qemu, libvirt, еще что-то? Каких версий?
Гость 7/8/8.1 или 10?
Параметры ядра?

Убунта 16.04, либвирт 2.4+ который умеет все необходимые параметры. Гость вин10.

Провел эксперимент с десяткой.


Доп. параметры virt-manager


Включение UEFI и чипсет Q35


Error 43 сразу после установки драйверов


Diff конфигурации ВМ, задаваемой через virsh
26a27
>       <vendor_id state='on' value='ASUS'/>
27a29,31
>     <kvm>
>       <hidden state='on'/>
>     </kvm>
29,30c33,34
<   <cpu mode='custom' match='exact'>
<     <model fallback='allow'>IvyBridge</model>
---
>   <cpu mode='host-passthrough'>
>     <topology sockets='1' cores='2' threads='1'/>
35c39
<     <timer name='hpet' present='no'/>
---
>     <timer name='hpet' present='yes'/>
39c43
<   <on_reboot>restart</on_reboot>
---
>   <on_reboot>destroy</on_reboot>
93,95d96
<     <controller type='virtio-serial' index='0'>
<       <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/>
<     </controller>
99a101,103
>     </controller>
>     <controller type='virtio-serial' index='0'>
>       <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/>

Oll Korrekt


libvirt 2.2.0
qemu 2.6.2
ovmf из штатного репо

Странно. Возможно, дело в разнице между амд и интелом. Конфиги у меня аналогичные.


<domain type='kvm'>
  <name>win10</name>
  <uuid>ed603f1e-1b20-6d3a-4536-fe92b90e9c18</uuid>
  <memory unit='KiB'>6291456</memory>
  <currentMemory unit='KiB'>6291456</currentMemory>
  <memoryBacking>
    <hugepages/>
  </memoryBacking>
  <vcpu placement='static'>4</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='8'/>
    <vcpupin vcpu='1' cpuset='10'/>
    <vcpupin vcpu='2' cpuset='12'/>
    <vcpupin vcpu='3' cpuset='14'/>
  </cputune>
  <resource>
    <partition>/machine</partition>
  </resource>
  <os>
    <type arch='x86_64' machine='pc-q35-2.5'>hvm</type>
    <loader type='rom'>/usr/share/ovmf/OVMF.fd</loader>
    <boot dev='hd'/>
    <bootmenu enable='no'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <hyperv>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='8191'/>
      <vendor_id state='on' value='Fixed43'/>
    </hyperv>
    <kvm>
      <hidden state='on'/>
    </kvm>
  </features>
  <cpu mode='host-passthrough'/>
  <clock offset='localtime'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  ...
</domain>
Моя простынка
<domain type='kvm'>
  <name>win8.1</name>
  <uuid>09d3f34c-a9ef-44e7-9c09-960c6fa8896e</uuid>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='x86_64' machine='pc-q35-2.6'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/win8.1_VARS.fd</nvram>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <hyperv>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='8191'/>
      <vendor_id state='on' value='ASUS'/>
    </hyperv>
    <kvm>
      <hidden state='on'/>
    </kvm>
  </features>
  <cpu mode='host-passthrough'>
    <topology sockets='1' cores='2' threads='1'/>
  </cpu>
  <clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='yes'/>
    <timer name='hypervclock' present='yes'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>destroy</on_reboot>
  <on_crash>restart</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>

Из существенных отличий:


      <vendor_id state='on' value='ASUS'/>

и


  <clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='yes'/>
    <timer name='hypervclock' present='yes'/>
  </clock>

У меня реальный vendor_id и в клоках разрешен HPET.
Кстати, ранее в параметры ядра требовалось прописывать что-то вроде iommu=pt и разной другой магии.

Вряд ли они проверяют vendor_id, слишком неуниверсально. Надо попробовать с таймером поиграться кстати.
Попробуйте

<features>
    <acpi/>
    <apic/>
    <hyperv>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='8191'/>
      <vendor_id state='on' value='lol'/>
    </hyperv>
    <kvm>
      <hidden state='on'/>//////////// <-----------
    </kvm>
    <vmport state='off'/>
  </features>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
    <timer name='kvmclock' present='yes'/>
    <timer name='hypervclock' present='yes'/>
  </clock>


//что то синтаксис не подсвечивается, ну да ладно
vendor_id обязателен для обхода 43 ошибки. также важен биос с uefi, а он вроде есть только на pc-i440fx. у вас же стоит q35. поправьте, если ошибаюсь.
не задавался этим вопросом, но гигабитной проводной сети внутри дома должно быть достаточно для комфортной передачи картинки (и соответственной задержки) — так что проблема сводится к выбору ПО для подключения. С ТимВьюером работал — у него задержки точно большие, но тут думаю протокол обмена с сервером основную лепту вносит.
Не помню на гике или хабре недавно были статьи от какого-то сервиса предлагающие такого рода услуги (удаленный игровой пк) — уж если у них получается, то в локалке точно должно работать.

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


  • виртуализация игровой машины с пробросом из хост-системы в гостя видеокарты
  • iscsi как средство раздать одно и то же дисковое пространство как виртуалке, так и (пока еще) самостоятельному ПК
  • дедупликация как средство избежать размещения двух-трех идентичных наборов данных (библиотеки steam в моем частном случае, но для виртуалок тоже весьма годится)
    Через гигабитный Ethernet отдавался только iscsi-том. К сожалению, хоть проброс видеокарты как устройства через локальную сеть гипотетически и возможен, но практически был бы бесполезен.

Прошу прощения, если ввел вас в заблуждение.

Так и не понял, что именно мы получили в итоге и самое главное: какие в этом преимущества?

Получили в итоге минус один довольно жручий ПК, экономию места (и средств на приобретение дополнительного SSD во второй игровой ПК) за счет дедупликации, некоторое количество экспы.


Преимущества — меньше греющихся железяк, меньше незапланированных трат из семейного бюджета (и даже некоторая прибыль от реализации образовавшихся излишков).

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

Создатель контента может проигноривать фидбек или нет, но без фидбека в принципе развитие контента невозможно, только все более унылые штамповки.
Тоже используем PCI-passthrough дома на двух компьютерах. Но домашний «Сервер» просто NAS c пассивным охлаждением(какой-то целерон с tdp 4 ватта или вроде того), там просто файлопомойка на ZFS, и больше ничего.
PCI-passthrough используется для того, чтобы заблокировать в игровой Windows инет в секьюрити целях (кроме серверов стима) и отключить апдейты, а то в Windows 10 они слишком навязчвивые, а так же для того, чтобы не держать в ней никакого софта вроде браузера, телеграм-клиента итд — когда запущена Windows виртуалка, она занимает один из двух мониторов. На втором в это время остаётся хост-система, что очень удобно (в другое время HDMI-переключатель переключает второй монитор на Linux)
Sign up to leave a comment.

Articles