Proxmox где хранятся диски виртуальных машин zfs

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 ?

Ответить | Правка | Cообщить модератору

Оглавление

  • Как скопировать образ VM в Proxmox VE 4.2 из local-zfs, Alexander Pytlev, 16:40 , 23-Июн-16, (1)
  • Как скопировать образ VM в Proxmox VE 4.2 из local-zfs, Liq, 11:24 , 18-Окт-16, (2)
    • Как скопировать образ VM в Proxmox VE 4.2 из local-zfs, Liq, 14:26 , 18-Окт-16, (3)
      • Как скопировать образ VM в Proxmox VE 4.2 из local-zfs, apytlev, 19:28 , 19-Окт-16, (4)

Сообщения по теме [Сортировка по времени | RSS]

> Как можно из этого получить файл с raw образом, например vm-100-disk-1.raw ?

zfs snapshot pool/vm-100-disk-1@now
zfs send pool/vm-100-disk-1@now > /tmp/vm-100-disk-1.raw
zfs destroy pool/vm-100-disk-1@now

1. «Как скопировать образ VM в Proxmox VE 4.2 из local-zfs» + / –
Сообщение от Alexander Pytlev on 23-Июн-16, 16:40
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. «Как скопировать образ VM в Proxmox VE 4.2 из local-zfs» + / –
Сообщение от Liq (ok) on 18-Окт-16, 11:24

У меня несколько обратная проблема.
Ранее VM (centos 7, 2008 R2) были на VMware ESXi 6.0
Руководство сказало установить бесплатный Proxmox 4.3 на «сервер» — обычную машину с i5 и 24Гб оперативки без аппаратного рэйда.

Установил в конфигурации ZFS 10 (4 диска по 4 Тб) — всё установилось, гостевые ос ставятся нормально.
По старым FAQ создал похожую VM, но не запускал, надо заменить вновь созданные файлы на файлы из vmware.
Перенёс vmdk на новый «сервер» и сделал кучу конвертаций с помощью qemu-img в qcow2, raw, img (только нафиг оно (qcow2) по старым FAQ уже не надо, qcow2 всё равно не подхватывает VM из /var/lib/zv/images и там нет VMID).
Понимаю что надо как-то заменить образы vm-100-disk-1 и vm-100-disk-2 на свеже сконвертируемые raw. Только не понимаю как. Можете подсказать что дальше делать?

# zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 140G 6.89T 96K /rpool
rpool/ROOT 132G 6.89T 96K /rpool/ROOT
rpool/ROOT/pve-1 132G 6.89T 132G /
rpool/data 224K 6.89T 96K /rpool/data
rpool/data/vm-100-disk-1 64K 6.89T 64K —
rpool/data/vm-100-disk-2 64K 6.89T 64K —
rpool/swap 8.50G 6.89T 64K —

# zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
rpool 7.25T 132G 7.12T — 1% 1% 1.00x ONLINE —

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. «Как скопировать образ VM в Proxmox VE 4.2 из local-zfs» + / –
Сообщение от Liq (ok) on 18-Окт-16, 14:26

Нашел что это можно делать через восстановление VM
1. сделал бекап VM
2. получил vzdump-qemu-100-2016_10_18-11_51_05.vma.gz
3. развернул в vzdump-qemu-100-2016_10_18-11_51_05.vma
4. далее vma extract и на выходе 3 файла:
root@proxmox1:/100# ls
disk-drive-scsi0.raw disk-drive-scsi1.raw qemu-server.conf

root@proxmox1:/100# cat qemu-server.conf
bootdisk: scsi0
cores: 2
ide2: local:iso/CentOS-7-x86_64-DVD-1511.iso,media=cdrom
memory: 4096
name: post.tandem-pro.net
net0: virtio=A2:C1:B1:18:8A:52,bridge=vmbr0
numa: 0
ostype: l26
scsi0: local-zfs:vm-100-disk-1,size=60G
scsi1: local-zfs:vm-100-disk-2,size=1T
scsihw: virtio-scsi-pci
smbios1: uuid=065d035e-4ae6-42c6-ba7a-a05087f47521
sockets: 2
#qmdump#map:scsi0:drive-scsi0:local-zfs::
#qmdump#map:scsi1:drive-scsi1:local-zfs::

5. Заменил disk-drive-scsi0.raw disk-drive-scsi1.raw на новые из vmware
6. почитав вот это:
https://forum.proxmox.com/threads/bug-in-vma-create.21878/
пытаюсь выполнить команду:
root@proxmox1:/100# vma create 5.vma -c qemu-server.conf drive-scsi0=disk-drive-scsi0.raw drive-scsi1=disk-drive-scsi1.raw
vma: file system may not support O_DIRECT

** (process:18296): ERROR **: can’t open file 5.vma — Invalid argument

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. «Как скопировать образ VM в Proxmox VE 4.2 из local-zfs» + / –
Сообщение от apytlev (ok) on 19-Окт-16, 19:28

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 — это потоковый алгоритм, предлагающий чрезвычайно быстрое сжатие и декомпрессию и выигрыш в производительности для большинства случаев использования — даже на довольно медленных CPU.
  • GZIP — почтенный алгоритм, который знают и любят все пользователи Linux-систем. Он может быть реализован с уровнями сжатия 1-9, с увеличением степени сжатия и использования CPU по мере приближения к уровню 9. Алгоритм хорошо подходит для всех текстовых (или других чрезвычайно сжимаемых) вариантов использования, но в противном случае часто вызывает проблемы c CPU — используйте его с осторожностью, особенно на более высоких уровнях.
  • LZJB — оригинальный алгоритм в ZFS. Он устарел и больше не должен использоваться, LZ4 превосходит его по всем показателям.
  • ZLE — кодировка нулевого уровня, Zero Level Encoding. Она вообще не трогает нормальные данные, но сжимает большие последовательности нулей. Полезно для полностью несжимаемых наборов данных (например, JPEG, MP4 или других уже сжатых форматов), так как он игнорирует несжимаемые данные, но сжимает неиспользуемое пространство в итоговых записях.

Рекомендуется сжатие 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

Внимание! Удаление не предусматривает запроса на подтверждение. Имейте в виду. Удаляется сразу.

Читайте также:  Дети под колес машины
Оцените статью