Символика эта и так на слуху, потому нет смысла подробно объяснять, что это за зверь.


Здесь не будет сравнения с LVM, ибо сравнивать muscle-car с jet-truck'ом хоть и можно, но бессмысленно.
Графиков и комиксов так же не завезли.
Это, скажем так, незавершенная история успеха, потому что апгрейд, которым она была вызвана, можно лишь прекратить, но не завершить.


Предпосылки


Практически в каждой айтишной семье присутствует несколько ПК и/или ноутбуков, наверняка имеется перероутер-HTPC, а то и вовсе какой-нибудь NAS. Вот и у нас было два ПК, потом добавился большой настенный монитор, а при таком раскладе рождение HTPC — вопрос времени. Когда он появился на свет, тут же был наречен гордым именем — Сервер. Позже выяснилось, что чаcть любимых игр умеет в Linux — и Сервер тут же обзавелся аккаунтом Steam.

Так прошло несколько лет, в течение которых Сервер получил 16ГБ памяти, на нем появились виртуалки с gitlab и проектами...


А потом пришло понимание, что назревает апгрейд, и апгрейдить сразу 3 ПК слишком накладно; в то же время, уже был успешный опыт с PCIE-passthrough и игровой виртуалкой.


Подходящим решением стала поэтапная миграция игровых машин в виртуалки. Пока смигрирована только одна, в дальнейшем под гостем я буду подразумевать именно её.
Из трех процессоров (i3-3220, i5-3470, i5- 3470K) VT-d поддерживал только второй, он и ушел в Сервер вместо i3. Была куплена низкопрофильная 1050Ti на замену 7970, а старое железо продано по частям.


Сервер получил последнюю UEFI-прошивку, Ubuntu 16.04 и самый большой из имевшихся SSD — Crucial M4, на 256 ГБ, под корневой пул. Установка проводилась по этому манулу, из которого был накопипащен в live-системе установочный скрипт. Потом, уже после успешной загрузки, были доустановлены virt-manager, libvirt-bin, ovmf и xubuntu-desktop. Разумеется, были включены VT-x и VT-d.

Кстати, отделение бинарной части системы от логов, кешей и прочих хомяков не раз помогало в процессе вивисекции системы экспериментов, позволяя вернуть рабочее состояние простым zfs rollback, доступным даже из initrd (но есть особенность: если вы используете отдельный датасет для /root — используйте параметр ядра init=/bin/sh для аварийной загрузки; sh, в отличие от bash, не будет создавать мусор в точке монтирования /root).
Чтобы в случае проблем с загрузкой не гадать, что же случилось, в /etc/default/grub закомментируйте все, что касается HIDDEN_TIMEOUT, установите явно таймаут отличный от 0 (у меня 10), раскомментируйте/добавьте GRUB_TERMINAL=console и обязательно уберите quiet splash из GRUB_CMDLINE.


Error-43 и все-все-все


  • первоначальная конфигурация
    UEFI на хосте и госте оказались залогом безболезненного проброса и работы видеокарты, но для этого видеокарта должна иметь полностью UEFI-совместимую прошивку. Мне повезло с этим, и старая референсная 7970 и новая 1050Ti были совместимы. Для создания UEFI-гостя потребуется пакет ovmf, также (если будете создавать гостя с помощью virt-manager) необходимо поставить галочку на последней странице мастера выбрать и выбрать UEFI в качестве микрокода и Q35 в качестве чипсета. На моей системе без выполнения этих действий гостевая система имела странные проблемы с замираниями и заиканием звука.
  • проброс устройств
    Для проброса устройств необходимо указать ядру использовать специальный драйвер — vfio-pci или pci-stub (уже устарел) для определенных id vfio-pci.ids=10de:1c82,10de:0fb9,8086:1e31 (у меня проброшены сама видеокарта, ее звук и четырехпортовый USB3-контроллер) и разрешить использование iommu intel_iommu=on (на AMD прописываются другие параметры, но за неимением врать не буду). Также для проброса видеокарты понадобится явно запретить ее использование видеодрайвером, так как пробрасывалась nvidia и проприетарный драйвер установлен не был, то у меня это выглядит так: modprobe.blacklist=nouveau nouveau.modeset=0. Все эти параметры прописываются в файле /etc/default/grub, в строке GRUB_CMDLINE. Не забудьте выполнить update-grub и перезапуститься перед добавлением подготовленных к пробросу устройств в гостя.
  • nVidia, или "ничего личного, это просто бизнес".
    К сожалению, в этой жизни ничего не получается просто и сразу, вот и меня ждала печально известная Error 43. Трюк с cpu=host хоть и полезен, но не помог. К счастью, оказалось достаточно воспользоваться virsh edit <guestname>, и в секции <features>/<hyperv> добавить строчку <vendor_id state='on' value='ASUS'/>. Но в свою очередь, libvirt из репозитория (включая backports) слишком протух и не понимал этого параметра. После нескольких неудачных попыток собрать и установить более свежую версию, я обратился к ppa, и у Jacob Zimmermann нашелся подходящий пакет. Рекомендую, найдя стабильную версию, не обновлять драйвера на видеркарту в госте, ввиду постоянной мутации бизнес-бага с пробросом.

Использование ZFS


  • LXC
    Тут все очень просто — создаем датасет (например, так: zfs create rpool/lxc), запускаем lxc init, выбираем тип хранилища ZFS, отказываемся от создания пула, соглашаемся на использование датасета, вводим имя созданого чуть ранее датасета. Сейчас там живут gitlab, samba-dc (с ключем --usentvfs, на самбе старше 4.3 не заведется), пара мелких проектов.
  • Дедупликация, сжатие и блоки.
    Для предоставления гостям блочных устройств я использую zvol — его сложно случайно удалить, просто создавать индивидуальные снимки. Но у zvol есть одна хитрая особенность: если он не разреженый (ключ -s при создании), то снимок будет занимать столько же места, сколько и оригинал.

    При использовании ZFS есть два способа сэкономить место на диске — это сжатие и дедупликация. И если со сжатием все понятно, то дедупликацию стоит разобрать поподробнее.

    Накладные расходы на дедупликацию составляют от ~200 до ~700 байт в памяти на реальных системах (подробнее можно посмотреть в выводе zdb -D <poolname>), а DDT (таблица дедупликации), размер которой зависит напрямую от количества уникальных блоков, должна храниться в памяти целиком; и это значит, что использовать дедупликацию с маленьким размером блока попросту невыгодно (кроме, разве что, фермы виртуалок с dedup_ratio намного большим единицы и титаническим количеством оперативной памяти). Кроме того, с маленьким размером блока (это касается в первую очередь zvol) невозможно использовать сжатие, отличное от zle.

    Стоит ли говорить, что размер блока zvol должен совпадать с размером кластера расположенной на нем ФС, а сама она должна быть выровнена по размеру блока (современные утилиты давно выранивают по границе 1МБ, чего более чем достаточно)?

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

    Так что, все zvol я создаю командой zfs create -V <size> -s -b 64K <zfs path>, добавляя -o dedup=on и -o compression=lz4 по необходимости.
  • 64КБ — наш выбор.
    Осталось научить гостя загружаться и работать с ФС с таким размером кластера. В случае с Linux применение ext4, например, с таким размером кластера невозможно — ее просто не удастся смонтировать. Однако, манипулируя параметрами монтирования stride и stripe-width можно добиться желаемого поведения.

    В случае с NTFS все хитрее и проще одновременно: Windows создает служебные разделы, содержимое которых меняется крайне редко, поэтому на размер их кластера можно не обращать внимания (а у загрузочного раздела еще и не удастся поменять — ни bootmgr ни ntldr не понимают размер кластера больше 4КБ). Если после выбора нераспределенного места нажать не кнопку "Установить", а "Создать", то установщик создаст и отформатирует все нужные разделы, а у вас появится номер диска и номер раздела, в который будет установлена гостевая система.

    Далее понадобится немного черной магии:
    • чертим пентаграмму, не забывая на каждое перекрестье линий установить по одной черной однажды уже горевшей свече
    • вызываем дремора рангом не ниже кинвал cmd (нажимаем Shift-F10)
    • запускаем diskpart, и далее в нем
    • select disk <номер диска>
    • select partition <номер раздела>
    • format FS=NTFS UNIT=64K QUICK
    • assign LETTER=S
    • покидаем diskpart
    • в cmd выполняем mkdir s:\windows.

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


Что это было?
 Ну, системный диск отформатирован с размером кластера 64КБ, и Windows внушено, что на диске уже есть ее инсталляция, поэтому форматировать его с настройками по умолчанию - не нужно. Грязный хак? Ну да, так в этом же суть построения Windows-систем: заставить ее делать то, что нужно, а не то, что ей хочется.

Дедуплицировать Steam, или с чего все и начиналось


Самый простой способ был завести smb или nfs шары и создать на них библиотеки Steam. Обычные файлы легко и естественно дедуплицируются, включая как экспортированные библиотеки, так и библиотеку Linux-клиента, без лишних телодвижений. Как и всегда, самое очевидное решение оказалось в принципе рабочим, но неправильным. SMB в таком режиме шевелится со скоростью ноутбучного жесткого диска, несмотря на то, что файлы лежат на SSD. NFS (а Windows 8.1 поддерживает NFS v3, не 4) шевелился чуть шустрее, по ощущениям как какой-нибудь "зеленый" десктопный диск, но этого все равно было слишком мало для комфортной игры. К тому же, все ОС от M$ обожают терять сетевые диски, автоматически подключаемые при логоне, и каждый раз указывать Steam на местоположение библиотеки быстро надоест.

Подходящим решением стало iSCSI. На Сервер был установлен targetcli, настроен по этому манулу с поправкой на использование blockio и путем вида /dev/zvols/<zfs path>. Для правильной работы unmap нужно использовать Windows 8+ (начиная с 8 реализована поддержка unmap для iSCSI-инициатора), а для каждого блочного устройства прописать set attributes emulate_3pc=1,emulate_tpu=1,emulate_caw=1,emulate_tpws=1,emulate_tas=1. Если все сделано правильно, то и удаление файлов и форматирование должно освобождать место и сокращать размер zvol.

Теперь одинаковые файлы в экспортируемых под библиотеки томах занимают место лишь однажды, однако библиотека Steam для Linux все равно занимает отдельное место. Создадим отдельный датасет под эту библиотеку с опциями -o dedup=on -o recordsize=64K. Если разделы в zvol выровнены по границе 1МБ, и размер кластера установлен в 64КБ, то логично, что делить файлы на хосте надо с той же гранулярностью, чтобы дедупликация могла найти одинаковые блоки.


Последствия


  • 16ГБ памяти, имеющихся у меня дома, таки маловато для гостя с 8ГБ, firefox на хосте, контейнеров и прочего — время от времени наступают странные подтормаживания, сопровождающиеся интенсивной дисковой активностью.
  • дедуплицированное хранилище лучше сделать отдельным пулом.
  • установка zfs set logbias=throughput <pool> значительно влияет на производительность, особенно при использовании дедупликации. Мало того, что при этом исключается дополнительный цикл запись-в-лог/стирание-лога, так еще и перестает вымываться кеш записи накопителя.
  • на гигабитной сети zvol на SSD ощущается намного быстрее жесткого диска, хотя заметно медленнее локального SSD
  • я задумался о 960EVO на 1ТБ

Вместо заключения


Что ж, мой маленький эксперимент завершился несомненным успехом, хотя на пути возникли трудности. Далее хотелось бы апгрейд на Zen2, 32-64ГБ памяти, NVME SSD, перенос второго ПК на Сервер… но это уже будет совсем иное колдунство.

Комментарии (27)


  1. Darka
    05.10.2017 20:01
    +1

    Можно было поступить проще — www.proxmox.com/en/proxmox-ve


    1. khajiit Автор
      05.10.2017 21:14

      Конечно можно. Из него даже десктопную систему сделать можно.
      Но:
      — в его основе 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 занял бы достойное место.


      1. kvaps
        06.10.2017 18:34

        Возможно я смогу ответить на некоторые ваши вопросы:

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

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

        Скрытый текст


        1. khajiit Автор
          06.10.2017 22:24

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


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

          Тут какая штука… По тексту не раз упоминалась аббревиатура 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 вынесено аж в заголовок) меньше всего хочется разбираться что там опять сломалось. Хотя на производстве, где обновления контролируются, где есть резервный узел, на который можно переехать в случае неудачи, пожалуй стоило бы применить.


          1. kvaps
            07.10.2017 11:58

            Мультимедия

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


            Бекап...

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


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

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


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


            1. DaylightIsBurning
              07.10.2017 16:54

              а какие проблемы с all-in-one в production? Я уже несколько раз об этом слышал, но объяснений нигде не встречал.


              1. kvaps
                07.10.2017 18:22

                Ну в production, чем надёжнее тем лучше. All-in-one установки по определю не могут быть более стабильными чем отдельно взятые компоненты в изолированных окружениях. В случае чего достаточно просто заменить отдельный компонент без ущерба для всей системы.
                Второе качество — это воспроизводимость установки и простота обновления. Никому не хочется возиться с патчами и со сборкой кастомных пакетов если того действительно не требуется. Чем проще — тем лучше.
                Это не говоря ещё о live-migration и high availability.


  1. khajiit Автор
    05.10.2017 21:11

    deleted


  1. VioletGiraffe
    06.10.2017 08:42

    А можно поподробнее о пробросе видеокарты? Какие задачи это позволяет выполнять? Ведь даже если у вас гигабитный Ethernet, это на порядки медленнее скорости шины PCI-E.


    1. xp3
      06.10.2017 13:23
      +1

      по-моему имеется ввиду проброс видеокарты из гипервизора в гостевую ос для игр, к которой пользователь подключается по rdp\vnc\…


      1. VioletGiraffe
        06.10.2017 13:57

        Вот с пробросом в гостевую ОС понятно. Непонятно, чего дальше можно добиться. По RDP / Teamviewer играть же невозможно.
        У меня ещё с детства была мечта, чтобы был в доме один мощный комп, к которому могли бы подключаться тонкие клиенты (таких терминов я тогда не знал, но идея уже оформилась). И вот если для работы в обычных приложениях действительно можно зайти удалённо с ноутбука / планшета (хотя всё равно Teamviewer притормаживает, полного комфорта нет), то для удалённого запуска игры я до сих пор технологий не видел. Хотя технически это уже должно быть посильно, внутри одного дома так точно.


        1. khajiit Автор
          06.10.2017 14:08

          А, тут все просто — монитор живой, по HDMI/DP отлично передается звук и картинка.
          Основная проблема в квартире — USB, он по прежнему не любит длинных кабелей.
          Удаленный запуск игр это nVidia GRID, у AMD тоже что-то есть, но цены не домашние. У Steam есть «домашняя трансляция», но это не совсем то…


          1. VioletGiraffe
            06.10.2017 14:59

            Спасибо за советы! Тоже думал об этом, но, во-первых, кабели, а во-вторых, в планшет или ноутбук HDMI не воткнёшь. То есть это тоже неплохой выход в некоторых условиях, но мне не подходит.


          1. kvaps
            06.10.2017 18:47

            Вот все не доходят руки потестить вытянет ли spice по гигабиту приемлимую картинку или нет. Судя по ощущениям должен, т.к. работает он уж точно быстрее RDP. Кстати USB он тоже умеет пробрасывать. Обязательно отпишитесь если попробуете :)

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


            1. khajiit Автор
              06.10.2017 23:43

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


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


              1. kvaps
                07.10.2017 11:21

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

                По steam: Спасибо за инфу, в принципе со стороны разработчиков это и правда было логично вынести кодирование на уровень железки, почему нет?


          1. lehnh
            06.10.2017 23:24

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


            1. khajiit Автор
              06.10.2017 23:52

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


              1. lehnh
                07.10.2017 10:51

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


                1. khajiit Автор
                  07.10.2017 23:37

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


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


                  1. lehnh
                    09.10.2017 13:25

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


                    <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>


                    1. khajiit Автор
                      09.10.2017 14:29

                      Моя простынка
                      <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>


        1. xp3
          06.10.2017 14:09

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


    1. khajiit Автор
      06.10.2017 13:38

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


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

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


  1. fido_max
    06.10.2017 11:01
    +1

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


    1. khajiit Автор
      06.10.2017 13:49

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


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


  1. khajiit Автор
    06.10.2017 14:10

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

    Создатель контента может проигноривать фидбек или нет, но без фидбека в принципе развитие контента невозможно, только все более унылые штамповки.