Comments 25
— монитор лишь один (с 2 входами и возможностью переключения между ними в настройках монитора)
— видеокарта без портов (т.е. она работает чисто как 3D-ускоритель, передавая картинку на встроенную графику по PCI-E)
таким образом, сетап соответствует схеме
"
Чисто теоретически есть, но сразу говорю, что я не пробовал данную методику, а описанная мной все же требует или видеопорт, подключенный напрямую к ВК, или прямой вывод дискретки на дисплей ноутбука:
https://gist.github.com/Misairu-G/616f7b2756c488148b7309addc940b28
Есть еще один вариант, это проброс интегрированной ВК в ВМ, судя по всему работает почти на любом ЦП от Интел, начиная с 4го поколения, но конкретно под ProxMox'ом работает медленно, есть вопросы по выводу изображения на дисплей. Гуглится по gvt-d
Встройку можно и целиком пробрасывать, как и отдельную видяху. И вывод на монитор будет работать без особых проблем. Даже звук по HDMI можно передавать, если ещё и встроенный звук пробросить.
А GVTd-D - это именно виртуальные ускорители графики, которых можно сделать несколько штук и пробросить в несколько виртуалок.
Но вывод на физический дисплей невозможен по определению.
Я глубоко не копал, но пробросить встройку как отдельную ВК в ВМ у меня не получилось с наскока. Чисто теоретически в этом случае изображение пойдет, для ноутбука, не на внешний дисплей, а на дисплей ноутбука, что сделает работу комфортной. Конечно мыслится что если физически прокинуть ядра ЦП + встройку + дискретку, то получим на выходе тот же ноутбук, но в виртуалке... Но практически пока что у меня не получилось.
Возможно это будет следующая тема для моей новой статьи.
Не совсем понимаю, зачем вообще это на ноуте?
А ещё если на ноуте есть дискретное видео, то в схеме "Muxed" дискретное видео не сможет выводить картинку на экран, хотя и будет доступно в хост-системе (т.к. мультиплексор управляется встроенной видяхой, а она недоступна хосту при пробросе в виртуалку)
Лично я этой темой заморачивался т.к. у меня неттоп, который и роутер и файлопомойка и куча чего ещё чисто серверного. И я решил, до кучи, сделать из него ещё и медиацентр (Kodi, Steam, RetroArch и т.д.) причем с виндой в отдельной виртуалке с возможностью подключать физическую клаву/мыш/геймпад
Не совсем понимаю, зачем вообще это на ноуте?
Виртуализация несет как плюсы, так и минусы. Лично для меня главное это удобства резервирования и безопасности.
Лично я этой темой заморачивался т.к. у меня неттоп, который и роутер и файлопомойка и куча чего ещё чисто серверного. И я решил, до кучи, сделать из него ещё и медиацентр (Kodi, Steam, RetroArch и т.д.) причем с виндой в отдельной виртуалке с возможностью подключать физическую клаву/мыш/геймпад
на чем реализовывали? каким гайдом пользовались для настройки?
Резервирование? Так это другими способами делается (Кажется у Акрониса была тулза, позволяющая делать снэпшоты диска и откатываться на них, если потребуется. Онаже позволяла вообще не сохранять изменения на диске при перезагрузке компа)
Безопасность? Вот тут не понял. Виртуалка от физического компа ничем не отличается. Если её хакнули - хакнут и всё остальное, т.к. оно всё в одной сети находится (Если только роутером всё не разграничено).
Медиацентр собирал сам по кусочкам из подручных средств. В основе - KODI. Из него уже запускается всё остальное, через плагины.
Конфиг самой виртуалки с виндой и проброшенной встроенной видяхой
agent: 1,fstrim_cloned_disks=1
args: -cpu host,+aes,hv_ipi,hv_relaxed,hv_reset,hv_runtime,hv_spinlocks=0x1fff,hv_stimer,hv_synic,hv_time,hv_vapic,hv_vpindex,+kvm_pv_eoi,+kvm_pv_unhalt,+pcid,+pdpe1gb,-hypervisor -device vfio-pci,host=00:02.0,id=hostdev0,bus=pci.0,addr=0x2,x-igd-opregion=on
balloon: 0
boot: order=scsi0
cores: 4
cpu: host
hostpci0: 0000:00:1f.3
machine: pc-q35-6.0
memory: 4096
name: MediaCenter
net0: virtio=01:02:03:04:05:06,bridge=vmbr0
numa: 0
onboot: 1
ostype: win10
scsi0: Home:108/vm-108-disk-0.raw,cache=writeback,discard=on,size=100G,ssd=1
scsihw: virtio-scsi-pci
smbios1: manufacturer=Rm94,base64=1
sockets: 1
startup: order=20,up=30
usb0: host=1-1,usb3=1
usb1: host=1-2,usb3=1
В "args" идут два параметра:
cpu - дефолтная строка запуска плюс host, aes и hypervisor. Последнее требуется для работы Bluestacks и некоторых других софтин, которые отказываются работать на виртуальном железе.
vfio-pci - собственно, проброс самой видеокарты. Тут важно "addr=0x2". Как я понял - драйвера на встроенную графику Intel гвоздями прибиты к этому адресу и если видяха не там - ничего работать не будет.
"hostpci0: 0000:00:1f.3" - это звуковуха. Работает только один раз. Если выключить виртуалку, то при следующем её включении звук "потеряется". Помогает только перезагрузка всего сервера (хоста).
Ps: До чего же неудобный и кривой редактор текста на хабре... жуть...
Резервирование? Так это другими способами делается (Кажется у Акрониса была тулза, позволяющая делать снэпшоты диска и откатываться на них, если потребуется. Онаже позволяла вообще не сохранять изменения на диске при перезагрузке компа)
Как по мне бэкап виртуалок удобнее и проще. Не нужно перезагружаться например, для отката. Я могу разворачивать несколько копий из бэкапа на одном и том же диске и ставить их параллельно. Акронис такое не позволит без танцев с бубном.
Безопасность? Вот тут не понял. Виртуалка от физического компа ничем не отличается. Если её хакнули - хакнут и всё остальное, т.к. оно всё в одной сети находится (Если только роутером всё не разграничено).
На Хосте Линукс, если настроить сеть для ВМ без доступа в интернет, то сохранность данных на виртуалке резко повышается, а всяких вирусов под линукс сильно меньше чем под винду.
Гипервизор себя ничем не выдает внешне, с учетом того что Линукс для большинства пользователей темный лес, то даже при попадении ноутбука в чужие руки, например хозяин ушел на обед, а вагончик ПТО оказался открытым с техникой для технадзора, то вытащить оттуда инфу он не сможет. Даже если вынет диск физически.
Хост предполагаю оставить для работы с тырнетом - Youtube + новости + почта. Тут все решается паролями.
vfio-pci - собственно, проброс самой видеокарты. Тут важно "addr=0x2". Как я понял - драйвера на встроенную графику Intel гвоздями прибиты к этому адресу и если видяха не там - ничего работать не будет.
Интересно. Нужно будет пробовать.
"hostpci0: 0000:00:1f.3" - это звуковуха. Работает только один раз. Если выключить виртуалку, то при следующем её включении звук "потеряется". Помогает только перезагрузка всего сервера (хоста).
у вас получилось изолировать устройство? У меня на домашнем ПК не вышло, в итоге вылетает вся группа, а в ней LAN... и привет сеть и тырнет.
у вас получилось изолировать устройство?
Вроде того. Proxmox позволяет частичный проброс, даже если в группе несколько устройств.
Моя IOMMU группа со звуковухой
IOMMU Group 14:
00:1f.0 ISA bridge [0601]: Intel Corporation B150 Chipset LPC/eSPI Controller [8086:a148] (rev 31)
00:1f.2 Memory controller [0580]: Intel Corporation 100 Series/C230 Series Chipset Family Power Management Controller [8086:a121] (rev 31)
00:1f.3 Audio device [0403]: Intel Corporation 100 Series/C230 Series Chipset Family HD Audio Controller [8086:a170] (rev 31)
00:1f.4 SMBus [0c05]: Intel Corporation 100 Series/C230 Series Chipset Family SMBus [8086:a123] (rev 31)
Не знаю, как, но SMBus, ISA, MemControl не прокинулись в виртуалку. Только звук. Остальное осталось в хосте и, вродь как, работает.
Ps: Сетевухи у меня все в отдельных группах (6 штук!)
Даже если вынет диск физически.
Если диск не шифрованный - достать данные ниразу не проблема.
Можно даже саму виртуалку запустить и зайти в неё.
В остальных случаях - Linux + CryptoFS или другим шифрованием. LVM или ZFS в качестве файлосистемы с поддержкой снепшотов.
И VirtualBox с виндой, если очень надо.
Не знаю, как, но SMBus, ISA, MemControl не прокинулись в виртуалку. Только звук. Остальное осталось в хосте и, вродь как, работает.
для их проброса в ВМ нужно принудительно прописывать, для хоста они тоже отваливаются, после старта ВМ с проброшенной звуковой картой введите на хосте lspci
Если диск не шифрованный - достать данные ниразу не проблема.
Можно даже саму виртуалку запустить и зайти в неё.
специалисту да это возможно, или good user'у, но у меня на участке народ не такой продвинутый что бы разобраться что на хосте с Линуксом крутится виртуалка и все данные в ней. Особенно если еще и Линукс затюнить под винду. Хотя на счет этого я еще не определился. За условные 10-30мин они не разберутся, мне этого достаточно. А если требуется отсутствовать дольше, то я всегда уношу с собой ноутбук в спец рюкзаке.
А GVTd-D — это именно виртуальные ускорители графики
Нет это именно проброс всей видяхи. И правильнее GVT-d, а виртуальные это GVT-g
Работать будет, но будет очень небольшой лаг, связанный с копированием памяти из дискретной GPU в встройку — именно этим и занимается Looking Glass.
upd не люблю менять то что написал но сначала не обратил внимание поэтому добавлю:
4.1 Linux при настройке локального времени почему-то считает что время установленное в BIOS это время по Гринвичу (GMT+0), в соответствии с локализацией к этому времени добавляются еще свой родной часовой пояс, MSK (GMT+3) в случае автора.
Это решаемо losst.ru/sbivaetsya-vremya-v-ubuntu-i-windows
4.1 Linux при настройке локального времени почему-то считает что время установленное в BIOS это время по Гринвичу (GMT+0), в соответствии с локализацией к этому времени добавляются еще свой родной часовой пояс, MSK (GMT+3) в случае автора. В то время как Windows время из BIOS считает местным, в зависимости от настроек часового пояса в системе юзера. Таким образом, если Linux стоит дуал-бутом в Windows и Linux, местное время в двух ОС принимает разницу в 3 часа. Немного неудобно.
скорее наоборот windows почему-то по умолчанию хранит время не в utc.
получается чтобы узнать какое время хранится в rtc, нам нужно где-то хранить стороннюю информацию: в каком часовом поясе мы находимся и был ли произведён переход на летнее/зимнее время.
например, в случае использования нескольких ос на одном компьютере мы получаем проблему с синхронизацией этой информации между ними.
И возникают одни вопросы, что такое сенсоры: temp1, Sensor 1, Sensor 2?
увы, датчики не унифицированы, нужно смотреть для вашей материнской платы (может быть кто-то выложил в гугле, или можно путём экспериментов с виндовым софтом или bios выяснить что где).
хотя на самом деле эта информация практически бесполезна.
Где тут температуры дискретной ВК
не подскажу, у меня как-то везде интегрированное видео.
возможно, их тут вообще нет )
посмотрите вывод консольного sensors, там понятнее какое значение к чему относится
и общей на ЦП!?
«Package id 0»
fancontrol у меня не установился
не установился или не получилось управлять оборотами кулеров? если второе, то, как я понимаю, это нормально для ноутбуков (
хотя могу ошибаться, у сейчас на руках только один нотбук с linux, оборотами там управляет bios, всё просто работает, не было даже повода разбираться.
то же самое с настольным компьютером: fancontrol работает, но схема из bios меня полностью устраивает, поэтому fancontrol удалил, зачем мне дополнительная потенциальная точка отказа.
fancontrol от Tuxedo в Debian ставится отказывается, в то время как tuxedo-control-center встал со скрипом… видимо в данном случае совместимость софта между Ubuntu и Debian не полноценная, а может быть я чего-то не знаю/не учел
смешивать пакеты из разных дистрибутивов (и даже из разных релизов одного дистрибутива) очень не рекомендуется.
а на вашем скриншоте видно, что вы пытаетесь установить одиночный deb-пакет, а он зависит от другого (а тот, возможно, от другого и т. п.).
если уж очень хочется попробовать, нужно прописать репозиторий в /etc/apt/sources.d
, тогда apt install сам сможет установить пакеты по зависимостям. но это на ваш страх и риск, гарантий, что всё пройдёт гладко дать не могу.
Спасибо за статью.
Когда по заказу пытался сделать DAW на виртуалке, посоветовался с опытным админом. Он сказал, что одного проброса мало, надо у хоста отгрызть часть ядер процессора на этапе загрузки и отдать их гостю полностью. Иначе хорошего тайминга не получить.
Но если всё железо отдавать гостю в монопольное владение, то может её загружать прямо на железе? Тогда я так и сделал. Вы не рассматривали вариант без виртуализации?
Работа в виртуальной машине имеет как свои плюсы, так и свои минусы, например виртуалку проще бэкапить и разворачивать, можно настраивать под разные задачи и прятать ее. С другой стороны ее работа требует определенного железа, обычно виртуалке не выделяется 100% ресурсов, пусть минимальные, но есть потери на виртуализацию, порядка 2-5%. Виртуализация это инструмент.
Лично для меня это способ, с одной стороны, перейти на Линкус максимально просто и безболезненно, но при этом для работы пользоваться софтом Windows, с другой стороны это дополнительная безопасность данных. У этого есть своя цена, озвученная выше, я считаю что меня она устраивает.
Согласен с вами, потеря ресурсов почти всегда минимальная. Но отзывчивость (latency) системы сильно страдает. Кстати, в вашем способе прокидывания дисков на виртуалку сильно падает скорость? Когда проверял на qemu, то хорошие результаты почти без потерь iops получил только с hostdev type='scsi'. Но в последних версиях он считается не самым быстрым.
В этом видео есть тесты скорости дисков
https://m.youtube.com/watch?v=wjlmWHJiEug
В первом случае это тест скорости чтения/записи в виртуальный SATA диск, который базируется на 2.5" SATA SSD Kingston 480Gb, второй тест это тест 3.5" SATA HDD WD Red 4Tb проброшенного в виртуалку напрямую, но без контроллера sata1: volume=/dev/disk/by-id/ata-WDC_WD40EFRX-68WT0N6_WD-WCC4E1АС9SХ9
Просадки есть, главным образом по чтению/записи рандомных блоков. Линейная скорость почти не просела
Меня результаты полностью устраивают, потому что для казуального гейминга, работы с видеоредактором и работы в офисе более чем хватает, на глаз я не вижу разницы.
GPU Passthrough хорошо работает почти для всех видеокарт, кроме последних iGPU интела (Intel Iris XE например).
Единственный гипервизор где работает проброс этих карт — это ACRN, но это это еще тот BDSM и глюкодром.
Так что последние NUC-и не советую брать, если интересует хоть какое-то использование интел графики в виртуальном окружении. Сам попал на это — лучше бы купил решение на амд. У интела обычно все лучше в плане дров для встройки под линуксом, но с последними они что-то накосячили и kvm/qemu с ними не работает нормально (вернее нужен специальный патченный видеобиос которого конечно же нет в наличии)
Плохо работает на amd платформах десктопных, требуются обновления bios, кучу шаманств с параметрами загрузчика и после этого переодические проблемы разного характера.
Также плохо работает на старых интелах, где нет поддержки в процессоре и с старыми bios
Также плохо работает на старых интелах, где нет поддержки в процессоре и с старыми bios
Ну это на ооочень старых интелах.
Плохо работает на amd платформах десктопных, требуются обновления bios, кучу шаманств с параметрами загрузчика и после этого переодические проблемы разного характера.
Но оно хотя бы работает. Т.е. если нужен Single GPU Passthrough и какой либо из новых процов, то тут только амд, т.к. повторюсь, что на 11-м поколении интела и выше пока что это не возможно (и бубен не поможет). И еще раз повторюсь что это есть в ACRN-е от интела, но продукт уж очень специфический и довольно таки глючный (хоть и очень интересный по фичам — например из коробки есть поддержка прямого вывода виртуальной GVT-g карты на hdmi и т.д.). И все бубны при настройке виртуалок и графики на амд, просто цветочки по сравнению с установкой и настройкой ACRN-а
начиная с 6-й версии ProxMox'а для случаев когда юзер для ВМ использует БИОС UEFI, а иначе ВК не пробросить в ВМ
Отлично всё работает на любом BIOS'е. Просто требуются разные шаманские обряды, чтобы оно заработало.
Хотя лично у меня всё работает с SeaBIOS, а вот OVMF (UEFI) работает только один раз - после включения сервера. Если выключить VM - она больше не стартует (100% загрузки выделенных ядер проца и никакой реакции).
А ещё понадобилось оставить виртуальную видеокарту (vga: default). Хотя во всех мануалах рекомендуется её отключать (vga: none), чтобы не мешалась.
Вопрос для понимания, пока на стадии изучения и тестирования (могу немного путать теплое с мягким))):
В чем принципиальное отличие в виртуализации и организации массивов и ФС, кроме графической оболочки:
Proxmox от Debian + |KVM + IOMMU| + |LXC| + |RaidZ + ZFS|
Unraid от Debian + |KVM + IOMMU| + |Docker| + |Snapraid + XFS + BTRFS|
OMV от Debian + |KVM| + |Docker| + |Mdraid + ext4 + RaidZ + ZFS|
Понятно что функционал бегло по основному (для меня сейчас), хочется понять что принципиально нового, удобного, полезного в выборе данных оболочек против Linux с установленными и настроенными модулями вручную?
Поясню почему задаю вопрос - и Proxmox, и Unraid, и OMV как мне показалось, задают некие ограничения создателями, будь то выбор файловой системы или типа массива, либо выбор контейнеризации, понятно что на хост разрешают "добавить", но красными буквами "не рекомендуют!".
Кто хочет кидайте тапки, но вот начал выбирать систему (FreeBSD не рассматривал), принципы реализации, и получается что в каждом варианте ИМХО есть четко выраженные взгляды создателей оболочек, систем (называйте как угодно), и приходится подстраиваться, либо править то, что не рекомендует создатель и при обновлении модулей оболочки что-то да имеет большую вероятность "полететь". В каждой из этих систем так или иначе для тонкой настройки приходится лазить под капот, дак не проще ли сразу под капот засунуть все что требуется без шилдика?
Например я хочу использовать |KVM + IOMMU| + |Docker|+ |LXC|+ |Mdraid + Snapraid + ext4| + Оболочку для мониторинга и быстрой корректировки как у OMV, но не OMV, но оболочка дело привычки ей как раз можно пренебречь и поставить тот же Webmin или Cockpit, хотя и тот и другой как две противоположности мне не зашли, лучше вообще без оболочки и пользоваться окружением через VNC если припрет "пощелкать" по визуальному интерфейсу + добавить приблуду для мониторинга по типу Grafana.
Верно ли я понял, что чего-то принципиально революционного отличающегося от чистого Linux Debian, Ubuntu, и прочих + нужные приложения и модули, в подобных оболочках нет?
Хочется услышать мнение опытных практиков. Спасибо.
P.S. Из всех троих больше импонирует OMV, но в нем заметил иные ограничения создателем - привязка настроек графической оболочки к конфигам, т.е. то что есть в оболочке приоритетнее ручной правки конфига, что тоже не устраивает, и не уверен в возможности использования IOMMU.
Все три это разного рода оболочки поверх дебиана. При этом прокс использует доработанное ядро от красношапки и свежий qemu.
OMV этот трогал очень давно, а вот Docker это такая дико самостоятельная штука, которая не просто активно живет своей жизнью и требует регулярных приседаний вокруг чистки хранилища образов, а еще и прячет все поднятое в нем активно меняет настройки сети хоста. Первое не всегда нужно, второе не всегда желательно.
ZFS очень крутая штука, если вам важна логическая целостность данных, эффективный кэш (он у нее свой, arc), дедупликация при записи (ест много памяти), блочные устройства (zvol), легковесные снепшоты и при этом дифференциальная синхронизация — берите и не сомневайтесь.
Из полезного прокс умеет пересылку разницы между снепшотами (replication) и автоматическое поднятие сервиса на другой ноде (HA). По остальным — щупать не доводилось.
GPU (desktop/laptop) Passthrough (Проброс видеокарты в ВМ) в ProxMox. Нюансы настроек. переезжаем в Linux