Proxmox где хранятся диски виртуальных машин zfs
Решил протестить новый релиз Proxmox Virtual Environment 4.2-2.
При установке выбрал RAID 1 на ZFS.
После установки создалось 2 хранилища
local и local-zfs
Развернул тестовые бекапы с других серверов, соответсвенно образы легли в local-zfs и для каждого образа создалась отдельная файловая система:
NAME USED AVAIL REFER MOUNTPOINT
rpool 158G 1.16T 96K /rpool
rpool/ROOT 61.1G 1.16T 96K /rpool/ROOT
rpool/ROOT/pve-1 61.1G 1.16T 61.1G /
rpool/data 89.8G 1.16T 96K /rpool/data
rpool/data/vm-100-disk-1 24.3M 1.16T 24.3M —
rpool/data/vm-101-disk-1 11.4G 1.16T 11.4G —
rpool/data/vm-103-disk-1 863M 1.16T 863M —
rpool/data/vm-107-disk-1 2.35G 1.16T 2.35G —
rpool/data/vm-111-disk-1 23.7G 1.16T 23.7G —
rpool/data/vm-111-disk-2 7.34G 1.16T 7.34G —
rpool/data/vm-222-disk-1 44.2G 1.16T 44.2G —
rpool/swap 7.44G 1.17T 39.2M —
Как можно из этого получить файл с raw образом, например vm-100-disk-1.raw ?
Оглавление |
|
Сообщения по теме | [Сортировка по времени | RSS] |
1. «Как скопировать образ VM в Proxmox VE 4.2 из local-zfs» | + / – | |
Сообщение от Alexander Pytlev | ||
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору |
2. «Как скопировать образ VM в Proxmox VE 4.2 из local-zfs» | + / – | |
Сообщение от Liq (ok) on 18-Окт-16, 11:24 | ||
У меня несколько обратная проблема. Установил в конфигурации ZFS 10 (4 диска по 4 Тб) — всё установилось, гостевые ос ставятся нормально. # zfs list # zpool list | ||
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору |
3. «Как скопировать образ VM в Proxmox VE 4.2 из local-zfs» | + / – | |
Сообщение от Liq (ok) on 18-Окт-16, 14:26 | ||
root@proxmox1:/100# cat qemu-server.conf 5. Заменил disk-drive-scsi0.raw disk-drive-scsi1.raw на новые из vmware ** (process:18296): ERROR **: can’t open file 5.vma — Invalid argument | ||
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору |
4. «Как скопировать образ VM в Proxmox VE 4.2 из local-zfs» | + / – | |
Сообщение от apytlev | ||
raw имиджи дисков у вас есть, конфигурация виртуальной машины есть, чего не хватает? 🐹 Proxmox Virtual Environment: Добавление и удаление хранилища ZFS в Proxmox VE.Опубликовано 2020-10-04 · Обновлено 2021-01-30 Содержание:1. Введение.1.1. Описание файловой системы. ZFS (Zettabyte File System) — файловая система, изначально созданная в Sun Microsystems для операционной системы Solaris. Эта файловая система поддерживает большие объёмы данных, объединяет концепции файловой системы и менеджера логических дисков (томов) и физических носителей, новаторскую структуру данных на дисках, легковесные файловые системы (англ. lightweight filesystems), а также простое управление томами хранения данных. ZFS является проектом с открытым исходным кодом и лицензируется под CDDL (Common Development and Distribution License). Основное преимущество ZFS — это её полный контроль над физическими и логическими носителями. Зная, как именно расположены данные на дисках, ZFS способна обеспечить высокую скорость доступа к ним, контроль их целостности, а также минимизацию фрагментации данных. Это позволяет динамически выделять или освобождать дисковое пространство на одном или более носителях для логической файловой системы. Кроме того, имеет место переменный размер блока, что лучшим образом влияет на производительность, параллельность выполнения операций чтения-записи, а также 64-разрядный механизм использования контрольных сумм, сводящий к минимуму вероятность незаметного разрушения данных. В Proxmox VE с помощью ZFS можно позволить себе репликацию данных на другой гипервизор, миграцию виртуальной машины/LXC контейнера, доступ к LXC контейнеру с хост-системы и так далее. 1.2. Пулы хранения. В отличие от традиционных файловых систем, которые располагаются на одном устройстве и, следовательно, при использовании более чем на одном устройстве для них требуется менеджер томов, ZFS строится поверх виртуальных пулов хранения данных, называемых zpool. Пул построен из виртуальных устройств (vdevs), каждое из которых является либо физическим устройством, либо зеркалом (RAID 1) одного или нескольких устройств, либо (RAID Z) — группой из двух или более устройств. Ёмкость всех vdevs затем доступна для всех файловых систем в zpool. Для ограничения пространства, доступного конкретной файловой системе или тому, может быть установлена квота. Кроме того, возможно использование дискового резервирования (лимита) — это гарантирует, что всегда будет оставаться некоторый доступный объём для конкретной файловой системы или тома. Каждый пул хранения состоит из одного или нескольких виртуальных устройств (virtual device, vdev). В свою очередь, каждый vdev включает одно или несколько реальных устройств. Большинство виртуальных устройств используются для простого хранения данных, но существует несколько вспомогательных классов vdev, включая CACHE, LOG и SPECIAL. Каждый из этих типов vdev может иметь одну из пяти топологий: единое устройство (single-device), RAIDz1, RAIDz2, RAIDz3 или зеркало (mirror). RAIDz1, RAIDz2 и RAIDz3 — это особые разновидности того, что назовут RAID двойной (диагональной) чётности. 1, 2 и 3 относятся к тому, сколько блоков чётности выделено для каждой полосы данных. Вместо отдельных дисков для обеспечения чётности виртуальные устройства RAIDz полуравномерно распределяют эту чётность по дискам. Массив RAIDz может потерять столько дисков, сколько у него блоков чётности; если он потеряет ещё один, то выйдет из строя и заберет с собой пул хранения. В зеркальных виртуальных устройствах (mirror vdev) каждый блок хранится на каждом устройстве в vdev. Хотя наиболее распространённые двойные зеркала (two-wide), в зеркале может быть любое произвольное количество устройств — в больших установках для повышения производительности чтения и отказоустойчивости часто используются тройные. Зеркало vdev может пережить любой сбой, пока продолжает работать хотя бы одно устройство в vdev. Одиночные vdev по своей сути опасны. Такое виртуальное устройство не переживёт ни одного сбоя — и если используется в качестве хранилища или специального vdev, то его сбой приведёт к уничтожению всего пула. Будьте здесь очень, очень осторожны. Виртуальные устройства CACHE, LOG и SPECIAL могут быть созданы по любой из вышеперечисленных топологий — но помните, что потеря виртуального устройства SPECIAL означает потерю пула, поэтому настоятельно рекомендуется избыточная топология. 1.3. Встроенное сжатие. Механизм копирования при записи также упрощает систему встроенного сжатия. В традиционной файловой системы сжатие проблематично — как старая версия, так и новая версия изменённых данных находятся в одном и том же пространстве. Если рассмотреть фрагмент данных в середине файла, который начинает свою жизнь как мегабайт нулей от 0x00000000 и так далее — его очень легко сжать до одного сектора на диске. Но что произойдёт, если мы заменим этот мегабайт нулей на мегабайт несжимаемых данных, таких как JPEG или псевдослучайный шум? Неожиданно этому мегабайту данных потребуется не один, а 256 секторов по 4 КиБ, а в этом месте на диске зарезервирован только один сектор. У ZFS нет такой проблемы, так как изменённые записи всегда записываются в неиспользуемое пространство — исходный блок занимает только один сектор 4 КиБ, а новая запись займёт 256, но это не проблема — недавно изменённый фрагмент из «середины» файла был бы записан в неиспользуемое пространство независимо от того, изменился его размер или нет, поэтому для ZFS это вполне штатная ситуация. Встроенное сжатие ZFS отключено по умолчанию, и система предлагает подключаемые алгоритмы — сейчас среди них LZ4, gzip (1-9), LZJB и ZLE.
Рекомендуется сжатие LZ4 практически для всех вариантов использования. Штраф за производительность при встрече с несжимаемыми данными очень мал, а прирост производительности для типичных данных значителен. Копирование образа виртуальной машины для новой инсталляции операционной системы Windows (свежеустановленная операционная система, никаких данных внутри ещё нет) с compression=lz4 прошло на 27% быстрее, чем с compression=none . 1.4. Секторы. Последний, самый базовый строительный блок — сектор. Это наименьшая физическая единица, которая может быть записана или считана с базового устройства. В течение нескольких десятилетий в большинстве дисков использовались секторы по 512 байт. В последнее время большинство дисков настроено на сектора 4 КиБ, а в некоторых — особенно SSD — сектора 8 КиБ или даже больше. В системе ZFS есть свойство, которое позволяет вручную установить размер сектора. Это свойство ashift. Несколько запутанно, что ashift является степенью двойки. Например, ashift=9 означает размер сектора 2^9, или 512 байт. ZFS запрашивает у операционной системы подробную информацию о каждом блочном устройстве, когда оно добавляется в новый vdev, и теоретически автоматически устанавливает ashift должным образом на основе этой информации. К сожалению, многие диски лгут о своём размере сектора, чтобы сохранить совместимость с Windows XP (которая была неспособна понять диски с другими размерами секторов). Это означает, что администратору ZFS настоятельно рекомендуется знать фактический размер сектора своих устройств и вручную устанавливать ashift. Если установлен слишком маленький ashift, то астрономически увеличивается количество операций чтения/записи. Так, запись 512-байтовых «секторов» в реальный сектор 4 КиБ означает необходимость записать первый «сектор», затем прочитать сектор 4 КиБ, изменить его со вторым 512-байтовым «сектором», записать его обратно в новый сектор 4 КиБ и так далее для каждой записи. В реальном мире такой штраф бьёт по твёрдотельным накопителям Samsung EVO, для которых должен действовать ashift=13 , но эти SSD врут о своём размере сектора, и поэтому по умолчанию устанавливается ashift=9 . Если опытный системный администратор не изменит этот параметр, то этот SSD работает медленнее обычного магнитного HDD. Для сравнения, за слишком большой размер ashift нет практически никакого штрафа. Реального снижения производительности нет, а увеличение неиспользуемого пространства бесконечно мало (или равно нулю при включённом сжатии). Поэтому мы настоятельно рекомендуем даже тем дискам, которые действительно используют 512-байтовые секторы, установить ashift=12 или даже ashift=13 , чтобы уверенно смотреть в будущее. Внимание! Свойство ashift устанавливается для каждого виртуального устройства vdev, а не для пула, как многие ошибочно думают — и не изменяется после установки. Если вы случайно сбили ashift при добавлении нового vdev в пул, то вы безвозвратно загрязнили этот пул устройством с низкой производительностью и, как правило, нет другого выхода, кроме как уничтожить пул и начать всё сначала. Даже удаление vdev не спасёт от сбитой настройки ashift! 2. Подключаем диск в системе.Подключаем физический диск к серверу и смотрим появился ли он в системе. Просто выполните действия в web-интерфейсе гипервизора Proxmox VE. Инициализируем диск в GPT разметке диска. Если всё хорошо, то преобразование может начаться сразу: А может не начаться и выдать выдать ошибку: Исправить ее очень просто. Переходим в консоль сервера и вводим эту команду в консоль: # /sbin/sgdisk /dev/sdb -U R -g Затем снова переходим в меню преобразования диска в GPT и операция завершается успешно. 3. Добавление нового хранилища.Добавляем новое хранилище в web-панели управления Proxmox VE. Переходим в web-интерфейс панели управления Proxmox VE, Выбираем сервер виртуальных машин и раздел «Диски» — «ZFS»: Готово! ZFS в строю. Теперь мы можем использовать хранилище для размещения виртуальных машин и контейнеров. 4. Удаление хранилища.Удаление производится простым способом. Паркуем все виртуальные машины, которые используют данное хранилище, размонтируем хранилище и удалим его. # zpool destroy name_of_zfs Внимание! Удаление не предусматривает запроса на подтверждение. Имейте в виду. Удаляется сразу. |