DaylightIsBurningописывал способ проброса аппаратного ускорения в lxc-контейнер, а если ничего кроме этого вас на хосте больше не держит, почему бы не переехать в контейнер?
Бекап...
К сожалению свойства в бекап не включаются, снапшоты удаляются. Если галочкой отмечен "Thin provisioning" бекап будет восстанавливаться как разреженный том.
Кстати в случае если у вас контейнер а не виртуальная машина, будут забекапленны только файлы а не весь volume.
Хотя на производстве… пожалуй стоило бы применить.
Поверьте не стоит :)
В производстве лучше вообще не допускать all-in-one установок под страхом жизни.
Либо отдельная железка, либо отдельная виртуалка — не иначе.
Тем не менее спасибо за статью, очень ждем продолжения :)
QXL нужен только для вывода картинки, оставить обсчитывать можно ту же самую nvidia. В linux это можно сделать через Bumblebee, в Windows вроде так умеет стандартный драйвер, технология называется Nvidia Optimus.
Это чаще используеься для переключения интегрированной/дескретной графики на ноутбуках, но, я думаю, должно сработать и в данном случае.
По steam: Спасибо за инфу, в принципе со стороны разработчиков это и правда было логично вынести кодирование на уровень железки, почему нет?
Вот все не доходят руки потестить вытянет ли spice по гигабиту приемлимую картинку или нет. Судя по ощущениям должен, т.к. работает он уж точно быстрее RDP. Кстати USB он тоже умеет пробрасывать. Обязательно отпишитесь если попробуете :)
А есть информация как steam стримит? Уж очень уж интересно они как они так хитро картинку жмут что им удалось от тормозов избавиться?
Возможно я смогу ответить на некоторые ваши вопросы:
> это значит deb-multimedia.org, это квест собери крыску из двух сотен пакетов
А зачем вам мультимедия на гипервизоре? — запустите контейнер и делайте внутри все чего душе угодно, не опасаясь при этом за хостовую систему.
> управление zvol. По умолчанию blocksize=8K, опций в нем я так и не нашел где задать
Размер блока — тут, thin provisioning там-же, другие опции только ручками.
Скрытый текст
> iscsi
iscsi там только в качестве клиента для внешних стораджей, и зачем вам дома iscsi?
> как Proxmox относится к бэкапу zvol
Бекап там идет только данных и конфига, то есть как zfs send или dd if=... и пайпом передается в lzo архив. Разворачивается так же, но в обратном направлении.
Уже на протяжении 5 пяти лет успешно использую беспроводные наушники, доволен просто всем: никаких тебе ни спутанных проводов, ни поломанных штекеров, ни расшатанных гнезд.
Острой необходимости в гнезде под 3.5 джек не ощущаю, но на данный момент я не стал бы полностью от него отказываться. С другой стороны приятно осознавать что тот же самый разъем распаян внутри Type-C и его отсутствие здесь не так критично.
Как заметили выше, этот разъем занимает места больше других разъемов на материнской плате телефона.
PS: На сколько я понимаю, в будущем из USB хотят сделать такую универсальную штуку которая будет соединять что угодно с чем угодно.
У меня Xiaomi MI Notebook, но не суть, т.к. стандарт там один.
Сам хаб как таковой не участвует в питании. Он имеет один Type-C вход под штатную зарядку и один выход, который подсоединяется непосредственно к ноутбуку.
Кстати, я счастливый обладатель ноутбука с Type-C и крайне доволен этим разъемом. На работу купил USB Type-C хаб с HDMI и дополнительную зарядку, подключил к нему монитор, клаву, мышь, внешнюю сетевуху.
Использую как док-станцию: ноут поставил, хаб подключил и всё работает. Очень удобно. :)
Это не так, разъем USB Type-C позволяет использовать его для чего-то и для зарядки через него одновременно. Основная сложность — только в выборе подходящего переходника. Вот для данной конкретной задачи:
На мой взгляд нет ничего ужаснее разъема 2.5, который был очень хрупкий и постоянно ломался.
Bonding предназначен для объединения одинаковых линков, с одинаковой скоростью и одинаковой задержкой передачи
Новый Network Teaming поддерживает веса для каждого порта, их можно изменять в реальном времени, проверяя качество канала внешней утилитой.
Если работать на уровне L2, то нужно учитывать алгоритмы управления TCP-окном и перегрузом.
Согласен, но поверх этого можно развернуть какой-нибудь ip-туннель через tcp, он и будет гарантировать доставку каждого пакета.
По поводу буферизации — идея хорошая, но сходу у меня идей нет на этот счет, может знаете какое-нибудь простое unixway-решение?
Неправильно рассуждаете, Proxmox и OpenNebula/OpenStack — это две совершенно разные вещи, хоть и используют один и тот же гипервизор.
Proxmox — это infrastructure virtualization, то есть если вы хотите просто поделить ваши bare-metal сервера на много виртуалок со всеми вытекающими: отказоустойчивость, бэкапы, kvm-консоль и т.д., но при этом работать с ними точно так же как и работали бы с обычными серверами (например подключить cd-rom и установить систему), если жизнь виртуалок для вас критична и сменяются они довольно редко, то это решение подойдет вам как нельзя лучше других.
OpenNebula/OpenStack — это уже cloud platform, а значит здесь вас ждут темплейты, виртуальные сети и автоматически скалируемые сервисы. В пару кликов вы можете создать или удалить сразу 100 однотипных виртуалок, вы можете передавать виртуалкам параметры, к которым можно получить доступ изнутри. Бывает, что жизненное состояние виртуальной машины здесь может быть вовсе не важно. А еще у этого всего есть API, так что таким облаком можете пользоваться даже не обязательно вы, но например ваше приложение, которое будет автоматически создавать в нем виртуалки и исполнять в них какой-то код.
Пока вы тут, вы помните про хуки, а потом кто-то другой может и забыть и все пойдет по накатной.
Все хуки централизованно декларируются в конфиге, про них невозможно забыть, т.к. при обновлении вы всегда будете видеть их в diff.
Кроме того, вся архитекура OpenNebula представляет ссобой не что иное, как систему вызова хуков. (если можно так выразиться).
У вас есть директория со скриптами называемая драйвером, в которой лежат скрипты для каждого действия, будь то storage-драйвер или compute-драйвер.
Вот например драйвер kvm, а вот драйвер ceph. При каждом действии вызывается соответсвующий скрипт. Просто, не правда ли?
В случае когда обычных хуков вам не хватает, ничто не мешает вам сделать свой собственный драйвер на тот или иной случай. Таким образом переопределить логику какого-либо действия крайне просто. А все изменения можно хранить в git и не опасаться что что-то куда-то потеряется.
PS: Я не критикую OpenStack я просто хочу больше рассказать про архитектуру OpenNebula.
Работает довольно стабильно (разворачивал с помощью docker).
До недавних пор была одна проблема — copy&paste между хостовой и удаленной системой. Оно слишком неудобное.
Но вроде и ее уже решили с помощью Clipboard API в браузере, не знаю осталась она или нет.
DaylightIsBurning описывал способ проброса аппаратного ускорения в lxc-контейнер, а если ничего кроме этого вас на хосте больше не держит, почему бы не переехать в контейнер?
К сожалению свойства в бекап не включаются, снапшоты удаляются. Если галочкой отмечен "Thin provisioning" бекап будет восстанавливаться как разреженный том.
Кстати в случае если у вас контейнер а не виртуальная машина, будут забекапленны только файлы а не весь volume.
Поверьте не стоит :)
В производстве лучше вообще не допускать all-in-one установок под страхом жизни.
Либо отдельная железка, либо отдельная виртуалка — не иначе.
Тем не менее спасибо за статью, очень ждем продолжения :)
Это чаще используеься для переключения интегрированной/дескретной графики на ноутбуках, но, я думаю, должно сработать и в данном случае.
По steam: Спасибо за инфу, в принципе со стороны разработчиков это и правда было логично вынести кодирование на уровень железки, почему нет?
А есть информация как steam стримит? Уж очень уж интересно они как они так хитро картинку жмут что им удалось от тормозов избавиться?
> это значит 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
Как странно, и ни слова про FreeIPA
Острой необходимости в гнезде под 3.5 джек не ощущаю, но на данный момент я не стал бы полностью от него отказываться. С другой стороны приятно осознавать что тот же самый разъем распаян внутри Type-C и его отсутствие здесь не так критично.
Как заметили выше, этот разъем занимает места больше других разъемов на материнской плате телефона.
PS: На сколько я понимаю, в будущем из USB хотят сделать такую универсальную штуку которая будет соединять что угодно с чем угодно.
Сам хаб как таковой не участвует в питании. Он имеет один Type-C вход под штатную зарядку и один выход, который подсоединяется непосредственно к ноутбуку.
Оно, не?
Использую как док-станцию: ноут поставил, хаб подключил и всё работает. Очень удобно. :)
На мой взгляд нет ничего ужаснее разъема 2.5, который был очень хрупкий и постоянно ломался.
Новый Network Teaming поддерживает веса для каждого порта, их можно изменять в реальном времени, проверяя качество канала внешней утилитой.
Согласен, но поверх этого можно развернуть какой-нибудь ip-туннель через tcp, он и будет гарантировать доставку каждого пакета.
По поводу буферизации — идея хорошая, но сходу у меня идей нет на этот счет, может знаете какое-нибудь простое unixway-решение?
Чем Linux bonding инкапсулированный в кучку L2 vpn-каналов не решение?
запустите flannel и будет вам счастье
Тут можно учить Kubernetes в интерактивном режиме бесплатно
и без смс.В коментариях автора теперь нельзя трекать если у статьи появились новые коментарии, вообще кроме заголовка от статьи там больше ничего не осталось.
Неправильно рассуждаете, Proxmox и OpenNebula/OpenStack — это две совершенно разные вещи, хоть и используют один и тот же гипервизор.
Proxmox — это infrastructure virtualization, то есть если вы хотите просто поделить ваши bare-metal сервера на много виртуалок со всеми вытекающими: отказоустойчивость, бэкапы, kvm-консоль и т.д., но при этом работать с ними точно так же как и работали бы с обычными серверами (например подключить cd-rom и установить систему), если жизнь виртуалок для вас критична и сменяются они довольно редко, то это решение подойдет вам как нельзя лучше других.
OpenNebula/OpenStack — это уже cloud platform, а значит здесь вас ждут темплейты, виртуальные сети и автоматически скалируемые сервисы. В пару кликов вы можете создать или удалить сразу 100 однотипных виртуалок, вы можете передавать виртуалкам параметры, к которым можно получить доступ изнутри. Бывает, что жизненное состояние виртуальной машины здесь может быть вовсе не важно. А еще у этого всего есть API, так что таким облаком можете пользоваться даже не обязательно вы, но например ваше приложение, которое будет автоматически создавать в нем виртуалки и исполнять в них какой-то код.
Все хуки централизованно декларируются в конфиге, про них невозможно забыть, т.к. при обновлении вы всегда будете видеть их в diff.
Кроме того, вся архитекура OpenNebula представляет ссобой не что иное, как систему вызова хуков. (если можно так выразиться).
У вас есть директория со скриптами называемая драйвером, в которой лежат скрипты для каждого действия, будь то storage-драйвер или compute-драйвер.
Вот например драйвер kvm, а вот драйвер ceph. При каждом действии вызывается соответсвующий скрипт. Просто, не правда ли?
В случае когда обычных хуков вам не хватает, ничто не мешает вам сделать свой собственный драйвер на тот или иной случай. Таким образом переопределить логику какого-либо действия крайне просто. А все изменения можно хранить в git и не опасаться что что-то куда-то потеряется.
PS: Я не критикую OpenStack я просто хочу больше рассказать про архитектуру OpenNebula.
Работает довольно стабильно (разворачивал с помощью docker).
До недавних пор была одна проблема — copy&paste между хостовой и удаленной системой. Оно слишком неудобное.
Но вроде и ее уже решили с помощью Clipboard API в браузере, не знаю осталась она или нет.
А еще можно установить Guacamole, и ни VPN, ни RDP-клиенты вам больше не понадобятся :)