Привет, Хабр! При работе с виртуальными машинами нередко возникает необходимость просмотреть или внести изменения в содержимое диска, не запуская саму ВМ. Это может понадобиться для диагностики, восстановления данных или точечной правки конфигурационных файлов. В zVirt такая задача решается несколькими способами: например можно напрямую подключиться к диску виртуальной машины как к блочному устройству и смонтировать его на уровне хост-системы. Это позволяет получить доступ к файловой системе образа без запуска ВМ. Далее рассмотрим основные подходы к тому, как это можно сделать на практике.
Меня зовут Павел Князькин, я системный архитектор в команде zVirt Orion soft. Этот материал мы готовили вместе с моим коллегой Игорем Владимировым, системным инженером из нашей команды. Надеемся, что он окажется полезным для пользователей платформы.
Общие сведения о стенде
На стенде имеется 2 ВМ:
- pk-centos9-gp. На ВМ установлена centos9. ВМ содержит 3 диска:
- sda – 35GB, предварительно размеченный диск. На диске создано три раздела: sda1 – ext4, sda2 – lvm с xfs, sda3 – ntfs.
- sdb – 30 GB, тонкий диск. На диске создано три раздела: sdb1 – ext4, sdb2 – lvm с xfs, sdb3 – ntfs.
- sdc – 70 GB. Загрузочный диск с ОС.
- pk-win2019-gp. На ВМ установлена windows 2019. ВМ Содержит один тонкий диск.
Для работы с дисками виртуальных машин в zVirt важно понимать, что используется несколько типов идентификаторов, и они относятся к разным уровням представления диска. В системе присутствуют следующие ключевые параметры:
- ID всего диска (id) — уникальный идентификатор самого диска. Он остается неизменным на протяжении всего жизненного цикла диска, включая создание и удаление контрольных точек (снимков). Это основной стабильный идентификатор объекта хранения.
- ID слоя (image_id) — идентификатор конкретного слоя диска. Например, это может быть текущий активный слой ActiveVM. В отличие от общего ID диска, значение image_id может изменяться при работе со снимками: при создании и последующем удалении контрольных точек структура слоев пересобирается, и активный слой может получить новый идентификатор.
Таким образом, id диска используется для стабильной идентификации самого диска, а image_id — для работы с конкретным состоянием или слоем этого диска в цепочке снимков. Давайте определим для каждого диска виртуальной машины идентификатор снимка диска (активного слоя диска машины - image_id). Найти этот идентификатор можно в интерфейсе zVirt по следующему пути: Ресурсы → Виртуальные машины → Выбираем нужную ВМ → Снимки → Идентификатор диска снимка
Идентификаторы снимка диска ВМ pk-centos9-gp
Идентификаторы снимка диска ВМ pk-win2019-gp
Для удобства дальнейшего взаимодействия со статьей мы подготовили таблицу, в которой указали, какой идентификатор снимка диска соответствует каждому диску.
Таблица 1. ВМ pk-centos9-gp
| Имя диска / размер |
Имя раздела |
Тип диска / тип файловой системы |
Идентификатор снимка диска (Активный слой диска машины) - Logical Volume |
| sda - 35 GB |
|
Предварительно размеченный диск |
3b36d17e-6240-4546-b8e0-11a855b0f31c |
|
sda1 |
ext4 |
|
|
sda2 |
lvm с xfs |
|
|
sda3 |
ntfs |
|
|
|
|
|
| sdb - 30 GB |
|
Тонкий тип диска |
e2f54f03-15ff-4f31-8e6b-aabbd6a96561 |
|
sdb1 |
ext4 |
|
|
sdb2 |
lvm с xfs |
|
|
sdb3 |
ntfs |
|
|
|
|
|
| sdc - 70 GB (загрузочный) |
|
Тонкий тип диска |
c5046e63-0247-4aec-99b4-9cdef3431bcc |
Таблица 2. ВМ pk-win2019-gp
| Имя диска / размер |
Имя раздела |
Тип диска / тип файловой системы |
Идентификатор снимка диска (Активный слой диска машины) - Logical Volume |
| 75 GB |
|
NTFS / тонкий тип диска |
a22788a4-9341-4fe4-a82f-df67f86f77f6 |
Информация о домене хранения
На нашем тестовом стенде все эти ВМ (и их диски) расположены в одном домене хранения cluster-storage-400-gp .
Обзор домена хранения cluster-storage-400-gp
Поскольку в данном примере используется домен хранения на базе блочного типа (на базе LVM), все диски виртуальных машин размещаются внутри одной Volume Group (VG). Соответственно, для дальнейшей работы необходимо определить ID. Сделать это можно через графический интерфейс zVirt: Хранилище → Домены хранения → Выбираем нужный домен → Имя домена. Для блочного типа домена хранения его идентификатор напрямую соответствует имени Volume Group (VG). Таким образом, в случае LVM: ID домена хранения = имя Volume Group (VG).
Идентификатор домена хранения cluster-storage-400-gp
Теперь посмотрим, как эта информация выглядит непосредственно на хосте. Перед началом работы с LVM напрямую необходимо отключить использование файла с фиксированным списком устройств. В противном случае LVM может «не видеть» часть томов, связанных с дисками виртуальных машин. Для этого отредактируйте конфигурационный файл LVM: nano /etc/lvm/lvm.conf
И установите следующий параметр (если он отсутствует, то его необходимо добавить в секцию devices ):use_devicesfile = 0
После этого поведение LVM изменится следующим образом:
- LVM перестанет использовать файл /etc/lvm/devices/system.devices, в котором задан статический список устройств
- При каждой операции будет выполняться сканирование всех доступных блочных устройств
- Это может немного снизить производительность операций, но гарантирует, что LVM обнаружит все тома
Это особенно важно при работе с дисками виртуальных машин и их слоями, так как они могут не попадать в заранее зафиксированный список устройств.
Теперь посмотрим информацию о домене хранения непосредственно на хосте. Для этого выполним команду, которая выводит список всех групп томов (VG - Volume Group) в системе:
[root@zvirt-43-main-host1-pk /]# vgs
VG #PV #LV #SN Attr VSize VFree
165151ea-24b7-4de3-a558-df31ccd2078c 1 16 0 wz--n- 399,62g 276,12g
Столбцы содержат следующую информацию. Таблица 3. Описание вывода команды vgs
| Имя |
Значение |
Расшифровка |
| VG |
165151ea-24b7-4de3-a558-df31ccd2078c |
Имя группы томов (Volume Group) |
| PV |
1 |
Количество физических томов (Physical Volumes), входящих в эту группу |
| LV |
16 |
Количество логических томов (Logical Volumes) внутри VG |
| SN |
0 |
Количество снимков (snapshots) |
|
w - writable (доступна для записи)
z - resizable (можно изменять размер)
n - Not available for allocation, из этой Volume Group нельзя создавать новые Logical Volumes, пока пока не изменим политику распределения |
Атрибуты VG |
| VSize |
399,62g |
Общий размер группы томов (сумма всех PV) |
| VFree |
276,12g |
Свободное пространство внутри VG |
Также информацию можно посмотреть в другом виде. Для этого выполним команду vgdisplay имя_группы_томов
[root@zvirt-43-main-host1-pk /]# vgdisplay 165151ea-24b7-4de3-a558-df31ccd2078c
--- Volume group ---
VG Name 165151ea-24b7-4de3-a558-df31ccd2078c
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 324
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 16
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 399,62 GiB
PE Size 128,00 MiB
Total PE 3197
Alloc PE / Size 988 / 123,50 GiB
Free PE / Size 2209 / 276,12 GiB
VG UUID ve21lF-uA8q-c1YJ-PITu-9reS-s7xd-qNkKqG
Подведем итог и сопоставим сущности zVirt с объектами LVM:
- Домен хранения → Volume Group (VG). Домен хранения в zVirt на уровне хоста представлен как группа томов LVM.
- Диск ВМ (его слой / снимок) → Logical Volume (LV). Каждый слой диска (включая активный слой ActiveVM и слои снимков) соответствует отдельному логическому тому в LVM.
- ID диска (id) — это идентификатор диска в zVirt
- ID слоя (image_id) — соответствует конкретному LV и может изменяться при работе со снимками
Важно учитывать, что:
- у одной виртуальной машины может быть несколько дисков
- эти диски могут находиться в разных доменах хранения (то есть в разных VG)
Информация о дисках ВМ (lvdisplay)
Теперь посмотрим, как на хосте выглядит информация об идентификаторе снимка диска — то есть об активном слое диска виртуальной машины, который соответствует Logical Volume (LV). Для примера возьмем запущенную виртуальную машину pk-centos9-gp. Если ВМ запущена на том же хосте, где выполняется проверка, активный слой ее диска будет доступен как обычное блочное устройство в системе. Его путь будет иметь следующий вид lvdisplay ID_vg | grep ID_lv :
[root@zvirt-43-main-host1-pk ~]# lvdisplay 165151ea-24b7-4de3-a558-df31ccd2078c | grep 3b36d17e-6240-4546-b8e0-11a855b0f31c -A 15 -B 1
--- Logical volume ---
LV Path /dev/165151ea-24b7-4de3-a558-df31ccd2078c/3b36d17e-6240-4546-b8e0-11a855b0f31c
LV Name 3b36d17e-6240-4546-b8e0-11a855b0f31c
VG Name 165151ea-24b7-4de3-a558-df31ccd2078c
LV UUID bRgRUw-LRYV-82ve-Yiy3-Wzua-awCq-iUbDLQ
LV Write Access read/write
LV Creation host, time zvirt-43-main-host5-pk.work.test, 2025-10-01 11:24:12 +0300
LV Status available
# open 1
LV Size 35,00 GiB
Current LE 280
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 131056
Block device 253:51
Таблица 4. Описание вывода команды lvdisplay
| LV Size |
35,00 GiB |
Размер тома |
| Current LE |
280 |
В этом этом логическом томе (LV) - 280 логических экстентов (LE — Logical Extents). |
| Segments |
1 |
Том состоит из одного непрерывного сегмента (не разбит на несколько физических областей) |
| Allocation |
inherit |
Политика выделения пространства унаследована от группы томов. Это значит, что этот том использует те же правила распределения данных, что и его группа томов |
| Read ahead sectors - auto |
currently set to 131056 |
Эта настройка отвечает за то, как операционная система заранее читает данные с диска, чтобы ускорить работу. Система настроена так, чтобы при чтении данных заранее подгружать около 64 МБ информации (131056 секторов — это примерно 64 мегабайта (131056 × 512 байт ≈ 67 МБ)). Такая «предзагрузка» сильно ускоряет процесс, потому что диск не ждёт новых запросов, а уже имеет данные в памяти. |
| Block device |
253:51 |
Это внутренний «порядковый номер» этого тома в Linux. Логический том - устройство №51, управляемое драйвером №253. Проще говоря - /dev/dm-51 |
Если ВМ выключена (не запущена), то информация будет следующей:
[root@zvirt-43-main-host1-pk /]# lvdisplay 165151ea-24b7-4de3-a558-df31ccd2078c | grep 3b36d17e-6240-4546-b8e0-11a855b0f31c -A 15 -B 1
--- Logical volume ---
LV Path /dev/165151ea-24b7-4de3-a558-df31ccd2078c/3b36d17e-6240-4546-b8e0-11a855b0f31c
LV Name 3b36d17e-6240-4546-b8e0-11a855b0f31c
VG Name 165151ea-24b7-4de3-a558-df31ccd2078c
LV UUID bRgRUw-LRYV-82ve-Yiy3-Wzua-awCq-iUbDLQ
LV Write Access read/write
LV Creation host, time zvirt-43-main-host5-pk.work.test, 2025-10-01 11:24:12 +0300
LV Status NOT available
LV Size 35,00 GiB
Current LE 280
Segments 1
Allocation inherit
Read ahead sectors auto
Если в выводе LVM для логического тома указано состояние LV Status: NOT available, это означает, что том на текущем хосте не активирован. При этом его метаданные присутствуют в системе, но само блочное устройство в /dev/mapper/<VG>-<LV> не создано, поэтому доступ к содержимому тома на данном узле отсутствует. В случае zVirt это нормальная ситуация для кластерного окружения с общим хранилищем. Даже если виртуальная машина выключена, LVM-тома могут оставаться неактивированными на конкретном хосте до момента, когда они потребуются (например, при запуске ВМ или операции доступа к диску). При этом важно учитывать, что активация логических томов в кластере контролируется системой управления виртуализацией. LVM сам по себе не управляет распределением доступа между узлами — это делает zVirt, чтобы избежать конфликтов и обеспечить корректную работу с общими дисками.
Аналогичная информация будет и по другим LV (сделать ссылку на таблицу 1 и 2 ). Посмотрим информацию о диске sdb на ВМ pk-centos9-gp. Пример команды: lvdisplay ID_vg | grep ID_lv
[root@zvirt-43-main-host1-pk /]# lvdisplay 165151ea-24b7-4de3-a558-df31ccd2078c | grep e2f54f03-15ff-4f31-8e6b-aabbd6a96561 -A 15 -B 1
--- Logical volume ---
LV Path /dev/165151ea-24b7-4de3-a558-df31ccd2078c/e2f54f03-15ff-4f31-8e6b-aabbd6a96561
LV Name e2f54f03-15ff-4f31-8e6b-aabbd6a96561
VG Name 165151ea-24b7-4de3-a558-df31ccd2078c
LV UUID fWCgNd-eCTF-vPRw-4c1G-RXdx-gKOw-RzwAc2
LV Write Access read/write
LV Creation host, time zvirt-43-main-host1-pk.work.test, 2025-09-30 15:13:26 +0300
LV Status NOT available
LV Size 12,50 GiB
Current LE 100
Segments 2
Allocation inherit
Read ahead sectors auto
--- Logical volume ---
LV Path /dev/165151ea-24b7-4de3-a558-df31ccd2078c/3b36d17e-6240-4546-b8e0-11a855b0f31c
LV Name 3b36d17e-6240-4546-b8e0-11a855b0f31c
VG Name 165151ea-24b7-4de3-a558-df31ccd2078c
Посмотрим информацию о диске sdc на ВМ pk-centos9-gp:
[root@zvirt-43-main-host1-pk /]# lvdisplay 165151ea-24b7-4de3-a558-df31ccd2078c | grep c5046e63-0247-4aec-99b4-9cdef3431bcc -A 15 -B 1
--- Logical volume ---
LV Path /dev/165151ea-24b7-4de3-a558-df31ccd2078c/c5046e63-0247-4aec-99b4-9cdef3431bcc
LV Name c5046e63-0247-4aec-99b4-9cdef3431bcc
VG Name 165151ea-24b7-4de3-a558-df31ccd2078c
LV UUID 9BElCS-dD12-gReD-hNpd-Udlc-pdaH-nJbmjp
LV Write Access read/write
LV Creation host, time zvirt-43-main-host1-pk.work.test, 2025-09-30 14:05:06 +0300
LV Status NOT available
LV Size 10,00 GiB
Current LE 80
Segments 3
Allocation inherit
Read ahead sectors auto
--- Logical volume ---
LV Path /dev/165151ea-24b7-4de3-a558-df31ccd2078c/a22788a4-9341-4fe4-a82f-df67f86f77f6
LV Name a22788a4-9341-4fe4-a82f-df67f86f77f6
VG Name 165151ea-24b7-4de3-a558-df31ccd2078c
[root@zvirt-43-main-host1-pk /]#
Посмотрим информацию о диске на ВМ pk-win2019-gp:
[root@zvirt-43-main-host1-pk /]# lvdisplay 165151ea-24b7-4de3-a558-df31ccd2078c | grep a22788a4-9341-4fe4-a82f-df67f86f77f6 -A 15 -B 1
--- Logical volume ---
LV Path /dev/165151ea-24b7-4de3-a558-df31ccd2078c/a22788a4-9341-4fe4-a82f-df67f86f77f6
LV Name a22788a4-9341-4fe4-a82f-df67f86f77f6
VG Name 165151ea-24b7-4de3-a558-df31ccd2078c
LV UUID 0U9Tod-ViWC-cYTu-NBKR-jNXv-hAXh-Y4K2Cj
LV Write Access read/write
LV Creation host, time zvirt-43-main-host1-pk.work.test, 2025-09-30 14:05:49 +0300
LV Status NOT available
LV Size 15,00 GiB
Current LE 120
Segments 1
Allocation inherit
Read ahead sectors auto
Информация о дисках ВМ (qemu-img)
Перейдём к сбору и проверке информации о том, какой тип диска используется для виртуальной машины — RAW или QCOW2. Для этого необходимо, чтобы ВМ была запущена на том хосте, где выполняется проверка, так как доступ осуществляется напрямую к активному блочному устройству. Выполним команду для ВМ pk-centos9-gp (пример команды qemu-img info /dev/<VG_ID>/<IMAGE_ID>) В зависимости от типа диска результат команды qemu-img info будет отличаться. Рассмотрим два варианта.
Диск формата RAW (ВМ pk-centos9-gp, диск sda)
[root@zvirt-43-main-host1-pk /]# qemu-img info /dev/165151ea-24b7-4de3-a558-df31ccd2078c/3b36d17e-6240-4546-b8e0-11a855b0f31c
image: /dev/165151ea-24b7-4de3-a558-df31ccd2078c/3b36d17e-6240-4546-b8e0-11a855b0f31c
file format: raw
virtual size: 35 GiB (37580963840 bytes)
disk size: 0 B
В данном случае используется виртуальный диск формата RAW с заданным размером 35 ГБ. Параметр disk size равен 0 B, что является нормальным для блочного устройства LVM, так как фактическое потребление пространства не отражается на уровне qemu-img.
Диск формата QCOW2 (ВМ pk-centos9-gp, диск sdb)
[root@zvirt-43-main-host1-pk /]# qemu-img info /dev/165151ea-24b7-4de3-a558-df31ccd2078c/e2f54f03-15ff-4f31-8e6b-aabbd6a96561
image: /dev/165151ea-24b7-4de3-a558-df31ccd2078c/e2f54f03-15ff-4f31-8e6b-aabbd6a96561
file format: qcow2
virtual size: 30 GiB (32212254720 bytes)
disk size: 0 B
cluster_size: 65536
Format specific information:
compat: 1.1
compression type: zlib
lazy refcounts: false
refcount bits: 16
corrupt: false
extended l2: false
В этом случае диск использует формат QCOW2, который поддерживает дополнительные возможности, такие как сжатие, снапшоты и управление ссылками. Несмотря на это, в данном примере фактический размер также отображается как 0 B, так как данные хранятся на уровне LVM-блока, а не в файле образа.
Таблица 5. Описание вывода команды qemu-img info
| QCOW2 |
QEMU Copy-On-Write v2 — основной формат виртуальных дисков для QEMU/KVM. |
| 30 GiB |
Виртуальный размер диска, тот что видит гостевая ОС. |
| 0 B |
Для QCOW2, который находится на блочном устройстве, qemu-img не может определить реальное использование |
| cluster_size: 65536 |
Размер кластера (64 КБ). Это минимальная единица хранения в QCOW2 - данные и метаданные записываются блоками по 64 КБ |
| compat: 1.1 |
Версия формата QCOW2. 1.1. Поддерживает сжатие и другие улучшения |
| compression type: zlib |
Используется стандартное zlib-сжатие для уменьшения размера данных на диске |
| lazy refcounts: false |
Счётчик ссылок обновляется сразу. Если включить (true), QCOW2 работает быстрее при записи, но может потребовать qemu-img check после сбоя. false - это безопасный режим, при котором данные и снапшоты не потеряются даже при аварийном отключении, но записи идут чуть медленнее. |
| refcount bits: 16 |
На каждый кластер выделяется 16 бит для счётчиков ссылок |
| corrupt: false |
Диск не повреждён |
| extended l2: false |
Для небольшого диска (30 ГБ)расширенные таблицы не нужны. true - добавлялся ещё один уровень таблиц, чтобы адресовать очень большой диск (несколько ТБ) |
Диск формата QCOW2 (ВМ pk-centos9-gp, диск sdc)
[root@zvirt-43-main-host1-pk /]# qemu-img info /dev/165151ea-24b7-4de3-a558-df31ccd2078c/c5046e63-0247-4aec-99b4-9cdef3431bcc
image: /dev/165151ea-24b7-4de3-a558-df31ccd2078c/c5046e63-0247-4aec-99b4-9cdef3431bcc
file format: qcow2
virtual size: 70 GiB (75161927680 bytes)
disk size: 0 B
cluster_size: 65536
Format specific information:
compat: 1.1
compression type: zlib
lazy refcounts: false
refcount bits: 16
corrupt: false
extended l2: false
Диск формата QCOW2 (ВМ pk-win2019-gp)
[root@zvirt-43-main-host1-pk /]# qemu-img info /dev/165151ea-24b7-4de3-a558-df31ccd2078c/a22788a4-9341-4fe4-a82f-df67f86f77f6
image: /dev/165151ea-24b7-4de3-a558-df31ccd2078c/a22788a4-9341-4fe4-a82f-df67f86f77f6
file format: qcow2
virtual size: 75 GiB (80530636800 bytes)
disk size: 0 B
cluster_size: 65536
Format specific information:
compat: 1.1
compression type: zlib
lazy refcounts: false
refcount bits: 16
corrupt: false
extended l2: false
Чтобы посмотреть реальный размер диска, можно использовать команду lvs с дополнительными параметрами, актуальными для LVM thin pool: lvs -o+seg_monitor,segtype,data_percent | grep ….. <ID слоя диска> . Эта команда позволяет получить информацию о фактическом использовании логического тома на уровне LVM. Она применима в среде zVirt при работе с LVM.
[root@zvirt-43-main-host1-pk ~]# lvs -o+seg_monitor,segtype,data_percent | grep 3b36d17e-6240-4546-b8e0-11a855b0f31c
3b36d17e-6240-4546-b8e0-11a855b0f31c 165151ea-24b7-4de3-a558-df31ccd2078c -wi------- 35,00g linear
[root@zvirt-43-main-host1-pk ~]# lvs -o+seg_monitor,segtype,data_percent | grep e2f54f03-15ff-4f31-8e6b-aabbd6a96561
e2f54f03-15ff-4f31-8e6b-aabbd6a96561 165151ea-24b7-4de3-a558-df31ccd2078c -wi------- 12,50g linear
[root@zvirt-43-main-host1-pk ~]# lvs -o+seg_monitor,segtype,data_percent | grep c5046e63-0247-4aec-99b4-9cdef3431bcc
c5046e63-0247-4aec-99b4-9cdef3431bcc 165151ea-24b7-4de3-a558-df31ccd2078c -wi------- 10,00g linear
[root@zvirt-43-main-host1-pk ~]# lvs -o+seg_monitor,segtype,data_percent | grep a22788a4-9341-4fe4-a82f-df67f86f77f6
a22788a4-9341-4fe4-a82f-df67f86f77f6 165151ea-24b7-4de3-a558-df31ccd2078c -wi-ao---- 15,00g linear
Практика. Работа с Linux и предварительно размеченными дисками
Важно: для монтирования разделов на хост необходимо выключить ВМ
В текущем разделе будем проводить работы с предварительно размеченным диском sda на 35 GB.
Чтобы посмотреть информацию о диске на выключенной ВМ, предварительно необходимо активировать volume group, сделав все логические тома внутри нее доступными системе. Для этого выполним команду vgchange -ay <ID-домена-хранения> .
[root@zvirt-43-main-host1-pk ~]# vgchange -ay 165151ea-24b7-4de3-a558-df31ccd2078c
16 logical volume(s) in volume group "165151ea-24b7-4de3-a558-df31ccd2078c" now active
После выполнения команды мы увидим, что все «дочерние» LV будут доступны. Для работы с RAW дисками будем использовать инструмент losetup . Первоначально будем работать с разделом sda1 . Данная команда выберет первое свободное loop-устройство /dev/loopX и после подключения просканирует таблицу разделов и создаст устройства вида /dev/loopXp1 ... /dev/loopXpN :
[root@zvirt-43-main-host1-pk ~]# losetup -fP /dev/165151ea-24b7-4de3-a558-df31ccd2078c/3b36d17e-6240-4546-b8e0-11a855b0f31c
Посмотрим информацию о структуре дисков, типах файловых систем, разметку дисков:
[root@zvirt-43-main-host1-pk ~]# lsblk -f /dev/loop0
NAME FSTYPE LABEL UUID MOUNTPOINT
loop0
├─loop0p1 ext4 1b0d334f-7b6e-43e4-b164-8f3e5a42acb2
├─loop0p2 LVM2_member Ey6Ttp-O8vv-dvI5-244x-yyJL-M5GX-Tt8rMj
└─loop0p3 ntfs 1D3A26241322EE0A
[root@zvirt-43-main-host1-pk ~]# fdisk -l /dev/loop0
Диск /dev/loop0: 35 GiB, 37580963840 байт, 73400320 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт
Тип метки диска: gpt
Идентификатор диска: 8117552E-FF40-A448-9807-2B78C01BCD75
Устр-во начало Конец Секторы Размер Тип
/dev/loop0p1 2048 10487807 10485760 5G Файловая система Linux
/dev/loop0p2 10487808 25167871 14680064 7G Файловая система Linux
/dev/loop0p3 25167872 44042239 18874368 9G Файловая система Linux
Видим, что есть 3 раздела на диске. Произведем монтирование sda1 (файловая система ext4) в заранее созданный каталог. Далее посмотрим структуру файлов и создадим новый файл:
[root@zvirt-43-main-host1-pk ~]# mount /dev/loop0p1 /test01/centos_sda1
[root@zvirt-43-main-host1-pk ~]# ll /test01/centos_sda1/
итого 20
drwx------. 2 root root 16384 сен 30 15:21 lost+found
-rw-r--r--. 1 root root 10 окт 1 11:03 sda1.txt
[root@zvirt-43-main-host1-pk ~]# touch /test01/centos_sda1/sda1-new.txt
Аналогично проведём работы с sda2 . Т.к. там используется структура lvm и файловая система xfs, то для начала выясним имя physical volumes; список всех volume groups, собранных из физических томов; список «виртуальных разделов» внутри LVM:
Информация о физических томах
[root@zvirt-43-main-host1-pk ~]# pvs
PV VG Fmt Attr PSize PFree
/dev/loop0p2 preallocated-vg-7g lvm2 a-- <7,00g 0
Информация о группах томов
[root@zvirt-43-main-host1-pk ~]# vgs
VG #PV #LV #SN Attr VSize VFree
preallocated-vg-7g 1 1 0 wz--n- <7,00g 0
Информация о логических томах
[root@zvirt-43-main-host1-pk ~]# lvs
LV VG Attr LSize Pool Origin
preallocated_lv-7g preallocated-vg-7g -wi------- <7,00g
После активации всего домена хранения (эту операцию мы делали ранее - vgchange -ay <ID-домена-хранения> необходимо активировать нужный нам Volume Group (VG). Выполним активацию:
[root@zvirt-43-main-host1-pk ~]# vgchange -ay preallocated-vg-7g
1 logical volume(s) in volume group "preallocated-vg-7g" now active
После выполнения команды мы увидим, что все «дочерние» LV будут доступны.
Произведем монтирование /dev/preallocated-vg-7g/preallocated_lv-7g/ в заранее созданный каталог. Далее посмотрим структуру файлов и создадим новый файл:
[root@zvirt-43-main-host1-pk ~]# mount /dev/preallocated-vg-7g/preallocated_lv-7g /test01/centos_sda2
[root@zvirt-43-main-host1-pk ~]# ll /test01/centos_sda2
[root@zvirt-43-main-host1-pk ~]# touch /test01/centos_sda2/sda2-new.txt
Аналогично проведём работы с sda3 . На нем используется файловая система NTFS. Для работы с NTFS разделами в среде Linux необходимо установить пакет ntfs-3g
[root@zvirt-43-main-host1-pk ~]# dnf install ntfs-3g
Произведем монтирование устройства /dev/loop0p3 в заранее созданный каталог. Далее посмотрим структуру файлов и создадим новый файл:
[root@zvirt-43-main-host1-pk ~]# mount /dev/loop0p3 /test01/centos_sda3
[root@zvirt-43-main-host1-pk ~]# ll /test01/centos_sda3
[root@zvirt-43-main-host1-pk ~]# touch /test01/centos_sda3/sda3-new.txt
Подведем итог: мы успешно смогли записать файлы на диски с различными файловыми системами. При этом сами ВМ были выключены.
Практика. Работа с Linux и тонкие диски
Важно: для монтирования разделов на хост необходимо выключить ВМ
В текущем разделе будем проводить работы с тонким диском sdb на 30 GB. Посмотрим на работу с ОС Linux на ВМ pk-centos9-gp. Работаем с sdb1 разделом. Рассмотрим способ с использованием механизма NBD (Network Block Device). Для дальнейшей работы нам потребуется загрузить модуль ядра (драйвер) командой:
[root@zvirt-43-main-host1-pk ~]# modprobe nbd
# В случае успешной операции - вывод команды не содержит никаких сообщений
Далее qemu-nbd будет использовать драйвер nbd для создания блочных устройств и осуществления ввода/вывода при работе с ними. Создадим новое виртуальное устройство с использованием слоя диска. Подключим диск ВМ как сетевое блочное устройство/dev/nbd2.Для этого выполним команду:
[root@zvirt-43-main-host1-pk ~]# qemu-nbd -c /dev/nbd2 /dev/165151ea-24b7-4de3-a558-df31ccd2078c/e2f54f03-15ff-4f31-8e6b-aabbd6a96561
Посмотрим информацию о структуре дисков, типах файловых систем, разметку дисков:
[root@zvirt-43-main-host1-pk ~]# fdisk -l /dev/nbd2
Диск /dev/nbd2: 30 GiB, 32212254720 байт, 62914560 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт
Тип метки диска: gpt
Идентификатор диска: 0712C414-6EC7-5F46-9E8D-4AE9598DE0B7
Устр-во начало Конец Секторы Размер Тип
/dev/nbd2p1 2048 8390655 8388608 4G Файловая система Linux
/dev/nbd2p2 8390656 20973567 12582912 6G Файловая система Linux
/dev/nbd2p3 20973568 37750783 16777216 8G Файловая система Linux
[root@zvirt-43-main-host1-pk ~]# lsblk -f /dev/nbd2
NAME FSTYPE LABEL UUID MOUNTPOINT
nbd2
├─nbd2p1 ext4 74369740-c1b8-495e-b380-7ec5cfe9a14f
├─nbd2p2 LVM2_member EYj0DU-gEyQ-dcH0-gAbD-SqK1-fTKJ-41dUNT
│ └─dynamic--vg--6g-dynamic--lv--6g xfs 0087aa4b-3156-4c0e-ba4b-bbe0181b481c
└─nbd2p3 ntfs 45BDA74B7EEF4276
[root@zvirt-43-main-host1-pk ~]#
Видим, что есть 3 раздела на диске. Произведем монтирование nbd2p1 (файловая система ext4) в заранее созданный каталог. Далее посмотрим структуру файлов и создадим новый файл:
[root@zvirt-43-main-host1-pk ~]# mount /dev/nbd2p1 /test01/centos_sdb1
[root@zvirt-43-main-host1-pk ~]# ll /test01/centos_sdb1/
итого 20
drwx------. 2 root root 16384 окт 1 11:15 lost+found
-rw-r--r--. 1 root root 9 окт 1 11:16 sdb1.txt
[root@zvirt-43-main-host1-pk ~]# touch /test01/centos_sdb1/sdb1-new.txt
Аналогично проведём работы с sdb2 . Т.к. там используется структура lvm и файловая система xfs, то для начала выясним имя physical volumes; список всех volume groups, собранных из физических томов; список «виртуальных разделов» внутри LVM:
Информация о физических тома
[root@zvirt-43-main-host1-pk ~]# pvs
PV VG Fmt Attr PSize PFree
/dev/nbd2p2 dynamic-vg-6g lvm2 a-- <6,00g 0
Информация о группах томов
[root@zvirt-43-main-host1-pk ~]# vgs
VG #PV #LV #SN Attr VSize VFree
dynamic-vg-6g 1 1 0 wz--n- <6,00g 0
Информация о логических томах
[root@zvirt-43-main-host1-pk ~]# lvs
LV VG Attr LSize Pool Origin
dynamic-lv-6g dynamic-vg-6g -wi-a----- <6,00g
После активации всего домена хранения (эту операцию мы делали ране - vgchange -ay <ID-домена-хранения>) необходимо активировать нужный нам Volume Group (VG). Выполним активацию:
[root@zvirt-43-main-host1-pk ~]# vgchange -ay dynamic-vg-6g
1 logical volume(s) in volume group "dynamic-vg-6g" now active
Произведём монтирование /dev/dynamic-vg-6g/dynamic-lv-6g в заранее созданный каталог. Далее посмотрим структуру файлов и создадим новый файл:
[root@zvirt-43-main-host1-pk ~]# mount /dev/dynamic-vg-6g/dynamic-lv-6g /test01/centos_sdb2
[root@zvirt-43-main-host1-pk ~]# ll /test01/centos_sdb2
[root@zvirt-43-main-host1-pk ~]# touch /test01/centos_sdb2/sdb2-new.txt
Аналогично проведем работы с sdb3 . На нем используется файловая система NTFS. Для работы с NTFS разделами в среде Linux необходимо установить пакет ntfs-3g .
[root@zvirt-43-main-host1-pk ~]# dnf install ntfs-3g
Произведем монтирование устройства /dev/nbd2p3 в заранее созданный каталог. Далее посмотрим структуру файлов и создадим новый файл:
[root@zvirt-43-main-host1-pk ~]# mount /dev/nbd2p3 /test01/centos_sdb3
[root@zvirt-43-main-host1-pk ~]# ll /test01/centos_sdb3
[root@zvirt-43-main-host1-pk ~]# touch /test01/centos_sdb3/sdb3-new.txt
Подведем итог: мы успешно смогли записать файлы на диски с различными файловыми системами. При этом сами ВМ были выключены. Раздел sdc является загрузочным и в текущей статье мы не будем его рассматривать.
Практика. Работа с Windows
Важно: для монтирования разделов на хост необходимо выключить ВМ
В текущем разделе будем проводить работы с тонким диском на 75 GB. Посмотрим на работу с ВМ а базе Windows - pk-win2019-gp. Рассмотрим способ с использованием механизма NBD (Network Block Device). Для дальнейшей работы нам потребуется загрузить модуль ядра (драйвер) командой:
[root@zvirt-43-main-host1-pk ~]# modprobe nbd
# В случае успешной операции - вывод команды не содержит никаких сообщений
Далее qemu-nbd будет использовать драйвер nbd для создания блочных устройств и осуществления ввода/вывода при работе с ними. Активируем конкретный логический том (LV), относящийся к диску данной ВМ:
[root@zvirt-43-main-host1-pk ~]# lvchange -ay /dev/165151ea-24b7-4de3-a558-df31ccd2078c/a22788a4-9341-4fe4-a82f-df67f86f77f6
Создадим новое виртуальное устройство с использованием слоя диска. Подключим диск ВМ как сетевое блочное устройство/dev/nbd4.Для этого выполним команду:
[root@zvirt-43-main-host1-pk ~]# qemu-nbd -c /dev/nbd4 /dev/165151ea-24b7-4de3-a558-df31ccd2078c/a22788a4-9341-4fe4-a82f-df67f86f77f6
# В случае успешной операции - вывод команды не содержит никаких сообщений
Посмотрим информацию о структуре дисков, типах файловых систем, разметку дисков:
[root@zvirt-43-main-host1-pk ~]# fdisk -l /dev/nbd4
Диск /dev/nbd4: 75 GiB, 80530636800 байт, 157286400 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт
Тип метки диска: dos
Идентификатор диска: 0xabfdbb1a
Устр-во Загрузочный начало Конец Секторы Размер Идентификатор Тип
/dev/nbd4p1 * 2048 1126399 1124352 549M 7 HPFS/NTFS/exFAT
/dev/nbd4p2 1126400 157284351 156157952 74,5G 7 HPFS/NTFS/exFAT
[root@zvirt-43-main-host1-pk ~]# lsblk -f /dev/nbd4
NAME FSTYPE LABEL UUID MOUNTPOINT
nbd4
├─nbd4p1 ntfs Зарезервировано системой 2AFC250EFC24D63B
└─nbd4p2 ntfs 48F0284DF0284392
Видим, что есть 2 раздела на диске. Произведем монтирование nbd4p1 и nbd4p2 (файловая система ntfs) в заранее созданные каталоги. Далее посмотрим структуру файлов и создадим новый файл:
[root@zvirt-43-main-host1-pk ~]# mount /dev/nbd4p1 /test01/win_01
[root@zvirt-43-main-host1-pk ~]# cd /test01/win_01
[root@zvirt-43-main-host1-pk win_01]# ll
итого 417
drwxrwxrwx. 1 root root 8192 сен 30 12:23 Boot
-rwxrwxrwx. 1 root root 408840 янв 7 2022 bootmgr
-rwxrwxrwx. 1 root root 1 сен 15 2018 BOOTNXT
-rwxrwxrwx. 1 root root 8192 сен 30 12:23 BOOTSECT.BAK
drwxrwxrwx. 1 root root 0 сен 30 12:24 Recovery
drwxrwxrwx. 1 root root 0 сен 30 12:24 'System Volume Information'
[root@zvirt-43-main-host1-pk ~]# mount /dev/nbd4p2 /test01/win_02
[root@zvirt-43-main-host1-pk ~]# cd /test01/win_02
[root@zvirt-43-main-host1-pk win_02]# ll
итого 2490404
drwxrwxrwx. 1 root root 0 окт 1 10:39 '$Recycle.Bin'
lrwxrwxrwx. 2 root root 20 сен 30 12:25 'Documents and Settings' -> /test01/win_02/Users
-rwxrwxrwx. 1 root root 2550136832 окт 8 17:38 pagefile.sys
drwxrwxrwx. 1 root root 0 янв 7 2022 PerfLogs
drwxrwxrwx. 1 root root 4096 окт 1 10:17 ProgramData
drwxrwxrwx. 1 root root 4096 окт 1 09:47 'Program Files'
drwxrwxrwx. 1 root root 4096 янв 7 2022 'Program Files (x86)'
drwxrwxrwx. 1 root root 0 сен 30 12:25 Recovery
drwxrwxrwx. 1 root root 4096 окт 1 10:54 'System Volume Information'
drwxrwxrwx. 1 root root 4096 окт 1 10:38 Users
drwxrwxrwx. 1 root root 16384 окт 8 14:02 Windows
[root@zvirt-43-main-host1-pk win_02]# touch win_02-new.txt
Подведем итог: мы успешно смогли записать файлы на диски ОС Windows с файловой системой NTFS. При этом сама ВМ была выключена.
Практика. Возврат в исходное состояние
После выполнения всех действий по добавлению файлов на ВМ вернем все в исходное состояние. Выясним все блочные устройства, у которых есть точка монтирования в /test01/:
[root@zvirt-43-main-host1-pk win_02]# lsblk | grep test01
├─loop0p1 259:3 0 5G 0 loop /test01/centos_sda1
│ └─preallocated--vg--7g-preallocated_lv--7g 253:54 0 7G 0 lvm /test01/centos_sda2
└─loop0p3 259:5 0 9G 0 loop /test01/centos_sda3
├─nbd2p1 43:65 0 4G 0 part /test01/centos_sdb1
│ └─dynamic--vg--6g-dynamic--lv--6g 253:55 0 6G 0 lvm /test01/centos_sdb2
└─nbd2p3 43:67 0 8G 0 part /test01/centos_sdb3
├─nbd4p1 43:129 0 549M 0 part /test01/win_01
└─nbd4p2 43:130 0 74,5G 0 part /test01/win_02
Отмонтируем все, смонтированное в /test01/*
[root@zvirt-43-main-host1-pk ~]# cd ~
[root@zvirt-43-main-host1-pk ~]# umount /test01/*
Изменим состояние Volume Group (VG), деактивировав все VG принудительно:
[root@zvirt-43-main-host1-pk ~]# vgchange -an --force preallocated-vg-7g
0 logical volume(s) in volume group "preallocated-vg-7g" now active
[root@zvirt-43-main-host1-pk ~]# vgchange -an --force dynamic-vg-6g
0 logical volume(s) in volume group "dynamic-vg-6g" now active
Посмотрим список loop devices с помощью команды losetup -a и удалим все loop devices , которые сейчас настроены (deallocate all).
[root@zvirt-43-main-host1-pk ~]# losetup -a
/dev/loop0
[root@zvirt-43-main-host1-pk ~]# losetup -D
[root@zvirt-43-main-host1-pk ~]# losetup -a
Отключим все NBD устройства:
[root@zvirt-43-main-host1-pk ~]# qemu-nbd -d /dev/nbd2
/dev/nbd2 disconnected
[root@zvirt-43-main-host1-pk ~]# qemu-nbd -d /dev/nbd4
/dev/nbd4 disconnected
Деактивируем LV (Logical Volume):
[root@zvirt-43-main-host1-pk ~]# lvchange -an /dev/165151ea-24b7-4de3-a558-df31ccd2078c/3b36d17e-6240-4546-b8e0-11a855b0f31c
[root@zvirt-43-main-host1-pk ~]# lvchange -an /dev/165151ea-24b7-4de3-a558-df31ccd2078c/e2f54f03-15ff-4f31-8e6b-aabbd6a96561
[root@zvirt-43-main-host1-pk ~]# lvchange -an /dev/165151ea-24b7-4de3-a558-df31ccd2078c/c5046e63-0247-4aec-99b4-9cdef3431bcc
[root@zvirt-43-main-host1-pk ~]# lvchange -an /dev/165151ea-24b7-4de3-a558-df31ccd2078c/a22788a4-9341-4fe4-a82f-df67f86f77f6
Проверим, что подключенных нами устройств нет в списке:
[root@zvirt-43-main-host1-pk ~]# lsblk
Перед началом работы с LVM мы отключали использование файла с фиксированным списком устройств. Вернём эту настройку обратно. Для этого откроем конфигурационный файл LVM:
nano /etc/lvm/lvm.conf
И установим следующий параметр:
use_devicesfile = 1
На этом процесс возврата в исходное состояние завершён корректно. Вы можете запустить ВМ и проверить, что все файлы были успешно созданы.-Источник
