Похоже, что я могу успешно выполнить pvcreate поверх необработанного блочного устройства, даже не делая шага по созданию таблицы разделов. Затем я могу создать группу томов, логический том и, наконец, файловую систему, смонтировать ее и протестировать через dd.
Кажется, работает, но мне нужно проверить работоспособность. Это плохая идея?
Как создать таблицу разделов GPT или MBR поверх необработанного блочного устройства?
Как использовать parted, чтобы показать, какая таблица разделов используется? Я пробовал делать:
parted, выберите / dev / sdb, распечатайте и я получаю:
Ошибка: / dev / sdb: нераспознанная метка диска
Тем не менее, диск в настоящее время используется, и я могу читать и писать на нем. Это ожидаемый результат при выполнении LVM поверх необработанного блочного устройства без таблицы разделов? Есть предположения?
Спасибо!
Даже если сам LVM не заботится о реальном разделе, одна из причин его создания - это сообщить программам разбиения, что «там что-то есть». Кошмарный сценарий - это новый системный администратор, который диагностирует проблему загрузки на сервере, запускает программу разбиения на разделы, видит неразмеченные диски и приходит к выводу, что диск поврежден.
Я не вижу недостатков в создании раздела LVM. Вы?
Хотя вы можете просто создать pv из необработанного блочного устройства, я обычно стараюсь избегать этого, поскольку это может вызвать путаницу относительно того, для чего используется блочное устройство. Это также может нарушить некоторые из подпрограмм автоматического обнаружения, которые LVM может использовать, если ему не хватает файлов конфигурации.
Вот пример использования parted для создания GPT с 1 разделом, который представляет собой весь диск, и установкой флага раздела равным lvm. Mkpart требует, чтобы вы указали файловую систему, но не создает файловую систему. Вроде бы давний баг в parted. Также начальное смещение в 1 м необходимо для обеспечения правильного выравнивания.
parted /dev/sdb
mklabel GPT
mkpart primary ext2 1M 100%
set 1 lvm on
Если вы создаете PV непосредственно на виртуальном запоминающем устройстве внутри гостевой KVM, то вы заметите, что логические тома гостевой системы видны на гипервизоре. Это может сильно запутать, если вы используете одни и те же имена логических томов и групп томов для нескольких гостей. Вы также можете получить некоторые предупреждения на гипервизоре о том, что он не может найти устройство.
Например, я воссоздал эту проблему на своем тестовом гипервизоре:
[root@testhost ~]# vgs
Couldn't find device with uuid dCaylp-1kvL-syiF-A2bW-NTPP-Ehlb-gtfxZz.
VG #PV #LV #SN Attr VSize VFree
vg_main 2 2 0 wz-pn- 19.25g 768.00m
vg_main 2 2 0 wz-pn- 19.25g 768.00m
vg_testhost 1 8 0 wz--n- 237.98g 120.15g
Здесь вы можете увидеть 2 группы томов с одинаковыми именами, обе от гостей, которые не должны отображаться на гипервизоре.
По этой причине я бы посоветовал вам сначала использовать parted или fdisk для создания там раздела KVM (как показано в предыдущем ответе 3dinfluence), прежде чем создавать PV и добавлять его в группу томов. Таким образом, гостевые логические тома остаются скрытыми от гипервизора.
Одним из недостатков является невозможность горячего добавления пространства к PV внутри таблицы разделов. Это не проблема, если вы используете все блочное устройство для PV.
Согласно руководству LVM от RedHat, раздел 4.2.1 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/logical_volume_manager_administration/physvol_admin
Они сказали, что нет необходимости иметь таблицу разделов, они даже предлагают нам уничтожить ее, если мы будем использовать весь диск для VG (группа томов), если только мы не собираемся включать только ее части (раздел).
Даже если в прошлом я использовал метку диска MS-DOS или метку диска GPT для PV, теперь я предпочитаю использовать LVM напрямую на основном блочном устройстве. Нет причин использовать 2 метки диска, если только у вас нет очень специфического варианта использования (например, диск с загрузочным сектором и загрузочным разделом).
Преимущества наличия LVM напрямую: