Расскажу своими словами про типы дисков в Proxmox, доступные по дефолту после установки для использования в виртуальных машинах.
Этот вопрос очень часто задают. Я не могу сказать, что обладаю экспертными знаниями по этой теме, но в своё время специально интересовался и составил для себя представления в каком случае какой из типов дисков выбирать.
RAW. Самый простой формат. Данные хранятся как есть, без дополнительной обработки и добавления служебной информации. Информацию в таком формате могут называть сырыми данными. По идее, это формат с максимальным быстродействием. При создании диска выделяется сразу же весь объем. Формат является универсальным для большинства популярных гипервизоров.
➕ Максимальная простота и производительность среди образов в виде файла.
➕ Универсальный формат с поддержкой в большинстве гипервизоров.
➕ Легкость переноса виртуальной машины на другой сервер. Достаточно просто скопировать файл.
➖ Не поддерживает снепшоты ни в каком виде.
➖ Занимает сразу все выделенное пространство на диске, даже если внутри виртуальной машины место будет свободно. Из-за отсутствия фрагментации в некоторых случаях это может оказаться плюсом.
QCOW2. Родной формат для гипервизора QEMU. Расшифровывается как Copy-on-write. Этот формат позволяет создавать динамические диски для виртуальных машин, а так же поддерживает снепшоты. Теоретически, скорость работы будет хоть и не сильно, но уступать RAW (на ~10%), так как появляются накладные расходы формата.
➕ Поддержка снепшотов и динамических дисков. Как следствие - более удобное управление дисковым пространством.
➕ Легкость переноса виртуальной машины на другой сервер. Достаточно просто скопировать файл.
➖ Более низкая производительность, по сравнению с другими типами образов.
LVM. Использование lvm томов в виде дисков виртуальных машин. Такой диск будет блочным устройством и теоретически должен работать быстрее всех остальных типов, так как нет лишней прослойки в виде файловой системы. На практике эту разницу с raw не разглядеть и не замерить. Я на тестах не замечал.
➕ Снэпшоты средствами самого lvm, с них легко снять бэкап без остановки виртуальной машины.
➕ Максимальное быстродействие.
➖ Более сложное управление по сравнению с дисками в виде отдельных файлов.
➖ Более сложный перенос на другой сервер.
У каждого типа есть свои преимущества и недостатки. Lvm проще всего бэкапить, так как есть снепшоты из коробки, но им сложнее всего управлять. Для того, кто хорошо знаком с lvm, это не проблема, если сталкиваешься первый раз, то возникает много вопросов. У raw нет снепшотов, лично для меня это большой минус, я этот формат редко использую. Если нет максимальной нагрузки на дисковую подсистему, то QCOW2 мне кажется наиболее удобным вариантом.
#proxmox #kvm
Этот вопрос очень часто задают. Я не могу сказать, что обладаю экспертными знаниями по этой теме, но в своё время специально интересовался и составил для себя представления в каком случае какой из типов дисков выбирать.
RAW. Самый простой формат. Данные хранятся как есть, без дополнительной обработки и добавления служебной информации. Информацию в таком формате могут называть сырыми данными. По идее, это формат с максимальным быстродействием. При создании диска выделяется сразу же весь объем. Формат является универсальным для большинства популярных гипервизоров.
➕ Максимальная простота и производительность среди образов в виде файла.
➕ Универсальный формат с поддержкой в большинстве гипервизоров.
➕ Легкость переноса виртуальной машины на другой сервер. Достаточно просто скопировать файл.
➖ Не поддерживает снепшоты ни в каком виде.
➖ Занимает сразу все выделенное пространство на диске, даже если внутри виртуальной машины место будет свободно. Из-за отсутствия фрагментации в некоторых случаях это может оказаться плюсом.
QCOW2. Родной формат для гипервизора QEMU. Расшифровывается как Copy-on-write. Этот формат позволяет создавать динамические диски для виртуальных машин, а так же поддерживает снепшоты. Теоретически, скорость работы будет хоть и не сильно, но уступать RAW (на ~10%), так как появляются накладные расходы формата.
➕ Поддержка снепшотов и динамических дисков. Как следствие - более удобное управление дисковым пространством.
➕ Легкость переноса виртуальной машины на другой сервер. Достаточно просто скопировать файл.
➖ Более низкая производительность, по сравнению с другими типами образов.
LVM. Использование lvm томов в виде дисков виртуальных машин. Такой диск будет блочным устройством и теоретически должен работать быстрее всех остальных типов, так как нет лишней прослойки в виде файловой системы. На практике эту разницу с raw не разглядеть и не замерить. Я на тестах не замечал.
➕ Снэпшоты средствами самого lvm, с них легко снять бэкап без остановки виртуальной машины.
➕ Максимальное быстродействие.
➖ Более сложное управление по сравнению с дисками в виде отдельных файлов.
➖ Более сложный перенос на другой сервер.
У каждого типа есть свои преимущества и недостатки. Lvm проще всего бэкапить, так как есть снепшоты из коробки, но им сложнее всего управлять. Для того, кто хорошо знаком с lvm, это не проблема, если сталкиваешься первый раз, то возникает много вопросов. У raw нет снепшотов, лично для меня это большой минус, я этот формат редко использую. Если нет максимальной нагрузки на дисковую подсистему, то QCOW2 мне кажется наиболее удобным вариантом.
#proxmox #kvm
Мы привыкли ко всяким проксмоксам, вмварям. А есть суровые люди, которые выше всего этого. Я как-то пришёл в одну небольшую компанию принять дела от ушедшего админа. Он уволился еще до моего прихода. Разбирался самостоятельно в его хозяйстве.
Смотрю по схеме на гипервизор. Захожу на него и не понимаю, что тут вообще происходит. Где сам гипервизор и как им управлять. Оказалось, что там стоял голый KVM и управлялся только через консоль. Пришлось разбираться, что тут и как, и где подключаться к виртуалкам. Я сам в то время XenServer во всю использовал и с KVM вообще не был знаком.
Для таких любителей консоли есть TUI интерфейс для управления виртуальными машинами - nEMU [Ncurses UI for QEMU].
https://github.com/nemuTUI/nemu
С его помощью прямо в консоли можно управлять виртуальными машинами - создавать, запускать, останавливать и т.д. Все это собрано в rpm или deb пакеты, так что легко поставить.
Посмотреть, как это работает - https://www.youtube.com/watch?v=y8RT6-AF1BA
Какие-то люди пишут всё это, форкают, лайкают, обсуждают на reddit. Причем регулярно выходят обновления и новые релизы. Скажите, есть среди вас хоть один человек, кому подобные поделки были бы нужны в наши дни?
#kvm
Смотрю по схеме на гипервизор. Захожу на него и не понимаю, что тут вообще происходит. Где сам гипервизор и как им управлять. Оказалось, что там стоял голый KVM и управлялся только через консоль. Пришлось разбираться, что тут и как, и где подключаться к виртуалкам. Я сам в то время XenServer во всю использовал и с KVM вообще не был знаком.
Для таких любителей консоли есть TUI интерфейс для управления виртуальными машинами - nEMU [Ncurses UI for QEMU].
https://github.com/nemuTUI/nemu
С его помощью прямо в консоли можно управлять виртуальными машинами - создавать, запускать, останавливать и т.д. Все это собрано в rpm или deb пакеты, так что легко поставить.
Посмотреть, как это работает - https://www.youtube.com/watch?v=y8RT6-AF1BA
Какие-то люди пишут всё это, форкают, лайкают, обсуждают на reddit. Причем регулярно выходят обновления и новые релизы. Скажите, есть среди вас хоть один человек, кому подобные поделки были бы нужны в наши дни?
#kvm
Последние несколько лет замечаю, что Proxmox вытеснил всех в нише управления виртуальными машинами KVM. Хотя так было далеко не всегда. Когда я начинал пользоваться виртуальными машинами на базе KVM, использовал для управления libvirt и консольную утилиту virsh, либо GUI для неё. Некоторым заказчикам даже в прод внедрял такое решение. Нормально работает и по сей день. Ставилось всё на обычный Debian.
Если вам по какой-то причине не подходит или не хочется использовать Proxmox, а причины этого вполне могут быть, посмотрите на Kimchi. Это простой и приятный веб интерфейс для управления гипервизором KVM. Работа веб интерфейса основана на HTML5. Ставится Kimchi на любой Linux дистрибутив. Есть готовые пакеты (deb и rpm) под все популярные системы.
Kimchi достаточно старый и известный продукт, который хоть и не очень активно, но развивается, не заброшен. Последний релиз был в 2020 году. В 21-м обещали обновление, но оно так и не случилось :( С его помощью можно создавать, запускать, останавливать виртуалки. Управлять виртуальными сетями и хранилищами. Создавать шаблоны, клонировать виртуалки и т.д. То есть вся база для управления виртуальными машинами есть.
Из аналогов мне приходит в голову только Cockpit. Он появился позже Kimchi. У него функционал схожий по управлению KVM и развивается вроде бы бодрее. Но Cockpit это не только управление гипервизором, но и сервером в целом. То есть более масштабный продукт.
Если кто-то ещё знает современные и удобные веб интерфейсы для управления KVM, поделитесь информацией.
Исходники - https://github.com/kimchi-project/kimchi
#kvm #linux
Если вам по какой-то причине не подходит или не хочется использовать Proxmox, а причины этого вполне могут быть, посмотрите на Kimchi. Это простой и приятный веб интерфейс для управления гипервизором KVM. Работа веб интерфейса основана на HTML5. Ставится Kimchi на любой Linux дистрибутив. Есть готовые пакеты (deb и rpm) под все популярные системы.
Kimchi достаточно старый и известный продукт, который хоть и не очень активно, но развивается, не заброшен. Последний релиз был в 2020 году. В 21-м обещали обновление, но оно так и не случилось :( С его помощью можно создавать, запускать, останавливать виртуалки. Управлять виртуальными сетями и хранилищами. Создавать шаблоны, клонировать виртуалки и т.д. То есть вся база для управления виртуальными машинами есть.
Из аналогов мне приходит в голову только Cockpit. Он появился позже Kimchi. У него функционал схожий по управлению KVM и развивается вроде бы бодрее. Но Cockpit это не только управление гипервизором, но и сервером в целом. То есть более масштабный продукт.
Если кто-то ещё знает современные и удобные веб интерфейсы для управления KVM, поделитесь информацией.
Исходники - https://github.com/kimchi-project/kimchi
#kvm #linux
При использовании виртуализации на базе QEMU (например, Proxmox) я всегда в обязательном порядке использую qemu-guest-agent, который позволяет гипервизору взаимодействовать с установленной системой. Для этого в свойствах виртуальной машины нужно включить использование агента, а на систему установить соответствующий пакет.
Для Debian пакет так и называется - qemu-guest-agent:
В общем случае в процессе эксплуатации системы вам не обязательно взаимодействовать с агентом. Он нужен гипервизору, например, для корректного завершения работы гостевой системы, для её заморозки во время бэкапа, для синхронизации времени и т.д.
При необходимости, вы тоже можете использовать возможности агента, обращаясь к гостевой системе через него. Для проверки связи с агентом, в консоли гипервизора можно набрать:
Если всё в порядке, то вы не увидите никакого вывода, а код завершения будет нулевой. Это был пример команды для хоста Proxmox. Если у вас другая система виртуализации, и там, к примеру, используется virsh для управления, то команда будет следующая:
Команды будут похожие. Приведу ещё один пример с Proxmox и virsh, а дальше буду только для Proxmox приводить. Смотрим время на гостевой системе:
Для взаимодействия с агентом используется отдельный протокол QMP, который возвращает ответы на запросы в формате json, так что для взаимодействия с ним пригодится утилита jq.
Теперь посмотрим, какие команды агента поддерживает конкретная виртуальная машина:
Я сразу обработал вывод, выбрав только поддерживаемые команды, и выведя само название. Можете посмотреть на полный вывод без обработки. К сожалению, конкретно в proxmox вывод supported_commands не совпадает с реальным списком, который поддерживается, потому что некоторые команды, типа
Соответственно, вот этот список более точный. Из названия команд чаще всего понятен смысл. Смотрим информацию об установленной ОС:
И так далее. Инструмент простой для освоения и использования. Может пригодиться, если нужен будет какой-то свой мониторинг с уровня гипервизора, например, за списком VM на хосте со следующей информацией:
◽гостевая система;
◽диски и точки монтирования;
◽сетевые интерфейсы и ip адреса на них;
◽количество cpu и ram.
Можно и доступность гостя так проверять. Также с помощью агента можно запускать любые команды на гостевой машине:
#kvm #proxmox
Для Debian пакет так и называется - qemu-guest-agent:
# apt install qemu-guest-agent# systemctl enable --now qemu-guest-agentВ общем случае в процессе эксплуатации системы вам не обязательно взаимодействовать с агентом. Он нужен гипервизору, например, для корректного завершения работы гостевой системы, для её заморозки во время бэкапа, для синхронизации времени и т.д.
При необходимости, вы тоже можете использовать возможности агента, обращаясь к гостевой системе через него. Для проверки связи с агентом, в консоли гипервизора можно набрать:
# qm agent <vmid> pingЕсли всё в порядке, то вы не увидите никакого вывода, а код завершения будет нулевой. Это был пример команды для хоста Proxmox. Если у вас другая система виртуализации, и там, к примеру, используется virsh для управления, то команда будет следующая:
# virsh qemu-agent-command vmname '{"execute": "guest-ping"}'Команды будут похожие. Приведу ещё один пример с Proxmox и virsh, а дальше буду только для Proxmox приводить. Смотрим время на гостевой системе:
# qm agent 101 get-time# virsh qemu-agent-command vmname '{"execute": "guest-get-time"}'Для взаимодействия с агентом используется отдельный протокол QMP, который возвращает ответы на запросы в формате json, так что для взаимодействия с ним пригодится утилита jq.
Теперь посмотрим, какие команды агента поддерживает конкретная виртуальная машина:
# qm agent 101 info | jq -r '.supported_commands[] | select(.enabled==true) | .name'Я сразу обработал вывод, выбрав только поддерживаемые команды, и выведя само название. Можете посмотреть на полный вывод без обработки. К сожалению, конкретно в proxmox вывод supported_commands не совпадает с реальным списком, который поддерживается, потому что некоторые команды, типа
guest-exec выполняются немного в другом синтаксисе. Те команды, что не работают, выдадут ошибку, а вместе с ошибкой выводится список, который реально поддерживается:# qm agent 101 get-cpustats400 Parameter verification failed.command: value 'get-cpustats' does not have a value in the enumeration 'fsfreeze-freeze, fsfreeze-status, fsfreeze-thaw, fstrim, get-fsinfo, get-host-name, get-memory-block-info, get-memory-blocks, get-osinfo, get-time, get-timezone, get-users, get-vcpus, info, network-get-interfaces, ping, shutdown, suspend-disk, suspend-hybrid, suspend-ram'qm guest cmd <vmid> <command>Соответственно, вот этот список более точный. Из названия команд чаще всего понятен смысл. Смотрим информацию об установленной ОС:
# qm agent 101 get-osinfo{ "id" : "debian", "kernel-release" : "6.1.0-13-amd64", "kernel-version" : "#1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29)", "machine" : "x86_64", "name" : "Debian GNU/Linux", "pretty-name" : "Debian GNU/Linux 12 (bookworm)", "version" : "12 (bookworm)", "version-id" : "12"}И так далее. Инструмент простой для освоения и использования. Может пригодиться, если нужен будет какой-то свой мониторинг с уровня гипервизора, например, за списком VM на хосте со следующей информацией:
◽гостевая система;
◽диски и точки монтирования;
◽сетевые интерфейсы и ip адреса на них;
◽количество cpu и ram.
Можно и доступность гостя так проверять. Также с помощью агента можно запускать любые команды на гостевой машине:
# qm guest exec 101 "df"#kvm #proxmox
